Thomas Lord wrote: > Arthur Smyles wrote: >> Changes >> >> (real? nan.0) => false >> (complex? nan.0) => false >> > > Honestly? No.
Well then you're not going to like the current spec either which says that those operations return true. > > It would make more logical sense to add a new value > to the language, "#NaB" (pronounced, "not a boolean"), > and have: > > (real? nan.0) => #NaB > (complex? nan.0) => #NaB > I thought of these functions as describing sets(types) of numbers. So you could determine whether NaN is in that set or not. > > The following should be (an example of) an error: > > (if #NaB 'yes 'no) => ...error... > > > NaN is a bottom value and (ordinary) type predicates are strict in > the type of their arguments. Bottom values have no > type other than "bottom". > > (real? _|_) => _|_ > > therefore > > (real? nan.0) => #f > > is bogus. > I interpret the real? function differently from you. (real? _|_) is asking is the bottom value real? We both agree that the answer is no. So I don't understand why you can't say #f. > > > > >> These would still hold >> (number? nan.0) => true >> > > No way, please. A NaN result from an > FPU signals that no proof has been found that any > number exists which is the requested result. > But then operations on numbers is no longer algebraically closed. I think that this is an important property to maintain. > The most logical thing would be to have two procedures: > > NUMERIC? > and > NUMBER? > > NUMERIC? returns #t only if its argument can be > passed to math operations without causing an error. > > NUMBER? returns #t only if there exists a number > consistent with the history of how its argument was > computed. > > > (number? nan.0) => #NaB > (numeric? nan.0) => #t > > > >> (nan? nan.0) => true >> All IEEE-754 mathematical operations with nan.0 >> >> > > Yes. NaN is a bottom value but there can still be some > type structure among bottom values that can be effectively > recognized. > > -t > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
