www.digitalmars.com         C & C++   DMDScript  

D - D complex (again)

reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
Some aspects of complex now work O.K. with 0.18.

Problems (1)

Multiplying an imaginary by itself causes a stack fault at compile time:

 imaginary imag = 2.5i;
 printf ("test of imag*imag = %Lf\n",imag*imag);

DMD caused a stack fault in module DMD.EXE at 015f:0040fed2.
Registers:
EAX=0073df84 CS=015f EIP=0040fed2 EFLGS=00010216
EBX=0073df84 SS=0167 ESP=00622000 EBP=00731a40
ECX=00a253e0 DS=0167 ESI=00d64ef4 FS=39d7
EDX=00480fec ES=0167 EDI=00737eb8 GS=39de
Bytes at CS:EIP:
57 e8 f0 02 00 00 8b 4b 1c 89 43 18 e8 e5 02 00
Stack dump:
00d64ef4 00731a40 0073df84 00a25404 0040924a 00731a40 0073df84 0040b61e
0040b625 00737eb8 00d64ef4 00d64ef4 004091c7 00731a40 00d64ef4 00409e6b

(2) I need to be able to extract the imaginary part of a complex
variable as a real number of type extended.  This is possible as
follows:

complex z = 1. + 2.i;
extended imag_part = z.im/1i;

That involves an unnecessary division sum.

As I explained before, it makes sense to me for   z.im to return an
extended number, rather than the imaginary number, but is it possible to
add another property e.g.

z.rim

which would return it as extended?

Other properties which would be useful would be the modulus

sqrt(z.re^2 + z.rim^2)

and the argument

atan2(z.rim,z.re)

(I forget the order of the arguments, what is needed is z.rim/z.re
protected against infinities).

These should preferably be worked out to full precision.

Thanks

John
Feb 07 2002
next sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"John Fletcher" <J.P.Fletcher aston.ac.uk> wrote in message
news:3C626C84.39229BEF aston.ac.uk...
[...]
 DMD caused a stack fault in module DMD.EXE at 015f:0040fed2.
 Registers:
 EAX=0073df84 CS=015f EIP=0040fed2 EFLGS=00010216
 EBX=0073df84 SS=0167 ESP=00622000 EBP=00731a40
 ECX=00a253e0 DS=0167 ESI=00d64ef4 FS=39d7
 EDX=00480fec ES=0167 EDI=00737eb8 GS=39de
 Bytes at CS:EIP:
 57 e8 f0 02 00 00 8b 4b 1c 89 43 18 e8 e5 02 00
 Stack dump:
 00d64ef4 00731a40 0073df84 00a25404 0040924a 00731a40 0073df84 0040b61e
 0040b625 00737eb8 00d64ef4 00d64ef4 004091c7 00731a40 00d64ef4 00409e6b
This recalls me a question: is it possible for a D program to crash? Anyway, how about adding a crash/unhandled exception reporting utility with the language? Ciao
Feb 07 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a3tsue$q3t$1 digitaldaemon.com...

 This recalls me a question: is it possible for a D program to crash?
 Anyway, how about adding a crash/unhandled exception reporting
 utility with the language?
In theory, it looks like it tries to handle all exceptions it can, both internal and system. At least the access violation is handled correctly, it just exits quietly with a tiny error message =)
Feb 07 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"John Fletcher" <J.P.Fletcher aston.ac.uk> wrote in message
news:3C626C84.39229BEF aston.ac.uk...
 Some aspects of complex now work O.K. with 0.18.

 Problems (1)

 Multiplying an imaginary by itself causes a stack fault at compile time:

  imaginary imag = 2.5i;
  printf ("test of imag*imag = %Lf\n",imag*imag);
Ok, I'll work on that.
 DMD caused a stack fault in module DMD.EXE at 015f:0040fed2.
 Registers:
 EAX=0073df84 CS=015f EIP=0040fed2 EFLGS=00010216
 EBX=0073df84 SS=0167 ESP=00622000 EBP=00731a40
 ECX=00a253e0 DS=0167 ESI=00d64ef4 FS=39d7
 EDX=00480fec ES=0167 EDI=00737eb8 GS=39de
 Bytes at CS:EIP:
 57 e8 f0 02 00 00 8b 4b 1c 89 43 18 e8 e5 02 00
 Stack dump:
 00d64ef4 00731a40 0073df84 00a25404 0040924a 00731a40 0073df84 0040b61e
 0040b625 00737eb8 00d64ef4 00d64ef4 004091c7 00731a40 00d64ef4 00409e6b

 (2) I need to be able to extract the imaginary part of a complex
 variable as a real number of type extended.  This is possible as
 follows:

 complex z = 1. + 2.i;
 extended imag_part = z.im/1i;

 That involves an unnecessary division sum.

 As I explained before, it makes sense to me for   z.im to return an
 extended number, rather than the imaginary number, but is it possible to
 add another property e.g.

 z.rim

 which would return it as extended?
I think a better way is just optimize out the /1i.
 Other properties which would be useful would be the modulus

 sqrt(z.re^2 + z.rim^2)

 and the argument

 atan2(z.rim,z.re)

 (I forget the order of the arguments, what is needed is z.rim/z.re
 protected against infinities).

 These should preferably be worked out to full precision.

 Thanks

 John
Just call the C ones for now.
Feb 07 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"John Fletcher" <J.P.Fletcher aston.ac.uk> wrote in message
news:3C626C84.39229BEF aston.ac.uk...
 Some aspects of complex now work O.K. with 0.18.

 Problems (1)

 Multiplying an imaginary by itself causes a stack fault at compile time:

  imaginary imag = 2.5i;
  printf ("test of imag*imag = %Lf\n",imag*imag);
Ok, I've got this fixed.
 (2) I need to be able to extract the imaginary part of a complex
 variable as a real number of type extended.  This is possible as
 follows:

 complex z = 1. + 2.i;
 extended imag_part = z.im/1i;

 That involves an unnecessary division sum.

 As I explained before, it makes sense to me for   z.im to return an
 extended number, rather than the imaginary number, but is it possible to
 add another property e.g.

 z.rim

 which would return it as extended?
I changed things around so that z.im will return the imaginary part as a real number. To get the imaginary part as an imaginary number: (imaginary)z This should cover the necessary cases.
Feb 11 2002
parent John Fletcher <J.P.Fletcher aston.ac.uk> writes:
Walter wrote:

 "John Fletcher" <J.P.Fletcher aston.ac.uk> wrote in message
 news:3C626C84.39229BEF aston.ac.uk...
 Some aspects of complex now work O.K. with 0.18.

 Problems (1)

 Multiplying an imaginary by itself causes a stack fault at compile time:

  imaginary imag = 2.5i;
  printf ("test of imag*imag = %Lf\n",imag*imag);
Ok, I've got this fixed.
Thanks. I had no problem multiplying real and imaginary.
 I changed things around so that z.im will return the imaginary part as a
 real number. To get the imaginary part as an imaginary number:
         (imaginary)z
 This should cover the necessary cases.
Thanks. Presumably that will be in the next release. John
Feb 12 2002