This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
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