CoCoA » CoCoA-5

And in CoCoA-5 would look like this:

/**/ Print NewRingFp(3);
FFp(3)[ID=3]
/**/ Print NewRingFp(3);
FFp(3)[ID=4]
/**/ Print NewRingFp(3);
FFp(3)[ID=5]

Should this topic be in CoCoALib rather than CoCoA-5?

From the point of a user it would be very handy if the C5 expression ZZ/(3) always produced the same ring (and similarly for NewZZmod(3) in CoCoALib). This can be achieved using a global table of rings, though there is some risk that it might fill up with "junk"...

• a ring prints out simply as ring(1), ring(2) etc
• describe RingOf(M) produces a full description of the ring (similar to what is currently printed)

This would make it very clear when two rings are the same, but forces use of a "special" command to find out what the ring really is. How often does one really want to print out all the information about the structure of a ring?

Do we want printing of rings to be valid as input? (e.g. in the printed form of a matrix)

John Abbott wrote:

Here is an idea: simple to implement, but perhaps not so nice to use?

• a ring prints out simply as ring(1), ring(2) etc
• describe RingOf(M) produces a full description of the ring (similar to what is currently printed)

I like it, it could be RingWithID(6). Maybe that could also be used as input?

The name RingWithID is longer than I would like; I originally suggested ring(3) but that is not so clear. Maybe RingID(3).

We could even regard RingID as an indexable value rather than a function, so the user would write RingID[3]. Not sure if this is a good idea... maybe it makes no difference?

15:07 I think it'd be easier for the user if RingID is a function; to me it would feel like an "exceptional case" if it were like a (read-only) list...

How will rings be printed in resolutions?

I recall that CoCoA used a syntax like ring#7; we could do this (but it would a new syntax, and thus require changes to lexer/parser).

Talked about this with Christof. Here's an idea we had:
allow RingID to have an optional second arg which is a string giving some info about the ring (this 2nd arg could be ignored when reading RingID(...)).

For instance we could get behaviour like this...

P ::= QQ[a,b];
P2 := P[x,y];
PrintLn P2;
RingID(7, "RingID(6)[x,y]");

John Abbott wrote:

allow RingID to have an optional second arg which is a string giving some info about the ring (this 2nd arg could be ignored when reading RingID(...)).

YES!! I'll try it immediately!
[Later]

# S ::= ZZ/(3)[x,y,z];
# S;
RingID(4,"RingID(3)[x,  y,  z]")
# CoeffRing(S);
RingID(3,"FFp(3)")

fixed all tests, but we should still discuss on the output.
For example

RingID(2,"RingID(0)[x,  y]")

RingID(2,"ZZ[x,y]")

Yesterday Christof suggested that ZZ and QQ should always be printed that way (rather than ring(0) and ring(1)). We were undecided about rings like ZZ/(3); one idea was to print it nicely if the nice form is sufficiently short (e.g. less than 10 chars).

John Abbott wrote:

Yesterday Christof suggested that ZZ and QQ should always be printed that way (rather than ring(0) and ring(1)). We were undecided about rings like ZZ/(3); one idea was to print it nicely if the nice form is sufficiently short (e.g. less than 10 chars).

OK, I'll make some experiments.
Meanwhile, we should also think of implementing RingID(N).
I think there is a table in GlobalManager. (wild guess)

what about this: (verbose, but not more than before the ID change)
I like it! .... but there is the problem of too many quotes :-(

# NewFractionField(NewPolyRing(QQ,SymbolRange("t",3,5)));
RingID(4,"FractionField(RingID(3,"QQ[t[3],t[4],t[5]]"))")

20140703-13:38 Your example seems too verbose to me; I think I would expect just RingID(4,"FrF(RingID(3))"). Hmm, this is tricky. I wonder whether this might be acceptable RingID(4, "FrF(RingID(3), "QQ[3indets]"))

added function ID for RING

I'm still not happy with the name of RingID; the name makes me think that it gets the ID from a ring, rather than gets the ring from its ID. RingWithID is clearer but is too long...
Puzzled.

John Abbott wrote:

I'm still not happy with the name of RingID; the name makes me think that it gets the ID from a ring, rather than gets the ring from its ID. RingWithID is clearer but is too long...

In fact, it is not too long (and it's very expressive), because at the end it [rints a shorter string than the "old-style" printing.
I think we need an extra function (I was trying to avoid that) saying whether the ring has a unique implementation (therefore it's better printed explicitely) or not (therefore printed with ID)

I had a look at GlobalManager and now I think that currently there is no way (yet) to see if "RingWithID(5)" exists and get its value.

Should this issue be in CoCoA-5 or CoCoALib?

You are right that there is no global register of rings currently. We would need one if we want to avoid creating two identical rings. As you know, I do not much like globals, though they are sometimes necessary. Some care will be needed to make a global work properly in a multithreaded environment.

Should all rings appear in the global registry? Even temporary rings which exist only inside a fn?

Am I correct in deducing that you want a fn which given a ring ID produces the corresponding ring?

John Abbott wrote:

Should this issue be in CoCoA-5 or CoCoALib?

I think it can stay in CoCoA-5 because it is easier re-create rings.

You are right that there is no global register of rings currently. We would need one if we want to avoid creating two identical rings. As you know, I do not much like globals, though they are sometimes necessary. Some care will be needed to make a global work properly in a multithreaded environment.

I think that trying to catch identical constructions might be tricky, and if it works 90% of the cases it might be even more confusing. I think that printing with ID helps the user understand better what a ring is and so avoid to make unncecessary (and costly, if we need to do all checks every time) re-creation of rings

Should all rings appear in the global registry? Even temporary rings which exist only inside a fn?

hmmmm, now I'm not sure we should do this.
A ring occupies lots of memory and we'd better get rid of the unused ones (everytime we compute a Groebner basis we create a temporary ring!)
Maybe the function "RingWithID(n)" should return an error saying something like:
"this is not a function: give names to rings or use RingOf(object)" ;-)
(I like that! it's an easy way to tell the user how to be more careful)

If we allow the user to write RingWithID(7), that will have a totally different meaning next time cocoa is started. So it fails the utility of being "re-usable" and saved output cannot be read again anyway.

Am I correct in deducing that you want a fn which given a ring ID produces the corresponding ring?

more than "want" was a "wondering". Now I'm getting convinced it should not be implemented.

I have implemented in CoCoALib

  void ***RingBase::myOutputSelfLong(std::ostream& out) const

I think it should be called by describe in CoCoA-5, which currently returns only

A value of type RING

I think it has just been forgotten; it seems like a good idea to me. Indeed now that direct printing produces a very compact(incomplete) form, CoCoA-5 really needs a way to get the full details of a ring.

I note that describe could produce several lines of output if we want it to. For instance, the description of a ring could be like this: (copied from comment 8)

RingWithID(9):  RingWithID(8)[a,b,c]
RingWithID(8):  RingWithID(4)/(ideal(x^100+lots-of-terms))
RingWithID(4):  RingWithID(2)[x,y,z]
RingWithID(2):  QQ