Project

General

Profile

Feature #1052

ReadExpr(P, string) and RingElem(P, string) in CoCoALib

Added by Anna Maria Bigatti 10 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Category:
Improving
Target version:
Start date:
26 Apr 2017
Due date:
% Done:

100%

Estimated time:
Spent time:

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

Related to CoCoA-5 - Design #1051: ReadExpr(P, string) and RingElem(P, string)Closed2017-04-24

Related to CoCoA-5 - Feature #909: ReadExpr: decimal pointClosed2016-07-14

History

#1 Updated by Anna Maria Bigatti 10 months ago

  • 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 10 months ago

  • Related to Design #1051: ReadExpr(P, string) and RingElem(P, string) added

#3 Updated by John Abbott 10 months ago

  • 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 10 months ago

John Abbott wrote:

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.

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 10 months ago

#6 Updated by Anna Maria Bigatti 10 months 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 10 months ago

updated all examples

#8 Updated by John Abbott 4 months ago

  • Status changed from In Progress to Feedback

JAA has updated all tests.

#9 Updated by John Abbott 4 months 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 4 months 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.

Also available in: Atom PDF