Re: bug in rem

In article <46ae685a$1@xxxxxxxxxxxxxxxxx>, ross <ross@xxxxxxxxxx> 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
.

Relevant Pages

  • Re: bug in rem
    ... the real problem is that a rem routine should never return that value. ... the programming issues were allowed to take precedence over what was important ...
    (comp.soft-sys.matlab)
  • Re: Native Code vs PCode OT
    ... > register Left-to-right Routine Yes ... claim influence or invention from Pascal. ... invented by a Russian first. ... to that new concept - Structured Programming. ...
    (microsoft.public.vb.general.discussion)
  • the problem of constants
    ... literal constants, ... Matlab's "copy on write" behaviour to provide the efficiency. ... prevent any routine from accidently changing the master ... to be any better, in terms of programming theory or efficiency, ...
    (comp.soft-sys.matlab)
  • Re: bug in rem
    ... the round-off error isn't the issue. ... the real problem is that a rem routine should never return that value. ... the programming issues were allowed to take precedence over what was important ...
    (comp.soft-sys.matlab)
  • Re: OCP and Java
    ... > a hard time imagining any programmer with the clairvoyance required ... The only place that I can think of where frozen is used in the Eiffel ... An example is a routine that compares to objects for equality. ... > kind of flexibiliy is valuable there are already programming ...
    (comp.object)