Design #1508
Initial ring
Description
The question of the initial ring in CoCoA-5 came up. There are two proposals to consider:
- (A) Right after the banner print a message saying what the current ring is;
- (B) start with no current ring, so the user is forced to set it.
Thoughts? Opinions?
History
#1
Updated by John Abbott over 3 years ago
Updated by - (1) use an extra flag to say no ring has been set
- (2) set a "strange" initial ring (e.g.
ZZ)
#2
Updated by John Abbott over 3 years ago
The technically easiest solution would be start with the ring ZZ; while not exactly what was suggested, I suspect that it would work well. We could also use QQ, which also has no indeterminates.
An important point is that such a change would break backward compatibility.
We could implement a flag saying which ring to use upon start-up (i.e. choosing between ZZ and the current choice, namely QQ[x,y,z])
A possible name for the flag is --use-QQxyz.
#3
Updated by John Abbott over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
A relevant line in the source code is Interpreter.C:1212 which contains:
this->setTopLevelVar("R", new RING(NewPolyRing(RingQQ(),symbols("x,y,z"))), VariableSlot::VSF_None);
I removed use R from init.cocoa5, and indeed CurrentRing then returns nothing (presumably NULL). I think I'd feel easier with having ZZ or QQ as the initial ring (rather than nothing at all).
#4
Updated by Anna Maria Bigatti over 3 years ago
Updated by - % Done changed from 10 to 20
I vote for (A) Right after the banner print a message saying what the current ring is
Cleanliness would demand having no initial ring, and indeed CoCoALib has no "CurrentRing".
However, for CoCoA5, I much prefer having an initial ring ready available for two reasons.
1. for the beginner: experience says people don't read the manual, especially when using a program for the first time. We don't want to put them off
2. for all those little computations one user (like me) may run on the fly.
I understand that some user might forget to set his ring "R", and then use the predefined "R", leading to unexpected behaviour.
So my suggestion is:- leave the initial current ring as is, activated in
init.cocoa5 - give it an awkward/explanatory name, like
QQxyz_StartingRing, instead ofR - possibly, add a flag for those who want CoCoA to start clean (but I'm not in that list!)
#5
Updated by John Abbott over 3 years ago
- by default start with the initial ring
QQ[x,y,z](why should it be assigned to a variable?) - have a start-up flag to say to start without an initial ring
- if we want the initial ring to be in a variable, how about
CoCoAInitialRing? Or perhapsCoCoA_Initial_Ring?
There is an important technical point: currently the initial ring is set by the line use R; in the file init.cocoa5.
The changes above require that the initial ring be set by C++ code; finding what changes to the code are needed may be non trivial :-/
#6
Updated by John Abbott over 3 years ago
Presumably the CoCoA-5 interpreter has a function which performs the command source. If this function can accept an istream then we could just create a string containing "use CoCoAInitialRing;", and then pass an istringstream to the code for executing the source command. This is a short-cut (and avoids having to create a special init file).
HINT: relevant part of Interpreter.C seems to be SourceStatement::implExecute(RuntimeEnvironment *runtimeEnv) around line 4030
PS does not look easy to use as I had hoped :-(
#7
Updated by John Abbott over 2 years ago
- Target version changed from CoCoA-5.4.0 to CoCoA-5.4.2