A reference to separate pairs of values

C++ has a complex class which has overloaded the basic arithmetic operators.
That's nice but there are some issues with regards to assignment of complex values.

Suppose you have another class that implements a complex array internally as two separate arrays of real and imaginary parts.

Code:

---

class carr {
double *rval ;
double *ival ;
unsigned len ;
....
public:
}

---

I wrote part of an iterator for a class like this. But I want my iterators * operator to return a reference to a complex number. While I can easily create such an iterator I can not assign to the * operator. In fact there is no way to return a complex reference to an element of this 'array' that I can see.

For example wouldn't it be nice if I could,

Code:

---

carr  c1(100) ;
c1[25] = std::complex<double>(1.0, -1.0) ;

---

There is no [] operator that I can construct that would support these semantics as far as I can tell. I think if I had a single flat double array of twice the size, it could be done with a cast, but otherwise am I out of luck? Do I require a separate set value function?

Quote:

---

Suppose you have another class that implements a complex array internally as two separate arrays of real and imaginary parts.

---

Why not simply implement the internal complex array as an array of std::complex<double>?

You have to invent some kind of reference object which encapsulates the action of setting the separate real and imaginary parts.

To clarify what I was saying.

I would describe this representation of complex number as "planar," as in, having a plane of real components and a plane of imaginary components. You want to interface this with a more "traditional" complex class, where real and imaginary are kept together. Call this traditional complex class "trad_complex." Then, you could:

Code:

---

class complex_ref
{
public:
    complex_ref(double &real_p, double &imag_p)
      : real(real_p), imag(imag_p)
    {}

    complex_ref &operator=(const complex_ref &complex_p)
    {
        real = complex_p.real;
        imag = complex_p.imag;
        return *this; // duh -- I forgot this initially
    }

    complex_ref &operator=(const trad_complex &trad_p)
    {
        real = trad_p.real;
        imag = trad_p.imag;
        return *this; // duh -- I forgot this initially
    }

    // Allow conversion to trad_complex
    operator trad_complex() const
    {
        return trad_complex(real, imag);
    }

    // Any other relevant operations...

    double ℜ
    double &imag;
};

---

When this type is constructed, it holds references to the actual real and imaginary parts. These parts could be located anywhere -- such as in a planar storage format. In practice, you might make the constructor of this class private, and make the complex iterator a friend, so that the only code which can construct complex_ref objects is the iterator itself (to prevent abuse of the class).

The real and imag parts are accessed as if they were contiguous members of the class -- however, they're really just references to the actual data.

Allowing conversion to trad_complex allows you to use the (presumably rich) set of features of the traditional complex class.

How would class carr be different from std::vector<std::complex<double> >?

Quote:

---

Originally Posted by anon

How would class carr be different from std::vector<std::complex<double> >?

---

Look at the class -- all the real parts are in one array, all the imaginary parts in another array. A std::complex<double> holds both the real and imaginary parts "right next to each other."

It's like the difference between flat color and planar color, in graphics.

Yes, but isn't that an implementation detail? For example considering the example usage:

Code:

---

carr  c1(100) ;
c1[25] = std::complex<double>(1.0, -1.0) ;

---

That would work, if carr stood for std::vector<std::complex<double> > and no new class would be necessary.

Is there something I don't see, but I can't see why one would want to go through all the hoops if the implementation decisions make it hard to implement desired behaviour.

Quote:

---

Originally Posted by anon

Yes, but isn't that an implementation detail? For example considering the example usage:

Code:

---

carr  c1(100) ;
c1[25] = std::complex<double>(1.0, -1.0) ;

---

That would work, if carr stood for std::vector<std::complex<double> > and no new class would be necessary.

Is there something I don't see, but I can't see why one would want to go through all the hoops if the implementation decisions make it hard to implement desired behaviour.

---

Without knowing the application I can't say, but planar representations can have advantages in certain situations.

The impression I got was that this "planar complex array" was something out of the OP's control, so I just tried to come up with something to turn it into a sane interface.

Quote:

---

Originally Posted by brewbuck

You have to invent some kind of reference object which encapsulates the action of setting the separate real and imaginary parts.

---

OK that's interesting. The semantic trickery I missed is the effect of declaring

Code:

---

double &real ;
double &imag ;

---

If I then initialize that with

Code:

---

carr c1(100) ;

real = *(c1.rval + k) ;
imag = *(c1.rval + k) ;

