1 Sep 2010 15:14

```I've been having an interesting discussion off-list with David Kay, but have concluded that we need the
expertise of somebody more knowledgeable about Scheme/Racket and its philosophy.

The "#i" indicates that a number is inexact, and that further computation based on it should be interpreted
accordingly.  The Scheme/Racket numeric libraries automatically mark as "inexact" most results of
trig, exponential, log, sqrt, and similar functions, even if the inputs were exact, because the
mathematically correct answers to these are irrational.  Likewise,

The question is under what circumstances (if any) you would want to mark something as inexact that DIDN'T
come from an irrational-valued library function or constant.  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.  On the other hand, you could work through this entire
example using exact numbers, and everything would come out correctly (since the only arithmetic
involved is addition, subtraction, multiplication, and division), so the argument could be made that
putting #i in there is distracting and pedantic.

Opinions?  Corrections?

Stephen Bloch
sbloch@...

```
1 Sep 2010 15:24

```On Sep 1, 2010, at 9:14 AM, I wrote:

> The "#i" indicates that a number is inexact, and that further computation based on it should be
interpreted accordingly.  The Scheme/Racket numeric libraries automatically mark as "inexact" most
results of trig, exponential, log, sqrt, and similar functions, even if the inputs were exact, because
the mathematically correct answers to these are irrational and don't have exact representations in any
common, convenient computer representation.  Likewise,

A sentence got cut off here, saying that the predefined constants pi and e are marked as inexact.

Stephen Bloch
sbloch@...

```
1 Sep 2010 15:29

```On Wed, Sep 1, 2010 at 2:14 PM, Stephen Bloch <sbloch@...> wrote:
irrational.  Likewise,
>
> The question is under what circumstances (if any) you would want to mark something as inexact that DIDN'T
come from an irrational-valued library function or constant.
>

Speed, speed, speed, and more speed. Some simple code I have has a
2.5x speedup when switching from exact to inexact arithmetic.

N.
```
1 Sep 2010 15:29

```
On Sep 1, 2010, at 9:14 AM, Stephen Bloch wrote:

> (since the only arithmetic involved is addition, subtraction, multiplication, and division), so the
argument could be made that putting #i in there is distracting and pedantic.

I second this opinion (re pedantic).

;; ---

The #i indicates inexactness as far as computer arithmetic is concerned, that is, what the so-called
'machine' level arithmetic supplies. In HtDP terms, since this representation of information
(numbers) and functions on it (arithmetic, etc) uses a fixed and finite amount of resources, you cannot
represent all the numbers on the number line. Ergo, when you have some information (number) for which
there is no piece of data on the machine (Number), you choose something close by. That's true for
operations and for people mapping information to data.

-- Matthias

```
1 Sep 2010 15:40

```On Sep 1, 2010, at 9:29 AM, Matthias Felleisen wrote:

> The #i indicates inexactness as far as computer arithmetic is concerned, that is, what the so-called
'machine' level arithmetic supplies.

And yet Scheme/Racket allows for inexact integers, whereas no computer I know of has an inexact integer
type supported at the machine level.

Stephen Bloch
sbloch@...

```
1 Sep 2010 15:50

```
On Sep 1, 2010, at 7:40 AM, Stephen Bloch wrote:

> On Sep 1, 2010, at 9:29 AM, Matthias Felleisen wrote:
>
>> The #i indicates inexactness as far as computer arithmetic is concerned, that is, what the so-called
'machine' level arithmetic supplies.
>
> And yet Scheme/Racket allows for inexact integers, whereas no computer I know of has an inexact integer
type supported at the machine level.

Don't forget some fun stuff (for which there are sound reasons):

> (inexact? (sin 0))
#f
> (inexact? (sin 0.0))
#t
>

rac

>
>
> Stephen Bloch
> sbloch@...
>
> _________________________________________________
> http://lists.racket-lang.org/listinfo/users

```

1 Sep 2010 21:15

```On Wed, Sep 1, 2010 at 6:40 AM, Stephen Bloch <sbloch@...> wrote:
> On Sep 1, 2010, at 9:29 AM, Matthias Felleisen wrote:
>
>> The #i indicates inexactness as far as computer arithmetic is concerned, that is, what the so-called
'machine' level arithmetic supplies.
>
> And yet Scheme/Racket allows for inexact integers, whereas no computer I know of has an inexact integer
type supported at the machine level.

Huh?  Any integer between -2^53 and 2^53 can be represented by a
double-precision float.

--

--
~jrm
```
1 Sep 2010 21:53

