Stephen Bloch writes:
An example in my textbook is
(define TANK-CAPACITY-GALLONS #i13.6) (define MPG #i28)
because the capacity of a gas tank, and miles-per-gallon fuel
efficiency, are based on physical measurements and therefore
inherently inexact.
I think this is misguided. The proper response to uncertainty in data is
to use something like interval arithmetic (which is, of course, beyond
scope for an introductory course).
"Inexact" in Racket is code for IEEE double-precision floating point.
This represents a fixed set of numbers in such a way that many
computations that would mathematically produce a value not in that set
will instead produce as close a value in the set as possible.
That value may have little to do with the uncertainty in the original
data, and may display in a peculiar way (e.g. 5.999999 when 6.0 would be
more readable and just as "inexact"), so I don't think it's a good idea
to use inexact values in the given circumstance, if all you're doing
with the data are elementary arithmetic operations.
The one place I tell my students to use inexact arithmetic with
elementary operations is if the exact computation will result in values
with a large representation -- for example, in doing some sort of simple
physical simulation where the position or velocity of a particle is
updated by some method involving division or multiplication. It's
another "CS requires not only the creation of abstractions, but their
systematic violation" teaching moment. --PR
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
