On Thu, 2 Jun 2005, Bradley Lucier wrote:

>On Jun 2, 2005, at 12:25 PM, bear wrote:

>> I would go further and say *all* of these procedures should return
>> #f if called with a NaN argument, regardless of how numbers or NaNs
>> are represented.

>NaNs are not integers, so they cannot be arguments to odd? and even?.

NaNs can be returned from integer operations on integer arguments;
therefore requiring a NaN check before using them as arguments to
these functions disrupts the orthogonal compositionality which makes
Lisps so expressive.

>>> <change floor, ceiling, truncate, and round to take rational
>>> arguments,
>>> not real arguments>
>>
>> I do not agree with you that these procedures ought not take real
>> arguments. Instead, they should return inexact numbers when given
>> inexact numbers and NaN when given NaN.

>In my classification of numbers, the infinities and NaN cannot be
>integers, there is no "nearest integer" to these objects, either above
>or below them.  Can you describe a use for

>(trunc +inf.0) => ???
>
>or something similar?

I think that it is reasonable for the above call to return +inf.0.
More broadly, I argue in favor of not restricting the domains of
functions any more than absolutely necessary, because I want to
use Lisp's power to build very complex expressions out of subexpressions
without having to validate each and every one of the subexpressions
against some set of requirements first.  Contagion of NaNs and
infinities through operations like trunc, round, floor, etc, serves
the same purpose as contagion of inexactness through these functions;
It makes expressive code succinct and allows correct code to use only
a few validity checks rather than using many checks at intermediate
points in the computation.

>>> <change rationalize to take rational arguments, not real arguments>

>> This does not make sense.  If you have rational arguments to start
>> with, what are you using rationalize for?

> To find a "simpler" rational approximation to the argument.

> I agree, this needs to be fixed.  I should have said that the
> infinities and NaNs are not valid arguments to rationalize.  If a
> system wants to have numbers like (sqrt 2), then they should be allowed
> as arguments to rationalize, too.

I'm of the opinion that, if NaN is given as either argument to
rationalize, it is proper for rationalize to return NaN.  Otherwise,
the results of passing an infinity as the first argument to rationalize
should be either NaN if you regard infinities as irrational, or infinity
if you regard them as rational.  The result of passing an infinity as
the second argument to rationalize should be the most simple rational
number under the criteria used by that function, which I believe is 0/1.

				Bear