[plt-scheme] fractions and decimals

From: Robert Bruce Findler (robby at cs.uchicago.edu)
Date: Sun Jan 19 18:44:45 EST 2003

To further complicate the issue, in the teaching languages (those
languages under the "How to Design Program" triangle in the language
dialog), decimal numbers are interpreted as exact numbers, not inexact
numbers. We found that having fewer sources of inexactness for
beginning students was preferable. 

So, if Stephen's original tests with the test suite tool had been in
the beginning language, I think he would have found what he expected.


At Sun, 19 Jan 2003 17:13:17 -0500, "Neil W. Van Dyke" wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > I'm playing with the new "test suite" feature, and was surprised to
> > discover that (cube 1/2) is NOT 0.125 (although it DOES match 1/8).
> > On further investigation, I found that (equal? 0.125 1/8) returns true
> > in Beginner mode, but #f in R5RS and textual mzscheme.  Whazzap?
> Scheme has a notion of "exactness" of numbers:
>     http://download.plt-scheme.org/doc/r5rs/r5rs-Z-H-9.html#%_sec_6.2.2
> If I understand correctly... the decimal-point literal "0.125" is
> assumed "inexact" by default (I think for historical/performance
> reasons, so that an implementation can use inexact native floating-point
> numbers and operations unless the programmer directs otherwise).  The
> ratio literal "1/8" is assumed "exact":
>     (exact? 0.125) => #f
>     (exact? 1/8)   => #t
> You can use the "#e" prefix for expressing exact constants as
> decimal-point literals, and you can use the "inexact->exact" procedure
> to create an exact value from an inexact one:
>     (equal?                   0.125  1/8) => #f
>     (equal?                 #e0.125  1/8) => #t
>     (equal? (inexact->exact   0.125) 1/8) => #t
> If your computations don't require exactness, you can use "#e" and
> "inexact->exact" with impunity.  You may still have difficulty testing
> the equality of two rational numbers, due to floating-point lossiness.
> (I defer to the mathematician on any philosophical implications.)
> -- 
>                                              http://www.neilvandyke.org/

Posted on the users mailing list.