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