Hi there,

sorry, but with these names for complex and imaginary numbers, you have created a joke among mathematicians for the years to come!

Why not rename these types to "complex" and "imag" and make code much more
readable? OK, the list
        float
        double
        real
        ifloat
        idouble
        imag
        cfloat
        cdouble
        complex
might not look quite as regular, but since most people will only work with
"real","imag" and "complex" (everything else is just for special cases and
compatibility) you would *really* improve readability!

Another detail concerning complex numbers:
        a.im
should really return a real number. Looking at all mathematics text books
all over the world, the function Im(a+bi) is defined to return the real
number b.

Ciao,
Nobbi

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c657eq$2loj$1@digitaldaemon.com...
> Hi there,
>
> sorry, but with these names for complex and imaginary numbers, you have created a joke among mathematicians for the years to come!
>
> Why not rename these types to "complex" and "imag" and make code much more
> readable? OK, the list
>         float
>         double
>         real
>         ifloat
>         idouble
>         imag
>         cfloat
>         cdouble
>         complex
> might not look quite as regular, but since most people will only work with
> "real","imag" and "complex" (everything else is just for special cases and
> compatibility) you would *really* improve readability!

You can alias them if it works better for you:

    alias creal complex;
    alias ireal imag;


> Another detail concerning complex numbers:
>         a.im
> should really return a real number. Looking at all mathematics text books
> all over the world, the function Im(a+bi) is defined to return the real
> number b.

It already works this way.

Walter wrote:
> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
>> sorry, but with these names for complex and imaginary numbers, you have created a joke among mathematicians for the years to come!
> 
> You can alias them if it works better for you:
> 
>     alias creal complex;
>     alias ireal imag;

True, but I'm less worried about my personal convenience, but the image of the language. Any mathematician will have problems taking a language serious that calls its complex type "creal"!

Also, thinking quite egoistic: Programming does not only mean writing and reading my own code, but also to read other peoples code. And most people will just stick with what the language definition tells them.

Therefore, I would strongly recommend to change the language definition and - if you want to keep compatibility, introduce aliases the other way around to the standard library.

