[BUG/SUGGESTION] Inverted and negative low and high values in Clamp function

[Yincognito]

This has been bugging me for a long time, and I'm not sure if it's a classic bug, a weird feature or just something that would better classify as a suggestion for the future, so I'll just mention it here:

Code: Select all

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1

---Measures---

[GoodClamping]
Measure=Calc
Formula=Clamp(125,100,10)

[BadClamping]
Measure=Calc
Formula=Clamp(-125,100,10)

---Meters---

[Result]
Meter=String
SolidColor=0,0,0,255
FontColor=255,255,255,255
MeasureName=GoodClamping
MeasureName2=BadClamping
Text=Good clamping = %1#CRLF#Bad clamping = %2
DynamicVariables=1

Notice the value of the "bad clamping" and compare it with the "good clamping". I know the low and high values in the clamp function are reversed and neither is an actual "good" clamping since the order is invalid, but this is intentional, first to showcase the issue and second because it can be a "real world" scenario. For example, scrolling:

Code: Select all

[Variables]
TxtG=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10#CRLF#11#CRLF#12#CRLF#13#CRLF#14#CRLF#15#CRLF#16#CRLF#17#CRLF#18#CRLF#19#CRLF#20#CRLF#21#CRLF#22#CRLF#23#CRLF#24#CRLF#25#CRLF#26#CRLF#27#CRLF#28#CRLF#29#CRLF#30
TxtB=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10
OffsetY=0

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1

---Meters---

