Re: [q-lang-users] Q 7.2 RC2

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

John Cowan wrote:
> I've tested some corner cases against RC3; I never did test RC2.

Hi John, thanks a lot for taking the time to test again.

> 1) Comparisons against nan still return false (per IEEE) rather than
> failing, which we had agreed is more Q-ish.

Yes, this was one of those ideas that sound nice in theory but turn out 
awful in practice. ;-) Having nan comparisons fail means that most 
definitions involving comparisons with numbers would have to check for 
nan values to avoid exceptions on failing conditions, which turns even 
the simplest numeric algorithms into a big unholy mess. So I decided to 
do it the IEEE way instead.

> 2) 3/0 and 3%0 both return the normal form 3/0.  Since / is now supposed
> to always return inexacts, I think these should return inf and 3%0
> respectively.

Yes, I have to agree that 3/0 should now return inf instead of failing, 
although that introduces a big incompatibility with earlier versions. :(

I'm not so sure about 3%0, though. As I argue under item 6 below, for me 
the right way to implement (%) on inexact numbers is the way it is done 
now, i.e., to fall back to inexact division. But inexact division 
returns (or rather will return when I fixed it) inf in this case. So 
there is a case for having 3%0 evaluate to inf, too. X%0 should still 
fail if X/0 does (the current definition isn't working correctly in that 
case, but I've fixed that now). However, AFAICT this case wouldn't 
actually arise any more.

> 3) Making sure that those really were normal forms made me aware of
> just how useful it would be to be able to turn off unparsing and then
> turn it on again easily.  I had to use my Chicken interface to make
> sure I wasn't being fooled.  An interpreter command would make sense.

Well, as I pointed out earlier there's already the possibility to just 
add a definition like "unparse = ();" to your script which has the 
effect of disabling all custom unparsings. But I agree that there should 
be a simpler way. Probably an "unparse" command taking an on/off arg, 
like "debug".

> 4) You had said earlier that you would provide unparsing rules for dict
> and the other container types.

I'm still undecided on this, because everything I do in the library sets 
a precedent that needs to be followed later. Numbers are a rather 
specific case, and it certainly makes sense to include default unparsing 
rules for complex and rational numbers in the library. But I'm not so 
sure whether this is the right thing for the container data structures 
yet, so I just postponed that decision. For the time being, you can 
easily add your own unparsing definitions for those data structures if 
you want/need them; they're all one-liners. :)

> 5) Nan is returning true for isratval and isintval, when it should return
> false; by convention, a NaN is real but not rational.

isintval nan correctly returns false over here, but isratval nan 
incorrectly returned true. That has been fixed.

> 6) When % is called on floats, the result is a float.  Ideally, 2.5%1
> should return 5%2, though I don't insist that the best possible fraction
> should be returned, just some reasonable fraction.  This may be best
> done in C, where you can call useful functions like frexp().

No, I have to disagree. That would promote the result to a more specific 
type than the operands and we all agreed that this should never be done. 
Therefore, if (%) is to work on all numbers (which is a good thing, 
IMHO) then the right way to do this is to fall back to inexact division 
on inexact operands.

Besides, there's also the issue that there's no single "canonical" way 
to do the rational approximation. So I think that it's much better to 
leave that to a separate module (like Rob's ratutils.q) which can do a 
much more comprehensive job and provide different kinds of specialized 
approximation algorithms.

> 7) This brings up the issue of coercions from exact to inexact (easy,
> just need a special case for complex numbers) and for inexact to exact.
> These should be in the library somewhere.

In fact they are. There's float to convert any Real number to a Float, 
there are round, trunc, floor and ceil to go the opposite direction, and 
there are Rob's Float -> Rational approximation algorithms. If needed, 
these can be applied to the real and imaginary components of Complex. 
What else do you need?

Granted, you can't just apply, say, round to Complex, but usually that 
doesn't make mathematical sense anyway. The library cannot know whether 
you'd prefer to round according to, e.g., the 1-, 2- or maybe the \infty 
norm, that should be up to the application.

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