```On Wed, Sep 01, 2010 at 12:15:27PM -0700, Joe Marshall wrote:
> On Wed, Sep 1, 2010 at 6:40 AM, Stephen Bloch <sbloch@...> wrote:
> > On Sep 1, 2010, at 9:29 AM, Matthias Felleisen wrote:
> >
> >> The #i indicates inexactness as far as computer arithmetic is concerned, that is, what the so-called
'machine' level arithmetic supplies.
> >
> > And yet Scheme/Racket allows for inexact integers, whereas no computer I know of has an inexact integer
type supported at the machine level.
>
> Huh?  Any integer between -2^53 and 2^53 can be represented by a
> double-precision float.

And others can be represented approximately by a double-precision float.

-- hendrik
```
1 Sep 2010 16:30

```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
```

1 Sep 2010 21:54

```On Wed, Sep 1, 2010 at 7:30 AM, Prabhakar Ragde <plragde@...> wrote:
>
> "Inexact" in Racket is code for IEEE double-precision floating point.

And for a particular, somewhat idiosyncratic `contagion' policy.

As Noel pointed out, the reason that we have floating-point is for speed.
(Well, also to approximate rationals and computable reals with a parsimonious
representation, but that is much less important these days.)

> 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.

This is correct, but bizarre (that is, it accurately describes the
weird behavior
of Scheme's `inexact' numbers).

Floating-point has two components:  first, it defines a representation
of a subset
of the rational numbers.  The representation is specified in enough detail that
one can build hardware that operates on that representation.  Second, it
defines a set of arithmetic-like operations on this representation.  These
operations have the property that they act as much as possible as exact
rational arithmetic, provided that the answer can represented, and they
produce erroneous, but the best representable approximation to the answer
otherwise.

What is bizarre is that the normal arithmetic operations such as add, subtract,
etc. are changed to the floating-point approximations based on the
```

1 Sep 2010 22:00

```2010/9/1 Stephen Bloch <sbloch <at> adelphi.edu>:
> I've been having an interesting discussion off-list with David Kay, but have concluded
> that we need the expertise of somebody more knowledgeable about Scheme/Racket and its philosophy.

Apropos philosophy. The rrrs mailing list is available online and
contains various
exchanges on inexact numbers. Here is one from Guy Steele with the
memorable quote:

INEXACT NUMBERS ARE NOT NUMBERS

INEXACT NUMBERS ARE NOT NUMBERS

INEXACT NUMBERS ARE NOT NUMBERS

They do not obey the rules followed by numbers, because they cannot.
Inexact numbers only represent our -approximate- -knowledge- about numbers.

See

http://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1989/msg00178.html

Here and there you'll see ideas that didn't catch on. Some of these
are still available.

The syntax   12##   is still legal. It signifies that the last two
digits are unknown.
In Racket it evaluates to 1200.0, though one might argue 1250.0 were a
better idea.

```

1 Sep 2010 22:09

```On Wed, Sep 1, 2010 at 4:00 PM, Jens Axel Søgaard <jensaxel@...> wrote:
>
> Apropos philosophy. The rrrs mailing list is available online and
> contains various
> exchanges on inexact numbers. Here is one from Guy Steele with the
> memorable quote:
>
>                         INEXACT NUMBERS ARE NOT NUMBERS
>
>                         INEXACT NUMBERS ARE NOT NUMBERS
>
>                         INEXACT NUMBERS ARE NOT NUMBERS
>
>   They do not obey the rules followed by numbers, because they cannot.
>   Inexact numbers only represent our -approximate- -knowledge- about numbers.
>
> See
>
> http://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1989/msg00178.html

If I have read the message correctly, Guy was quoting those three
lines as well; they were written by Alan Bawden.

--Carl
```
1 Sep 2010 22:15

```2010/9/1 Carl Eastlund <cce <at> ccs.neu.edu>:
> If I have read the message correctly, Guy was quoting those three
> lines as well; they were written by Alan Bawden.

Oops. You are right. Guy used spaces to quote Alan, so I misread
what was quoted.

--
Jens Axel Søgaard
_________________________________________________
http://lists.racket-lang.org/listinfo/users```
1 Sep 2010 22:17

```> Back then they also discussed other representations of inexact numbers