[BUG] Miscalculation

[Yincognito]

Simple bug - check the result of this measure in Rainmeter (426.40156 via the log):

Code: Select all

[Test]
Measure=Calc
Formula=(256*Exp(-((420-(480+410)/2)/((480-410)/2))**2))

then see if it matches the Google calculator one (153.695498547 returned):

Code: Select all

(256*exp(-((420-(480+410)/2)/((480-410)/2))**2))

So... what's going on here? I mean, sure, loss of precision and such, but that much of a difference is not normal. For example, if you change the 420 to 500, it should yield around 21.66, yet it gives... 3024.69! By the way, it's probably related to negative powers, since if I use the (256/Exp(((Number-(480+410)/2)/((480-410)/2))**2)) equivalent, it works properly.

Note: in case you wonder, I'm just trying to adjust one of my color transition / spectrum skin variants to provide the RGB based on the wavelength:

Spectrum.svg.png

[balala]

Simple bug - check the result of this measure in Rainmeter (426.40156 via the log):

Not sure this is a bug, but might be. In any case the difference resides on how Rainmeter treats the rising to power of an expression. In your formula the **2) power is applied to all expression, including the following marked minus: (256*exp(-((420-(480+410)/2)/((480-410)/2))**2)). In Google Calculator, the rising to power applies ONLY to the expression included to the parenthesis and the result is multiplied by -1.
To get the same result modify the formula to something like this: (256*exp(-1*((420-(480+410)/2)/((480-410)/2))**2)). This way you get the same result, because this time the rising to power doesn't apply to -1 anymore.

[Yincognito]

Not sure this is a bug, but might be. In any case the difference resides on how Rainmeter treats the rising to power of an expression. In your formula the **2) power is applied to all expression, including the following marked minus: (256*exp(-((420-(480+410)/2)/((480-410)/2))**2)). In Google Calculator, the rising to power applies ONLY to the expression included to the parenthesis and the result is multiplied by -1.
To get the same result modify the formula to something like this: (256*exp(-1*((420-(480+410)/2)/((480-410)/2))**2)). This way you get the same result, because this time the rising to power doesn't apply to -1 anymore.

Your fix works indeed (same with inserting a 0 before the minus), but it shouldn't even need to be used:
- first, the corresponding brackets don't include the - in the first place: ( 256 * exp ( - ( (420 - (480 + 410) / 2) / ( (480 - 410) / 2) ) ** 2))
- secondly, the raise to power operator should have precedence anyway over the minus one, according to both classic math and expression syntax rules
Even if we assume for the sake of the argument that the two points above are both false ... this way in which Rainmeter currently treats the rising to power of an expression isn't documented anywhere, as far as I can tell.

P.S. Since when the bracket after the power tells a program what to raise to that power, instead of the bracket before the power?

[Yincognito]

To further isolate the problem, currently, (-1**2) is incorrectly equivalent to ((-1)**2) and yields 1, but should actually be equivalent to (-(1**2)) and yield -1, based on how math works.

Found out why this happens as well, it's hilarious. Apparently, the poor makers of C++ (who are otherwise worthy of praise for creating one of the fastest and efficient programming languages) thought of rewriting BASIC mathematics and let the unary + and - have higher precedence than all of the remaining operations, including multiplication, division, addition and subtraction.

Even error prone Javascript thought of giving an error when writing console.log(-1**2); cause ... it's "ambiguous", despite the vast majority of the other languages (and Google too) correctly setting multiplication to have higher precedence than both the "unary" nonsense (is that even an operation?) or the subtraction. Here's a little discussion about this from people who actually went to school - needless to say, while everybody accepts this behavior (cause they have no other choice, of course), nobody really gets it WHY.

So, let's call this an accepted / intentional - but clearly incorrect - C++ behavior. It has nothing to do with Rainmeter, but because Rainmeter was programmed in C++, it inherited both its strengths and its flaws, intentional or not. The way things are going, looks like one day folks would even argue whether 1+1 equals 2 or 3...