// this assigns to the k'th element of the carr array?
real = 1.0 ;
imag = -1.0 ;

---

What you are saying is that you then wrap real and imag in a class and overload the assignment operator with the code segment you provided,

Code:

---

complex_ref &operator=(const complex_ref &complex_p)
    {
        real = complex_p.real;
        imag = complex_p.imag;
    }

---

This allows something like

Code:

---

complex_ref  cr(c1.rval + 25, c1.ival + 25) ;
cr = std::complex<double>(1.0,-1.0) ;

---

That's pretty nifty, and a subtle point with regards to the meaning of a 'reference' value, which is a kind of pointer in disguise I suppose. I'm actually a little confused by this however, so I'm not sure if I really understand this.

By what you are saying there is a vast difference between assignment and initialization for reference values. ie

Code:

---

double x = 5.0 ;
double y = 6.0 ;
double &r(x) ;
// r == 5
r = 7 ; // x = 7
r = y ; // x = y = 6.0
// how do I change r's reference to point to y?

---

Is this correct?
Edit:
It seems to be correct based on a quick search. However reference can only be initialized once. You can't change what they are pointing to.

You cannot assign to a reference (as in assign to the reference itself), so in the given scope, r can only ever be an alias for x.

Quote:

---

Originally Posted by SevenThunders

By what you are saying there is a vast difference between assignment and initialization for reference values. ie

Code:

---

double x = 5.0 ;
double y = 6.0 ;
double &r(x) ;
// r == 5
r = 7 ; // x = 7
r = y ; // x = y = 6.0
// how do I change r's reference to point to y?

---

Is this correct?

---

Yes, a reference can only be "seated" during construction time. Once constructed, all assignments to the reference simply assign to the underlying value, they cannot "reseat" the reference. So the references inside the complex_ref are seated in the constructor, but after that point, they act as shuttles to the actual data.

EDIT: To further clarify all this, the intention of this complex_ref class is that the iterator's operator*() will return one of them. It builds a complex_ref from the appropriate real and imaginary parts, and returns it. The caller who uses this reference can act as if it was just a trad_complex -- it is assignable as such.

Quote:

---

Originally Posted by brewbuck

Without knowing the application I can't say, but planar representations can have advantages in certain situations.

The impression I got was that this "planar complex array" was something out of the OP's control, so I just tried to come up with something to turn it into a sane interface.

---

Basically I've got a thousand lines of dense C code plus an entire interface to Matlab that uses a format with separate real and imaginary arrays. The purpose of my class is to provide a kind of interface to another set of libraries that do things properly. Flat arrays for multidimensional real and complex tensors and matrices.

Here is another odd thought along the lines of Brewbuck's solution. What would happen if I declared the type:

typedef std::complex<double &> complexref ;

and then provided overloaded assignment operators for going back and forth between the two types

Code:

---

std::complex<double>  // and
std::complex<double &>

---

Would this work?

Quote:

---

Would this work?

---

No, since you cannot have a container of references.

Quote:

---

Originally Posted by laserlight

No, since you cannot have a container of references.

---

It does compile however, but I've not tried to use it. What would the problem be? It seems like most of the natural complex op.s would work.

Edit: Nope you are right it won't let me construct an array of references.

Quote:

---

Originally Posted by SevenThunders

It does compile however, but I've not tried to use it. What would the problem be? It seems like most of the natural complex op.s would work.

---

The problem is that when a reference is created it MUST be seated to another variable. In the following code, where exactly does that reference get seated?

Code:

---

std::complex<double &> val;

---

std::complex will attempt to default-construct the real and imaginary parts -- but since these parts are of type "double &" there is no such default constructor.

Quote:

---

It does compile however, but I've not tried to use it. What would the problem be? It seems like most of the natural complex op.s would work.

---

Are you sure it compiles? I noticed that my statement was inaccurate since std::complex is not a container, but still, references are not copyable (though what they refer to may be copyable). So, what happens if you try to assign a std::complex<double&> to another std::complex<double&>? It would mean that you have to assign the references themselves so they refer to a different object, and as pointed out this is illegal.

Quote:

---

Originally Posted by brewbuck

The problem is that when a reference is created it MUST be seated to another variable. In the following code, where exactly does that reference get seated?

Code:

---

std::complex<double &> val;

---

std::complex will attempt to default-construct the real and imaginary parts -- but since these parts are of type "double &" there is no such default constructor.