[ContainerVisible]
Meter=Image
W=100
H=242
SolidColor=0,0,0,255
MouseScrollUpAction=[!SetVariable OffsetY (Clamp(#OffsetY#+16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable OffsetY (Clamp(#OffsetY#-16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]
DynamicVariables=1

[Container]
Meter=Image
W=100
H=242
SolidColor=0,0,0,255

[Text]
Container=Container
Meter=String
FontFace=Tahoma
FontSize=10
Y=#OffsetY#
FontColor=255,255,255,255
Text=#TxtG#
DynamicVariables=1

Replace the value of the Text option in [Text] with #TxtB# and you'll realize what I mean. I know I can further clamp stuff or use conditionals to make it behave properly, but there is also the possibility of making it behave "correctly" by fixing the "bug" in the first place, and avoid making the formula unnecessarily longer. Unless, of course, the "bug" is some kind of feature to "toggle" between the invalid ordered low and high values...

P.S. Not sure about backward compatibility on this one, but I find it hard to believe someone would use the strange results of this case in a skin. I'm also not 100% sure of how a fix should be implemented, e.g. which value to choose between the invalid low and the invalid high ones. Hopefully you'll see this a bit clearer than I do at this time.

[Brian]

I'll be honest...I have no idea what the issue here.

I know the low and high values in the clamp function are reversed and neither is an actual "good" clamping since the order is invalid, but this is intentional, first to showcase the issue and second because it can be a "real world" scenario.

The order is invalid...or in other words, you aren't using the function correctly. The manual clearly states:

Clamp(x, low, high): Restricts value x to low and high limits.

The low is the second parameter. The high is the third.

Are you suggesting that Rainmeter determine which of those two parameters is lowest and highest, then restrict x based on that?

-Brian

[Yincognito]

Are you suggesting that Rainmeter determine which of those two parameters is lowest and highest, then restrict x based on that?

I thought of that, but I think that would be undesirable in about half the cases, where you actually want the function to not work, given that the "low" value is in this case greater than the "high" value. That was the purpose of the "real world" scenario.

I guess the point I was trying to make here is that in the case of such invalid order, the behavior of the function is inconsistent (i.e. sometimes it's choosing the "low" value aka the 2nd parameter, sometimes it's choosing the "high" value aka the 3rd parameter, in effect toggling between them in a somewhat arbitrary fashion).

Ideally, it should react "the same", or at least according to some logic, when the order is invalid. I just don't know what that logic should be, hence not being able to suggest an "expected" behavior and appealing to someone who can see things clearer in that regard.

Anyway, if you think otherwise, it's no problem. I was just trying to see if there was a way to avoid letting the user cover the possibility of the "low" being greater than the "high" by making the formulas longer, that's all.

P.S. Don't worry about the honesty, I always prefer it.

[Brian]

the behavior of the function is inconsistent

There is where I am lost. What exactly is inconsistent with the results of the clamp function? As far as I can tell, it is behaving exactly as described.

Clamp is just shorthand for: (x < low) ? low : ((x > high) ? high : x).

Here is your 2nd example with some extra visuals to show the values in clamp:

Code: Select all

[Variables]
TxtG=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10#CRLF#11#CRLF#12#CRLF#13#CRLF#14#CRLF#15#CRLF#16#CRLF#17#CRLF#18#CRLF#19#CRLF#20#CRLF#21#CRLF#22#CRLF#23#CRLF#24#CRLF#25#CRLF#26#CRLF#27#CRLF#28#CRLF#29#CRLF#30
TxtB=1#CRLF#2#CRLF#3#CRLF#4#CRLF#5#CRLF#6#CRLF#7#CRLF#8#CRLF#9#CRLF#10
OffsetY=0

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1

---Meters---

[ContainerVisible]
Meter=Image
W=100
H=242
SolidColor=0,0,0,255
MouseScrollUpAction=[!SetVariable OffsetY (Clamp(#OffsetY#+16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable OffsetY (Clamp(#OffsetY#-16.1,[Container:H]-[Text:H],0))][!UpdateMeter *][!Redraw]
DynamicVariables=1

[Container]
Meter=Image
W=100
H=242
SolidColor=0,0,0,255

[Text]
Container=Container
Meter=String
FontFace=Tahoma
FontSize=10
Y=#OffsetY#
FontColor=255,255,255,255
Text=#TxtB#
DynamicVariables=1


[X]
Measure=Calc
Formula=#OffsetY#+16.1
DynamicVariables=1

[Low]
Measure=Calc
Formula=[Container:H]-[Text:H]
DynamicVariables=1

[High]
Measure=Calc
Formula=0
DynamicVariables=1

[ClampInfo]
Meter=String
FontFace=Tahoma
FontSize=9
X=30
FontColor=255,255,255,255
Text=X=[X]#CRLF#Low=[Low]#CRLF#High=[High]#CRLF#OffsetY:#OffsetY#
DynamicVariables=1

When I scroll down, the result changes the offset to 81 (seems correct to me). When I keep scrolling down, it stays at 81.

Code: Select all

First time:
  X = 0  - 16.1  = -16.1
  OffsetY = (-16.1 < 81) ? 81 : (-16.1 > 0) ? 0 : -16.1    =  81
Second time:
  X = 81 - 16.1  =  64.9
  OffsetY = ( 64.9 < 81) ? 81 : ( 64.9 > 0) ? 0 :  64.9    =  81

When I scroll up, the result "toggles" between 0 and 81 because of the formula.

Code: Select all

First time:
  X = 0  + 16.1  = 16.1
  OffsetY = (16.1 < 81) ? 81 : (16.1 > 0) ? 0 : 16.1    =  81
Second time:
  X = 81 + 16.1  = 97.1
  OffsetY = (97.1 < 81) ? 81 : (97.1 > 0) ? 0 : 97.1    =  0

-Brian

[Yincognito]

There is where I am lost. What exactly is inconsistent with the results of the clamp function? As far as I can tell, it is behaving exactly as described.

Clamp is just shorthand for: (x < low) ? low : ((x > high) ? high : x).

You're right, mathematically (which, after all, is the whole purpose of the function), it all happens correctly, and there's no inconsistency. I guess I was referring more to the perceived inconsistency in terms of the expected result from a user perspective, where the result "should" have stayed on just one of the interval's boundaries in the case of such an invalid order, without any toggling (for this scrolling example, that boundary would be 0, but in other cases it might be the other one, aka 81).

But then, indeed, it's difficult to know which of the boundaries should the function stay at when the order of arguments is invalid, since it also depends on the direction of incrementing / decrementing. In the end letting the simple math and the conditionals do their job is probably better.

Sorry for bothering you with this and for the lack of clarity here. Some things are better left as they are, can't expect a function to read minds or figure out the desired result, at least not without complicating it further. Thanks for sharing your clear view on this, much appreciated!