www.digitalmars.com         C & C++   DMDScript  

D - D complex

reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
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.
Jan 25 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 25 2002
next sibling parent reply "H. Ellenberger" <ele1 gmx.ch> writes:
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
Jan 26 2002
next sibling parent Ruslanas Abdrachimovas <anubis 03bar.ktu.lt> writes:
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?


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

Feb 01 2002
prev sibling next sibling parent reply "D" <s_nudds hotmail.com> writes:
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?

Feb 04 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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"?
Feb 04 2002
parent reply "D" <s_nudds hotmail.com> writes:
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"?

Feb 04 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3nn6k$2bf2$1 digitaldaemon.com...
 A new operator that I define.  Perhaps I will call it .+ or .v+ where the

 indicates a user defined vector operation.

I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc. If someone forgets a space it could cause lots of problems. Sean
Feb 05 2002
parent reply "D" <s_nudds hotmail.com> writes:
Arrrg, tokens should be whitespace delimited.

However, I'm open to optional formats.

Sean L. Palmer <spalmer iname.com> wrote in message
news:a3odsq$2lo0$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3nn6k$2bf2$1 digitaldaemon.com...
 A new operator that I define.  Perhaps I will call it .+ or .v+ where


 v
 indicates a user defined vector operation.

I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc. If someone forgets a space it could cause lots of problems. Sean

Feb 05 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
In the past, when writing script languages and general-purpose lexers I'm
often tempted to require whitespace.  Users tend to get annoyed if you do
though.  I'm sure not used to putting whitespace everywhere.

Sean

"D" <s_nudds hotmail.com> wrote in message
news:a3pge4$5hq$1 digitaldaemon.com...
 Arrrg, tokens should be whitespace delimited.

 However, I'm open to optional formats.

 Sean L. Palmer <spalmer iname.com> wrote in message
 news:a3odsq$2lo0$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3nn6k$2bf2$1 digitaldaemon.com...
 A new operator that I define.  Perhaps I will call it .+ or .v+ where


 v
 indicates a user defined vector operation.

I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc. If


 forgets a space it could cause lots of problems.

 Sean


Feb 06 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
Feb 04 2002
parent reply "D" <s_nudds hotmail.com> writes:
 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?


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3mu6r$1sun$1 digitaldaemon.com...
 People keep mentioning that example (and it is a good one), but
 how many examples like that are there really?

Lots. In fact most of the places where operators can be used do not conform to the standard meanings of the existing operators. Equality can be made an exception. OdessE writes:
 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 /.

How do you intend to logically redefine the meaning of the square root function?
 To me,
 defining new operators seems like operator overloading 'on steroids'.

Creating new operators is to operator overloading what creating new functions are to function overloading. OdessE writes:
 Why do you oppose overloading of simple operators but support
 the more powerfull 'operator overloading on steroids'?

Because operator overloading is distinct from creating new operators. If there is to be one feature added, then it should be creating new operators. Overlaying new function onto existing operators simply clouds the meaning of every statement in a program.
Feb 04 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3nnm3$2bmc$1 digitaldaemon.com...
 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?


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3mu6r$1sun$1 digitaldaemon.com...
 People keep mentioning that example (and it is a good one), but
 how many examples like that are there really?

Lots. In fact most of the places where operators can be used do not

 to the standard meanings of the existing operators. Equality can be made

 exception.

And assignment. And how many ways are there to define > or < ?
 OdessE writes:
 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 /.

How do you intend to logically redefine the meaning of the square root function?

How do you intend to logically redefine the meaning of the assignment operator? Your reasoning makes sense, but you keep contradicting yourself by saying that defining new operators is not bad. I think most people are pretty familiar with =, +, -, *, /, ==, < and >. I doubt many of them are familiar with the hundreds of math operators that exist today. Check out the Math operators section of a Unicode table. And then there are ofcourse the operators that I invent myself. Do you really think they wil make sense? How about: Table <+- Record1; That means adding a record to a table. I invented the operator myself, cool huh. But string1 = string2 + string3, now *that* is a mystery!
 To me,
 defining new operators seems like operator overloading 'on steroids'.

