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

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.


Attachment: signature.asc
Description: Digital signature

Reply via email to