q-lang-users — general discussion, questions, suggestions, etc.

Re: [q-lang-users] Q 7.2 RC1 Issue 3: IEEE floats

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

John Cowan wrote:
> But none of "on inf", "-inf", or "nan" has the correct meaning input.
> This should be cleaned up.

I don't understand, what's "on inf"?

Defining inf and nan as const variables in the library would probably do 
the trick. In fact, this is what I do (for inf) in some of my scripts.

> Furthermore, currently an attempt to do a floating-point division by
> zero is made to fail, rather than returning the IEEE-appropriate results
> (negative or positive infinity, unless the numerator is also zero,
> in which case NaN).

That's easy to fix. If I don't hear any objections, I'll do that tomorrow.

> This should be cleaned up by defining a syntax for these values to
> be used on input and output, and by not failing when doing a floating
> division by zero (though an exact division by zero should still fail).

Is there a portable way to check for inf and nan values? (So that I 
don't have to rely on the C library to do the right thing when printing 
those numbers.)

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

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

John Cowan wrote:
> In particular, "1 over 5+2 over 3" looks totally wrong for 1/5 + 2/3;

Of course, the same issue arises with "div". But then again you don't 
see that very often in expressions printed by the interpreter.

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

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

John Cowan wrote:
> I'm not happy with "over" as the notation for rational numbers.
> In particular, "1 over 5+2 over 3" looks totally wrong for 1/5 + 2/3;
> the visual grouping is hopelessly broken.  I realize that we can't use
> "/" for this purpose, but can't we use another symbol operator?

Actually I've been tossing around the idea to make the "/" builtin 
undefined on Int Int so that it could be defined in the library. But 
that would probably break just about any Q script out there, so it's not 
really an option.

> 
> I would propose "|", which is visually close to "/" and is used in the
> "units" program for the same purpose.  A non-ASCII alternative would be ÷
> (division sign).  These would be very minor changes to the lexer.

"|" is not possible as it is already used as a delimiter in 
list/stream/tuple notation, so we'd get very evil ambiguities in the 
expression grammar. And I don't like the idea of using something which 
is not 7 bit ASCII. Of course a programmer can easily define his own 
aliases using extended characters, but the language and the library 
should be 7 bit only IMHO.

So I'm afraid that the only 7 bit ASCII punctuation symbol that's left 
is "%" (incidentally, this is also what Haskell uses for the same 
purpose). It's been a while since this has been used as a comment 
character, so I'd say it's safe to reuse it now. Then you could type 
your example as "1%5 + 2%3". Acceptable?

ATM user-defined operator symbols can only be made from punctuation 
symbols outside the 7 bit range, but I guess that I could change that, 
even if it's only to be used in this single case.

Rob, what's your take on this? Do you prefer "over" or "%"? After all 
it's your module. ;-)

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

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

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

John Cowan wrote:
> I am not happy with the names of the syntactic vs. semantic number
> predicates.  Currently it is isint, isrational, isreal, etc. for syntactic
> (representation) predicates, and isintnum, isratnum, iscompnum etc. for
> semantic (value) predicates.  This is intended to be consistent with
> isbool, isfile, islist etc., which are syntactic; however, it is only
> with numbers that this dichotomy between syntactic and semantic types
> is really necessary.

I can understand your issues, but swapping the names of the semantic and 
the syntactic predicates will even create more confusion (unless I also 
change the type names, of course, but I'm not inclined to do so).

So we'll have to change the name of the semantic predicates then. Any 
suggestions? How about intp, rationalp, realp, complexp? Looks familiar 
to Lisp programmers, non-Lispers will surely hate it, but it is short 
and at least reminiscent of the Scheme functions.

> (By the way, does Q use any sort of fixed-width integer representation
> internally, or are all integers in GMP format internally?  I'm just
> curious.)

GMP everywhere, there are no machine integers in Q. :)

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

[q-lang-users] Q 7.2 RC1 Issue 4: isinfty

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

The current test for infinity also applies to NaNs.  These should be
split into isinfty and isnan, perhaps depending on the fact that nan +
nan = nan, whereas infinity plus itself is also nan, not infinity.

