This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer wrote:
Which bits do you twiddle so you don't spoof the hardware generated NaNs?This is platform dependent, even among IEEE-754 platforms.
Of course. Many aspects of NaNs will be hardware dependent. In particular, any implementation of context will need information on the hardware.
Leaving NaN syntax unspecified does not prevent implementations from putting NaNs to any use.
Fine. Why don't we also leave the action of car and cdr on pairs as unspecified? After all, this does not constrain implementations from putting pairs to use.
Many behaviors are left unspecified by R5RS, such as when operations on exacts would produce results not representable as exacts; and division by zero; and multiplication by exact zero; and syntax for EOF.
Yes, but division by an exact zero is UNDEFINED whereas the properties of a NaN in IEEE arithmetic are well defined.
The thing is, R6RS needs to strike a balance between being sufficiently specific to be useful and and sufficiently vague to be easy to implement widely.
Suppose we read data from a spectrometer, then compute the average of each pair of adjacent values and write it out. None of the values should be infinite. But if somehow a positive infinity and a negative infinity were adjacent, the average would be a NaN, which would be written out. The probability of this happening is so remote that writing checks for it borders on lunacy. But stuff does happen -- I would like my implementation to choke when reading those NaNs.
Eh? You want to write a program that does not adequately validate its input and have R6RS do the work for you?
What about a program that reads data from a spectrometer and writes the average of each pair. The data should all be non-zero, but what happens if a couple of negative numbers get into the original data stream? Do you want a version of read that signals an error on negative numbers?
Basically, what is different between NaNs (which sometimes indicate an error and sometimes indicate missing data) and negative numbers (which sometimes indicate an error and sometimes indicate valid data)?
Where is the end of this? Are you proposing a series of read procedures: read-and-signal-error-on-NaN read-and-signal-error-on-negative-numbers read-and-signal-error-on-a-null-rather-than-a-pair read-and-signal-error-on-exact-integers-that-are-not-prime read-but-not-strings-containing-the-substring-froobleA clean way to get what you want would be to have two IEEE arithmetic modules, one which signalled on NaNs (both generated and read) and one which did not.
Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México