octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jaroslav Hajek
Subject: Re: left-right (up-down) parsing may lead to over/underflow of prod
Date: Wed, 23 Apr 2008 16:13:09 +0200

On Wed, Apr 23, 2008 at 3:04 PM, Rolf Fabian <address@hidden> wrote:
>
>  > Datum: Wed, 23 Apr 2008 07:20:33 +0200
>  > Von: "Jaroslav Hajek" <address@hidden>
>  > An: "Octave Maintainers List" <address@hidden>
>  > CC: "David Bateman" <address@hidden>, "Rolf Fabian" <address@hidden>
>
> > Betreff: Re: left-right (up-down) parsing may lead to over/underflow of prod
>
>
>
> > I've committed `safeprod' to OctaveForge (main/general).
>  >
>  > --
>  > RNDr. Jaroslav Hajek
>  > computing expert
>  > Aeronautical Research and Test Institute (VZLU)
>  > Prague, Czech Republic
>  > url: www.highegg.matfyz.cz
>
>
>  You should withdraw and remove 'safeprod.m' as soon as possible
>  because it is a mess and far away from beeing safe in contradiction
>  to its name.

Well, it was an initial attempt, so please be patient.
I'm sure it can get better over time. After all, none of Octave's (or
OctaveForge's) functions are
safe, they all come with NO WARRANTY :)

>
>  1) Its help part is corrupted and not understandable.

I've corrected some mistakes - missing braces in @deftypefn and "sum"
instead of
"prod". Are there more mistakes?
In what sense is it not understandable? Please elaborate.

>  2) If input is a row vector no product is formed

fixed.

>  3) It returns NaNs where not appropriate
>    e.g. safeprod([realmax;2]) |- ans = NaN

this is actually a bug in log2 (Octave's builtin). Check this out:
[f, e] = log2 (realmax)
I'll try to fix that in Octave instead.


>    whereas Octave:> prod([realmax;2]) = Inf
>    gives already the correct answer whereas
>    your 'improvement' fails!
>    Similar for e.g. :> safeprod([realmax;2i]) |- ans = NaN
>    whereas prod gives correct ans = 0 + Infi

I hope this will be fixed as well by fixing log2.

>  4) It is easy to construct input which leads to
>    under/overflow of your 'safeprod' function.
>    Hence it is not 'safe'.
>  5) Weird things may be returned from 'safeprod'
>    for complex input containing some Inf, -Inf, Infi
>    entries.

Can you show particular examples for later use?
log2 again does not work well for Inf - it returns [NaN, Inf].
But perhaps safeprod should handle Inf and NaN's as a special case anyway.

>  I summarize that your function seems to be a nice little
>  trial to work around the prod bug, but unfortunately it
>  is not able to remove it completely and thus useless.
>
I would not call it useless, rather a partial success :)

Seriously, if you insist on calling the behaviour of `prod' a bug, you
can as well say that
`sum' is buggy, because it is not associative either. floating-point
multiplication and addition
just aren't associative - that's normal. If you want to make sum and
prod truly associative, your only chance is to fix a particular
ordering, for instance, by a lexicographical sort.


I can try to make a compiled replacement for Octave's log2 now. If you
want to collaborate further, I can send it to you afterwards for bug
hunting and/or improvement suggestions.

regards,

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]