[BUGS] AutoScale Stuff

[Yincognito]

Skin:

Code: Select all

[Variables]
Value=0.599

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[String]
Measure=String
String=#Value#
DynamicVariables=1

[Number]
Measure=Calc
Formula=#Value#
DynamicVariables=1

---Meters---

[Result]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=Number
MeasureName2=String
AutoScale=2
NumOfDecimals=0
Text="Result for Number = %1#CRLF#Result for String = %2"
MouseScrollUpAction=[!SetVariable Value (#Value#+1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Value (#Value#-1)][!UpdateMeasure *][!UpdateMeter *][!Redraw]
LeftMouseUpAction=[!SetVariable Value (#Value#+Sgn(#Value#)*1000)]
MiddleMouseUpAction=[!SetVariable Value (#Value#-Sgn(#Value#)*1000)]
DynamicVariables=1

Effects:

- string values are not scaled, but maybe this is intentional
- scrolling between -10 to 10 values, you'll see how 1 is skipped, and of course there is also a -0 there as well
- if you left click on it while on a negative value, you'll see that negative values are not scaled, unlike when left clicking on a positive value

P.S. Middle click reverts to the lower (positive or negative) values, for conveniency.
P.S.S. Curiously, for Value >= 0.6 and Value < 1, the 1 is not skipped, so it seems the rounding to 1 is done at 0.6 instead of 0.5? Why? By the way, this happens when displaying [Number:/1000,0] where the result becomes 1 once it hits 600 and not 500 (or even 501)...

EDIT: Found out what might be an explanation for rounding from 0.6 instead of 0.5 here, but apart form being a behavior inherited from C++ / C# and unfeasible to modify, it doesn't seem to sit well with the common understanding of it...

[Brian]

Huh, this is a really weird bug. After digging around, it seems Microsoft "tweaked" floating point precision at some point during the Windows 2004 (May 2020) update.

A bug was reported to Microsoft a few months later, but was mistakenly marked as a "duplicate", even though the specific issue is different.
https://developercommunity.visualstudio.com/t/printf-rounding-bug-in-C-runtime-version/1197890?space=62&q=0.6#page-content

After some testing, this bug seems to only effect the classic C printf functions specifically using "0" precision (0 decimal places), and seems to only effect those values between 0.5 to 0.6. Unfortunately we use these functions all over the place in the code, so fixing this will get tricky.

-Brian

[Yincognito]

Huh, this is a really weird bug. After digging around, it seems Microsoft "tweaked" floating point precision at some point during the Windows 2004 (May 2020) update.

A bug was reported to Microsoft a few months later, but was mistakenly marked as a "duplicate", even though the specific issue is different.
https://developercommunity.visualstudio.com/t/printf-rounding-bug-in-C-runtime-version/1197890?space=62&q=0.6#page-content

After some testing, this bug seems to only effect the classic C printf functions specifically using "0" precision (0 decimal places), and seems to only effect those values between 0.5 to 0.6. Unfortunately we use these functions all over the place in the code, so fixing this will get tricky.

-Brian

Yep, I imagine you do use them in lots of places. Sorry for giving you more work with this, hopefully a good solution will be found eventually. If not, I can't say I'm troubled much in my skins regarding this, and I have my own logarithmic autoscale as a backup anyway (since Round() seems to do things properly), the issue came up when trying to help here.

[Brian]

Ok, so after some back and forth with Microsoft over this issue, I think we finally have fixed the issue.

If you could test this version out, that would be helpful.
https://builds.rainmeter.net/test_builds/Rainmeter-4.5.14.3635-prerelease.exe

-Brian

PS - Not sure I totally answered the "string" value part of the question, but numeric strings never use Autoscale or any numeric modifications since they are....well, strings. Rainmeter prefers the string value over the number value in most cases, so if you want the number value, you have to specifically use the number value section variable.

[Yincognito]

Ok, so after some back and forth with Microsoft over this issue, I think we finally have fixed the issue.

If you could test this version out, that would be helpful.
https://builds.rainmeter.net/test_builds/Rainmeter-4.5.14.3635-prerelease.exe

-Brian

PS - Not sure I totally answered the "string" value part of the question, but numeric strings never use Autoscale or any numeric modifications since they are....well, strings. Rainmeter prefers the string value over the number value in most cases, so if you want the number value, you have to specifically use the number value section variable.

Ok, I tested the version a bit, it works well for the most part now. I'm ok with not doing this for strings (as doing so will produce other side effects I reckon, though using section variable parameters limits scaling to hardcoded fixed values) or having the ugly -0 inherited from C++ (since a substitution can easily get rid of that, visually). The scaling now works fine, going up or down from "50 + 1" so to speak, e.g. 1.5___1 becomes 2 and so on, and although I'm personally used to go up from "50 + 0" in everyday life, I perfectly understand the reasons and it's certainly better than before - nice job!

There would be one last thing to mention here, and that is scaling 999.5___1 to 1 k instead of letting it be plain unscaled 1000 (similar for negatives or multiples). Not sure if there's a reason why it is left unscaled, but I've seen this for a long time in my skins, where I'd need to take one extra character into account (if I used the scaling by 1000, which I don't, as bytes and everything else are scaled by 1024) just for this one instance of 4 digits instead of 3. From my POV, it should be ... 997, 998, 999, 1 k, 1 k, 1k ... instead of ... 997, 998, 999, 1000, 1 k, 1k ... as it is now, to keep the displayed digits limited to 3 in this case and of course performing the scaling at all times without exceptions. What do you think about it?

[Brian]

What do you think about it?

This happens because the scaling happens before the rounding. So, when you see 1000, the actual value is 999.5___1, and since it is not yet over 1000, no scaling happens. Then the result is rounded to get the final output, which in this case, means 999.5___1 is rounded to 1000.

Not sure there is another way around this with NumOfDecimals=0.

-Brian

[Yincognito]

This happens because the scaling happens before the rounding. So, when you see 1000, the actual value is 999.5___1, and since it is not yet over 1000, no scaling happens. Then the result is rounded to get the final output, which in this case, means 999.5___1 is rounded to 1000.

Not sure there is another way around this with NumOfDecimals=0.

-Brian

You know, I initially wanted to mention this order of operations as a possible reason for the entire thing, before eventually settling for mentioning the rounding systems in the link from my first post - looks I had the right hunch, after all.

Well, this is just making you aware of the things I noticed, in the end I guess we can live with this since there's no other / easy solution to it. I'm sure you realize though that logically, the order should be the reverse: rounding before scaling. Whether reverting the order is not feasible in terms of the underlying code, that's another matter.