Nicholas Clark wrote:
If one has floating point in the mix [and however much one uses rationals, and has the parser store all decimal string constants as rationals, floating point enters the mix as soon as someone wants to use transcendental functions such as sin(), exp() or sqrt()], I can't see how any implementation that wants to preserve "infinite" precision for as long as possible is going to work, apart fromstoring every value as a thunk that holds the sequence of operations that were used to compute the value, and defer calculation for as long as possible. (And possibly as a sop to efficiency, cache the floating point outcome of evaluating the thunk if it gets called)
Floating point has no effect on this. A float is just a syntax for an exact rational. What you're talking about mostly is how an exact irrational would be represented, symbolically. The result of an exact numeric sin() etc would be a symbolic number, and it is only when you separately explicitly convert it to a rational does any rounding and loss occur, and it would be the rounding operation itself that has extra parameters to control the rounding. Alternately, an inexact numeric sin() that results in an exact rational is just a wrapper over the last 2 operations combined, and it takes rounding-control parameters. I see no problem here. -- Darren Duncan
