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

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

John Cowan wrote:
> I agree: we need different operators for exact and inexact division.

There's one last issue concerning division that we should think about 
before the final release: How should (/) behave with rational (and 
complex rational) operands?

Note that (%) returns an exact (rational or complex rational) result for 
any combination of exact operands, and that's what it's supposed to do.

With (/) we currently (RC2) have that (/) returns a Float if both 
operands are Int and a Rational if at least one of them is a Rational. 
That's also the way it works in Haskell:

Haskell (Hugs, May 2006 version):
Ratio> 12/8
1.5
Ratio> 12%1/8
3 % 2

Q (7.2 RC2):
==> 12/8
1.5
==> 12%1/8
3%2

In Q the same also applies to complex integer vs. complex rational values:

==> 1/i
0.0-1.0*i
==> 1%1/i
-(1%1)*i

But note that the machinery behind this in Haskell is quite different 
from Q. In Q there is *only one* (/) function which happens to be 
defined on both Int and Rational, so we have ad-hoc polymorphism here. 
In contrast, in the Haskell example the two instances of (/) come from 
two different instances of the Fractional type class and so they are in 
fact *two different* functions which just happen to be called by the 
same name. (At least that's how I understand the notion of type classes 
in Haskell. I'm not an expert Haskell programmer, so someone please 
correct me if I'm wrong.)

Therefore one could argue that in Q, following the principle of the 
least surprise, one should expect that (/) _always_ denotes inexact 
division and thus 12%1/8 should return 1.5 just like 12/8. This would 
also be consistent with the behaviour of (^) which also returns inexact 
values for all combinations of operands.

What do you all think? Should (/) always return inexact results? Or 
would you prefer exact results when possible? (With the notable 
exception of the builtin (/): Int Int -> Float; we really need to keep 
this for backward compatibility, and thus (/) on complex integers should 
also return inexact values.)

(Rob, I realize that changing (/) to always return inexact results might 
break ratutils.q in some places. But that should be easy to fix if we 
use (%) instead of (/) in those situations.)

Comments?

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