The NumWorks graphing calculator

Posted Sep 28, 2017 18:51 UTC (Thu) by davidstrauss (guest, #85867)
Parent article: The NumWorks graphing calculator

I have to say: I'm disappointed that it's not relying on a more established system like GNU Octave or, better, one with symbolic processing. Precise number storage can only go so far to getting perfect results for situations where you take a square root and then square the result. Symbolic processing can yield the correct result more reliably.

The NumWorks graphing calculator

Posted Sep 28, 2017 19:39 UTC (Thu) by jmspeex (subscriber, #51639) [Link] (4 responses)

Note that in octave, sqrt(2)^2-2 gives me 4.4409e-16, which is 2^-51

The NumWorks graphing calculator

Posted Sep 29, 2017 8:52 UTC (Fri) by davidstrauss (guest, #85867) [Link] (1 responses)

I'm not suggesting that Octave is perfect, just that it would be nicer to handle issues like this within Octave. Comparatively few people will benefit from fixing the code behind this calculator.

The NumWorks graphing calculator

Posted Sep 29, 2017 9:38 UTC (Fri) by njd27 (subscriber, #5770) [Link]

I presume that basing the calculator software on GPL code wouldn't have suited their licensing goals.

The NumWorks graphing calculator

Posted Sep 30, 2017 7:08 UTC (Sat) by madhatter (subscriber, #4665) [Link] (1 responses)

For clarification, I should add that the issue is solely with the accuracy of the carried-forward Ans token, representing the answer to an earlier calculation, since that's only evaluated to 7 sig fig. The internal accuracy of the NumWorks is far higher: arcsin(arccos(arctan(tan(cos(sin(9)))))) returns 9 (in degrees mode), as it should: even my TI84+ returns 8.99999997.

That said, (sqrt(2))²-2 also returns 4.440892x10^-16, while the TI84+ returns 0.

The NumWorks graphing calculator

Posted Oct 2, 2017 16:31 UTC (Mon) by davidstrauss (guest, #85867) [Link]

My point is that, for any given level of accuracy/precision, there's arithmetic you can feed it that will reveal its deficiencies. If the goal is to cleanly have the "square" and "square root" operations neutralize each other, that requires symbolic processing to be reliable. Otherwise, it's just a question of how far you can stretch the implementation before it breaks, and non-symbolic systems tend to break that way silently. Such systems yield results that are very close to the proper one but with bewildering notation (like the ones in the article).