Andrei Alexandrescu Wrote:

> Nick Sabalausky wrote:
> > "Justin Johansson" <n...@spam.com> wrote in message 
> > news:haavf1$2gs...@digitalmars.com...
> >> It's a difficult challenge to get high performance, readable and 
> >> maintainable code out of complex number
> >> intensive algorithms.   Use of library types for complex numbers has, in 
> >> my experience been problematic.
> >> Complex numbers should be first class value types I say.
> >>
> > 
> > There's been discussion before (I can't find it now, or remember the name 
> > for it) of type systems that allow for proper handling of things like m/s 
> > vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a feature 
> > or with complex/imaginary numbers in any actual code, so I can't be sure, 
> > but I've been wondering if a type system like that would be an appropriate 
> > (or even ideal) way to handle real/complex/imaginary numbers.
> 
> It better be. Complex numbers aren't that complicated of a notion. 
> What's lost in pulling them out of the language is the ability to define 
> literals.

> "Now please name five remarkable complex literals."

(re, im) ::= (0, 0), (1,0), (0,1), (1,1), (pi/2, 0), (0, pi/2), 
e_to_the_power_(minus j),
 e_to_the_power_(minus j * pi/2)

Is that what you mean?

Guess one has to study Maxwell's equations, microwaves and the black art of 
Smith Charts to
appreciate .. not that anyone really cares too much these days .. no need to 
design antennae
for transmitters and receivers from scratch now that microwave towers and 
iPhones are consumer items.

(FYI, Electrical engineers use j and mathematicians use i to denote sqroot(-1). 
 We do that
since the letter i is conventionally used for current (as in amperes)).

-- Justin

Reply via email to