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

"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

"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 =)

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

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

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