[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IEEE NaN and Trichotomy
- To: email@example.com, firstname.lastname@example.org (Jim Allard)
- Subject: Re: IEEE NaN and Trichotomy
- From: email@example.com (Andrew LM Shalit)
- Date: Mon, 4 Jan 1993 14:42:22 -0500
At 3:58 PM 12/28/92 -0500, Jim Allard wrote:
> Robert Cassels writes:
> >Of course the compiler would turn (not (binary< ...)) into the most
> >efficient machine instruction(s), which might be a branch-less-or-equal and
> >wouldn't necessarily need an explicit "not" instruction. The issue here
> >isn't what machine instructions get generated (I assume we can write
> >sufficiently clever compilers), but what the programmer writes to get what
> Actually, I believe the compiler would not be allowed to perform this
> transformation, since it would change the IEEE result for NaN arguments. Weird
> stuff, isn't it?
> Andrew LM Shalit writes:
> >If my memory serves me correctly, signalling an exception on NaN comparisons
> >wouldn't bee IEEE compatible. You have to return #f.
> I must admit, I have only read things written by others who I must assume read
> the standard. In those documents there appeared to be two valid choices,
> signalling or returning NaNs.
Yes, but in this context 'signalling' means setting a bit which the program
can check at its discretion. This 'signalling' does not involve (cannot
involve) interrupting the flow of the program, they way 'signalling' in the
Dylan exception system does.
This interpretation is based on e-mail discussions with Jerome Coonen (IEEE
math guru) a couple of years ago.