e to the i pi

[Lane Straatman]

That's plane wrong.

You're plain funny. LS

 

[Keith Thompson]

If we multiply an imaginary number by itself an imaginary number of times,
maybe that would be real, on the analogy that a negative number multiplied
by itself is a positive.

No, that's not how it works. Operations on imaginary and complex
numbers are well defined mathematically, and well supported in C99.

Let's try it

int main(void)
{
int unity = 1;
int test1;

test1 = 0 - unity;

printf("%d * %d = %d\n", test1, test1, test1 * test1);
printf("Now a bit more complex %f\n", pow( sqrt(test1), sqrt(test1) );

return 0;
}

Nope.

Let me guess, you were so certain you were right that you didn't
bother to try it. There's a missing ')' on the second printf. You're
missing the required "#include <stdio.h>", which you can probably get
away with on many implementations. You're also missing the required
"#include <math.h>", which will probably cause the double results of
pow() and sqrt() to be interpreted as type int.

The sqrt() function takes a double argument and returns a double
result. In mathematical terms, it applies only to real numbers; it
can't give you a valid result for sqrt(-1). C99 supports imaginary
and complex numbers, as we've been discussing in this very thread.

Let's try it again:

#include <complex.h>
#include <math.h>
#include <stdio.h>
int main(void)
{
const double pi = 4 * atan(1.0);
const double complex result = cexp(I * pi);
printf("pi = %.10g\n", pi);
printf("result = %.10g + %.10g * I\n",
creal(result), cimag(result));
return 0;
}

Here's the output I get:

pi = 3.141592654
result = -1 + 1.224606354e-16 * I

It's not surprising that the result is inexact, since the value of pi
cannot be represented exactly.

 

[Keith Thompson]

Eric Sosman said:

Either you have a couple of axes to grind, or you're misreading what
Malcolm wrote, which rings true.

Yes, what Malcolm wrote about "what most folks think" is at least
plausible (though I suspect that most people who would ask what
e^(i*pi) is in the first place are likely to know the answer). It
wasn't entirely clear to me that Malcolm understands the issue
himself.

On the other hand, perhaps Malcolm's subtlety just escaped me, in
which case I'm duly embarrassed to have missed it.

The fact that I wrote the above *before* I got the "couple of axes"
joke makes this more likely. *Sigh*

 

[Keith Thompson]

For kicks and giggles, I'd like to see how precise one can get with this
using these predefined types. arctan of 1.0 will improve pi. Is there an
easy way to adduce e in C to the full width of a double? LS

exp(1.0)

 

[Malcolm McLean]

Let me guess, you were so certain you were right that you didn't
bother to try it.

Microsoft have taken away my compiler. I bought a brand new Windows Vista
machine, installed my copy of Visual Studio and - no executable.

 

[Richard Heathfield]

Malcolm McLean said:

Microsoft have taken away my compiler. I bought a brand new Windows Vista
machine, installed my copy of Visual Studio and - no executable.

You need Service Pack 7. Admittedly, Visual Studio won't work with that
either (possibly modulo emulators), but you get a perfectly capable C
compiler as part of the bundle. And of course it's completely free.

 

[Lane Straatman]

Lane Straatman a écrit :

[...]

If we multiply an imaginary number by itself an imaginary number of
times, maybe that would be real, on the analogy that a negative number
multiplied by itself is a positive.

Let's try it
[commented out, below]
Nope.

I'm not sure what Malcolm is trying to do here. Without the overloading
of functions in tgmath.h, I doubt that sqrt() and pow() are going to
cover the complex cases. I couldn't get sqrt() to work on an imaginary.

Devcpp doesn't even have tgmath.h . I copied it out of lcc and put it in
the include file and got a cool 300 errors:

That will never work.

Sorry, header files are NOT portable

A lot of them are, but this is exactly the type that would not be: filled
with type definitions that ordinary mortals can't remember. sqrt() looks
like this in tgmath.h at the dinkumware site:
sqrt
double sqrt(double x);
float sqrt(float x);
long double sqrt(long double x);
double _Complex sqrt(double _Complex x);
float _Complex sqrt(float _Complex x);
long double _Complex sqrt(long double _Complex x);The function returns the
real square root of x, x^(1/2).

I would think double _Complex sqrt(double _Complex x) gives the root in the
complex plane we're looking for.

 

[Malcolm McLean]

You need Service Pack 7. Admittedly, Visual Studio won't work with that
either (possibly modulo emulators), but you get a perfectly capable C
compiler as part of the bundle. And of course it's completely free.

Seriously?
I need a Windows library to compile my games and BASICdraw, but not for
scientific stuff. At the moment I'm just glad I didn't throw my old PC away.
However I did put the old cathode ray monitor to one side, so now I have to
unplug and replug monitors every time I use my compiler.

They are up to service pack 7 within one week of the OS coming on market?

 

[Keith Thompson]

Is there something about tgmath.h that makes its inclusion here ill-advised?