-- 
Andrew Watt on Microsoft:                       John Cowan
Never in the field of human computing           co...@cc...
has so much been paid by so many                http://www.ccil.org/~cowan
to so few! (pace Winston Churchill)

[q-lang-users] Q 7.2 RC1 Issue 3: IEEE floats

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

Currently, Q floating-point operations do not conform to IEEE floats,
even though that is the underlying implementation on all important
machines.  Specifically, the support for infinities and NaNs is deficient.
Currently, the following expressions are evaluated as follows:

==> def pinf = 1.0e307 * 1.0e307
==> def ninf = -pinf
==> pinf
inf
==> ninf
-inf
==> pinf + ninf
nan

But none of "on inf", "-inf", or "nan" has the correct meaning input.
This should be cleaned up.

Furthermore, currently an attempt to do a floating-point division by
zero is made to fail, rather than returning the IEEE-appropriate results
(negative or positive infinity, unless the numerator is also zero,
in which case NaN).

This should be cleaned up by defining a syntax for these values to
be used on input and output, and by not failing when doing a floating
division by zero (though an exact division by zero should still fail).

-- 
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <co...@cc...>

[q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

I'm not happy with "over" as the notation for rational numbers.
In particular, "1 over 5+2 over 3" looks totally wrong for 1/5 + 2/3;
the visual grouping is hopelessly broken.  I realize that we can't use
"/" for this purpose, but can't we use another symbol operator?

I would propose "|", which is visually close to "/" and is used in the
"units" program for the same purpose.  A non-ASCII alternative would be ÷
(division sign).  These would be very minor changes to the lexer.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 co...@cc...
 I wish it were impossible."                    http://www.ccil.org/~cowan

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

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

I am not happy with the names of the syntactic vs. semantic number
predicates.  Currently it is isint, isrational, isreal, etc. for syntactic
(representation) predicates, and isintnum, isratnum, iscompnum etc. for
semantic (value) predicates.  This is intended to be consistent with
isbool, isfile, islist etc., which are syntactic; however, it is only
with numbers that this dichotomy between syntactic and semantic types
is really necessary.

I want to argue two things: that semantic predicates are more fundamental
and deserve the shorter names, and that (in the alternative) the
particular names "isintnum", "isratnum", etc.  are very unfortunate.

Fundamentally, a number is a number, and its representation is a
low-level issue.  What counts is that a number actually is or is not
complex, or rational, or an integer; not what its representation may be.
Representations matter only when considering efficiency, which is a
second-order concern in Q.  It is better to use isinteger to determine if
something really is an integer rather than to determine if its internal
representation is a GMP integer.

(By the way, does Q use any sort of fixed-width integer representation
internally, or are all integers in GMP format internally?  I'm just
curious.)

In addition, Q's numeric tower is now modeled on that of Scheme,
but the names are exactly the opposite of Scheme's.  In Scheme, the
predicate "rational?" tests for a rational number, not for a (numerator,
denominator) representation -- and the nickname for such a representation
is "ratnum".  So people like me who use both Scheme and Q will need
to remember that the names have exactly opposite meanings in the two
languages.  This is regrettable.

-- 
One Word to write them all,             John Cowan <co...@cc...>
  One Access to find them,              http://www.ccil.org/~cowan
One Excel to count them all,
  And thus to Windows bind them.                --Mike Champion

Re: [q-lang-users] Q 7.2 RC1 available

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

Albert Graef scripsit:

> I've just uploaded a candidate for the upcoming 7.2 release. It is 
> available here:

First of all, this release builds and installs properly on Cygwin.
So that's one thing out of the way.  I do have a number of issues with
the new features, though.  To prevent this email from growing too large,
I will post each issue separately.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
In computer science, we stand on each other's feet.
        --Brian K. Reid

[q-lang-users] Q 7.2 RC1 available

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

Hi all,

I've just uploaded a candidate for the upcoming 7.2 release. It is 
available here:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=425798

New in this release:

- a hook into the expression printer which allows you to define custom 
unparsings for all data types ('unparse' function)

- a revision of Q's numeric tower, which now also includes a 'Real' type

- overhaul of complex.q (complex numbers are now represented using an 
algebraic type 'Complex')

- integration of rational.q into the standard library (only the 
'Rational' type and basic rational arithmetic is defined in this module, 
the remaining operations from Rob Hubbard's "Q+Q" library are in a 
separate add-on package which is now also included in binary releases)

- new Scheme-like semantic number type predicates in typec.q, as 
suggested by John Cowan

More details can be found in the release notes, available here:
http://sourceforge.net/project/shownotes.php?release_id=425798&group_id=96881

It would be nice if you could all test the new rational and complex 
number implementations, so that any remaining bugs can be ironed out 
before the final release.

Rob, I hope I did an acceptable job integrating your library, if not 
then please complain. ;-) The documentation in rational.pdf needs some 
minor updates as detailed in private mail. It would be nice if you could 
have a look at that, and please let me know if you find anything in the 
rational number support that still needs to be changed before the final 
release. And thanks a lot again for making "Q+Q" available, this is 
really an important addition to the library!

