[racket-dev] (round), etc. in Typed Racket
> -----Original Message-----
> From: Vincent St-Amour [mailto:stamourv at ccs.neu.edu]
> Sent: 13 December 2010 17:01
> To: Jos Koot
> Cc: 'Noel Welsh'; dev at racket-lang.org
> Subject: Re: [racket-dev] (round), etc. in Typed Racket
>
> At Mon, 13 Dec 2010 16:43:58 +0100,
> Jos Koot wrote:
> > Would we not have the same problem with 'rational?'.
> > All reals, both exact and inexact ones are rationals (for
> the obvious
> > reason that we cannot represent every irrational number in finite
> > memory) Would we not need the same distinction between
> > 'exact-rational?' and 'inexact-rational?'. May be
> 'rational?' should
> > mean 'exact-rational?' and 'real?' should mean
> 'inexact-real?' or 'inexact-rational?'.
>
> I like that, it's consistent with exact-integer -> integer.
>
> > And how about exact and inexact 'complex?'?
>
> It's a bit more tricky, since there are potentially 4 kinds
> of complexes, each part could be exact or inexact. However,
> I'm not sure that complex numbers of the shape
> exact+inexact*i are of any use, and apart from the special
> case inexact+0i (inexact reals), I don't see much use for
> inexact+exact*i either.
>
> > I have the feeling that the numeric tower is tilting like
> that of Pisa.
>
> Sounds more like straightening it up to me.
>
> > When it comes to efficiency, flonums may be preferred, but
> it is not
> > difficult to enforce a function to do all its computations
> with flonums.
>
> It can be tricky if you mix exacts and inexacts, the result
> is not always inexact:
> (* 3.4 0) -> 0 ; not 0.0
When multiplying any number (nan and inf excepted) by exact 0, should, of
course produce exact 0.
There are more problems though. How about:
(let ((x 1.0)) (- x x))
Should it produce inexact or exact 0?
Don't ask me, for I am not sure, yet. IIAR Racket produces 0.0.
Evidently the problem is located in the simulation of truly REAL
computations within a finite memory that necessarily must produce
approximations for many computations.
I am inclined to the idea that a programmer should be aware of when he or
she is using exact numbers or approximations of them.
Jos
>
> Vincent