From: ross <ross@nospam.com>
Subject: Re: bug in rem
Newsgroups: comp.soft-sys.matlab
References: <46ae48de$1@news.eftel.com.au> <f8lija$j7o$1@fred.mathworks.com>
NNTP-Posting-Host: 202.61.162.14
Message-ID: <46ae685a$1@news.eftel.com.au>
Date: 31 Jul 2007 06:38:18 +0800
X-Trace: news.eftel.com.au 1185835098 202.61.162.14 (31 Jul 2007 06:38:18 +0800)
Lines: 57
Path: news.mathworks.com!newsfeed-00.mathworks.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news1.optus.net.au!optus!newsfeeder.syd.optusnet.com.au!news.optusnet.com.au!newsfeed.pacific.net.au!news.uwa.edu.au!news.waia.asn.au!news.eftel.com.au!not-for-mail
X-Original-Bytes: 3368
Xref: news.mathworks.com comp.soft-sys.matlab:421771


"us " <us@neurol.unizh.ch> wrote:
>ross:
><SNIP FP headache evergreen...
>
>> x = 1.5511623754564467e105;
>> r = rem(x,10)
>> r = 2.54629497041811e+089
>
>...should not come as a surprise, because your <x> is represented with the 
>uncertainty of
>
>     eps(x)
>
>that happens to be ---
>
>     2.546294970418108e+089
>
>us


Look, the round-off error isn't the issue. You will note that I said "whatever 
the cause".  That phrase was meant to indicate that I know that the value 
returned is due to roundoff error, but the real problem is different.  In fact 
the real problem is that a rem routine should never return that value.  This is 
not an evergreen newbie problem, it's a comment on the inadequacy of the 
programming.

rem and mod should not, by definition, return values that exceed the magnitude 
of the modulus or radix, and the software should be written to reflect that.
This is an "absolute" consideration.  IMO the software is broken if it doesn't 
conform to the expected mathematical behaviour, when that is possible. In other 
words, if I want to express pi to 100 sig figs in a Matlab double, it can't be 
done.   However it is entirely possible to ensure that a remainder doesn't 
exceed the divisor, and it absolutely should be done.

Secondly, I believe that there is a more "relative" consideration, which is 
that the numerical routines should protect the user from the effects of 
round-off error where possible. None of us disagree that one should understand 
the effects of round off error in order to program in an informed way.  
However, it is absurd to have to put all the error trapping code into every 
application routine.  It should be in the basic numerical functions.  There are 
many applications where certain inputs might generate high disparaties in the 
values at some point in the routine.  The routine should not crash at that 
point.  It's true that if one does a careful error analysis one might expect 
those situations.  But this is not the 1950s anymore guys - the user can expect 
to have routines that dealt with out-of-range cases gracefully, not by 
returning absurd values.  If you don't include sensible error trapping in the 
routines, you force the user to be watching the details all the time instead of 
concentrating on the main objectives.  It's the old mainframe mentality where 
the programming issues were allowed to take precedence over what was important 
to the user, which was why programming was such a black art then.  It's very 
important to get away from this oldfashioned point of view.  (And for God's 
sake, before you send a bunch of irrelevant flames -- I am not arguing that an 
understanding of round-off error is oldfashioned).

Ross