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?


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
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


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 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




the

 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




 the

 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 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


conform

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


an

 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.


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.


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


 conform

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


 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 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.


 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.


 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






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 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


 conform

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






made

 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


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.


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


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.


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








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.


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






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.


 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


 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.




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.  .+ .- .*


and

 ./ 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


 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.




 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.


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




"

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




adding

 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).



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).



 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