Calculator Forensics (2002)
Posted4 months agoActive3 months ago
rskey.orgTechstory
calmmixed
Debate
40/100
Calculator ForensicsNumerical AnalysisComputational Accuracy
Key topics
Calculator Forensics
Numerical Analysis
Computational Accuracy
The post shares a 2002 analysis of various calculators' accuracy in computing a complex mathematical expression, sparking discussion on numerical analysis, computational accuracy, and the evolution of calculators.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3d
Peak period
40
Day 4
Avg / period
20.5
Comment distribution41 data points
Loading chart...
Based on 41 loaded comments
Key moments
- 01Story posted
Sep 18, 2025 at 2:43 PM EDT
4 months ago
Step 01 - 02First comment
Sep 21, 2025 at 3:55 PM EDT
3d after posting
Step 02 - 03Peak activity
40 comments in Day 4
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 30, 2025 at 5:24 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45293438Type: storyLast synced: 11/20/2025, 6:45:47 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Since by AGI, we usually mean human-like, that system should be able to self correct the same way we do.
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.
[1]: https://godbolt.org/z/dK85Eq8r6
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.
https://core-math.gitlabpages.inria.fr/
3pi - 9
= 0.42477796076937971538793014983850865259150819812531746292483377692344921885
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.
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.