[LIL'BUG?] Signed Zero?

[Yincognito]

The simplest skin ever:

Code: Select all

[SignedZero]
Measure=Calc
Formula=(0*(-1))
OnUpdateAction=[!SetVariable SignedZero (0*(-1))]
DynamicVariables=1

[Text]
Meter=String
SolidColor=255,255,255,255
FontSize=16
MeasureName=SignedZero
Text="%1#CRLF#[SignedZero]#CRLF##SignedZero#"
DynamicVariables=1

Is there any reason why Rainmeter creates a whole new number, aka the signed zero, other than to makes us believe we've discovered a new numerical system and beg for the creation of a Nobel Prize for Mathematics?

P.S. I'm not sure if fixing this would be entirely useful in the case of measures, since one can easily remove the - in front of 0 via a Substitute for its string value and having the "sign of zero" could provide us with a hint regarding the sign of the other operands that 0 was multiplied (or divided?) with, but in the case of a measure's numerical values or a variable, there isn't such a workaround available...

EDIT: Just discovered a (pretty obvious, after all) workaround to remove the negative sign before zero: add another zero to the result. So, (0*(-1)) would become (0*(-1)+0). I'm guessing this could work using subtraction as well. It's funny that adding more zeros to the mix corrects the issue regarding zeros in the first place, but hey, no wonder zero is a special number, right?

[Yincognito]

Ok, it seems the workaround I discovered doesn't work in all situations, like in the sample skin below (which is close to my actual usage scenario):

Code: Select all

[Variables]
Step=10

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

---Measures---

[Rotation]
Group=RotationGroup
Measure=Calc
Formula=((360+Rotation+#Step#)%360)
DynamicVariables=1

[Latitude]
Group=RotationGroup
Measure=Calc
Formula=(-180/PI*Asin(Sin(Rotation*PI/180))+0)
;Formula=(((Rotation+90)%180-90)*(1-2*(Trunc((Rotation+270)/180)%2))+0)
DynamicVariables=1

[Longitude]
Group=RotationGroup
Measure=Calc
Formula=(180-(Rotation+180)%360)
DynamicVariables=1

[Signed]
Group=RotationGroup
Measure=Calc
Formula=((Rotation+180)%360-180)
DynamicVariables=1

---Meters---

[Text]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=Rotation
MeasureName2=Latitude
MeasureName3=Longitude
MeasureName4=Signed
Text="Rotation  = %1#CRLF#Latitude  = %2#CRLF#Longitude = %3#CRLF#Signed    = %4"
LeftMouseUpAction=[!TogglePauseMeasureGroup RotationGroup][!UpdateMeter *][!Redraw]
DynamicVariables=1

The skin simply converts a 0° to 360° rotation angle into its equivalent in latitude (-90° to 90°) and longitude (-180° to 180°) coordinates, as well as to the signed -180° to 180° interval. When I apply the "+0" workaround to remove the "-" in front of "0" as described above, only my previous (((Rotation+90)%180-90)*(1-2*(Trunc((Rotation+270)/180)%2))+0) formula properly yields the normal, unsigned 0, with the workaround failing when applied to my current (and shorter) (-180/PI*Asin(Sin(Rotation*PI/180))+0) formula. In this case, the skin incorrectly converts the 0° and 180° rotations to -0 (instead of plain 0) for both the numeric and the string value of the measure:

SignedZero.jpg

For the record, there isn't any "near zero but not quite zero" value that would justify the sign in front of a, say, -0.00000001 or such. It's just the raw zero that for some reason carries the negative sign in front of it when it shouldn't.

So, it looks like a fix is in fact needed for this, especially since I use the numerical value of the measure, on which I can't apply the (string value typical) Substitute to remove the unwanted / incorrect negative sign in front of the 0...

[jsmorley]

You might want to use Abs(SomeValue)

[death.crafter]

You might want to use Abs(SomeValue)

That would change sign of negative values too

[Yincognito]

You might want to use Abs(SomeValue)

Thought about that, but while it solves the "-0" issue, it has the unwanted effect of changing the sign of my other non-zero values as well. The (Sgn(SomeValue)*Abs(SomeValue)) or (Sgn(SomeValue)*Abs(SomeValue)+0) variations don't work either, at least not fully (i.e. they might remove the sign in front of the 0 on one instance but leave it there in another).

P.S. Death.crafter mentioned the same thing.

[jsmorley]

Thought about that, but while it solves the "-0" issue, it has the unwanted effect of changing the sign of my other non-zero values as well. The (Sgn(SomeValue)*Abs(SomeValue)) or (Sgn(SomeValue)*Abs(SomeValue)+0) variations don't work either, at least not fully (i.e. they might remove the sign in front of the 0 on one instance but leave it there in another).

P.S. Death.crafter mentioned the same thing.

Formula=( (0*(-1)) = -0 ? 0 : (0*(-1)) )

[Yincognito]

Formula=( (0*(-1)) = -0 ? 0 : (0*(-1)) )

LMAO, yeah ... well, at least it's a short workaround, so I guess I'll take it. Or I'll just let the "-0" as it is, after all I don't mind it that much, it was more for the sake of consistency. Thanks, I'll surely use this method if I find the signed 0 too inconvenient.

EDIT: Actually, it's not a short workaround at all, since my:

Code: Select all

(-180/PI*Asin(Sin(Rotation*PI/180)))

becomes:

Code: Select all

((-180/PI*Asin(Sin(Rotation*PI/180))=-0)?0:(-180/PI*Asin(Sin(Rotation*PI/180))=-0))

Basically, it doubles the length of the formula. The longer the formula, the longer the workaround. Now I really miss that "+0" workaround working, hahaha!

---------------------------
UPDATE: The workaround doesn't work for my formula though:

Code: Select all

Formula=(((-180/PI*Asin(Sin(Rotation*PI/180)))=-0)?(0):(-180/PI*Asin(Sin(Rotation*PI/180))))

This is despite the fact that for Rotation = 180, calculation steps are quite straightforward:

Code: Select all

Sin(Rotation*PI/180) = Sin(180*PI/180) = Sin(PI) = 0
Asin(Sin(PI)) = Asin(0) = 0
-180/PI*Asin(0) = -180/PI*0 = -57.29578 * 0 = 0

I understand that trigonometric functions yield fractional numbers so getting a precise value is somewhat tricky, but it's odd...

[Yincognito]

Formula=( (0*(-1)) = -0 ? 0 : (0*(-1)) )

Just for fun, a couple of other things I discovered, for Rotation = 180 or Rotation = 0, just like before:

Code: Select all

Formula=(-180/PI*Asin(Sin(Rotation*PI/180)))
; this, i.e. my original formula, gives -0
Formula=(180/PI*(-Asin(Sin(Rotation*PI/180))-1+1))
; this gives the same -0
Formula=(-180/PI*Asin(Sin(Rotation*PI/180))-2+2)
; this gives -0 too
Formula=(180/PI*(-Asin(Sin(Rotation*PI/180))-2+2))
; this finally gives 0
Formula=(180/PI*(-Asin(Sin(Rotation*PI/180))+2-2))
; but hold on ... swapping -2 and +2 from above again gives -0 for Rotation = 180, yet 0 for Rotation = 0 !!!

Notice the subtle differences in the syntax of the formulas, aka the positioning of the round brackets, of the - sign, or the amount added and subtracted - but also the perfect equivalence between the formulas - and how they give either the same or a different result. Something interesting is happening here - maybe related to the interval the functions give values in?

[sl23]

Sorry for interrupting, I just had to say, it made me giggle reading the conversation about equations! Sorta reminded me of Big Bang Theory! What's funny is that I am completely clueless as to what the heck you lot are on about!!!

[Yincognito]

Sorry for interrupting, I just had to say, it made me giggle reading the conversation about equations! Sorta reminded me of Big Bang Theory! What's funny is that I am completely clueless as to what the heck you lot are on about!!!

Yep, well, I did intend the conversation to have a fun side from the start, because after all the whole "-0" occurrence is kind of funny ... as long as one can use a workaround that actually works.

It's not much about this other than, to put it as simple as possible, if you multiply, say, 0 with -1, our lovely Rainmeter will yield -0 instead of plain 0. Basically it will leave a (negative) sign where there should be none. It doesn't affect the result of other calculations, but it can be a bit inconvenient if you want to display that result to the user. The kind of user that panics when he sees a "normal" log error in Rainmeter would probably incorrectly think there's something wrong with the calculations after seeing this...