Creating new operators is to operator overloading what creating new functions are to function overloading.

No it is not. Operators are predefined symbols, even in math. Sure, new ones are 'made' up now and then, but it is nothing to compare with normal functions!
 OdessE writes:
 Why do you oppose overloading of simple operators but support
 the more powerfull 'operator overloading on steroids'?

Because operator overloading is distinct from creating new operators.

 there is to be one feature added, then it should be creating new

  Overlaying new function onto existing operators simply clouds the meaning
 of every statement in a program.

string1 = string2 + string3; Cloudy that statement heh? string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3)); or string1 :*$=: string2 :*$+: string3; Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 05 2002
parent reply "D" <s_nudds hotmail.com> writes:
 Lots.  In fact most of the places where operators can be used do not

 to the standard meanings of the existing operators. Equality can be made

 exception.


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3pi39$6ls$1 digitaldaemon.com...
 And assignment.
 And how many ways are there to define > or < ?

Yes, and assignment. As for > and <, it is clear from the existance of -> and >> and << that "><" could be defined to mean a variety of things from shift to align, to point's to... I could see > being used to shift the bits in a bitmap to the right. or used to select the n th entry in a table or structure. or perhaps check if the object on the left side is bigger than that on the right. Perhaps it would check if the object on the left could be made smaller by compression. Perhaps it will perform the compression. file = file > compressionfactor There are many possibilities..
 How do you intend to logically redefine the meaning of the square root
 function?


Odesse writes:
 How do you intend to logically redefine the meaning of the assignment
 operator?

I don't. I oppose operator overloading. Odesse writes:
 Your reasoning makes sense, but you keep contradicting
 yourself by saying that defining new operators is not bad. I think most
 people are pretty familiar with =, +, -, *, /, ==, < and >.
 I doubt many of them are familiar with the hundreds of math operators
 that exist today. Check out the Math operators section of a Unicode
 table. And then there are ofcourse the operators that I invent myself.

We program in ASCII not unicode. I fail to see your point. Odesse writes:
 Do you really think they wil make sense? How about:

 Table <+- Record1;

 That means adding a record to a table. I invented the operator myself,
 cool huh. But  string1 = string2 + string3, now *that* is a mystery!

Strings are basic operators in D, so I presume the above syntax is supported. As to Table <+- Record1; I see from the operator that it is user defined. Since there is presumably no operator overloading I will construct a master table telling me the character equivalents of the opcodes you have invented. I will then turn to that page and see what the operator does. In short order I will have memorized the table and the meaning of your program will no longer be obfuscated by operators that appear to be something they are not.
 To me,
 defining new operators seems like operator overloading 'on steroids'.

Creating new operators is to operator overloading what creating new functions are to function overloading.


Odesse writes:
 No it is not. Operators are predefined symbols, even in math. Sure,
 new ones are 'made' up now and then, but it is nothing to compare
 with normal functions!

Yes Operators are predefined and have sanctioned meanings. You prove my point. Altering the sanctioned meanings that we are all conditioned to recognize is a disaster waiting to happen. My analogy stands in fact, your observation strengthens my argument.
   Because operator overloading is distinct from creating new operators.

 there is to be one feature added, then it should be creating new

  Overlaying new function onto existing operators simply clouds the


 of every statement in a program.

string1 = string2 + string3; Cloudy that statement heh? string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3)); or string1 :*$=: string2 :*$+: string3; Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language!