B.t.w: after consideration I would change my proposal from "imag" to "imaginary" as the replacement keyword for "ireal". The type would be typed rather rarely, so the longer word is more appropriate (and you can't misinterpret it as abbrevation of "image")

>> Another detail concerning complex numbers:
>>         a.im
>> should really return a real number. Looking at all mathematics text books
>> all over the world, the function Im(a+bi) is defined to return the real
>> number b.
> 
> It already works this way.

True, sorry, I got caught by an error in
        http://www.digitalmars.com/d/float.html
section
        Complex and Imaginary types
reading:
| For example:
|         cd.re           is 4.5 double
|         cd.im           is 2i idouble
|         c.re            is 4.5 real
|         c.im            is 2i ireal

> B.t.w: after consideration I would change my proposal from "imag" to "imaginary" as the replacement keyword for "ireal". The type would be typed rather rarely, so the longer word is more appropriate (and you can't misinterpret it as abbrevation of "image")

I was just going to mention that, so will simply say "hear, hear!"

>True, but I'm less worried about my personal convenience, but the image of the language. Any mathematician will have problems taking a language serious that calls its complex type "creal"!

But then where do I put my fish?

Haw Haw wrote:

>>True, but I'm less worried about my personal convenience, but the image of the language. Any mathematician will have problems taking a language serious that calls its complex type "creal"!
> 
> But then where do I put my fish?

Sorry, I guess I don't get you. I assume a pun somewhere, but my dictionary keeps quiet about any meaning of "creal".

try "creel" instead ... it's a Scottish name for what others might call a "lobster pot" ...

- Kris

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c668d9$1cc3$1@digitaldaemon.com...
> Haw Haw wrote:
>
> >>True, but I'm less worried about my personal convenience, but the image
of
> >>the language. Any mathematician will have problems taking a language serious that calls its complex type "creal"!
> >
> > But then where do I put my fish?
>
> Sorry, I guess I don't get you. I assume a pun somewhere, but my
dictionary
> keeps quiet about any meaning of "creal".

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65gk6$42f$1@digitaldaemon.com...
> Walter wrote:
> >
> > "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
> >> sorry, but with these names for complex and imaginary numbers, you have created a joke among mathematicians for the years to come!
> >
> > You can alias them if it works better for you:
> >
> >     alias creal complex;
> >     alias ireal imag;
>
> True, but I'm less worried about my personal convenience, but the image of the language. Any mathematician will have problems taking a language serious that calls its complex type "creal"!
>
> Also, thinking quite egoistic: Programming does not only mean writing and reading my own code, but also to read other peoples code. And most people will just stick with what the language definition tells them.
>
> Therefore, I would strongly recommend to change the language definition
and
> - if you want to keep compatibility, introduce aliases the other way
around
> to the standard library.
>
> B.t.w: after consideration I would change my proposal from "imag" to "imaginary" as the replacement keyword for "ireal". The type would be
typed
> rather rarely, so the longer word is more appropriate (and you can't misinterpret it as abbrevation of "image")
>
> >> Another detail concerning complex numbers:
> >>         a.im
> >> should really return a real number. Looking at all mathematics text
books
> >> all over the world, the function Im(a+bi) is defined to return the real
> >> number b.
> >
> > It already works this way.
>
> True, sorry, I got caught by an error in
>         http://www.digitalmars.com/d/float.html
> section
>         Complex and Imaginary types
> reading:
> | For example:
> |         cd.re           is 4.5 double
> |         cd.im           is 2i idouble
> |         c.re            is 4.5 real
> |         c.im            is 2i ireal

I see where the confusion came from, thanks. I fixed the doc.

In article <c66f9s$1qqk$1@digitaldaemon.com>, Walter says...
>
>"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65gk6$42f$1@digitaldaemon.com...
[...]
>> True, sorry, I got caught by an error in
>>         http://www.digitalmars.com/d/float.html
>> section
>>         Complex and Imaginary types
>> reading:
>> | For example:
>> |         cd.re           is 4.5 double
>> |         cd.im           is 2i idouble
>> |         c.re            is 4.5 real
>> |         c.im            is 2i ireal
>
>I see where the confusion came from, thanks. I fixed the doc.

Ehm, still not fixed. From the updated doc:

cd.re		is 4.5 double
cd.im		is 2 double
c.re		is 4.5 real
c.im		is 2 real

IMO it should be:

cd.re		is 3.6 double
cd.im		is 4 double
c.re		is 4.5 real
c.im		is 2 real

Ciao

Sorry to continue nagging about this, but I'm pretty serious:

"creal" is an abbrevation for "complex real" which is a contradiction in itself! "imaginary real" is even worse than that.

Nobody would have a problem to talk about "complex float" or "imaginary integer". These terms are rarely used in mathematics, but everyone will understand intuitively what is meant.

I know that the systematics of the typenames in D suggests to continue from "cfloat" and "cdouble", but systematics is not the most important issue here.

"cfloat" and "cdouble" will hardly ever be used. Most programs will just handle "real" and "complex"/"creal" values (even "imaginary"/"ireal" would be an exception, I guess)

Just for practical usage, it would therefore be far easier to read a program talking of "real" and "complex" values, than to see the two types only distinguished by a single letter "c".

Leaving it to the programmer to define
        alias creal complex;
himself means unnecessary confusion and looks like telling the user to fix a
problem that should have been fixed in the language in the first place.

Every serious scientist would introduce that alias for himself just to avoid typing an oxymoron all over his code. Other code will probably just stick with the "official" name for the type. Therefore you'll have a strange confusion factor for no good reason but some pointless systematics in the naming of standard types.

Ciao,
Nobbi