I am interested to see that D has a built in complex.

I can do

complex z = 1. + 2.i

but

extended r = z.re;

will not compile (nor will z.im).

How can a complex number value be output?

On a point of strategy, an operator is needed to extract the imaginary part without the i.  This is the usual role played by the imaginary operator in other languages.

The complex number is in many ways just an ordered pair of numbers (x,y) with particular rules for manipulation.  It is often needed to extract the real and imaginary parts to compute other properties

e.g.   sqrt(x^2 + y^2)     and atan(y/x)

for which access to the numerical value is needed.

Cheers

John


P.S. Thanks for all the good work.

"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C512862.EB749F7A@aston.ac.uk...
> I am interested to see that D has a built in complex.
> I can do
> complex z = 1. + 2.i
> but
> extended r = z.re;
> will not compile (nor will z.im).

Sounds like a bug!


> How can a complex number value be output?

A printf with z.re, z.im.


> On a point of strategy, an operator is needed to extract the imaginary part without the i.  This is the usual role played by the imaginary operator in other languages.
>
> The complex number is in many ways just an ordered pair of numbers (x,y) with particular rules for manipulation.  It is often needed to extract the real and imaginary parts to compute other properties
>
> e.g.   sqrt(x^2 + y^2)     and atan(y/x)
>
> for which access to the numerical value is needed.
>
> Cheers
>
> John
>
>
> P.S. Thanks for all the good work.

It's actually fun.

Walter wrote:

> "John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C512862.EB749F7A@aston.ac.uk...
> > I am interested to see that D has a built in complex. [...] How can a complex number value be output?
>
> A printf with z.re, z.im.

Yet annother reason why I strongly advocate for classes and
operator
overloading.

The benefits:

- Ordinary math syntax for complex calculation for _all_
kind of base type
- IO can be overloaded to use same syntax as ordinary
numbers
- And most important hint to Walter: If it is not done in
the language proper, others have done or will do that silly
work (and btw. there exist good samples of complex classes
in C++ to see how it can be done). (Divide and conquer ;-)


The disadvantage

- Some silly guys will abuse operator overloading. But you are not going to tell me that you can avoid this in D - language anyhow?

HE

Walter wrote:

> "John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C512862.EB749F7A@aston.ac.uk...
> > I am interested to see that D has a built in complex.
> > I can do
> > complex z = 1. + 2.i
> > but
> > extended r = z.re;
> > will not compile (nor will z.im).
>
> Sounds like a bug!
>

It just says

no property 're' for type 'complex'

John

"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C55246C.213B384@aston.ac.uk...
>
>
> Walter wrote:
>
> > "John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C512862.EB749F7A@aston.ac.uk...
> > > I am interested to see that D has a built in complex.
> > > I can do
> > > complex z = 1. + 2.i
> > > but
> > > extended r = z.re;
> > > will not compile (nor will z.im).
> >
> > Sounds like a bug!
> >
>
> It just says
>
> no property 're' for type 'complex'

I have it fixed now, it'll go out in the next upload. -Walter

Just don't be C++ addicted. :/ T o be good and practical there must be more restrictions for "silly guys" applied. :)

H. Ellenberger wrote:

> Walter wrote:
> 
> 
>>"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message
>>news:3C512862.EB749F7A@aston.ac.uk...
>>
>>>I am interested to see that D has a built in complex. [...]
>>>How can a complex number value be output?
>>>
>>A printf with z.re, z.im.
>>
> 
> Yet annother reason why I strongly advocate for classes and
> operator
> overloading.
> 
> The benefits:
> 
> - Ordinary math syntax for complex calculation for _all_
> kind of base type
> - IO can be overloaded to use same syntax as ordinary
> numbers
> - And most important hint to Walter: If it is not done in
> the language proper, others have done or will do that silly
> work (and btw. there exist good samples of complex classes
> in C++ to see how it can be done). (Divide and conquer ;-)
> 
> 
> The disadvantage
> 
> - Some silly guys will abuse operator overloading. But you
> are not going to tell me that you can avoid this in D -
> language anyhow?
> 
> HE
> 

You can only abuse operator overloading if operator function "overlaying" exists.

You can get the same benefits of operator overlaying by defining new operatores rather than foolishly altering the meaning of existing ones.

Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?


H. Ellenberger <ele1@gmx.ch> wrote in message news:3C5297FD.F8957AD5@gmx.ch...
> Walter wrote:
> - Some silly guys will abuse operator overloading. But you
> are not going to tell me that you can avoid this in D -
> language anyhow?

"D" <s_nudds@hotmail.com> wrote in message news:a3lhlb$rap$1@digitaldaemon.com...

> You can only abuse operator overloading if operator function "overlaying" exists.
>
> You can get the same benefits of operator overlaying by defining new operatores rather than foolishly altering the meaning of existing ones.
>
> Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?

But then again, speaking of vectors, what are you going to use instead of plus to add them, if you don't like "overlaying"?

"D" <s_nudds@hotmail.com> wrote in message news:a3lhlb$rap$1@digitaldaemon.com...
> You can only abuse operator overloading if operator function "overlaying" exists.
>
> You can get the same benefits of operator overlaying by defining new operatores rather than foolishly altering the meaning of existing ones.
>
> Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?
>

People keep mentioning that example (and it is a good one), but
how many examples like that are there really? Defining new
operators might be great and it might not, but it seems strange to
me if you could define new operators such as for square root, or
dot product or sum (or what is that strange E called in English :) ),
but not for very basic operations such as =, ==, +, -, * and /. To me,
defining new operators seems like operator overloading 'on steroids'.
Why do you oppose overloading of simple operators but support
the more powerfull 'operator overloading on steroids'?
I use operations like comparisons and assignments much more than
square root, especially for classes...
Sorry D if I seem harsh, but you take strong positions, so you
get strong replies. You speak your mind though, and stir up some
dust, and I like that!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

A new operator that I define.  Perhaps I will call it .+ or .v+ where the v indicates a user defined vector operation.

Now that I have answered your question, please answer mine.

Pavel Minayev <evilone@omen.ru> wrote in message news:a3llg0$t0a$1@digitaldaemon.com...
> But then again, speaking of vectors, what are you going to use instead of plus to add them, if you don't like "overlaying"?