Path: news.mathworks.com!newsfeed-00.mathworks.com!news.kjsl.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread4.news.pas.earthlink.net.POSTED!5f968bd6!not-for-mail
From: ellieandrogerxyzzy@mindspring.com.invalid (Roger Stafford)
Newsgroups: comp.soft-sys.matlab
Subject: Re: bug in rem
Message-ID: <ellieandrogerxyzzy-3007071704380001@dialup-4.232.57.163.dial1.losangeles1.level3.net>
References: <46ae48de$1@news.eftel.com.au> <f8lija$j7o$1@fred.mathworks.com> <46ae685a$1@news.eftel.com.au>
Organization: -
Lines: 78
Date: Tue, 31 Jul 2007 00:04:38 GMT
NNTP-Posting-Host: 4.232.57.163
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread4.news.pas.earthlink.net 1185840278 4.232.57.163 (Mon, 30 Jul 2007 17:04:38 PDT)
NNTP-Posting-Date: Mon, 30 Jul 2007 17:04:38 PDT
Xref: news.mathworks.com comp.soft-sys.matlab:421776


In article <46ae685a$1@news.eftel.com.au>, ross <ross@nospam.com> wrote:

> 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
--------------------
  There is an old computer adage that is pertinent here, Ross.  "Garbage
In, Garbage Out".  And, given the 53-bit accuracy limitation of IEEE
binary double precision floating points numbers, "garbage" is precisely
what you have put into the 'rem' function input when you write the absurd
expression rem(1.5511623754564467e105,10)!  Even with the very first step
of finding the nearest representable number to that decimal string, an
integer in this case, the correct answer for the remainder with ten as
divisor will have been irretrievably lost.  IEEE 754 binary numbers almost
certainly cannot represent 1.5511623754564467e105 exactly even if it is an
integer with 89 trailing zeros.  Matlab has to select the nearest integer
it can realize and the difference in this case will be astronomically
large, which will of course change the remainder completely.  Would you
rather the 'rem' function issue the message, "You've to be kidding,
fella!"?  In my opinion it would almost be justified.  The lesson to be
learned here is that there is no substitute for using the little gray
cells when it comes to writing good programs.  Matlab, and indeed all such
numerical computation programs, simply won't do all your thinking for you
- perhaps by the next millennium, but certainly not yet.  You as a
programmer have to be constantly aware of such limitations when dealing
with a finite set of numbers and attempting to approximate the
mathematical ideal of the infinite continuum of real numbers.  If you do
otherwise, you put yourself in the same class as people who ask
indignantly why 100*.07==7 (or numerous similar equalities) come out false
in matlab.

Roger Stafford