www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.complex

reply eles <eles eles.com> writes:
Hello,
 I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
\dmd2\windows2\bin on path.

 Compiling the following:

import std.complex;

int main(){

	return 0;
}

fails with:

C:\dmd2>dmd test.d
OPTLINK (R) for Win32  Release 8.00.2
Copyright (C) Digital Mars 1989-2009  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test.obj(test)
 Error 42: Symbol Undefined _D3std7complex12__ModuleInfoZ
--- errorlevel 1

why?
May 08 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 09/05/10 02:27, eles wrote:

 Hello,
   I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
 \dmd2\windows2\bin on path.

   Compiling the following:

 import std.complex;

 int main(){

 	return 0;
 }

 fails with:

 C:\dmd2>dmd test.d
 OPTLINK (R) for Win32  Release 8.00.2
 Copyright (C) Digital Mars 1989-2009  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 test.obj(test)
   Error 42: Symbol Undefined _D3std7complex12__ModuleInfoZ
 --- errorlevel 1

 why?


You usually get this error when you haven't passed the relevant file to 
dmd. I don't use windows so I can't verify what's going on here, it 
seems phobos isn't getting linked in though. Do you get any errors like 
this if you try and import std.stdio? If so make sure you have dmd set 
up correctly, that is having the library search paths and librarys 
correct in dmd's config file, and making sure dmd is finding its config 
file.

Sorry I can't give more specific advise, the steps that need to be taken 
are different to linux/os x/freebsd... Someone else with more windows 
experience may be able to help here :)
May 08 2010
parent reply eles <eles eles.com> writes:
Thanks for your answer. Me too, I prefer working on linux but for
some reasons I remain on windows until dmd goes 64-bit.

For the record, std.stdio works fine:

Compiling

import std.stdio;

int main(){
writefln("hello!\n");
	return 0;
}

results in:

C:\dmd2>dmd test.d

C:\dmd2>test
hello!

So, the problem is somewhere in std.complex.
May 09 2010
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

eles wrote:

 Thanks for your answer. Me too, I prefer working on linux but for
 some reasons I remain on windows until dmd goes 64-bit.
 
 For the record, std.stdio works fine:
 
 Compiling
 
 import std.stdio;
 
 int main(){
 writefln("hello!\n");
 	return 0;
 }
 
 results in:
 
 C:\dmd2>dmd test.d
 
 C:\dmd2>test
 hello!
 
 So, the problem is somewhere in std.complex.


Doesn't work even with 2.028.
For some reason complex isn't compiled into the standard lib.

You can make it work by passing the full path to complex.d
on the command line along with test.d

Though I think there's been discussion about the whole complex number
support. Not sure what's going off but I think it's going to overhauled
or replaced, so you'd be better off not using std.complex

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFL5ruJT9LetA9XoXwRAoLSAJ9tLQo3i+CwkfV6a0dQHiQx7WyVlACfTNPp
kJH0pkJFwxy4FlQkn9jFLmo=
=SeTC
-----END PGP SIGNATURE-----
May 09 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 09/05/10 14:41, div0 wrote:

 Though I think there's been discussion about the whole complex number
 support. Not sure what's going off but I think it's going to overhauled
 or replaced, so you'd be better off not using std.complex


std.complex has just undergone its major rewrite, I'm not sure if it 
made it into the latest release or not, it will definitely be in the 
next one if it isn't already in though.
May 09 2010
parent reply eles <eles eles.com> writes:
actually, i think 2.045 was the second (after 2.044) release to
include std.complex.

as i understand, std.complex should replace the native types cfloat,
creal, ifloat, ireal etc.

i was eager to test the new std.complex. it seems that some work is
still needed. maybe someone could submit a bug report?

otoh, native types creal, cfloat etc. are not deprecated, it seems.
they should be, i think.

eles
May 09 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sun, 09 May 2010 18:57:08 +0000, eles wrote:


 actually, i think 2.045 was the second (after 2.044) release to include
 std.complex.


You are right, what's in Phobos now is the new std.complex.



 as i understand, std.complex should replace the native types cfloat,
 creal, ifloat, ireal etc.
 
 i was eager to test the new std.complex. it seems that some work is
 still needed. maybe someone could submit a bug report?


Based what div0 is saying, the problem doesn't seem to be with the module 
itself, since the problem existed even with 2.028, which contained the 
old std.complex.  Rather, I suspect Robert is right that the module 
doesn't get compiled into the Phobos library file.  (I wonder if it could 
be because it only contains templated code?)

I'll look into it, hopefully we'll get it fixed by the next release.  
Until then, just do what div0 suggests and pass std.complex to DMD by the 
command line.



 otoh, native types creal, cfloat etc. are not deprecated, it seems. they
 should be, i think.


Well, it's up to Walter to decide when that happens.  std.complex is 
ready for it. ;)

