Path: news.mathworks.com!not-for-mail
From: "David Wilson" <wizwilson@gmail.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: bug in rem
Date: Tue, 31 Jul 2007 01:08:27 +0000 (UTC)
Organization: David Wilson (ID: 1-78B87)
Lines: 65
Message-ID: <f8m22b$sus$1@fred.mathworks.com>
References: <46ae48de$1@news.eftel.com.au> <f8lija$j7o$1@fred.mathworks.com> <46ae685a$1@news.eftel.com.au>
Reply-To: "David Wilson" <wizwilson@gmail.com>
NNTP-Posting-Host: webapp-01-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1185844107 29660 172.30.248.36 (31 Jul 2007 01:08:27 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Tue, 31 Jul 2007 01:08:27 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 39625
Xref: news.mathworks.com comp.soft-sys.matlab:421781


ross <ross@nospam.com> wrote in message <46ae685a$1@news.eftel.com.au>...
> "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
> 

While your argument is well constructed regarding the fact that rem(a,b) should never return a value outside [0,b-1], 
the problem remains that what, in your opinion, should rem then return in your somewhat extreme example? 

We should not really return NaN or Inf simply because we can't compute it (& it is already used), and we cannot really return anything in the range [0,b-1] since that seems to indicate that that is infact the answer. We could throw up a warning I suppose, but that's not done in other similar overflow cases.