Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> Is there some particular reason why complex numbers (in complex.q)
> are not a type Complex with a constructor comp_rect?  This
> would be helpful for clean conversion from and to Scheme, and would
> allow the addition of polar complex numbers if someone needs them.

No other than that mathematicians since Euler himself actually think of 
them as points in the complex plane. So pairs of numbers seemed to be 
the most obvious representation to me, at the time (several years ago) I 
wrote this module.

Incidentally, I've discussed this with Rob in private mail a few days 
ago, who reminded me of my own proposal on the ML to change this. I 
didn't get much feedback then, almost one year ago, so I eventually 
didn't bother to make the change. Maybe we can discuss this now and 
settle it once and for all.

I agree that the algebraic type representation has its advantages. It 
would make complex numbers a real type which could be used as a guard 
and which could even become a subtype of Num as it should be. And it 
would also be consistent with Rob's rational number representation, if 
his "Q+Q" module becomes part of the standard library in the future.

The only real problem I see is readability, compare (7,5) to something 
like "comp_rect 7 5". Rob's module has a similar issue (not that there's 
currently much that he can do about it), the rational number X/Y is 
represented as "rat X Y".

Therefore I'm currently considering the idea to provide a hook into the 
expression pretty-printer which would make it possible to define a 
custom unparsing for certain types of objects. (Of course the defined 
unparsing would have to be reparseable so that it can reconstruct the 
original object. Like compiled lambdas unparse into a lambda expression 
in Q 7.1.) Then you could define, say,

unparse (comp_rect X Y) = '(X+Y*i);

and have 'i' defined as complex 0 1 in complex.q, so that X+Y*i would 
actually reconstruct comp_rect X Y. Note that the unparse hook, or 
whatever we'd call this function, would in fact return a quoted term and 
not a string to the pretty-printer. That makes sure that the unparsing 
is at least something that is reparseable, and gives the pretty-printer 
a chance to figure out the proper precedence level for the expression.

Of course this goes a long way to handle such simple things like complex 
or rational numbers. But this feature could be useful for other data 
types, too, in particular external types. What do you all think about 
it? Is it "the right thing"?

> (Of course, it would be even cooler if 2i, which is currently
> the useless application of 2 to i, were syntax sugar for
> "comp_rect 0 2".)

Hmm, didn't we have enough of that syntax candy already with the last 
release? ;-) I'd prefer the X+Y*i notation I suggested above, that's 
almost as tidy and you don't need any special syntax to support that.

Opinions? Other ideas?

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