automatic Inf+NaN*i conversion

John W. Eaton jwe at bevo.che.wisc.edu
Fri Apr 25 09:53:40 CDT 2008


On Fri, 25 Apr, Rolf Fabian wrote:

| Ben already pointed out that ML has the same 'feature'
| implemented. Thus, from former experience, it makes
| absolutely no sense for me to dig publicly further into
| this matter because I believe to already know the majority
| of your eventual comments and replies in advance.

And earlier, on 23-Apr-2008, Rolf Fabian wrote:

| 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.
| 
| 1) Its help part is corrupted and not understandable.
| 2) If input is a row vector no product is formed
| 3) It returns NaNs where not appropriate
|    e.g. safeprod([realmax;2]) |- ans = NaN
|    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   
| 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.
| 
| 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.

Rolf,

Perhaps it is just a language thing, but your comments here come
across as increasingly condescending and rude.  Perhaps you would
consider lightening up the tone of your messages a bit, or perhaps
find some other forum on which to vent.

jwe


More information about the Bug-octave mailing list