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

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

John Cowan wrote:
> I have two suggestions, neither of which I am wild about.  One is is
> "isintval", "isratval", etc.  This is verbose but clear: it's about
> values, not representations.  The other is cleverer and can't be confused
> with the existing predicates, but may be *too* clever:  "isinZ", "isinQ",
> "isinR", "isinC".

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

> 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

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?

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

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.

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