www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Remove complex and imaginary types?

reply Reiner Pope <none here.com> writes:
Daniel919 Wrote:


 The remaining advantage is that of imaginary literals, i.e. the i 
 postfix:

     3 + 5i



 I'd really like to reserve the above phrase to be reserved to mean an 
 imaginary number. If one has the library delivered right with the 
 standard compiler or if one has to walk around the Globe in search of 
 the One library that actually implements it, I'd still want to have 
 this particular notation reserved (in the Language Grammar itself) for 
 this particular purpose.



 I do too. And been thinking along the lines of simply putting a hack in 
 that the postfix 'i' means that it's a literal of type 'imaginary', and 
 the compiler looks to see if "std.complex" was imported.
 
 This isn't as outlandish as it sounds, as there's precedent for it both 
 in C++ <typeinfo> and java.lang.String, as well as D's Object.



 What about a more general solution like
 -----------------------------
 import std.stdio, std.conv;
 
 struct complex {
      real re;
      real im;
      complex opAdd(real r) { return complex(re+r, im); }
      complex opAdd_r(real r) { return complex(re+r, im); }
      complex opAdd(complex c) { return complex(re+c.re, im+c.im); }
      string toString() { return std.conv.toString(re) ~ "+" ~ 
 std.conv.toString(im) ~ "i"; }
 }
 
 //complex opPostfix("i")(T)(T im) { return complex(0,im); }
 
 void main() {
 //    complex c =      1+5i      +     2+3i       +     6i;
      complex c = 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
      writefln( c );
 }
 -----------------------------
 
 This would also allow
 
 real opPostfix("L")(T)(T x) { return x; }
 
 T opPostfix("k")(T)(T x) { return x * 1000; }
 meter opPostfix("m")(T)(T x) { return meter(x); }



Here's my version from a while back: 

http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_literal_syntax_53992.html

  -- Reiner
Jan 11 2008
next sibling parent "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Reiner Pope" <none here.com> kirjoitti viestissä 
news:fm9kta$2f2e$1 digitalmars.com...

 Daniel919 Wrote:


 The remaining advantage is that of imaginary literals, i.e. the i
 postfix:

     3 + 5i



 I'd really like to reserve the above phrase to be reserved to mean an
 imaginary number. If one has the library delivered right with the
 standard compiler or if one has to walk around the Globe in search of
 the One library that actually implements it, I'd still want to have
 this particular notation reserved (in the Language Grammar itself) for
 this particular purpose.



 I do too. And been thinking along the lines of simply putting a hack in
 that the postfix 'i' means that it's a literal of type 'imaginary', and
 the compiler looks to see if "std.complex" was imported.

 This isn't as outlandish as it sounds, as there's precedent for it both
 in C++ <typeinfo> and java.lang.String, as well as D's Object.



 What about a more general solution like
 -----------------------------
 import std.stdio, std.conv;

 struct complex {
      real re;
      real im;
      complex opAdd(real r) { return complex(re+r, im); }
      complex opAdd_r(real r) { return complex(re+r, im); }
      complex opAdd(complex c) { return complex(re+c.re, im+c.im); }
      string toString() { return std.conv.toString(re) ~ "+" ~
 std.conv.toString(im) ~ "i"; }
 }

 //complex opPostfix("i")(T)(T im) { return complex(0,im); }

 void main() {
 //    complex c =      1+5i      +     2+3i       +     6i;
      complex c = 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
      writefln( c );
 }
 -----------------------------

 This would also allow

 real opPostfix("L")(T)(T x) { return x; }

 T opPostfix("k")(T)(T x) { return x * 1000; }
 meter opPostfix("m")(T)(T x) { return meter(x); }



 Here's my version from a while back:

 http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_literal_syntax_53992.html



I agree - this suffix support should make it into the language. It would be 
a generic way of handling imaginary values, SI-units, etc.

However, in your post from May, you say alphabetic. I'd rather have the 
suffix alphanumeric, with the first character locket to alphabetic - as we 
may need to express square meters, cubic feet etc., eg. in a general-purpose 
unit library.
Jan 12 2008
prev sibling parent reply renoX <renosky free.fr> writes:
Reiner Pope a écrit :

 Daniel919 Wrote:
 

 The remaining advantage is that of imaginary literals, i.e. the i 
 postfix:

     3 + 5i



 imaginary number. If one has the library delivered right with the 
 standard compiler or if one has to walk around the Globe in search of 
 the One library that actually implements it, I'd still want to have 
 this particular notation reserved (in the Language Grammar itself) for 
 this particular purpose.



 that the postfix 'i' means that it's a literal of type 'imaginary', and 
 the compiler looks to see if "std.complex" was imported.

 This isn't as outlandish as it sounds, as there's precedent for it both 
 in C++ <typeinfo> and java.lang.String, as well as D's Object.



 -----------------------------
 import std.stdio, std.conv;

 struct complex {
      real re;
      real im;
      complex opAdd(real r) { return complex(re+r, im); }
      complex opAdd_r(real r) { return complex(re+r, im); }
      complex opAdd(complex c) { return complex(re+c.re, im+c.im); }
      string toString() { return std.conv.toString(re) ~ "+" ~ 
 std.conv.toString(im) ~ "i"; }
 }

 //complex opPostfix("i")(T)(T im) { return complex(0,im); }

 void main() {
 //    complex c =      1+5i      +     2+3i       +     6i;
      complex c = 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
      writefln( c );
 }
 -----------------------------

 This would also allow

 real opPostfix("L")(T)(T x) { return x; }

 T opPostfix("k")(T)(T x) { return x * 1000; }
 meter opPostfix("m")(T)(T x) { return meter(x); }



 Here's my version from a while back: 
 
 http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_literal_syntax_53992.html
 
   -- Reiner