The difference of course is that with operator overloading programmers are forced to write obscure code. When the have the ability to create new operators, they have the option of making their code have clear meaning. We have already seen that the assignment operator can be taken as being a 1:1 copy. So, from your example... beta = alpha :$+ omega What do we know about this expression? We know that :$+ is the addition operator that adds two strings. Because there is no operator overloading we know that the operator is unique. Hence we can conclude that alpha and omega are two string values. We also know that the result will be a string value Hence we know that beta is also a string. So by knowing the meaning of :$+ (which does provide reasonable visual cues to it's intended meaning) we can conclude everything we need to know about the expression at hand. Odesse. Thank you for once again proving my point.
Feb 06 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 Odesse writes:
 Your reasoning makes sense, but you keep contradicting
 yourself by saying that defining new operators is not bad. I think most
 people are pretty familiar with =, +, -, *, /, ==, < and >.
 I doubt many of them are familiar with the hundreds of math operators
 that exist today. Check out the Math operators section of a Unicode
 table. And then there are ofcourse the operators that I invent myself.

We program in ASCII not unicode. I fail to see your point.

Maybe it's time a programming *language* started supporting Unicode. Editors will follow. Sean
Feb 06 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3r09f$27h0$1 digitaldaemon.com...

 Maybe it's time a programming *language* started supporting Unicode.
 Editors will follow.

The very first phase of compilation (as stated in the D specs) is that: "The source file is checked to see if it is in ascii or wchar, and the appropriate scanner is loaded." =)
Feb 06 2002
prev sibling parent reply "D" <s_nudds hotmail.com> writes:
Lets get some unicode keyboards first.
Better yet.  Scrap this unicode nonsense while there is still a chance.


Sean L. Palmer <spalmer iname.com> wrote in message
news:a3r09f$27h0$1 digitaldaemon.com...
 Odesse writes:
 Your reasoning makes sense, but you keep contradicting
 yourself by saying that defining new operators is not bad. I think



 people are pretty familiar with =, +, -, *, /, ==, < and >.
 I doubt many of them are familiar with the hundreds of math operators
 that exist today. Check out the Math operators section of a Unicode
 table. And then there are ofcourse the operators that I invent myself.

We program in ASCII not unicode. I fail to see your point.

Maybe it's time a programming *language* started supporting Unicode. Editors will follow. Sean

Feb 07 2002
next sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"D" <s_nudds hotmail.com> ha scritto nel messaggio
news:a3tvlc$rco$1 digitaldaemon.com...
 Lets get some unicode keyboards first.

A japanese keyboard is an exapmle. Ciao
Feb 07 2002
prev sibling parent reply "Immanuel Scholz" <digital-mars kutzsche.net> writes:
"D" <s_nudds hotmail.com> schrieb im Newsbeitrag
news:a3tvlc$rco$1 digitaldaemon.com...
 Lets get some unicode keyboards first.
 Better yet.  Scrap this unicode nonsense while there is still a chance.

Ihk! All those american or english bastards who do not care that other languages do not fit in 127 chars. ;-) What it is a s**t already with in german... Imi
Mar 06 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a66hpd$1koj$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> schrieb im Newsbeitrag
 news:a3tvlc$rco$1 digitaldaemon.com...
 Lets get some unicode keyboards first.
 Better yet.  Scrap this unicode nonsense while there is still a chance.

Ihk! All those american or english bastards who do not care that other languages do not fit in 127 chars. ;-) What it is a s**t already with in german... Imi

LOL! I guess D was expressing his open mind, calling Unicode nonsense, therefore banning Japanese, Chinese, Russian, Turkish etc. etc. etc. users to use paper and pen for ever! :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Mar 11 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a6j1gd$1j91$1 digitaldaemon.com...

 LOL!
 I guess D was expressing his open mind, calling Unicode
 nonsense, therefore banning Japanese, Chinese, Russian,
 Turkish etc. etc. etc. users to use paper and pen for ever!
 :)

Well, Russian users prefer Windows-1251 or KOI8-R anyhow, I guess nobody here cares about the UNICODE, in fact... =)
Mar 11 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a6j535$1kpr$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a6j1gd$1j91$1 digitaldaemon.com...

 LOL!
 I guess D was expressing his open mind, calling Unicode
 nonsense, therefore banning Japanese, Chinese, Russian,
 Turkish etc. etc. etc. users to use paper and pen for ever!
 :)

Well, Russian users prefer Windows-1251 or KOI8-R anyhow, I guess nobody here cares about the UNICODE, in fact... =)

Oh... Well, another dream of unification shattered then... :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Mar 11 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3qv4k$26uo$1 digitaldaemon.com...
 Lots.  In fact most of the places where operators can be used do not

 to the standard meanings of the existing operators. Equality can be



 an
 exception.


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3pi39$6ls$1 digitaldaemon.com...
 And assignment.
 And how many ways are there to define > or < ?

