Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> The latter, since an inexact 0.0 might not really be zero, and so the
> true number that is inexactly represented might be close to the real
> axis but not actually on it.

Makes perfect sense. I'll do it that way.

>>Which makes me wonder whether that would be the right thing in Q.
>>Actually I think it would be better if comparisons with nan just fail.
> 
> In fact, this is what IEEE-compliant hardware *already* does, so you
> don't need to do anything.

No, with "fail" I mean that, e.g., nan=0.0 would be a normal form. In Q, 
that makes much more sense than returning false in such a case. Either 
those numbers are incomparable and then the operation should fail; or 
they _are_ comparable but then the result should make sense (which it 
doesn't if both nan=0.0 and nan<>0.0 return false because the latter 
should be the negation of the former).

> Well, I suppose you could trap the SIGFPE exception.

Ugh. In fact I already do that but only to print backtraces and exit 
from the interpreter in an orderly manner. I wouldn't want to emulate 
IEEE floating point numbers that way. Let's just say that systems 
without a proper IEEE floating point arithmetic loose; ppl will just 
have to put up with the deficiencies of those systems or have to set up 
their own SIGFPE handling in their Q scripts.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag