Complex question

[Thad Smith]

But then you lose the lvalue-preserving property. It looks like
there is no way to do what Jacob wanted without breaking the
conformance of creal(). Too bad.

Come to think of it, how is it done in Fortran ? The same way
as in C99, I think.
complex z
z= cmplx(new_real_val, imag(z))
z= cmplx(real(z), new_imag_val)

No direct accessors there either. To change one of the components
you have to synthesize a new complex number.

Yes, within the source, but the two assignments above can easily be
optimized to only set the needed component.

 

[user923005]

It could be implemented (for instance) as:

complex {
double parts[2];
};

or
complex {
double re;
double im;
};

or whatever underneath the covers, since that bit is not specified
clearly.

Of course it might be implemented as the standard specifies:
"Each complex type has the same representation and alignment
requirements as an array type containing exactly two elements of the
corresponding real type; the first element is equal to the real part,
and the second element to the imaginary part, of the complex
number."
When you think about that, then I'm sure you will realize that there are
a number of ways to accomplish what you want.

It's kind of sad if you are forced to do it in an underhanded way by
taking the address, though.

 

[jacob navia]

It could be implemented (for instance) as:
complex {
double parts[2];
};
or
complex {
double re;
double im;
};
or whatever underneath the covers, since that bit is not specified
clearly.

Of course it might be implemented as the standard specifies:
"Each complex type has the same representation and alignment
requirements as an array type containing exactly two elements of the
corresponding real type; the first element is equal to the real part,
and the second element to the imaginary part, of the complex
number."
When you think about that, then I'm sure you will realize that there are
a number of ways to accomplish what you want.

It's kind of sad if you are forced to do it in an underhanded way by
taking the address, though.

Specially if it could have been so easy to specify a couple of "setter"
functions:

// For double _Complex
double sreal(complex,double); // Returns the old value
double simag(complex,double); // Returns the old value

that would do this!

 

[David Thompson]

But then you lose the lvalue-preserving property. It looks like
there is no way to do what Jacob wanted without breaking the
conformance of creal(). Too bad.

Come to think of it, how is it done in Fortran ? The same way
as in C99, I think.
complex z
z= cmplx(new_real_val, imag(z))
z= cmplx(real(z), new_imag_val)

aimag, since it dates to the days of 'implicit integer i-n'. (Also the
source of the wise(?) saying, 'God is real unless declared integer.')

for single-precision complex, which until F90 was the only standard
complex type. For non-default=single complex in F90/5, you need to do
CMPLX (real, imag, [KIND=] desired_kind_number) even if real and imag
both already have the correct kind. I think there was a proposal to
add a generic=kind-following COMPLEX() in F03 but I don't see it.

No direct accessors there either. To change one of the components
you have to synthesize a new complex number.

Although FORTRAN/Fortran like C does specify that the representation
is the usual R,I and allow you to access it with EQUIVALENCE, or even
more grodily with mismatched COMMONs. (To be precise, these allow you
to overlay whatever the representations are for most types, but only
for some types does the standard define the representations so this
portably produces a useful result. COMPLEX = 2 REAL is portable.)

- formerly david.thompson1 || achar(64) || worldnet.att.net