Nitpick with FLOOR etc. Michael Sperber (07 Jul 2005 08:46 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (09 Jul 2005 00:50 UTC)
Re: Nitpick with FLOOR etc. Michael Sperber (11 Jul 2005 06:55 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 02:01 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (16 Jul 2005 08:38 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 17:42 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (16 Jul 2005 09:12 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 18:19 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (17 Jul 2005 17:23 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (17 Jul 2005 17:35 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (17 Jul 2005 22:43 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 01:43 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 02:31 UTC)
Re: Nitpick with FLOOR etc. bear (18 Jul 2005 05:59 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 18:57 UTC)
Re: Nitpick with FLOOR etc. bear (19 Jul 2005 01:35 UTC)
Re: Nitpick with FLOOR etc. Alan Watson (19 Jul 2005 20:30 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 17:35 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (24 Jul 2005 23:15 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 03:24 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 18:24 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 18:41 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 23:36 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (22 Jul 2005 00:50 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (25 Jul 2005 00:54 UTC)
Re: Nitpick with FLOOR etc. bear (27 Jul 2005 15:56 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (01 Aug 2005 16:33 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (25 Jul 2005 01:16 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (25 Jul 2005 02:38 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (28 Jul 2005 01:11 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (28 Jul 2005 18:15 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (01 Aug 2005 16:59 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (02 Aug 2005 13:58 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 17:39 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 18:15 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (20 Jul 2005 19:24 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (20 Jul 2005 21:35 UTC)
Re: Nitpick with FLOOR etc. bear (20 Jul 2005 22:41 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (20 Jul 2005 22:47 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 01:31 UTC)

Re: Nitpick with FLOOR etc. Aubrey Jaffer 21 Jul 2005 01:28 UTC

 | Date: Wed, 20 Jul 2005 17:35:24 -0400
 | From: Paul Schlie <xxxxxx@comcast.net>
 |
 | > From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
 | >  | I would presume:
 | >  |
 | >  |  (> #i1/0 1e1000) => #f
 | >
 | > Okay.  (number->string 1e1000) ==> #i+/0
 | > If you meant #e1e1000, then the answer should be #t.
 |
 | yes I meant #e1e1000, which implies you'd advocate:
 |
 |   (> #i1e400 #e1e1000) => #t
 |
 | which doesn't seem particularly reasonable, given that it's false,
 | (and honestly can't see how it can be rationalized as being otherwise).

Not only that: (= 1e400 1e500).  In fact, we don't need infinities to
construct these inexact conundrums: (= 1e-400 1e-500).

The total order of the reals is a crucial property for many
applications.  SRFI-70 preserves and extends the total order at the
price of conundrums like (= 1e400 1e500).

 | nor does (inexact->exact #i1/0) => 1e306 [or whatever] seem reasonable

If the conversion is unreasonable, "then a violation of an
implementation restriction may be reported."

  procedure: exact->inexact z
  procedure: inexact->exact z

    `Exact->inexact' returns an inexact representation of z. The value
    returned is the inexact number that is numerically closest to the
    argument. If an exact argument has no reasonably close inexact
    equivalent, then a violation of an implementation restriction may
    be reported.

    `Inexact->exact' returns an exact representation of z. The value
    returned is the exact number that is numerically closest to the
    argument. If an inexact argument has no reasonably close exact
    equivalent, then a violation of an implementation restriction may
    be reported.

 | unless you propose that (- #i1/0 1) :: (- 1e306 1), thereby #1/0
 | merely represents the greatest magnitude inexact value, which all
 | values greater than saturate to.  Thereby an exact infinity would
 | correspondingly represent the greatest representable exact value,
 | which all corresponding greater values saturate to as well.

You brought up exact infinities, not me.  I have no use for exact
infinities.  But I have tried to write SRFI-70 to avoid obstructing
those who claim they do.