---

Well I tried to contruct it like

Code:

---

double x,y ;
std::complex<double &> val(x,y) ;

---

But I'm having some issues with the roll your own complex reference class as well. If I want to implement a forward iterator it seems I can either support reading the values or assigning the values but not both.

The problem is how can I write an assignment operator that assigns a class of type complex_ref to the class std::complex<double> ?

Code:

---

typedef std::complex<double> complexd

complexd & complexd::operator=(complex_ref &u)
{

  this->real() = u.real() ;
  this->imag = u.imag() ;
  return *this ;
}

---

unfortunately complexd->real() is a const reference, assignment shouldn't be able to work.
Maybe this? (based on your implementation)

Code:

---

typedef std::complex<double> complexd

complexd & complexd::operator=(complex_ref &u)
{

 *this = u.complexd() ;
  return *this ;
}

---

O wait maybe I'm misunderstanding something.

Code:

---

        operator complexd() const
        {
                return (complexd(real,imag)) ;
        }

---

Does this overload a type cast or something? This syntax is new to me. If so is the type cast applied automatically?

Quote:

---

Originally Posted by SevenThunders

unfortunately complexd->real() is a const reference, assignment shouldn't be able to work.
Maybe this? (based on your implementation)

Code:

---

typedef std::complex<double> complexd

complexd & complexd::operator=(complex_ref &u)
{

 *this = u.complexd() ;
  return *this ;
}

---

---

Close:

Code:

---

*this = u.operator complexd();

---

Or:

Code:

---

*this = (complexd)u;

---

Actually, does that work? I am not sure if you can invoke a conversion operator through a typedef like that. It is an alias for the same type, but I'm not sure what the standard says. You might have to explicitly specify "std::complex<double>" instead.

I'm sure laserlight or CornedBee will know the answer to that one.

Quote:

---

Originally Posted by brewbuck

Close:

Code:

---

*this = u.operator complexd();

---

Or:

Code:

---

*this = (complexd)u;

---

Actually, does that work? I am not sure if you can invoke a conversion operator through a typedef like that. It is an alias for the same type, but I'm not sure what the standard says. You might have to explicitly specify "std::complex<double>" instead.

I'm sure laserlight or CornedBee will know the answer to that one.

---

Not only does it work but the cast is not needed and the attempt to overload = for std::complex is unnecessary. Not only is the attempt at overloading unnecessary, it won't let me for some reason. Maybe operator overloadings have to be friends of the underlying class. Anyway this seems to be right as rain on MS Vis. Studio 2008.

Code:

---

        double x = 1.0 , y = 1.0 ;
        complexref r(x,y) ;
        complexd u = r ;
        std::cout << u  << std::endl ;

---

Quote:

---

Originally Posted by SevenThunders

Not only does it work but the cast is not needed and the attempt to overload = for std::complex is unnecessary.

---

I guess so, since std::complex<double> already has an operator=(const std::complex<double>) and we've provided an implicit conversion to that type.

Quote:

---

Not only is the attempt at overloading unnecessary, it won't let me for some reason.

---

What is some reason? What error do you get?

Quote:

---

Originally Posted by brewbuck

I guess so, since std::complex<double> already has an operator=(const std::complex<double>) and we've provided an implicit conversion to that type.



What is some reason? What error do you get?

---

It could be a problem with syntax, since it gets a bit squirly, but this code,

Code:

---

std::complex<double> & std::complex<double>::operator=(complexref &cr)
{
*this = cr ;
return(*this) ;
}

---

gives me a compile error

Quote:

---

: error C2511: 'std::complex<double> &std::complex<double>::operator =(complexref &)' : overloaded member function not found in 'std::complex<double>'

---

in MS Visual Studio 8. It's probably something stupid I did with the syntax.

Well, you're trying to create a new member of std::complex<T>, which is impossible without changing the header file.

I thought you were trying to say that the assignment operator FROM std::complex<T> TO complex_ref was not working -- it should.

Quote:

---

Originally Posted by brewbuck

Well, you're trying to create a new member of std::complex<T>, which is impossible without changing the header file.

I thought you were trying to say that the assignment operator FROM std::complex<T> TO complex_ref was not working -- it should.

---

Actually I was just trying to overload the assignment operator for complex<T>. Somehow this doesn't quite work unless you change the header, which I don't need to do thanks to the cast trick.