Re: Complex numbers & Oakwood suggestions

[Brian Hawley <bhawley@luc.edu>]

I wrote:
[Argument that the complex number libs should be implemented differently,
 propose recycling functional notation...]

Mike Griebling <grieblm@trt.allied.com> wrote:
[Argument that the details of the COMPLEX internals should be hidden,
 aliasing problem with my notation, suggestion of alternate means of
recycling the numbers and of disallowing assignment...]

I was kicking myself when I read your comments. I agreed with almost every
one. Of course the recycling should be handled by the implementer; what was
I thinking? Immutable complex numbers are a good idea because they would 
lead to a functional style of programming, a good mindset to be in when you
are doing mathematical code. This would also require that the fields of the
COMPLEXDesc record be hidden, and perhaps the COMPLEXDesc type too depending
on the assignment rules for records with hidden fields. This would hide the
implementation details nicely (that seems a little silly; how else would you
put together a Cartesian complex number? :).

I disagree with you about the Low* modules; I think that we should still have
them. There is no reason that the Low* modules should show the implementation
details, and it would help to consolidate code that could be used standard
and array math modules. 

Howabout I rearrange your code to use Low* modules? It wouldn't be that hard
and then we could have something concrete to arge about. I'll even throw in
our polar complex code in that style and have our best math head look your
code over (it looks great to me, but he might see something I wouldn't).

On to the next subject...

Michael Acken <acken@informatik.uni-kl.de> wrote:
[Proposal to add complex numbers in the Oakwood style to OOC...]

The Oakwood guidelines provide many excellent arguments themselves against 
such a proposal, but I can think of a few others. Complex numbers can be 
implemented using the *REAL types well enough, and they are only of use to 
a relatively small number of people. Oberon is meant to be a simple, small
language. A complex number library that is implemented using functional 
notation would not be much different in practice to use than a built-in 
type--you would have to put the module name before the functions, but that's
what aliased module imports are for.

My arguments to this point have been mostly about efficiency issues. I don't
actually need to use complex numbers for my work, since I do mostly language 
and UI design. Most of what I know about them has come from Michael Smith, a
friend and industrial-strength math head. He and I implemented libraries for
complex numbers in Oberon; he did the algorithms and I programmed them. Mike
has seen the Oakwood guidelines, and he doesn't like them. His major concern
is that they are implemented in the Cartesian style. Despite the popularity
of Cartesian complex numbers, Mike has shown me that polar numbers are much
more efficient for a wide variety of tasks. When we implemented our complex
library, we chose not to take sides on the issue and did the full set of 
functions for both types of complex numbers.

If we are going to extend the language we should start with array literals,
constructors and operations in the Oberon/V style. Despite the fact that V
was designed for numeric programming, the array extensions can be useful for
general purpose code as well. If you doubt this, take a look at how they are
used in the Object Pascal language of Borland Delphi. They use open array
parameters and literal arrays to implement type-safe variable arguments. I 
would love to be able to do that in Oberon. That same notation could be used
for calls to external C functions as well. The array ops could also increase
optimization opportunities on systems with pipelines or multiple processors 
(like your BeBox, Mike :). 

What do you think?
Brian Hawley
bhawley@luc.edu