-Lars
May 09 2010
prev sibling parent reply Don <nospam nospam.com> writes:
eles wrote:

 Hello,
  I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
 \dmd2\windows2\bin on path.
 
  Compiling the following:
 
 import std.complex;
 
 int main(){
 
 	return 0;
 }
 
 fails with:
 
 C:\dmd2>dmd test.d
 OPTLINK (R) for Win32  Release 8.00.2
 Copyright (C) Digital Mars 1989-2009  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 test.obj(test)
  Error 42: Symbol Undefined _D3std7complex12__ModuleInfoZ
 --- errorlevel 1
 
 why?


Makefile problem. This is a critical (but trivial to fix) bug.
May 09 2010
parent reply eles <eles eles.com> writes:
Thank you, Don. I saw your post on the http://news.gmane.org/
gmane.comp.lang.d.dmd.beta group. I'll wait for the next release.

Does anybody knows about when the http://d.puremagic.com/issues/
show_bug.cgi?id=2460 (DMD bug 2460) will be addressed?
May 09 2010
parent reply eles <eles eles.com> writes:
Confirmation: in the new beta, the test case for the std.complex
compiles on windows xp with dmd 2.046beta. I cannot post on the
D.phobos newsgroup, but I post the confirmation here.

I did not test it further.

Compiling

import std.complex;

int main(){
	return 0;
}


results in:

C:\dmd2>dmd test.d

C:\dmd2>test

C:\dmd2>

While we are here, can somebody look at DMD bug 2460 please?

eles
May 11 2010
parent reply eles <eles eles.com> writes:
the following test case also works:

Compiling

import std.stdio;
import std.complex;

Complex!(double) x,y;

int main(){
	writefln("salut!\n");
	x.re=1;
	x.im=1;
	y=x.conj();
	writefln("x=%f+%f*i\n",x.re,x.im);
	writefln("y=%f+%f*i\n",y.re,y.im);
	return 0;
}


results in

C:\dmd2>dmd test.d

C:\dmd2>test
salut!

x=1.000000+1.000000*i

y=1.000000+-1.000000*i

C:\dmd2>

Which is OK. However, displaying complex numbers in that way is not
very nice. Is there any dedicated formatting for that? (it would be
nice to be able displaying a complex number in both Cartesian and
Polar formats)

eles
May 11 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 11 May 2010 11:51:34 +0000, eles wrote:


 the following test case also works:
 
 Compiling
 
 import std.stdio;
 import std.complex;
 
 Complex!(double) x,y;
 
 int main(){
 	writefln("salut!\n");
 	x.re=1;
 	x.im=1;
 	y=x.conj();
 	writefln("x=%f+%f*i\n",x.re,x.im);
 	writefln("y=%f+%f*i\n",y.re,y.im);
 	return 0;
 }
 
 
 results in
 
 C:\dmd2>dmd test.d
 
 C:\dmd2>test
 salut!
 
 x=1.000000+1.000000*i
 
 y=1.000000+-1.000000*i
 
 C:\dmd2>


Cool!



 Which is OK. However, displaying complex numbers in that way is not very
 nice. Is there any dedicated formatting for that? (it would be nice to
 be able displaying a complex number in both Cartesian and Polar formats)


The problem is that there doesn't seem to be any "standard" way of 
converting stuff to strings in Phobos.

The toString() function I put into Complex is designed to write complex 
numbers to an arbitrary output range.  It may seem very verbose when all 
you want to do is to get a simple string representation, but it was meant 
as a proposal for exactly such a standard.

Another possibility was proposed by Don, as demonstrated in 
std.bigint.BigInt.toString():

    http://www.digitalmars.com/d/2.0/phobos/std_bigint.html#toString

The idea is that if a type defines such a toString(), it should -- in the 
future, that is -- work automatically with std.conv.to(), 
std.stdio.writef*() etc.  Then you'd be able to do things like

    auto z = Complex!real(1, -2);

    auto str1 = to!string(z);
    assert (str1 == "1-2i");

    writefln("%.2g", z); // Prints "1.00-2.00i"

Right now, you are kind of stuck with the way you demonstrated, or you 
can have Complex.toString() write to an std.array.Appender!string range.

-Lars
May 11 2010
parent reply eles <eles eles.com> writes:
Maybe I am wrong, but my feeling is that if the complex numbers were a native
type (like creal&co. are now), then it would have been possible to have a
dedicated formatting (just like %f, %d and %s are) for writefln.

Putting the type into the library seems to forbid some very nice things:

 - initializing with "Complex!double z=1+2i" or "Complex!double z=1+2*i" or or
"Complex!double z=2.23*exp(1.107*i)" syntax (which is very practical) - even in
C99 one could write "complex double z=1+2*I" (but "I" is a defined symbol) -
instead of "Complex!double(2,3)"
 - lack of support for formatting in writef (although, that should not be
limited to native types)
 - formatting in writef/printf is quite versatile for regular use, and could be
