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.
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.
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.)
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.
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?)
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.
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.
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".
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.
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.
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.
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°.
It's better to start from the parent page otherwise you're missing all context:
https://www.rskey.org/~mwsebastian/miscprj/forensics.htm
This is where this post should probably point, IMHO.
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
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.
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/
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
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.
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
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.
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.
I was with you until I remembered the default unit for angles in calculators is degrees, not radians.
The page also specifies it's degrees mode.
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.
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°.
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)