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

[John C. <co...@cc...>]

Albert Graef scripsit:

> I like isintval etc., that looks much more "Q'ish" than isinZ etc.

Okay.

> > That reminds me that the rules for isintnum, isratnum, and isrealnum
> > when applied to type Complex do not check that the imaginary form
> > is an *exact* 0.  As I pointed out before, an inexact 0 is really
> > a representation for any number n such that -d < n < d, where d is
> > the smallest positive float.
> 
> So what's the right way to implement these? R5RS gives these as examples 
> (I couldn't find the relevant part of the R6RS draft):
> 
> (real? -2.5+0.0i)               ===>  #t
> (integer? 3+0i)                 ===>  #t

The numeric draft material for R6RS appears at
http://srfi.schemers.org/srfi-75/srfi-75.html .

> So should isrealval Z return true if im Z=0 but isintval Z => true only 
> if eq (im Z) 0? Or do you suggest that both predicates should always 
> return false when im Z is inexact?

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.

> I'll also have to fix the built-in comparison of floating point numbers 
> so that any comparison with nan always returns false. 
> 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.

> Some builtins like
> ln and atan/atan2 probably have to be modified, too. And some of the 
> definitions in complex.q need to be fixed so that they only fail with 
> exact zeros.

Yes.

> And what happens with all of that if the host system doesn't have IEEE 
> floating point? A division by 0.0 causing the interpreter to segfault? 
> That would be rather unfortunate.

Well, I suppose you could trap the SIGFPE exception.

-- 
There are three kinds of people in the world:   John Cowan
those who can count,                            co...@cc...
and those who can't.