Calculator Forensics (2002)(rskey.org)
rskey.org
Calculator Forensics (2002)
https://www.rskey.org/~mwsebastian/miscprj/results.htm
43 comments
Couldn't resist checking what math.h does for floats and doubles on godbolt, it returns slightly above 9, but curiously not exactly equal to any answer in that list [1]. Maybe not that surprising, these transcendental functions are always iffy in the last digits.
[1]: https://godbolt.org/z/dK85Eq8r6
[1]: https://godbolt.org/z/dK85Eq8r6
I would be really surprised if any physical calculator used binary floating point numbers instead of binary-coded decimal. The appearance of repeating bits even for relatively simple decimal numbers like 0.1 is likely to confuse and annoy a calculator user expecting an exact answer.
I would assume most basic calculators use regular floating point circuits, and then just round aggressively for the display.
Microcontrollers with floating point hardware are very expensive (60¢ and up) compared to microcontrollers without (3¢), and since the 01980s, software floating point has been plenty fast enough to use in pocket calculators, even on the slowest microcontrollers available.
To be somewhat concrete, on amd64 with valgrind --tool=callgrind my non-BCD decimal fixed-point RPN calculator program https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.... compiled for the console (rpncalc_linux.c) takes 228,141 instructions to process the input "2 3q" from the keyboard, and 229,824 instructions to process the input "2 3/q", an additional 1,683 instructions for the division, mostly to display the result. Division is probably the worst case for regular arithmetic. An additional division operation takes another 1,601 instructions. A subtraction instead takes 1,563.
On an 8-bit processor like a PIC or AVR, you need to run more instructions to do the same work, but it's typically maybe a factor of 8 for data processing and less for things like looping. So we're talking about maybe 10,000 instructions per keystroke, probably less. On a 16MHz 1T microcontroller, that's less than a millisecond.
You might think that if the microcontroller doesn't have space for floating-point circuitry it also doesn't have space for enough memory for software floating point, but that would be wrong. My decimal floating point library is 1204 bytes (≈602 instructions) compiled for AVR, and the calculator UI logic is 2134 bytes (≈1067 instructions). This fits in all but the smallest microcontrollers. Like, it doesn't quite fit in an ATTiny25.
To be somewhat concrete, on amd64 with valgrind --tool=callgrind my non-BCD decimal fixed-point RPN calculator program https://gitlab.com/kragen/bubbleos/tree/master/yeso/rpncalc.... compiled for the console (rpncalc_linux.c) takes 228,141 instructions to process the input "2 3q" from the keyboard, and 229,824 instructions to process the input "2 3/q", an additional 1,683 instructions for the division, mostly to display the result. Division is probably the worst case for regular arithmetic. An additional division operation takes another 1,601 instructions. A subtraction instead takes 1,563.
On an 8-bit processor like a PIC or AVR, you need to run more instructions to do the same work, but it's typically maybe a factor of 8 for data processing and less for things like looping. So we're talking about maybe 10,000 instructions per keystroke, probably less. On a 16MHz 1T microcontroller, that's less than a millisecond.
You might think that if the microcontroller doesn't have space for floating-point circuitry it also doesn't have space for enough memory for software floating point, but that would be wrong. My decimal floating point library is 1204 bytes (≈602 instructions) compiled for AVR, and the calculator UI logic is 2134 bytes (≈1067 instructions). This fits in all but the smallest microcontrollers. Like, it doesn't quite fit in an ATTiny25.
Cheap calculators use microcontroller-like CPUs which simply have no room for floating-point hardware. BCD or fixed-point integers in software are much cheaper and simpler.
CORE-MATH provides correctly rounded transcendental functions. (Though that doesn't mean that this calculation will return exactly 9. And I haven't tried it.)
https://core-math.gitlabpages.inria.fr/
https://core-math.gitlabpages.inria.fr/
chalk it up to floating point accuracy
Forensics? Have these calculators committed a crime (against numerical analysis)?
I think it's forensic in the sense that, should you perform this operation on an unknown calculator, this chart could be used to identify it.
On second thought what you'd probably do is identify the chipset of a calculator.
I think you'd identify the "OS" of a calculator. For example, HP famously had lots of long, complex, highly accurate algorithms in its firmware. They could reuse large portions of that between different models, regardless of the hardware executing it.
For sure. I was imagining that the software would be pretty thin and the FP behavior would be primarily a function of chipset, but I stand corrected.
If they have, this site has their fingerprints.
Failure to identify an identity! Straight to calculator jail!
This is a good way to find out what fugitive chip an unknown calculator is harboring.
It would be nice to see an update. HP Prime? TI Nspire series? Swissmicros? Numworks? (the numworks app gives 9, but are the algorithms hardware-independent?)
Wolfram alpha result - https://www.wolframalpha.com/input?i=arcsin+%28arccos+%28arc...
3pi - 9
= 0.42477796076937971538793014983850865259150819812531746292483377692344921885
3pi - 9
= 0.42477796076937971538793014983850865259150819812531746292483377692344921885
This is the result if you do it in radians, but the test actually requires that you set the calculator to degrees mode first.
Note that all of the inverse trig functions are multivalued because the trig functions are periodic. Here, Wolfram Alpha is giving you one of the possible answers. The entire family of answers should be +/-9 + n*pi for any integer n; the sign on the 9 is due to cos being an even function.
Note that all of the inverse trig functions are multivalued because the trig functions are periodic. Here, Wolfram Alpha is giving you one of the possible answers. The entire family of answers should be +/-9 + n*pi for any integer n; the sign on the 9 is due to cos being an even function.
irb(main):012> Math.asin(Math.acos(Math.atan(Math.tan(Math.cos(Math.sin(9*Math::PI/180))))))*180/Math::PI
=> 9.00000000000001
Numerically difficult since intermediate values end up close to a local maximum of cos
[deleted]
Nice. Checked on a Commodore SR-37, produces the same result as the SR-36 per the site. (9.08210803 Commodore SR-36)
I always wonder... if there was an AGI and it's chipset gave the wrong answer, how would it ever know?
The neural networks we use today have really terrible accuracy, and we tend to make them worse, not better, as having more neurons is better than having more precision. Human brains are also a mess, but somehow, they work, and we are usually able to correct our own mistakes.
Since by AGI, we usually mean human-like, that system should be able to self correct the same way we do.
Since by AGI, we usually mean human-like, that system should be able to self correct the same way we do.
How do humans know? usually someone corrects someone else. we have repeatability in physics, or we wait 30 years and quash convictions etc. etc.
I'd presume it could reason around the wrong answer, at least to realize something was off. Current LLMs will sometimes hallucinate that this has happened when they're "thinking".
So what's the correct answer?
9 degrees. arcsin(arccos(arctan(tan(cos(sin(9)))))) basically makes a set of sin-cos-tan layers that arctan-arccos-arcsin unwrap one-by-one, which should result in nothing having changed, unless the functions used weren't accurate.
That's incorrect, you have to choose the proper inverse branch if you want the answer to be 9.
There is no choice here - each inverse is uniquely determined. That's similar to how 3 and -3 are both square roots of 9 (i.e., solutions to x^2=9), but sqrt(9)=3 as it denotes the principal square root, which by convention is always the non-negative value. Of course, in a different context we might design functions to have multi-valued properties, like atan2(x,y) != atan(y/x) in general (atan2 takes quadrant in account and returns full range [-pi, pi], atan only returns principal values in [-pi/2, pi/2]) as practical applications benefit from preserving quadrant beyond just the principal inverse (or not failing when x=0!)
The inverse branches are not unique, you might think there is no choice being made but picking the standard branch is a choice b/c I can always shift the result by 2π by picking a different branch of the inverse. The answer is not unique & the assumption is that the calculators are using the standard branch.
Of course, but the choice is standard and thus the answer is 9. I can define a non-standard sqrt(x) which sometimes gives the positive root and sometimes the negative one, and then sqrt(sqrt(16)) could be -2 or undefined (if I defined sqrt(16)=-4) but that's just silly - the only reasonable interpretation for what the calculator should show for sqrt(sqrt(16)) is simply 2.
Yes, that's what those functions do.
You can assume that sin(9) is within the range of all the functions that are post-composed w/ it so what you end up w/ in the end is arcsin(sin(9)). Naively you might think that's 9 but you have to be careful b/c the standard inverse branch of sin is defined to be [-1, 1] → [-π/2, π/2].
Edit: The assumption is that the calculators are using specific branches of the inverse functions but that's still a choice being made b/c the functions are periodic there are no unique choices of inverse functions. You have to pick a branch that is within the domain/range of periodicity.
Edit: The assumption is that the calculators are using specific branches of the inverse functions but that's still a choice being made b/c the functions are periodic there are no unique choices of inverse functions. You have to pick a branch that is within the domain/range of periodicity.
arcsin(arccos(arctan(tan(cos(sin(9)))))) = 9 (in degrees mode - when regular trig functions output pure numbers, those numbers get interpreted as degrees for the next function and similar for inverses - calculator style), because each intermediate lands in the principal-value domain of the next inverse (e.g., arctan(tan(x)) = x when x \in (-90°, 90°) and the intermediates happen to be in those ranges). Specifically, sin(9°) ≈ 0.156434, cos(0.156434°) ≈ 0.999996, arctan(tan(0.999996°)) = 0.999996°, arccos(0.999996)≈0.156434°, arcsin(0.156434)≈9°.
[deleted]
Didn't expect to see this site here. From time to time I show this site to young guys.
Disappointed in the HP-48.
thanks for sharing!
Previously:
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=42757455 - Jan 2025 (1 comment)
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=28561298 - Sept 2021 (19 comments)
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=7682045 - May 2014 (2 comments)
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=42757455 - Jan 2025 (1 comment)
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=28561298 - Sept 2021 (19 comments)
Calculator Forensics (2002) - https://news.ycombinator.com/item?id=7682045 - May 2014 (2 comments)
https://www.rskey.org/~mwsebastian/miscprj/forensics.htm
This is where this post should probably point, IMHO.