I like a lot all those proposal for adding suffix based literal, but I'm 
afraid that these could interfere(sp?) with the ones already existing in 
the language, so I wonder if 'library added' suffix shouldn't have an 
operator to distinguish them for the language one.

I'm thinking about the underscore '_': 5.8f_km would be replaced by 
km(5.8f), if there is no operator, there are some risk of ambiguity: 
"5.8fm" is-it 5.8f meters or 5.8 femtometers?

With 5.8f_m and 5.8_fm you remove the ambiguity and the _ is visually 
'pleasing' so this syntax would still be used.

Regards,
renoX
Jan 12 2008
next sibling parent Daniel919 <Daniel919 web.de> writes:
 Here's my version from a while back:
 http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_literal_syntax_53992.html






I agree,
T opSuff_k(T)(T x) { return x * 1000; }
is better to handle than
T opPostfix("k")(T)(T x) { return x * 1000; }


For example
alias somefunc opSuff_k;
would be too difficult with the other syntax.



 I like a lot all those proposal for adding suffix based literal, but I'm 
 afraid that these could interfere(sp?) with the ones already existing in 
 the language, so I wonder if 'library added' suffix shouldn't have an 
 operator to distinguish them for the language one.
 
 I'm thinking about the underscore '_': 5.8f_km would be replaced by 
 km(5.8f), if there is no operator, there are some risk of ambiguity: 
 "5.8fm" is-it 5.8f meters or 5.8 femtometers?
 
 With 5.8f_m and 5.8_fm you remove the ambiguity and the _ is visually 
 'pleasing' so this syntax would still be used.



What about:
auto a = 5.8f m;
auto b = 5fm; //<=> auto b = 5 fm;
auto c = 5.8f fm;
And the compiler always tries to find the longest match.
Jan 12 2008
prev sibling next sibling parent Gilles G. <schaouette free.fr> writes:
You could just express "float km" like this: (5.8f)km.


renoX Wrote:

 
 I like a lot all those proposal for adding suffix based literal, but I'm 
 afraid that these could interfere(sp?) with the ones already existing in 
 the language, so I wonder if 'library added' suffix shouldn't have an 
 operator to distinguish them for the language one.
 
 I'm thinking about the underscore '_': 5.8f_km would be replaced by 
 km(5.8f), if there is no operator, there are some risk of ambiguity: 
 "5.8fm" is-it 5.8f meters or 5.8 femtometers?
 
 With 5.8f_m and 5.8_fm you remove the ambiguity and the _ is visually 
 'pleasing' so this syntax would still be used.
 
 Regards,
 renoX
Jan 12 2008
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 1/12/08, renoX <renosky free.fr> wrote:

 I'm thinking about the underscore '_': 5.8f_km would be replaced by
 km(5.8f),



Why not the asterisk? Oh wait! - We already /have/ that functionality!

    5.8f*km

is replaced by

    km.opMul_r(5.8f);

Seems to me that nothing new is needed.
Jan 12 2008
next sibling parent renoX <renosky free.fr> writes:
Janice Caron a écrit :

 On 1/12/08, renoX <renosky free.fr> wrote:

 I'm thinking about the underscore '_': 5.8f_km would be replaced by
 km(5.8f),



 Why not the asterisk? Oh wait! - We already /have/ that functionality!
 
     5.8f*km
 
 is replaced by
 
     km.opMul_r(5.8f);
 
 Seems to me that nothing new is needed.



Because
1) when we write physic equation we don't write "5.0 x km" (x being the 
multiplication sign) but "5.0 km" so it would be nice if the language 
supported a way to make similar notations.

2) this could makes unneeded additional multiplication.

3) When you write "5km" you don't mean 5 * 1km but km(5), but sure most 
of the time it's the same..

Regards,
renoX
Jan 12 2008
prev sibling next sibling parent Daniel919 <Daniel919 web.de> writes:
 Why not the asterisk? Oh wait! - We already /have/ that functionality!
 
     5.8f*km
 
 is replaced by
 
     km.opMul_r(5.8f);
 
 Seems to me that nothing new is needed.



