Re: [q-lang-users] Query about Type Tests (Complex and Rational).

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

Hi Rob,

well, you caught me "in flagranti" before the new "numeric tower" (which 
is in fact more like an appartment building with 3 floors ;-) is 
actually finished (I still have to add Rational to the picture). I 
haven't discussed this on the list yet, because I first wanted to test 
out things for myself.

Rob Hubbard wrote:
>            Num
>             |
>             |
>           C[R] denoting Complex [with Real parts]
>            / \
>           /   \
>        C[Q]    R = Real
>         / \   /
>        /   \ /
>     C[Z]    Q = Rational
>        \   /
>         \ /
>          Z = Int
> 
>         (C[Z] is the ring of Gaussian Integers.)
> 
> Should these types be related as supertype:subtype, and can Q express
> these (especially where there is more than one supertype)?

Unfortunately not, since Q only has single inheritance. Another 
limitation is that you cannot make Rational a supertype of Int. The 
supertype is set when a type is declared and it cannot be changed after 
that; so Int, as a built-in type, can only be given another built-in 
type as a supertype.

As John has pointed out, it's useful to distinguish between syntax and 
semantics here. Data types are a syntactic concept; they are all about 
representations of certain kinds of data, and which operations apply to 
what data. Then there's the semantic level, our interpretation of what 
these representations actually mean in an ideal mathematical world.

Right now I'm just trying to get the data types right so that they will 
work in the intended way. So I've introduced the abtract data type Real 
purely out of practical considerations, since I want to be able to 
extend the built-in system of number types at all levels. In the new 
system alternative integer types can now be derived from Int, 
alternative floating point types from Float, other subtypes of real 
numbers (like Rational) from Real, and other types of non-real numbers 
(like Complex) from Num.

So the new system looks like this (Rational already included in the 
picture, although this hasn't been implemented in the standard library yet):

Num --> Real --> Int
     +        +-> Float
     +        +-> Rational
     +-> Complex

This has the big advantage over the former system with just two levels 
(Num as a supertype versus the rest) that Complex (which is now a 
subtype of Num) can now be an aggregate of two Real's and will hence 
just work with any other user-defined data types derived from Real or 
any of its subtypes, too.

The (syntactic) predicates associated with these types are isnum, 
isreal, isint, isfloat, isrational and iscomplex. If we also add the 
(semantic) predicates is_complex_rational, is_complex_int as well as 
is_real_or_complex and is_int_or_rational, then all remaining 
memberships in your diagram can be tested easily.

I obviously just followed the KISS principle here, but so far it seems 
to work pretty well. The only real shortcoming I see is that Int is not 
a subtype of Rational and Real not a subtype of Complex. So, e.g., if 
you want to have a function which operates on both Int's and Rational's 
you cannot just define it on Rational arguments and be done with it. 
OTOH, Rational and Int are sufficiently different so that this can 
actually be justified, and if you really have an operation which can be 
defined in a generic fashion on both Int's and Rational's then chances 
are good that it can actually be defined on Real anyway. The same 
applies to Real and Complex and their common supertype Num.

If you hold on for a little longer then I can complete the new 
implementation by integrating Rational into the standard library (maybe 
tonight). I could then release a candidate so that everybody can 
actually try it out and we can go on discussing it. Ok?

Cheers,
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