Hacker News Reader

Comment by pascal_cuoq | Hacker News Reader

> 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.

View on HN

> because π is not representable is their system (typically base-2 or base-10 floating-point).

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.

Spot on. This is one reason I still use my 50g - it uses decimal internal representation with known precision on every operation.

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)

I favor the 48GX with several modifications. I have a library that gives me 5 stack lines, but also shows a symbolic representation. In other words, typing "5 6 /" is represented as "5/6" rather than a decimal equivalent. If you multiply that by 2, my calculator maintains the symbolic representation as "(5/6)*2". By retaining values as symbolic representation for as long as possible, when you finally evaluate, it will result in "5/3". This is great for when things cancel out and it allows me to carry precision further since I'm not working with approximations. I can also request the decimal representation at any time. This is what no other calculator app is giving me.

The 50g already does that as it has a built in CAS so symbolic is default. This are represented in their rational form or with respect to pi.

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.

Phooey, I thought I'd solved this. What would you recommend I do instead?

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.

Nailed it. Nice to see someone who understands the situation properly.

Reply on news.ycombinator.com