John, the rational number constructor is named "rat", in case you need 
that for your Q egg for Chicken. It's a private symbol, so you probably 
have to use a qualified identifier like "rational::rat" to access it via 
libqint.

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

Re: [q-lang-users] Exponentiation operator

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

John Cowan wrote:
> I can live with it, I think, as long as all operators do appropriate
> argument promotion.  In particular, the numeric comparisons should work properly
> in all cases except ordering involving complex numbers.

Yes, that's the case already in the current release, and will still work 
in Q 7.2 when rational.q will be part of the standard library.

> I now think that ^ should always return a float (transcendental exponentiation)
> whereas pow should accept any exact left argument and integer right argument
> and return an integer or rational result.

Right, that's how it's going to be (I think that Rob's implementation 
already does this).

Ok, so it looks like this is resolved. Back to coding. :)

Thanks for the replies,
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

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

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

John Cowan wrote:
> I would assume these predicates return false on non-numbers.

Hmm, I wouldn't. The concept of 'exactness' applies to numbers, so I 
would let isexact fail on objects which are not of type Num. But of 
course in Q it's easy for the programmer to then just add an equation 
'isexact _ = false otherwise' to his application if he thinks that this 
is more appropriate.

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

Re: [q-lang-users] Exponentiation operator

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

Albert Graef scripsit:

> Ok, so that would mean that we never promote the result to a type less 
> general that the argument types. Fair enough. That's what effectively 
> happens in Haskell, too, AFAICS.
> 
> John, you argued in favour of "auto-simplification", do you think you 
> can also live without it?

I can live with it, I think, as long as all operators do appropriate
argument promotion.  In particular, the numeric comparisons should work properly
in all cases except ordering involving complex numbers.

I now think that ^ should always return a float (transcendental exponentiation)
whereas pow should accept any exact left argument and integer right argument
and return an integer or rational result.

-- 
John Cowan    <co...@cc...>     http://www.ccil.org/~cowan
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.

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

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

Albert Graef scripsit:
> John Cowan wrote:
> >>Like isintnum, iscomplexnum, etc. Maybe we should also add isexact?
> > 
> > Sounds good.  And isinexact (which would be true of floats and of
> > complex numbers with at least one float component).
> 
> Wouldn't 'isinexact' simply be the negation of 'isexact'?

I would assume these predicates return false on non-numbers.
(In fact, the Scheme equivalents throw errors on non-numbers, which
I consider a defect.)

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
        --Gerald Holton

Re: [q-lang-users] q in Q

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

John Cowan wrote:
> See http://lemick.sourceforge.net/papers/JIT_design.pdf for a brief paper.

Looks interesting, thanks for the link!

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

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

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

John Cowan wrote:
>>Like isintnum, iscomplexnum, etc. Maybe we should also add isexact?
> 
> Sounds good.  And isinexact (which would be true of floats and of
> complex numbers with at least one float component).

Wouldn't 'isinexact' simply be the negation of 'isexact'?

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

Re: [q-lang-users] Exponentiation operator

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

Rob Hubbard wrote:
> All the functions return a "normalised" value. Thus a simple way to 
> implement the other behaviour is to change "normalisation" to reduce to 
> Int when possible.

You will find that those cases are already treated separately (for 
optimization purposes) in the prototype stdlib rational.q that I sent 
you in private mail. So the necessary changes are in fact trivial.

> There's a chance that some of my algorithms will need 
> to be tweaked afterwards, as sometimes I assume in some private 
> functions that a value is in the form (rat N D).

