It does return the correct value for sin(π) though (you gotta call __sinpi(x / M_PI) if you don't want to return -8.74e-8 or some ridiculous value).
It does return the correct value for sin(π) though (you gotta call __sinpi(x / M_PI) if you don't want to return -8.74e-8 or some ridiculous value).
This is ridiculous. Your calculator (most calculators) cannot apply sin to π, because π is not representable is their system (typically base-2 or base-10 floating-point).
What you have done here is make sine worse for all values, including the representable value closest to π, in order to obtain what you think is a cosmetically satisfying result for the latter. Note that seeing the closest representable value to π does not mean that the user intended π. Perhaps the user obtained this value as the result of a computation and it's a coincidence. Or perhaps the user really wants to know what the sine of 0x1.921fb54442d18p+1 (the double closest to π) is. Hint: it is not zero.
Casio scientific calculators do have an internal representation of π (it's treated differently from the closest possible typed value) and very nuanced representations of numbers in general.
As you say, this is where calculator apps almost inevitably fail - representing numbers properly is really crucial to the UX, and floating point numbers are not sufficient.
Casios are a mess. They are actually made my Kinpo which do a shitty job of pretty much everything. The notable exceptions being the FX991MS and Fx5800P which are very very close to my 50g (which was laboriously tested on paper before I trusted it)
50g is basically a 48GX emulator with 400MHz ARM core that emulates Saturn, MetaKernel and a CAS. Goes like lightning. Oh and a bigger screen so you get 7-9 stack lines. Also you can use SD cards as ports. Mine has 256Mb of Flash. Eats a set of batteries once a month but it's worth it for the power.
I can create a symbolic list with 50,000 entries in quite happily on the device then do all standard two-variable stats on it in 1-2 seconds.
I should clarify for other readers: __sinpi() is an Apple-created addition to Math.h, what it does is multiply the argument by M_PI before calculating. When you consider that my calculator has a key which inputs the constant pi (which is, of course, not actually pi, but M_PI), it all comes out in the wash (cosmetically speaking).
However, what would you do instead? Test before each trig function whether the argument is a multiple of M_PI and then choose which function to use? I would imagine this would fall apart at higher values...
Also consider that 'cosmetically satisfying' is not an unreasonable goal (in my mind) when the calculator really only has horizontal space for 12 digits in 36-point Helvetica, but you're right, as the user could arrive at arbitrary values by other means.