Is my vision that bad? No, it's just a bug in Apple's Calculator

A friend doing homework for a university assignment, circa Leopard or Snow Leopard, noticed that Calculator produced negative values when raising a negative number to an even power.

The bug turned out to be in CFNumber, in Core Foundation. CFNumber does a lot of fiddly stuff at the bit level for performance, and one of their optimizations for exponentiation was incorrect. Somehow it was never found by tests or due to buggy behaviors it created in other apps, but by someone clicking buttons and thinking critically about the output.

In Excel (and some other languages), unary minus has higher precedence than exponentiation, so that -x^2 = (-x)^2 = x^2. That can bite you (for example when calculating the normal probability density function “manually”).

Interesting, I started playing with spotlight and typing in (-20)^21 returns " = 0", which is obviously not correct.

And typing in "(-22)^21" gives "-71100888972574851072", but wolfram alpha insists it should be "-15519448971100888972574851072".

Looks like there are still bugs here.

The Windows 3.1 calculator has a fun bug where 2.01 - 2.00 returns the result of 0.00, not 0.01.

That always amused me.

Maybe they never had proper tests. Something as simple as exponentiating,which is a basic functionality of any modern calculator, not working for 50% of all integers? That looks to me like no one ever really tested that stuff.

Acording to https://en.wikipedia.org/wiki/Windows_Calculator#Windows_9x_..., the Win98 version of calc.exe got an arbitrary-precision math library for basic math functionality to fix this sort of problem.

also mentioned by Raymond Chen, https://devblogs.microsoft.com/oldnewthing/20040525-00/?p=39... :

"Today, Calc’s internal computations are done with infinite precision for basic operations (addition, subtraction, multiplication, division) and 32 digits of precision for advanced operations (square root, transcendental operators)."

And they fixed the square-root-of-a-perfect-square bug a few years ago, https://www.reddit.com/r/Windows10/comments/89s53g/microsoft...

Spotlight on Sequoia looks correct, though it limits precision more than wolfram alpha.

(-20)^21 = -2.097152x10^27 and (-22)^21 = -1.5519448971*10^28

Wow that's bizarre.

At first I thought it was just an overflow error but no it's nothing like that. The math is indeed very clearly broken, as I play around with it on Sonoma on my M1.

I'm genuinely shocked. I though this kind of floating-point math was rock-solid, tested thoroughly over the decades.

There must be a way to do a mash-up between a spreadsheet and other languages like FORTRAN. Perhaps the language could be pluggable. You could mix and match and the spreadsheet formulas are the glue. Cell values abstract away the details of how that value got there. But, it accepts a refresh request.

Are there languages where this isn’t the case?

Python for one, and given that, I'd assume most languages.

No bug in Big Sur spotlight:

"(-20)^21" = -2.097152e27 "(-22)^21" = -1.551944897e28

almost all of them?

Hah,

macOS Sonoma 14.6.1 on M1 = 0

iOS 17.6.1 = -0

WTF.

Standard mathematical notation?

Can this be true? Does the calculator have any irrational number? What if I enter PI * 2? Infinite precision, wouldn't that mean running until your RAM is full? Or would it simply work, because no irrational number is calculated to infinite (as many as the device could) digits and is therefore finite and can easily be multiplied?

Or another even simpler case: If division is infinite precision, and I enter (2/3) * X, does the calculator internally work with fractions? Otherwise it would have infinite digits to compute.

It's arguably ambiguous.

In the UK at least if you don’t put the parentheses you will get flagged for a ‘bidmas error’ because indexes (exponentiation) have higher precedence than multiplication

Source: have made this mistake. Have been flagged.

Yes, it looks like spotlight math is broken on both.

For 2/3, it does indeed work with fractions internally. For pi, it uses some floating point representation I think, you get about 50 digits.

Shouldn’t

    -3²

be the same as

    0-3²

?

Not necessarily. E.g. 2*-3 is not the same as 2*0-3.

I learnt this in NZ as bedmas.

Brackets, exponents, division, multiplication, addition, subtraction.

Bedmas, Christmas in bed!

For PI, calc.exe, in scientific mode, returns 3.1415926535897932384626433832795 which is 32 digits of precision (33 chars if you include the decimal pt).