Yohanes Santoso wrote:

> Clearly, symbolic computation is complicated. It is _unrealistic_ to
> expect this algorithm to be implemented within CPU due to its
> complexity and resource consumption (processing power, memory,
> etc). It is also unreasonable to expect ruby to implement this as ruby
> is a generic programming language, not a mathematician's best friend
> like Mathlab.

Ah, yes.  This is the veritably crux of the matter.

Generic programming isn't required to be mathematically correct.  It isn't 
even /expected/ to be mathematically correct.  Why, if you're a popular CPU 
maker, you don't even feel that it's necessary for your floating point math 
to even be generally /accurate/. ;-)

This is what I find interesting.  I must reitterate that I'm inclined to 
agree that Ruby is correct in following IEE 754 rather than Mathematica; it 
is unfortunate, but necessary.  It doesn't negate the fact that I think the 
whole situation is rather silly and -- to be honest -- sloppy.  And 
unintuitive.

> undefined operation. But here in lies the subtle point: one undefined
> does not equal to another undefined. So, ruby/CPU got this correct by
> coincidence.

> So, mathematically, lim x->0[(-1/x) * 100] != lim x->0[(-1/x) *
> (1/x)]. In this case, ruby is wrong because this should be false:
> 
> irb(main):005:0>  (-1/0.0) * 100 == (-1/0.0) * (1/0.0)
> true

And

irb(main):073:0> (0/0.0) == (0/0.0)
true
irb(main):074:0> (1/0.0) == (1/0.0)
true


> But since ruby is a general programming language, it serves two
> different population: those who care about the mathematical
> correctness of a calculation (slow) and those who don't (fast). If

Right.

-- 
 |..  "Put your hand on a hot stove for a minute and it seems like an
<|>    hour.  Sit with a pretty girl for an hour and it seems like a
/|\    minute.  THAT's relativity."
/|    -- Albert Einstein
 |