Yes, and assignment. As for > and <, it is clear from the existance

 and >> and << that "><" could
 be defined to mean a variety of things from shift to align, to point's

    I could see > being used to shift the bits in a bitmap to the right.
    or used to select the n th entry in a table or structure.
    or perhaps check if the object on the left side is bigger than that on
 the right.
    Perhaps it would check if  the object on the left could be made smaller
 by compression.
    Perhaps it will perform the compression.

    file = file > compressionfactor

    There are many possibilities..


 How do you intend to logically redefine the meaning of the square root
 function?


Odesse writes:
 How do you intend to logically redefine the meaning of the assignment
 operator?

I don't. I oppose operator overloading. Odesse writes:
 Your reasoning makes sense, but you keep contradicting
 yourself by saying that defining new operators is not bad. I think most
 people are pretty familiar with =, +, -, *, /, ==, < and >.
 I doubt many of them are familiar with the hundreds of math operators
 that exist today. Check out the Math operators section of a Unicode
 table. And then there are ofcourse the operators that I invent myself.

We program in ASCII not unicode. I fail to see your point. Odesse writes:
 Do you really think they wil make sense? How about:

 Table <+- Record1;

 That means adding a record to a table. I invented the operator myself,
 cool huh. But  string1 = string2 + string3, now *that* is a mystery!

Strings are basic operators in D, so I presume the above syntax is supported.

Actually I think at the moment it is not. Now if we could use operator overloading that wouldn't matter. String addition through operators could (and I think should) be added to the core language ofcourse, but is it really plausible that every datatype in existence that we would like to use operators on should be added to the core language? What if we want an int256? What if we need any mathematical datatype that operators are normally used on? You can't include them all, so some will be left out.
 As to

 Table <+- Record1;

 I see from the operator that it is user defined.  Since there is

 no operator overloading
 I will construct a master table telling me the character equivalents of

 opcodes you have invented.
 I will then turn to that page and see what the operator does.

Just like you could do with a normal function. So what is the point? To me the whole point of operator overloading is that you know what operation is performed without having to consult documentation. I don't know what <+- does. At least with a normal function I can read it from it's name. Table.Add (Record); These new operators are actually a step back.
 In short order I will have memorized the table and the meaning of your
 program will no longer be
 obfuscated by operators that appear to be something they are not.

Cool, memorizing tables for every program. Sounds practical.
 To me,
 defining new operators seems like operator overloading 'on




   Creating new operators is to operator overloading what creating new
 functions are to function overloading.


Odesse writes:
 No it is not. Operators are predefined symbols, even in math. Sure,
 new ones are 'made' up now and then, but it is nothing to compare
 with normal functions!

Yes Operators are predefined and have sanctioned meanings. You prove my point. Altering the sanctioned meanings that we are all conditioned to recognize is a disaster waiting to happen. My analogy stands in fact, your observation strengthens my argument.

No it does not. The meaning of the operation + is defined. It means adding two entities. It does not say exactly what type those entities are. Could be integers, could be floats or could be strings. With operator overloading you are *not* altering the sanctioned meaning of the operator, you are just enabling your new type, your class, to be used in that predefined operation.
   Because operator overloading is distinct from creating new



 If
 there is to be one feature added, then it should be creating new

  Overlaying new function onto existing operators simply clouds the


 of every statement in a program.

string1 = string2 + string3; Cloudy that statement heh? string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3)); or string1 :*$=: string2 :*$+: string3; Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language!

The difference of course is that with operator overloading programmers are forced to write obscure code.

No they are not. They are enabled to allow their classes to behave in the same way as other types. Sometimes this makes great sense and is not obscure at all.
 When the have the ability to create new operators, they have the option of
 making their code have clear meaning.

No they don't. They are creating new operators. They are inventing them, making them up, grabbing them from a hat. No one else but the one that invented the operator knows anything about it. How is that clearer than just saying Add() or Assign()? If it is to save some typing, don't bother. If it is to add clarity to the language, it is not helping.
 We have already seen that the assignment operator can be taken as being a
 1:1 copy.
 So, from your example...

    beta = alpha :$+ omega

   What do we know about this expression?

