On Mar 24, 2012, at 6:36 PM, Stefan O'Rear <stefa...@cox.net> wrote: > On Sat, Mar 24, 2012 at 06:16:58PM -0700, Jonathan Lang wrote: >> IMHO: if we're going to take loss of precision into account, we should do so >> explicitly. I'm a bit rusty, so forgive me if I misuse the terminology: if >> a number has an epsilon, the epsilon should be attached to it as a trait so >> that it can be accessed by the program. This allows all sorts of things, >> like "close enough" smart-matching and error propagation. The main question >> is if Perl should assign a minimum epsilon to all floats by default, or if >> this should be an "all's fair if you predeclare" type of thing. > > Speaking as an implementor, I think this is quite unlikely. Some of my > reasons: > > 1. Interval arithmetic (this is the correct technical term) is very > inefficient on some popular architectures. > > 2. After a long computation which is numerically stable *but which Perl > cannot _prove_ the stability of*, error bounds will be very large, and > if smart-matching automatically takes them into account, it will tend > to result in extremely suprising false positives
I'll concede that these two (especially the second one) are sufficient arguments against the "default epsilon" idea, rendering my disagreement on the third point largely moot. That said: > 3. Adding hidden state to numbers that is not visible by default will make > debugging harder. Not hiding the state will make output much noisier. That's why I was suggesting making epsilon available as a trait (e.g., something like "5 but error(.01)"): if you need it, it would be easy to look it up; if you don't need it, it would be easy to ignore it. > Larry is free to override this of course. Also, interval arithmetic ought > to be possible as a module. Absolutely, it would be possible as a module. And with your second point above, it ought to be a module, to be explicitly applied when the programmer wants to use interval arithmetic.
