CoCoA » CoCoALib

Yes, I believe C++11 makes it easier to construct std::vector values. I don't recall all the details.

Do we want to invest in a temporary solution until CoCoA switches to C++11?

it would be handy even though I don't know how many times we would use it (we had implemented the similar constructor for ideals, which removed the urgency)

We have these (for short lists)

  ideal::ideal(ConstRefRingElem r1)
  ideal::ideal(ConstRefRingElem r1, ConstRefRingElem r2)
  ideal::ideal(ConstRefRingElem r1, ConstRefRingElem r2, ConstRefRingElem r3)
  ideal::ideal(ConstRefRingElem r1, ConstRefRingElem r2, ConstRefRingElem r3, ConstRefRingElem r4)
  inline std::vector<T> CoCoAVector(const T& a)
  inline std::vector<T> CoCoAVector(const T& a,const T& b)
  inline std::vector<T> CoCoAVector(const T& a,const T& b,const T& c)
  inline std::vector<T> CoCoAVector(const T& a,const T& b,const T& c,const T& d)

It seems to me that this will be covered by the "braced constructor" for C++ vectors that appeared in C++11.

What might be more interesting is a constructor for "homogeneous" vectors of RingElem, by which I mean that all elements are in the same ring. Presumably one could also have an empty vector of elements of a given ring -- this would even have a well-defined sum!

The example use in ex-RingHom4.C did not work properly:

 vector<RingElem> v = CoCoAVector(zero(Fp), one(Fp));

The problem is that CoCoAVector returns a vector<RingElemAlias>.

The following is trickier still:

  vector<RingElem> v = CoCoAVector(one(Fp), RingElem(Fp,2));

Not sure how to fix this in a nice way.

Anna, can we postpone this to the next release?

I think that the problem I mentioned in comment 14 means that this is not yet properly ready for "public use".

Re-reading the comments I think it's not worth it.

I went through all the code and removed all calls to CoCoAVector.
Using, when possible, the {...} C++ syntax, or RingElems.

So now I suggest Reject

Recalling part of my comment 13:
One aspect we could implement, which C++ does not, is the notion of "list of elems of ring R" (i.e. we state in advance the ring in which the elems will lie).

If we think this idea is worth discussing, maybe it should be made into a separate issue?

John Abbott wrote:

Recalling part of my comment 13:
One aspect we could implement, which C++ does not, is the notion of "list of elems of ring R" (i.e. we state in advance the ring in which the elems will lie).

If we think this idea is worth discussing, maybe it should be made into a separate issue?

Separate issue. In fact I had started (and abandoned) something along these lines.
One reason why I wanted this constructor was to make vector of integers for selecting rows and columns in submat.

For documentation, I add this snippet about vectors of RingElem:

    auto v = RingElems(RingQQt(2), "1/2, 1.4, t[1]*t[2]");
    cout << v << endl;

    v = {v[1], v[2]};
    cout << v << endl;