Nothing, just that it includes a really strange operator no one knows. *You* might think it is clear, but in other languages a $ generally has absolutely nothing to do with strings. +, on the other hand, is a universally known math symbol.
   We know that :$+ is the addition operator that adds two strings.

No we don't, we would have to look that up.
    Because there is no operator overloading we know that the operator is
 unique.
   Hence we can conclude that alpha and omega are two string values.

We could also just look at their declaration, but hey that would be impractical, rather just memorize some operator tables...
   We also know that the result will be a string value
   Hence we know that beta is also a string.

   So by knowing the meaning of :$+ (which does provide reasonable visual
 cues to it's intended meaning)

No it does not. I see a +, which I know, but what that : and $ mean, I just don't know, sorry.
 we can conclude everything we need to know about the expression at hand.

After reading a pile of documentation... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 07 2002
next sibling parent reply "D" <s_nudds hotmail.com> writes:
 Strings are basic operators in D, so I presume the above syntax is
 supported.


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3ulb6$1s2p$1 digitaldaemon.com...
 Actually I think at the moment it is not.
 Now if we could use operator overloading that wouldn't matter.
 String addition through operators could (and I think should) be added
 to the core language ofcourse, but is it really plausible that every
 datatype
 in existence that we would like to use operators on should be added
 to the core language?

Clearly not. Since all new datatypes that can be defined within the language are aggregate. Odesse writes::
 What if we want an int256? What if we need
 any mathematical datatype that operators are normally used on?
 You can't include them all, so some will be left out.

Then you must use an aggregate datatype to simulate them, and only the equality operators would apply to them. For other operations new operators would need to be defined. .+ .- .* and ./ look reasonable to me.
 As to

 Table <+- Record1;

 I see from the operator that it is user defined.  Since there is

 no operator overloading
 I will construct a master table telling me the character equivalents of

 opcodes you have invented.
 I will then turn to that page and see what the operator does.


Odesse writes:
 Just like you could do with a normal function. So what is the point?

Your statement is completely false. Are you just being childish or are you as ignorant as a door? With your inferior concept of operator overloading, you can not simply consult a table to find which operation an operator is performing because with your method the same operator is used to perform a multitude of operations. When new operators are defined however, there is a 1 to 1 correspondance between operators and function. Odesse writes:
 To me the whole point of operator overloading is that you know
 what operation is performed without having to consult documentation.

And you have already admitted that you don't. So your support for operator overloading is based on an irrational religious dogma rather than fact. Odesse writes:
 I don't know what <+- does. At least with a normal function I can
 read it from it's name. Table.Add (Record);

True enough, but you always know exactly what the standard operators "+-*/ etc.} do. And they constitute the vast bulk of operators used. Odesse:
 These new operators are actually a step back.

As new operators provide all of the functionality of the old operators, and also provide substantial advantage, and remove the flaws inherent in operator overloading, the ability to provide new operators is clearly superior.
 In short order I will have memorized the table and the meaning of your
 program will no longer be
 obfuscated by operators that appear to be something they are not.


Odesse writes:
 Cool, memorizing tables for every program. Sounds practical.

Eminently more practical than having to remember the alternate meanings of existing operators that are overloaded. In fact, you lose on this point as well, for while + may be redefined to mean add a script segment to the end of a *.mpg file, I have no such requirement. I could just as easily define the operator for the function to be .addscript. The function then transforms from a + b (your inferior solution) a .addscript b (my superior solution)
 My analogy  stands in fact, your observation strengthens my argument.


Odesse writes:
 No it does not. The meaning of the operation + is defined. It means adding
 two entities.

Unless it's applied to strings, in which case it means append the second string with the first. Once again your argument is based on nonsense. You are embarrasing yourself Odesse. I suggest you lick your wounds, pick yourself up, go home and learn from your failure here.
Feb 07 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3vhqj$19tc$1 digitaldaemon.com...
 Strings are basic operators in D, so I presume the above syntax is
 supported.


OddesE <OddesE_XYZ hotmail.com> wrote in message news:a3ulb6$1s2p$1 digitaldaemon.com...
 Actually I think at the moment it is not.
 Now if we could use operator overloading that wouldn't matter.
 String addition through operators could (and I think should) be added
 to the core language ofcourse, but is it really plausible that every
 datatype
 in existence that we would like to use operators on should be added
 to the core language?

Clearly not. Since all new datatypes that can be defined within the language are aggregate. Odesse writes::
 What if we want an int256? What if we need
 any mathematical datatype that operators are normally used on?
 You can't include them all, so some will be left out.

Then you must use an aggregate datatype to simulate them, and only the equality operators would apply to them.

I would like to be able to add my int256's...
   For other operations new operators would need to be defined.  .+ .- .*

 ./ look reasonable to me.

Why the dot? Where did the colon go? Why .+ instead of :+: ? If you can't make up your mind on this why do you presume hundreds of programmers from different companies will all agree on it and come up with the same solution? What if I define a int512? Use .+ and .- as well? Is this supposed to be possible in your solution? Where is the advantage then? What with vectors and strings? I know from earlier posts you propose :$+: for strings and :V+: for vecors, but what if I disagree? I live in the Netherlands, and the dollar sign has absolutely nothing to do with strings in Dutch. How am I supposed to know it signifies a string operation? I know you will tell me I should learn English, but why if math is universal and very clear?
 As to

 Table <+- Record1;

 I see from the operator that it is user defined.  Since there is

 no operator overloading
 I will construct a master table telling me the character equivalents



 the
 opcodes you have invented.
 I will then turn to that page and see what the operator does.


Odesse writes:
 Just like you could do with a normal function. So what is the point?

Your statement is completely false. Are you just being childish or are you as ignorant as a door?

Excuse me, what is false about my statement? "
 I will then turn to that page and see what the operator does.



Why can't you consult your documentation to find out what a certain normal function does? I was hoping for a way to avoid having to rely on documentation for so many things. I know what the plus operation signifies, I don't have to consult any documentation for that. I learned that years ago in math class.
     With your inferior concept of operator overloading, you can not simply
 consult a table
 to find which operation an operator is performing because with your method
 the same operator
 is used to perform a multitude of operations.

Read: With 'my' superior concept of operator overloading, you don't need to go to all the trouble of consulting lengthy tables to find which operation an operator is performing because with 'my' method the same operator is used to perform the *same* operation on a multitude of operands, just like in math, coincidentally...
   When new operators are defined however, there is a 1 to 1 correspondance
 between operators
 and function.


 Odesse writes:
 To me the whole point of operator overloading is that you know
 what operation is performed without having to consult documentation.

And you have already admitted that you don't. So your support for operator overloading is based on an irrational religious dogma rather than fact.

Where did I admit that? Support such claims with facts, or don't make them. I *do* know what the normal math operations are *supposed* to do. + adds entities, - subtracts them, * multiplies them... Strange that you don't know that....
 Odesse writes:
 I don't know what <+- does. At least with a normal function I can
 read it from it's name. Table.Add (Record);

True enough, but you always know exactly what the standard operators "+-*/ etc.} do. And they constitute the vast bulk of operators used.

"True enough, but you always know exactly what the standard operators "+-*/ etc.} do." Mmmm....Strange... I just spent a bunch of posts saying exactly this, and you replied to all of them in a very inflamatory mannor saying that this was not the case. + could be used to add web pages to web servers? At last we agree. It is vey clear what + should do, hence it is not necessary and indeed undersirable to obscure its obvious meaning with strange and arbitrary characters not normally used in operators.
 Odesse:
 These new operators are actually a step back.

