[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reading NaNs



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-frooble

A 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