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.
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.
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°.
https://www.rskey.org/~mwsebastian/miscprj/forensics.htm
This is where this post should probably point, IMHO.