As new operators provide all of the functionality of the old operators, and also provide substantial advantage, and remove the flaws inherent in operator overloading, the ability to provide new operators is clearly superior.

They provide the technical functionality of the old operators, agreed, but so do normal named functions, so why bother with operators at all? Are you saying that it is worth all the fuss to be able to say mat1 :MtxMul mat2 instead of mat1.MtxMul (mat2) ? Where is the big advantage in that? As I am very bad in English, or at least *might* be :), I have no idea what mul stands for... With * I know this is the computer representation of a math multiplicication, or "vermenigvuldiging" in Dutch, in this case applied to two matrices. New operators might be very useful for defining operators that are new to the language. I would love to see a square root operator, or an operator for powers. What I would not like to see is all kinds of new operators defined for doing things that we already have perfectly suitable operators for, such as addition or multiplication. In such cases they provide the substantial disadvantage that their meaning is not immediately clear. That means without consulting documentation, operator tables or doing a web search, just looking at the source code. The fact that 10 different programmers might define all kinds of different new operators for string addition or the same operators for different operations just obscures the meaning of the code, making it much *less* self-documenting. What about :$+: .$+ :+$: .+$ :$+ :+$ all defined (by different programmers ofcourse) for adding strings? In most languages $ has nothing to do with strings, and people from countries with such languages might choose s or S instead of the $ sign, immediately tripling the amount of operators for the *same* operation to a whopping EIGHTEEN! And one can easily imagine this number rising even further! Or how about :+ for adding strings defined by programmers from company A, but for adding vectors by programmers from company B and for matrices by programmers from company C? Where is the "substantial advantage" in that? Are you really telling me you don't see how this might cause confusion? Isn't the main purpose of operator overloading to write code that closely resembles the problem domain, thus making it easier to understand what is happening? Or do you think that it's main purpose is saving a few characters to type?
 In short order I will have memorized the table and the meaning of your
 program will no longer be
 obfuscated by operators that appear to be something they are not.