immediately extended to complex numbers (e.g. if one formatting is specified,
then both real and imaginary parts would be displayed with that format),
although 2 different complex-number formats should be defined: real/imaginary
and amplitude/phase
May 11 2010
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 11 May 2010 15:08:07 +0000, eles wrote:


 Maybe I am wrong, but my feeling is that if the complex numbers were a
 native type (like creal&co. are now), then it would have been possible
 to have a dedicated formatting (just like %f, %d and %s are) for
 writefln.
 
 Putting the type into the library seems to forbid some very nice things:
 
  - initializing with "Complex!double z=1+2i" or "Complex!double z=1+2*i"


I don't think there will still be a special syntax for complex literals 
when the built-in types are deprecated.  I'd guess not.  It is, however, 
likely that creal etc. will be aliases for Complex!real etc.  And this 
doesn't look that bad:

  auto z = cdouble(1,2);



  or or
 "Complex!double z=2.23*exp(1.107*i)" syntax (which is very practical) -


The following does just that, and IMO it looks a lot better:

  auto z = fromPolar(2.23, 1.107);



 even in C99 one could write "complex double z=1+2*I" (but "I" is a
 defined symbol) - instead of "Complex!double(2,3)"


If you want that, just define

  immutable I = Complex!float(0, 1);

Perhaps it would be an idea to put that in std.complex, but I'm not 
convinced.



  - lack of support for formatting in writef (although, that should not
  be
 limited to native types)
  - formatting in writef/printf is quite versatile for regular use, and
  could be
 immediately extended to complex numbers (e.g. if one formatting is
 specified, then both real and imaginary parts would be displayed with
 that format), although 2 different complex-number formats should be
 defined: real/imaginary and amplitude/phase


This is exactly what I'm proposing.  Complex numbers don't have to be 
built-in for that.

-Lars
May 11 2010
parent eles <eles eles.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s
article

 On Tue, 11 May 2010 15:08:07 +0000, eles wrote:

 Maybe I am wrong, but my feeling is that if the complex numbers




were a

 native type (like creal&co. are now), then it would have been




possible

 to have a dedicated formatting (just like %f, %d and %s are) for
 writefln.

 Putting the type into the library seems to forbid some very nice




things:

  - initializing with "Complex!double z=1+2i" or "Complex!double




z=1+2*i"

 I don't think there will still be a special syntax for complex


literals

 when the built-in types are deprecated.  I'd guess not.  It is,


however,

 likely that creal etc. will be aliases for Complex!real etc.  And


this

 doesn't look that bad:
   auto z = cdouble(1,2);


My opinion is that it does. Image writing y=(3+2i)^2+z^2*i.

OTOH, the suggestion you made below (see below)...


  or or
 "Complex!double z=2.23*exp(1.107*i)" syntax (which is very




practical) -

 The following does just that, and IMO it looks a lot better:
   auto z = fromPolar(2.23, 1.107);

 even in C99 one could write "complex double z=1+2*I" (but "I" is a
 defined symbol) - instead of "Complex!double(2,3)"


 If you want that, just define
   immutable I = Complex!float(0, 1);


it is nice. However, I think it should be defined as Complex!real
(0,1);

I hope it will be automatically downsized to Complex!int if the left
value is a Complex!int and so on.

I vote for defining it in std.complex for the folowing reasons:

 - it will enforce coding discipline and standardize code among
libraries and users, the code will be consistent and copy-paste
portable.
 - it is similar to C99, already judged as acceptable for the C
community
 - if such an elementary thing is left to be defined by the
programmer, what long before not using the std.complex module at all?
I mean, as well one could re-define the whole complex library. I
think having std.complex in the standard library is primarily for
standardization and only second for its usefulness (ok, is useful
too, but I want to make a point).

 Also, I think the best is to mimick the functions in the C99
<complex.h>: http://www.opengroup.org/onlinepubs/009695399/basedefs/
complex.h.html

 Me, for one, I prefer writing y=z*conj(z) instead of z=z*z.conj().
OK, maybe is just personal preference.

 OTOH, I feel like maintaining x.re and x.im instead of creal(x) and
cimag(x), since the latter (as defined in C99) are only right-values.

 I have some experience with both C99 complex and with GNU Scientific
Library GSL_COMPLEX. Both have ups and downs, I still prefer to work
with C99, though.

 Also, if we are here, is any way to define ' (apostrophe) for an
(unary) operator? Having z' to mean (z conjugate) would be awesome
(y=z*z'). But maybe is just my Matlab background speaking here. Or
another character (ideas, anyone?... #z

 A note of modesty: I do not try to push it harder than it is
acceptable, but since the complex numbers are just in a major
rewrite, let's try to do it in the best way. We are not constrained
by compatibility/legacy issues.

 Thanks.

 eles
May 11 2010