Yes, it's not supported my many compilers, and you don't need it.
<tgmath.h> just lets you use simple names for math functions that work
with any real type. The declarations in <tgmath.h> are "type-generic
macros" that simply invoke the appropriate function for the argument
type. For example, to compute the square root of a "double complex"
value, just use the csqrt() function in <complex.h> (or csqrtf() for
"float complex", or csqrtl for "long double complex").

 

[Richard Heathfield]

Malcolm McLean said:

Seriously?

Er, no. Sorry, Malcolm, I thought you knew - "Service Pack 7" is the traditional
name for Linux when being recommended as a fix for a Windows-specific problem.

I need a Windows library to compile my games and BASICdraw,

You have just discovered that Microsoft aren't all that interested in supporting
"legacy software" (e.g. their own two-year-old compiler, if your account is
anything to go by). Have you considered porting your stuff to a more stable
platform?

 

[JimS]

Malcolm McLean said:


You need Service Pack 7. Admittedly, Visual Studio won't work with that
either (possibly modulo emulators), but you get a perfectly capable C
compiler as part of the bundle. And of course it's completely free.

Vista supports Visual Studio 2005 only, as far as I can tell, and VS
needs a service pack to do that properly AND it has to be run as
Administrator.

Jim

 

[Lane Straatman]

Yes, what Malcolm wrote about "what most folks think" is at least
plausible (though I suspect that most people who would ask what
e^(i*pi) is in the first place are likely to know the answer). It
wasn't entirely clear to me that Malcolm understands the issue
himself.

I hope he takes from this a means to further his adducation.

On the other hand, perhaps Malcolm's subtlety just escaped me, in
which case I'm duly embarrassed to have missed it.

He's got me after complex roots, now, and I've thought about it enough to
want to write it from scratch.

The fact that I wrote the above *before* I got the "couple of axes"
joke makes this more likely. *Sigh*

Axis is correct, as one of them is Joshu's. LS

 

[CBFalconer]

.... snip ...

#include <stdio.h>
#include <stdbool.h>
#include <complex.h>

int main(void)
{
double complex z3, z4, z5;
z5= 0 + I*(3.14159);
z3=2.71828 + 0*I;
z4=cpow(z3,z5);
printf("%lf %lf\n", creal(z4), cimag(z4));
return 0;
}
Thanks for replies. e is now set closer to what Dr. Kelly has
listed for it, and I've got the right order on cpow().

For kicks and giggles, I'd like to see how precise one can get
with this using these predefined types. arctan of 1.0 will
improve pi. Is there an easy way to adduce e in C to the full
width of a double? LS

How about "exp(1.0);".

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Tim Prince]

Lane Straatman wrote:
Since we have a bunch of

rationals in C, we have a bunch of transcendentals as the arctan's of these
numbers. LS

In C, the atan() functions are a bunch of rationals. Ideally, in
certain ranges, with something resembling IEEE754 compliance, the
quality is measurable in ULPS difference between the actual result and
the mathematically correct one. It looks like you jumped from C to
something else in mid-sentence.

 

[Lane Straatman]

Malcolm McLean said:


Er, no. Sorry, Malcolm, I thought you knew - "Service Pack 7" is the
traditional
name for Linux when being recommended as a fix for a Windows-specific
problem.


You have just discovered that Microsoft aren't all that interested in
supporting
"legacy software" (e.g. their own two-year-old compiler, if your account
is
anything to go by). Have you considered porting your stuff to a more
stable
platform?

I don't want you to think that I would tea up on you for your lack of
proximity to the evil empire.* I have a linux disk, somewhere. I think it
had to do with a penguin; I can't quite remember the file. And that's what
happens every time with linux for people like me, who get knocked out every
couple of years: we forget that maze of files and switches and did I see
curses.h? LS
*it occurs to me that I made a spoonerism last night when I called you
"C-3pio."

 

[Lane Straatman]

Lane Straatman wrote:
Since we have a bunch of
In C, the atan() functions are a bunch of rationals. Ideally, in certain
ranges, with something resembling IEEE754 compliance, the quality is
measurable in ULPS difference between the actual result and the
mathematically correct one. It looks like you jumped from C to something
else in mid-sentence.

You couldn't be more wrong. I had a conversation with C_Dreamer about this.
LS

 

[Richard Bos]

Devcpp doesn't even have tgmath.h .

Of course it doesn't. It's a C89 implementation, not a C99 one.

I copied it out of lcc

Bad idea, as you'd have known if you'd read the FAQ.

Is there something about tgmath.h that makes its inclusion here ill-advised?

<http://c-faq.com/cpp/missinghdr.html>

Richard

 

[Richard Bos]

Microsoft have taken away my compiler. I bought a brand new Windows Vista
machine,

More fool you.

<http://www.theregister.co.uk/2006/11/22/vista_eula_worries/>
<http://www.securityfocus.com/columnists/423>
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html>

Richard

 

[Richard Heathfield]

Lane Straatman said:

You couldn't be more wrong.

Tim is right - atan() returns a double, and doubles have a finite number
of bits, so they literally *cannot* store irrational numbers. The best
they can do is store the closest rational approximation one can find
within the bits available.

 

[Hallvard B Furuseth]

For kicks and giggles, I'd like to see how precise one can get with
this using these predefined types.

Use long double, then. And atanl, cexpl.