[racket] read of numbers with decimal point default to exact?

The read-decimal-as-inexact parameter allows you to change read's
behavior in this way. Is that what you're looking for?

Robby

On Fri, Jul 23, 2010 at 1:20 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> This is just a small idea, not something I'd argue for strongly...
>
> How about making numbers formatted with decimal points, like "12.34", read
> as exact rather than inexact?
>
> The rationale being: decimal point format is a commonplace and very useful
> format for writing exact rational numbers, and if one writes a number like
> "5.55", there is nothing except an old Scheme convention to imply that one
> intends "5.55" to be any less exact than "555/100".  (I'm ignoring any
> question of precision here, which Scheme does not address either.)
>
> For example, with this change, the following expression would evaluate to an
> exact 5 rather than what it currently does: an inexact 4.999999999999999.
>
> (/ (read (open-input-string "5.55")) 1.11)
>
> The exact 5 result would also be what I imagine is expected by, say, casual
> programmers using Racket for financial calculations, which I think would be
> a small selling point for Racket.
>
> Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 5.55 / 1.11
> 4.9999999999999991
>
> The only good linguistic argument I can think of against this is that, when
> we have Racket *write* (as in the "write" procedure, not "display") inexact
> rationals in decimal-point form, they'd need to be written with an "#i"
> prefix, so that inexactness is preserved on a *read* of that same format by
> Racket.  The drawbacks I see to the "#i" on write are small: (1) visually,
> it's a little bit more cluttered; (2) it will break any legacy code that
> assumes it can do a write of numbers for some interoperation or UI purpose
> that doesn't work if the "#i" prefix is added.  "#i" could even be
> considered helpful, as in a heads-up to the programmer that they have a
> number that might be corrupted by IEEE floating-point operations they didn't
> expect.
>
> The only implementation efficiency argument I can think of against this is
> perhaps wanting numbers to be inexact by default, so that native
> floating-point representation and operations can be used more often.  If
> that is indeed a consideration, I'd prefer to leave adding "#i" prefixes and
> "exact->inexact" calls as optimizations that can be added consciously by
> programmers, with the default being more exact than efficient.
>
> --
> http://www.neilvandyke.org/
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>