Odesse writes:
 Cool, memorizing tables for every program. Sounds practical.

Eminently more practical than having to remember the alternate meanings of existing operators that are overloaded.

As I keep saying, the meaning of the operations does not change. * means multiplication, + addition. The overloaded operators just enable new types to be multiplied or added.
   In fact, you lose on this point as well, for while + may be redefined to
 mean
 add a  script segment to the end of a *.mpg file,  I have no such
 requirement.

"True enough, but you always know exactly what the standard operators "+-*/ etc.} do." You keep contradicting yourself don't you?
   I could just as easily define the operator for the function to be
 .addscript.

Why could .addscript not be defined to do something unexpected? Your new operators are more descriptive, granted, but so are function names, so why bother with strange new operators? Operator plus has a very defined meaning in math. You can implement operator + to do a whole bunch of strange things, but how does that proof anything? You can also implement .addscript to do strange and unexpeced things, such as deleting the .mpg file. Not difficult at all, so your solution does not solve the problem you keep insisting it does.
 The function then transforms from

 a + b               (your inferior solution)
 a .addscript b  (my superior solution)

I wouldn't use a operator at all in this case. I would use a.AddScript(b) (my even more superior solution) Do you see that it looks almost the same? And there is no need to add any functionality to the language at all. You are just using (long) names as operators, then proudly suggesting that their meaning is clear because you created a new operator. Maybe the meaning of the operator is clear because it isn't an operator at all, just a function name thinly disguised as an operator?
 My analogy  stands in fact, your observation strengthens my argument.


Odesse writes:
 No it does not. The meaning of the operation + is defined. It means


 two entities.

Unless it's applied to strings, in which case it means append the second string with the first.

I wonder how you define adding two strings in any other way than concatenating the second string of characters to the first? Are you going to add the ASCII values? Are you really suggesting it is difficult to understand what "Hello " + "World!" means? I am adding two entities, strings, and I can readily conclude from my knowledge of the math operator +, combined with my knowledge of the data types of the operands, strings, what is going to happen. Why would :$+: be more clear? What is the append operator in math? Or is there none? What about matrices? Is operator + doing something fundamentally different when adding matrices? The operation is performed in a different matter, but the same thing is happening, two matrices are being *added*. I wonder why you say in a previous post: "Strings are basic operators in D, so I presume the above syntax is supported." about adding strings with plus, but are now claiming that the use of operator + with strings is ambiguous in some way. Apart from the fact that strings are operands not operators, and that they are not basic types in D, you seem to think or want strings to be added (oh sorry, concatenated) with a standard operator + in this previous post. But now that you find out that you were wrong, and that strings are not basic types in D, you suddenly claim that adding them with plus would be ambiguous, that the meaning of that operation would not be defined and that we need a new operator for it. Do you propose we define different operators + for all basic types? i+ for ints, f+ for floats, e+ for extended floats and $+ for strings? Why is it okay to overload operators for built-in types but not for new types? D (or C/C++ for that matter) does not include strings as a basic type, but at least with operator overloading you can add such types to the language, with minimal bloat. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 16 2002
prev sibling parent reply "Immanuel Scholz" <digital-mars kutzsche.net> writes:
"OddesE" <OddesE_XYZ hotmail.com> schrieb im Newsbeitrag
news:a3ulb6$1s2p$1 digitaldaemon.com...
...
 to the core language? What if we want an int256? What if we need
 any mathematical datatype that operators are normally used on?
 You can't include them all, so some will be left out.

