> As you explained, +inf.0 actually stands for all of the real
> numbers that are above a certain size.
To be precise, I said +inf.0 represents a whole range of numbers.
> Most of the numbers for which +inf.0 stands are not integers. That
> argument is not at all convincing, however, because the same is true of
> * all* inexact integers.
Right, in which case we should not consider (integer? 3.0) => #t.
> At some point, you have to look at the operational meaning
> of integer? and other predicates. One of the main uses of
> integer? in SRFI 77 is to define the domain on which things
> like flodd?, fleven?, flquotient, flremainder, inexact-odd?,
> and inexact-even? are defined. If we don't want to have to
> describe how these things behave on +inf.0 or -inf.0, then
> we can exclude them from the domain by defining them as
> non-integers. That is the approach taken in SRFI 77.
I'd much rather describe how these work (or explicitly say their behavior
is unspecified) than introduce the strange notion that infinities are
irrational into the report.
> This would be a bad thing to do if there were plausible
> examples of problems it would cause. If you can think
> of such problems, we'd like to hear about them.
It adds extra overhead to primitives that are already slower than most
programmers probably imagine.
> In mathematics, a rational number has a finite integral
> numerator and denominator.
Hmm. Implicit in this statement is that integers can be infinite (or
"finite integral" would be redundant). Does this mean that infinite
integers are irrational? Also, should (integer? +inf.0) => #t even
though (rational? +inf.0) => #f?
> Both the standards document
> and working programmers need some way to distinguish
> the finite inexact reals from the infinities and NaNs.
> That seems like a natural use for the rational? predicate,
> which has not heretofore had much in the way of a portable
> semantics on inexact numbers anyway.
I prefer something more direct, and something that doesn't imply that
+inf.0 is irrational, like exceptional-flonum?
> > I would prefer that it be required, but I'll settle for allowed.
> > Similarly, I prefer that (/ x 0) be an error, but I'll settle for allowed.
>> That's all I ask.
>
So, it sounds like we can agree on (for nonnegative x):
(* x 0) => 0 or +nan.0 if x = +nan.0 or x = +inf.0
=> 0 or 0.0 otherwise
(/ 0 x) => 0 or +nan.0 if x = +nan.0
=> 0 or 0.0 otherwise
(/ x 0) => +nan.0 or raise exception if x = +nan.0 or x = 0.0
=> +inf.0 or raise exception otherwise
Right?
Kent