CoCoA » CoCoA-5

Simpler test:

/**/ P ::= QQ[x[1..10000]]; --> a bit slow
/**/ NumIndets(P); --> instant
10000
/**/ indet(P,9876); --> instant
x[9876]
/**/ RingElem(P, "x[9876]"); --> very slow > 70s

After a common investigation via skype, we noticed that ReadExpr (called by RingElem) creates map<symbol, RingElem>& SymTable, in order to make the search faster (see #881).
In this case, with a ring with many indets, every RingElem in the map is quite big, so the creation of this map takes time and memory.

Try converting the code in RingElemInput so that it uses map<symbol, long>& SymTable, and then compare timing also for long polys with few indets (#881).

Anna implemented a quick fix: it was much faster, but would also sometimes give a wrong answer (we understood why).

• a dedicated function which says whether a symbol is in a ring (the result might be bool or it might be an index, with -1 meaning "not found").
• Using AreDistinct to detect if a symbol is in a ring is not efficient.
• how to produce the ringelem corresponding to a symbol without incurring a large time and memory overhead?
• one possible idea is to have inside the ring a std::map which returns the index of a symbol (if it corresponds to an indet); it seems that there is already a std::vector of ringelems, one for each symbol.

We need to think about the design, and perhaps make a prototype implementation.

I checked my personal code.
My guess at the old history is that I made a map<symbol, long> (long instead of RingElem) with the indices of symbols(P), which, at first, would then build the i-th indet in P, giving the wrong answer mentioned in https://cocoa.dima.unige.it/redmine/issues/1629#note-5.

Now it calls RingElem(P, s), with s a symbol (in function ReadAtom, ch=='a', reading the symbol s) so it works correctly and I (at last!) check it in.

I think that now we should just make sure that RingElem(P, s) in each ring implementation is as fast as it can be.

Closing after 7 months in feedback.