The NYC subway fare is $2.90. I was using PCalc on iOS to step through remaining MetroCard values per swipe and discovered that AC, 8.7, m+, 2.9, m-, m-, m- evaluates to -8.881784197E-16 instead of zero. This doesn't happen when using Apple's calculator. I wrote to the developer and he replied, "Apple has now got their own private maths library which isn't available to developers, which they're using in their own calculator. What I need to do is replace the Apple libraries with something else - that's on my list!"
I wrote the calculator for the original blackberry. Floating point won't do. I implemented decimal based floating point functions to avoid these rounding problems. This sounds harder than it was, basically, the "exponent" part wasn't how many bits to shift, but what power of two to divide by, so that 0.1, 0.001 etc can be represented exactly. Not sure if I had two or three digits of precision beyond whats on the display. 1 digit is pretty standard for 5 function calculators, scientific ones typically have two.
It was only a 5 function calculator, so not that hard, plus there was no floating point library by default so doing any floating point really ballooned the size of an app with the floating point library.
The JVM based devices came years later. This was around 1998, with the 386 based blackbery pager that could only do emails over Mobitex, no phone calls. It even looked like a pager. At the time, phones were not so dominant, data switched over mobile only existed on paper, and two-way paging looked like it had a future. So we totally killed the crude 2-way paging networks that were out there. And RIM successfully later made the transition to phone networks. Wasn't till iPhone and android that RIM ran into trouble.
Sounds like he's just using stock math functions. Both Javascript and Python act the same way when you save the result immediately after subtracting two numbers multiple times, rather than just 8.7 - (2.9*3).
