Feature #1052
ReadExpr(P, string) and RingElem(P, string) in CoCoALib
Description
Should we have in CoCoALib (as in CoCoA-5) RingElem(P, string) behaving like ReadExpr(P, string)?
Currently there is no RingElem(P, string) in CoCoALib (closest syntax takes a symbol).
Related issues
History
#1
Updated by Anna Maria Bigatti about 7 years ago
Updated by - Subject changed from ReadExpr(P, string) and RingElem(P, string) to ReadExpr(P, string) and RingElem(P, string) in CoCoALib
#2
Updated by Anna Maria Bigatti about 7 years ago
- Related to Design #1051: ReadExpr(P, string) and RingElem(P, string) added
#3
Updated by John Abbott about 7 years ago
Updated by - Status changed from New to In Progress
- % Done changed from 0 to 10
We should try to keep CoCoALib similar to CoCoA-5 (or make CoCoALib simpler if it is different from CoCoA-5).
If in CoCoA-5 we are happy to have RingElem(P, str) do what ReadExpr(P, str) currently does, then the same should apply to CoCoALib.
Right now I think it is a good idea, but I have not thought much about possible complications.
One potentially delicate situation is something like RingElem(Zmod3, "3/6"). This was already mentioned in comment 3 of issue #938, and comments 5 and 7 of issue #909. In summary: the string is converted to an expression tree where the constants are integers, then the expression tree is interpreted... consequently RingElem(Zmod3, "3/6") will produce an error ("division by zero").
What should RingElem(Zmod3, "0.5") produce? Currently ReadExpr(Zmod3, "0.5") produces -1 because the decimal fraction is converted to a reduced rational (1/2 in this case) which is then mapped into Zmod3. While I do feel a bit uneasy about letting users map decimal fractions into finite fields, it is well-defined in CoCoA(Lib) because we have the convention that a decimal fraction is regarded as being exactly equal to the obvious rational number (e.g. "1.23" is the same as 123/100). So I see no good technical reason to forbid mapping decimal fractions into rings.
#4
Updated by Anna Maria Bigatti about 7 years ago
John Abbott wrote:
If in CoCoA-5 we are happy to have
RingElem(P, str)do whatReadExpr(P, str)currently does, then the same should apply to CoCoALib.Right now I think it is a good idea, but I have not thought much about possible complications.
If we do it now (and I see no objection, as I was the one stumbling in this problem!!) I would also change the examples using it.
#5
Updated by John Abbott about 7 years ago
- Related to Feature #909: ReadExpr: decimal point added
#6
Updated by Anna Maria Bigatti about 7 years ago
- Tracker changed from Design to Feature
- Assignee set to Anna Maria Bigatti
- % Done changed from 10 to 90
Done, documented, tested.
RingElem is better than ReadExpr because it highlights it is just for one RingElem.
#7
Updated by Anna Maria Bigatti about 7 years ago
updated all examples
#8
Updated by John Abbott over 6 years ago
- Status changed from In Progress to Feedback
JAA has updated all tests.
#9
Updated by John Abbott over 6 years ago
Does this change make the file RingElemInput obsolete?
At least the function ReadExpr should be regarded as obsolescent, right?
#10
Updated by John Abbott over 6 years ago
- Status changed from Feedback to Closed
- % Done changed from 90 to 100
Even though ReadExpr(R, str) and RingElem(R, str) do the same thing, we can probably leave them both in CoCoALib (at least for the time being).
I do not much like ReadExprSemicolon, but we can leave it for the time being. I think the terminating character should be an argument (not part of the fn name).
Closing.