Those parts of your module will end up in the separate ratutils.q module 
and thus need to be rewritten anyway, because ratutils won't have access 
to the rat constructor any more (which is private to rational.q). I've 
already checked this, the necessary changes should be rather minimal.

BTW, even if we don't decide for the "auto-simplification", I'd like to 
propose that the numerator, denominator and num_den functions should 
accept Int arguments, too, then _all_ operations in the rational base 
module would work on Rational and Int alike. This would also be 
analogous to complex.q, where 're' and 'im' are also defined on Real.

> I think that the behaviour ought to follow the style of what you do with 
> (^).

Ok, so that would mean that we never promote the result to a type less 
general that the argument types. Fair enough. That's what effectively 
happens in Haskell, too, AFAICS.

John, you argued in favour of "auto-simplification", do you think you 
can also live without it?

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

Re: [q-lang-users] Exponentiation operator

[Rob H. <hub...@gm...>]

John Cowan wrote:
> Albert Graef scripsit:
>   
>> A related question is whether rational arithmetic should return an Int
>> instead of a Rational when the denominator of the result is 1.
>>     
>
> I think it should, yes.  And likewise when the numerator is 0.
>   

The Rationals are normalised (that is, they are reduced to have a 
positive denominator, and coprime numerator and denominator). So, when 
the numerator is 0, the denominator is 1. Thus the denominator  is 1 
exactly when the overall value is integral.

Re: [q-lang-users] Exponentiation operator

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

Rob Hubbard wrote:
> (2) A value of a type as simple as possible (up to the simplicity of the 
> arguments perhaps): thus Int if possible, otherwise Rational if 
> possible, otherwise Real if possible, otherwise (perhaps) Complex (e.g. 
> (-1)^(1/2) would be complex).

I suppose you mean "Float" rather than "Real" here. ("Real" is similar 
to "Num" in that it's an abstract type with no objects of its own. It's 
just a common umbrella for Int, Float and (soon) Rational.)

> That is, I think either
> (1) no attempt at all should be made to return an exact value in a 
> suitable type; a Float should be returned where possible (i.e. where 
> defined and Real), or
> (2) a thorough attempt should be made.

I foresee that (2), while desirable, would mean a lot of complication. 
In particular, we need to be able to check whether a given root of a 
bigint is again a bigint, _without_ converting to an inexact 
representation somewhere in that decision procedure. Thus I'm leaning 
towards solution (1). Q is not supposed to be a computer algebra system 
after all, and the pow function is there if an exact solution is needed, 
in cases where its existence is obvious. The rest should be the burden 
of the application programmer. :)

So that means that exponentiation yields a Float result if it exists, 
and a Complex result otherwise. In fact this is the way it is 
implemented right now, but this would then also apply to the Rational type.

> That doesn't really answer the question does it??

It does, since it helped to remind me that innocent-looking changes 
sometimes have dramatic consequences. ;-)

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

Re: [q-lang-users] q in Q

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

Albert Graef scripsit:

> Yes, we already discussed this here a while ago... Translating Q's 
> bytecode would be the most straightforward approach. JIT compilation 
> looks nice, but I'm also considering compilation to C or maybe Ksi (the 
> latter approach would be tied to gcc, however). This is still a while 
> away, though (I first want to resolve all the remaining portability 
> issues and finish the Q companion book).

Sure.  There's a neat trick for fairly portable JIT compilation: you
wrap a block of code using labels, and then use memcpy to copy
everything from one label to the next into a buffer area.  Do that
for each bytecode and you've built up your compiled code in the buffer.
That way you have no dependency on assembly language.

See http://lemick.sourceforge.net/papers/JIT_design.pdf for a brief paper.

-- 
Possession is said to be nine points of the law,                John Cowan
but that's not saying how many points the law might have.       co...@cc...
        --Thomas A. Cowan (law professor and my father)

Re: [q-lang-users] Exponentiation operator

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

Albert Graef scripsit:

