operations on complex numbers in C99

[David Marsh]

I understand that C99 supports a complex type and complex
arithmetic. There is nothing about it in the FAQ and online
searches turned up very little except synopses. Can anyone point
me toward sources or give examples which show how to:

-declare a complex variable
-assign the real and imaginary parts
-perform the basic +,-,*,/ operations on complex numbers

Thanks,
David

[Robert Gamble]

On Aug 8, 12:48 pm, Richard Heathfield <[e-mail].i nvalidwrote:

Richard Tobin said:

In article <LoqdncSPdoMrcC TbnZ2dnUVZ8s3in [e-mail]>,
Richard Heathfield <[e-mail].i nvalidwrote:

>>creal() and cimag() are functions, which therefore do not yield
lvalues. You can't assign to them.

>>that is not a general restriction on functions, which may certainly
return a modifiable lvalue.

>Can you provide such an example?

>char *foo(char *s)
{
printf("%s\n", s);
return s;
}

The value returned by foo() is a pointer to a modifiable lvalue, not a
modifiable lvalue.

Good point. I cannot, then, see any way that a function may return a
modifiable lvalue.

It cannot, functions calls evaluate either to void or rvalue
expressions, that was my point.

Robert Gamble

[Keith Thompson]

those who know me have no need of my name <no************ ****@usa.netwri tes:

in comp.lang.c i read:

>>creal() and cimag() are functions, which therefore do not yield
lvalues. You can't assign to them.

that is not a general restriction on functions, which may certainly return
a modifiable lvalue. though creal and cimag do not.

I wrote the quoted text ("creal() and cimag() are functions, ...").
Please don't snip attribution lines.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <11************ *********@w3g20 00hsg.googlegro ups.com>,
Robert Gamble <rg*******@gmai l.comwrote:

>Good point. I cannot, then, see any way that a function may return a
modifiable lvalue.

>It cannot, functions calls evaluate either to void or rvalue
expressions, that was my point.

I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <11************ *********@w3g20 00hsg.googlegro ups.com>,
Robert Gamble <rg*******@gmai l.comwrote:

>>Good point. I cannot, then, see any way that a function may return a
modifiable lvalue.

>>It cannot, functions calls evaluate either to void or rvalue
expressions , that was my point.

I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

Except that no standard library function is defined to return an
lvalue.

I suppose, theoretically, that such a function could be defined in a
future version of the standard, but I sincerely hope that doesn't
happen (unless a mechanism is added to allow user-defined functions to
return lvalues).

<OT>Perhaps the OP who claimed that functions can return modifiable
lvalues was thinking of C++?</OT>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

>Except that no standard library function is defined to return an
lvalue.

Right, but the example that started this was just the sort of thing
the might plausibly be made to do so:

creal(myvar)=8. 0;

One can imagine that being implemented as a macro in such a way that
it *would* work, for example

#define creal(x) ((x)._realpart)

which would make it natural to wish for a function to be able to do
the same.

Of course, it would be simpler to standardise such a thing it by
requiring it to be a macro, and allowing the macro to use some kind of
implementation-defined magic function if it wished to (errno is an
existing example, I think).

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>>I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

>>Except that no standard library function is defined to return an
lvalue.

Right, but the example that started this was just the sort of thing
the might plausibly be made to do so:

creal(myvar)=8. 0;

One can imagine that being implemented as a macro in such a way that
it *would* work, for example

#define creal(x) ((x)._realpart)

which would make it natural to wish for a function to be able to do
the same.

Of course, it would be simpler to standardise such a thing it by
requiring it to be a macro, and allowing the macro to use some kind of
implementation-defined magic function if it wished to (errno is an
existing example, I think).

Exactly. Making it a macro would make sense (and I'd argue for
calling it CREAL rather than creal). Making it a "function" that
behaves in a way that no user-defined function can possibly behave
would be silly.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

On Wed, 08 Aug 2007 23:38:45 +0000, Richard Tobin wrote:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>>I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

>>Except that no standard library function is defined to return an
lvalue.

Right, but the example that started this was just the sort of thing
the might plausibly be made to do so:

creal(myvar)=8. 0;

Where will we stop? What about atan(myvar) = 1 to set myvar to
tan(1)? :-)

One can imagine that being implemented as a macro in such a way that
it *would* work, for example

#define creal(x) ((x)._realpart)

which would make it natural to wish for a function to be able to do
the same.

That would sound great, but for consistency with the rest of the
language I'd prefer setreal(z, x).
Much like ferror() which doesn't return a lvalue (but, depending
on how the FILE object is made, it could be very straightforward
to write a macro which does), and we have to use clearerr() to set
it to zero (and have no way to set it to one).

Of course, it would be simpler to standardise such a thing it by
requiring it to be a macro, and allowing the macro to use some kind of
implementation-defined magic function if it wished to (errno is an
existing example, I think).

-- Richard

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[jacob navia]

Richard Tobin wrote:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>>I can't see any way that you can write a function returning a
modifiable lvalue (or any lvalue at all), but that doesn't mean that a
standard library function couldn't be defined to return one.

>Except that no standard library function is defined to return an
lvalue.

Right, but the example that started this was just the sort of thing
the might plausibly be made to do so:

creal(myvar)=8. 0;

One can imagine that being implemented as a macro in such a way that
it *would* work, for example

#define creal(x) ((x)._realpart)

which would make it natural to wish for a function to be able to do
the same.

This is EXACTLY how it is implemented in lcc-win32.
This makes access to the parts of a complex number VERY
efficient.

The correct way is it however:

double _Complex z1;

....

z1 = 22.0+cimag(z1)* I; // Sets the real part to 22
or
z1 = creal(z1)+22*I; // Sets the imaginary part to 22

Of course, it would be simpler to standardise such a thing it by
requiring it to be a macro, and allowing the macro to use some kind of
implementation-defined magic function if it wished to (errno is an
existing example, I think).

-- Richard