**Skin**:

Code: Select all

```
[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=47,47,47,255
---Measures---
[Value]
Measure=Calc
Formula=Log(1-Frac(4294967295.999))
---Meters---
[Result]
Meter=String
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
MeasureName=Value
NumOfDecimals=5
Text=Value = %1
UpdateDivider=-1
DynamicVariables=1
```

**Issue**:

- the result should be -3.00000 and not -3.00003 (see the Rainmeter log too)

**Notes**:

- both Frac(4294967295.999) and 1-Frac(4294967295.999) yield the correct results, i.e. 0.999 and 0.001

- because of that, Log() of the above should yield the integral -3 or -3.00000, just like the plain Log(0.001) does

- if I remove 2 digits to make Formula=Log(1-Frac(42949672.999)), the result is correct, but becomes less precise the larger the number

- this is not limited to the Log() function, it occurs when similar many digits values (e.g. around 14 or 15, like 1234567890.12345) are used in computations

- it looks like a floating point range issue (somewhat normal), I just wonder if it can be avoided, and if so, what's the range that guarantees correct results

**P.S.**I think I touched some related subjects in the past, just can't remember which of them included floating point imprecision out of a certain range.

**EDIT**: Curiously, the issue also happens if I break the 1 Calc measure into 2 Calc measures (despite the value of the 1st being reasonable), e.g.:

I think it would be nice if we'd be able to get the correct result in a single Calc measure instead of using all kinds of tricks to force it to be correct.