> Now I'm reconsidering this. Maybe it would be better if ^ actually 
> returned an Int where this is possible, and a Float otherwise? (This 
> wouldn't be possible in a language with static typing like Haskell, of 
> course, but Q doesn't have this problem.) A similar issue arises with 
> the definition of ^ for Rational. Should Rational ^ Int be a Rational? 
> Or a Float, like Rational ^ Rational and Rational ^ Float are?

I'd split ^ into two operators, one to return a Float (perhaps ^) always,
and one to return an exact result where possible, a Float where necessary
(perhaps **, perhaps pow).

> A related question is whether rational arithmetic should return an Int
> instead of a Rational when the denominator of the result is 1.

I think it should, yes.  And likewise when the numerator is 0.

I also think, for the same reasons, that a complex operator should
return a Real when the imaginary part is 0 (but not 0.0), for reasons
stated before.

-- 
Knowledge studies others / Wisdom is self-known;      John Cowan
Muscle masters brothers / Self-mastery is bone;       co...@cc...
Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)

Re: [q-lang-users] Exponentiation operator

[Rob H. <hub...@gm...>]

Albert Graef wrote:
> A related question is whether rational arithmetic should return an Int 
> instead of a Rational when the denominator of the result is 1. Rob, what 
> is your take on this? In your current implementation it will always 
> return a Rational, right?
>
> Albert
>
>   
Yes, currently a Rational is returned even if the value could be float.

All the functions return a "normalised" value. Thus a simple way to 
implement the other behaviour is to change "normalisation" to reduce to 
Int when possible. There's a chance that some of my algorithms will need 
to be tweaked afterwards, as sometimes I assume in some private 
functions that a value is in the form (rat N D). Thus perhaps there 
should be separate "normalisers" for producing intermediate values, and 
for returning values to a the public interface.

I think that the behaviour ought to follow the style of what you do with 
(^).

There are pros and cons with either approach. On the one hand, always 
having a Rational gives you certainty of type. On the other hand, having 
a simpler type returned may be an advantage, especially when that's an 
intermediate value.

Rob.

Re: [q-lang-users] Exponentiation operator

[Rob H. <hub...@gm...>]

I would prefer either:

(1) Always a float, or
(2) A value of a type as simple as possible (up to the simplicity of the 
arguments perhaps): thus Int if possible, otherwise Rational if 
possible, otherwise Real if possible, otherwise (perhaps) Complex (e.g. 
(-1)^(1/2) would be complex).

That is, I think either
(1) no attempt at all should be made to return an exact value in a 
suitable type; a Float should be returned where possible (i.e. where 
defined and Real), or
(2) a thorough attempt should be made.

With (2), I would like to see (1 over 100)^(1 over 2) return (1 over 10).

I would also expect the algorithm for (2) know that (N over 1) is an 
integer.

On the other hand, I would not expect the algorithm to recognise that 
e.g. 0.5 = 1/2. It's fair for the algorithm to assume that a value 
expressed in a given inexact type can not be expressed exactly as a 
simpler type.

[Perhaps there should be operators to do both.]

When both (1) and (2) produce values, those values should be "equal" (in 
some sense; the problem is of course that you can't rely on testing 
equality of floats). That's quite a tall order as X^(1/N) has N complex 
values, so great care would need to be taken in choosing the "principal 
value".

One possibility for the algorithm is to (a) first find a complex value, 
then (b) attempt a series of simplifications somehow.

That doesn't really answer the question does it??

Rob.

Re: [q-lang-users] Exponentiation operator

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

A related question is whether rational arithmetic should return an Int 
instead of a Rational when the denominator of the result is 1. Rob, what 
is your take on this? In your current implementation it will always 
return a Rational, right?

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

[q-lang-users] Exponentiation operator

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

The built-in ^ operator currently returns a floating point value in all 
cases. That makes sense, because it is supposed to work with negative 
and fractional exponents too, so this seems to be the only way to make ^ 
work consistently. For the case of integer bases and positive integer 
exponent there's the pow function which returns an Int value.

Now I'm reconsidering this. Maybe it would be better if ^ actually 
returned an Int where this is possible, and a Float otherwise? (This 
wouldn't be possible in a language with static typing like Haskell, of 
course, but Q doesn't have this problem.) A similar issue arises with 
the definition of ^ for Rational. Should Rational ^ Int be a Rational? 
Or a Float, like Rational ^ Rational and Rational ^ Float are?

Comments appreciated. :)

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