By the way: What about a big-integer built in data type for all those cryptographes in us? (I think 256 bit are not enough) Imi
Mar 06 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a66hu7$1kti$1 digitaldaemon.com...

 By the way: What about a big-integer built in data type for
 all those cryptographes in us?

 (I think 256 bit are not enough)

Just how big? I guess the bignum library would be a better solution. Of course, we don't have operator overloading yet, but it could be done with functions for now.
Mar 06 2002
parent "Immanuel Scholz" <digitals-mars kutzsche.net> writes:
"Pavel Minayev" <evilone omen.ru> schrieb im Newsbeitrag
news:a66rfi$1p9o$1 digitaldaemon.com...
 "Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
 news:a66hu7$1kti$1 digitaldaemon.com...

 By the way: What about a big-integer built in data type for
 all those cryptographes in us?

 (I think 256 bit are not enough)

Just how big? I guess the bignum library would be a better solution. Of course, we don't have operator overloading yet, but it could be done with functions for now.

especally cryptologic functions tend to be very mathematical, so infix-Notation is a REQUIREMENT! I think without it, I will write a preprocessor for D to define my own infix notation ;) (This is the reason, I do not use Java for cryptology - they do not let you overwrite operator+, and BigInteger.add(..) is too difficult to read (when used in chains). Imi
Mar 08 2002
prev sibling parent reply Juarez Rudsatz <juarez correio.com> writes:
"D" <s_nudds hotmail.com> wrote in news:a3lhlb$rap$1 digitaldaemon.com:

 
 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?

One of objectives of D is have many distinc compilation fases : 1. ascii vs unicode 2. lexical 3. sintax 4. semantic 5. optimization 6. code generation The language is buid for easy implementation, and simplicity. If we include `new operators` instead of `overloaded operators` we are mixing two fases (3 & 4). The sintatical fase will be very simple and semantical very #%=. For example : What are variable and what are operators ? (compiler view) x = y plus variable - yav - iseq rest varx;
Feb 08 2002
parent "D" <s_nudds hotmail.com> writes:
You will see in every one of my examples, that I have prefixed new operators
with a period.
Other symbols would be just as acceptable.

If the period is used, the compiler would look at any whitespace period
nonwhitespace combination
that follows a variable or constant to be an operator label and try to match
it against the operators it has on file.

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


 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?


Juarez Rudsatz <juarez correio.com> wrote in message news:Xns910FCC6F35219juarezcorreio 63.105.9.61...
 One of objectives of D is have many distinc compilation fases :

 1. ascii vs unicode
 2. lexical
 3. sintax
 4. semantic
 5. optimization
 6. code generation

 The language is buid for easy implementation, and simplicity.
 If we include `new operators` instead of `overloaded operators` we are
 mixing two fases (3 & 4).

 The sintatical fase will be very simple and semantical very #%=.

 For example :

 What are variable and what are operators ? (compiler view)

 x = y plus variable - yav - iseq rest varx;

Feb 09 2002
prev sibling parent Jakob Kemi <jakob.kemi telia.com> writes:
On Sat, 26 Jan 2002 12:50:21 +0100, 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

As complex is a builtin type, shouldn't all the standard operators just work as expected ? (my 2 euro cents) Jakob Kemi
Mar 11 2002
prev sibling parent reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
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
Jan 28 2002
parent "Walter" <walter digitalmars.com> writes:
"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
Jan 28 2002