Here are some ideas how it would be even better than it could be with 
opSuff.
(opSuff would not allow: "z=5i;" <=> "z=5*i;")
-----------------------------------------------
import std.stdio, std.conv;

struct complex {
	real re;
	real im;
	complex opAdd(complex z) { return complex(re+z.re, im+z.im); }
	complex opAdd(real r) { return opAdd( complex(r,0) ); }
	//alias opAdd(real r) opAdd_r(real r);
	complex opAdd_r(real r) { return opAdd( r ); }
	
	complex opMul(complex z) { return complex(re*z.re-im*z.im, 
re*z.im+im*z.re); }
	complex opMul(real r) { return opMul( complex(r,0) ); }
	//alias opMul(real r) opMul_r(real r);
	complex opMul_r(real r) { return opMul( r ); }
	
	string toString() { return std.conv.toString(re) ~ "+" ~ 
std.conv.toString(im) ~ "i"; }
	
	struct i {
		static complex opMul_r(real im) { return complex(0,im); } //z=5*i;
//		static opJux_r(real im) { return complex(0,im); } //z=5i; //z=5f i;
			//z=5fi; is tricky, especially if "fi" is a symbol
			//but if "with(complex)" is used, "i" dominates over "fi", so this 
becomes: z=complex.i.opJux_r(5f);
//		static opExpr() { return complex(0,1); } //z=i;
			//is considered if none of the functions above matches
			//it would even be possible to make opExpr() the only function of i
	}
}


void main() {
	complex z; with(complex) z = 1+5*i + 2+3*i + 6*i; //maybe 
"with(complex)" can be inferred, when creating a complex?
//	complex z = 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
	writefln( z );
}
-----------------------------------------------
Jan 12 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 1/12/08, renoX <renosky free.fr> wrote:

 I'm thinking about the underscore '_': 5.8f_km would be replaced by
 km(5.8f),



 Why not the asterisk? Oh wait! - We already /have/ that functionality!
 
     5.8f*km
 
 is replaced by
 
     km.opMul_r(5.8f);
 
 Seems to me that nothing new is needed.



But km, i, or whatever, must be at global scope, and then you couldn't 
have local variables named that way.
Jan 12 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
renoX <renosky free.fr> wrote:


 Reiner Pope a =E9crit :

 Daniel919 Wrote:


 The remaining advantage is that of imaginary literals, i.e. the i=




















 postfix:

     3 + 5i




















 an imaginary number. If one has the library delivered right with t=

















 standard compiler or if one has to walk around the Globe in search=

















 of the One library that actually implements it, I'd still want to =

















 have this particular notation reserved (in the Language Grammar  =
















 itself) for this particular purpose.

















 in that the postfix 'i' means that it's a literal of type  =













 'imaginary', and the compiler looks to see if "std.complex" was  =













 imported.

 This isn't as outlandish as it sounds, as there's precedent for it =














 both in C++ <typeinfo> and java.lang.String, as well as D's Object.=













 What about a more general solution like
 -----------------------------
 import std.stdio, std.conv;

 struct complex {
      real re;
      real im;
      complex opAdd(real r) { return complex(re+r, im); }
      complex opAdd_r(real r) { return complex(re+r, im); }
      complex opAdd(complex c) { return complex(re+c.re, im+c.im); }
      string toString() { return std.conv.toString(re) ~ "+" ~  =










 std.conv.toString(im) ~ "i"; }
 }

 //complex opPostfix("i")(T)(T im) { return complex(0,im); }

 void main() {
 //    complex c =3D      1+5i      +     2+3i       +     6i;
      complex c =3D 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
      writefln( c );
 }
 -----------------------------

 This would also allow

 real opPostfix("L")(T)(T x) { return x; }

 T opPostfix("k")(T)(T x) { return x * 1000; }
 meter opPostfix("m")(T)(T x) { return meter(x); }










 http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_lite=







    -- Reiner



 I like a lot all those proposal for adding suffix based literal, but I=





 afraid that these could interfere(sp?) with the ones already existing =





 the language, so I wonder if 'library added' suffix shouldn't have an =





 operator to distinguish them for the language one.

 I'm thinking about the underscore '_': 5.8f_km would be replaced by  =




 km(5.8f), if there is no operator, there are some risk of ambiguity:  =




 "5.8fm" is-it 5.8f meters or 5.8 femtometers?

 With 5.8f_m and 5.8_fm you remove the ambiguity and the _ is visually =





 'pleasing' so this syntax would still be used.

 Regards,
 renoX



Votes++

In addition to removing ambiguity, requiring an initial underscore would=
  =

lower the chance of collisions with other symbols.

---
Simen Kjaeraas
Jan 14 2008