Front page | perl.perl6.language |
Postings from March 2012
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. 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. Larry is free to override this of course. Also, interval arithmetic ought to be possible as a module. -StefanThread Previous | Thread Next