Re: left-right (up-down) parsing may lead to over/underflow of prod

[Rolf Fabian]

> I see 2 argument against this (but I'm not sure how strong they really
> are)
> 1. speed -- you need to calc the logs of the N numbers you are
> planning to multiply. I am not sure exactly how slow it is, but surely
> much slower than a simple product
> 2. While in the test cases you give the method you suggest is clearly
> superior, I'm quite sure there are some examples in which you loose
> precision because of summing logs (I'm too lazy to think this out to
> the end, but surely someone can think for me ?).
> 
> This looks like one of the many cases where numerical calculations
> fail because of limited precision, and you just have to know your data
> in order to make it work -- a lot of us call it "job security" :)
> 
> Shai


As another option to work around this problem it might be
possible to im a combination of current mode
and proposed algorithm:

1st) apply currently implemented 'prod'
2nd) if the result of current prod is 0 or Inf, check whether
     under or overflow has occurred
     a) if result is 0, but none of the factors is zero,
        an underflow must have had occurred
     b) if result is infinite, but all of the factors are infinite
        an overflow must have had occurred
3rd) if over/or underflow is detected, recalculate the product
     using the sum of logarithms of factors.

Because of the over/underflow checks some additional execution
time should be needed. But checking for infinite or zero values
is actually not a critical task because this can be done in a
vectorized way without heavy looping.

Rolf 

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer