Feature #823
NewPolyRing with weights -- better interface?
Description
According to the C5 manual, if we want to create a new poly ring with given weights then we must supply a complete order matrix, and also say how many rows contribute to the weights (the "grading dim").
The examples in src/CoCoA-5/tests/lecture-HF1.cocoa5
which use this feature all seem to be of the form:
wts := mat(/*weights matrix*/); P := NewPolyRing(QQ, indets, CompleteToOrd(wts), NumRows(wts));
Would it not be simpler and clearer to allow the following input:
wts := mat(/*weights matrix*/); P := NewPolyRing(QQ, indets, wts);
perhaps
wts
could even be just a list of lists of integers? (though the conversion to a matrix automatically verifies that each row has the same length).
2024-03 new function name: NewPolyRingWeights(QQ,"x,y", W);
Related issues
History
#1 Updated by John Abbott over 8 years ago
- Category set to enhancing/improving
- Target version set to CoCoA-5.?.?
An alternative would be to accept a record
as an argument, but this does make the input longer: for instance
wts := /*weights*/; P := NewPolyRing(QQ, indets, record[weights := wts]);
This approach has the advantage that whoever reads the code understands immediately the role of the 3rd arg (though an astute choice of variable name would probably do this too).
Comments? Opinions? Ideas?
#2 Updated by John Abbott 9 months ago
- Target version changed from CoCoA-5.?.? to CoCoA-5.4.4
It would be good to offer an easier way to specify name ranges:
The following does not currently work:
NewPolyRing(QQ, "x[1..4],y[1..4]", W, 2);
It is much more cumbersome having to write something like this:
concat(SymbolRange("x",1,4), SymbolRange("y",1,4))
Also it would be handy being able to specify just the weights (with implicit grading dim), and let NewPolyRing
complete the term ordering (somehow, presumably RevLex
). Perhaps there should be two similar but different names? OSCAR is easier than CoCoA!
#3 Updated by Anna Maria Bigatti 9 months ago
John Abbott wrote:
It would be good to offer an easier way to specify name ranges:
The following does not currently work:
x[1..4],y[1..4] would be quite nice in cocoalib as well ;-)
a bit of parsing needed.
Follow in new issue (so we don't mix up quite different topics) ----> #1747
It is much more cumbersome having to write something like this:
[...]
P := NewPolyRing(QQ, indets, wts);
would be trivial to do and nice to use.
I cannot see any drawbacks in it.
what about
#4 Updated by Anna Maria Bigatti 9 months ago
- Status changed from New to In Progress
- % Done changed from 0 to 20
#5 Updated by Anna Maria Bigatti 9 months ago
- Related to Feature #1747: NewPolyRing with indices -- better interface? added
#6 Updated by Anna Maria Bigatti 3 months ago
John Abbott wrote:
An alternative would be to accept a
record
as an argument, but this does make the input longer: for instance
[...]This approach has the advantage that whoever reads the code understands immediately the role of the 3rd arg (though an astute choice of variable name would probably do this too).
I think it would easier to implement, use and document, to have NewPolyRingWeights
(which should just call NewPolyRing
as we do now)
#7 Updated by John Abbott 3 months ago
[after phone discussion]
Might the name NewPolyRingWithWeights
be clearer?
Anyway, we can always later change the name, and make the old one obsolescent.
#8 Updated by Anna Maria Bigatti 15 days ago
- Related to Bug #1789: GradingMat with negative weights should complain (or deal with them properly!!) added
#9 Updated by Anna Maria Bigatti 15 days ago
- Assignee set to Anna Maria Bigatti
- Target version changed from CoCoA-5.4.4 to CoCoA-5.4.2
- % Done changed from 20 to 70
#10 Updated by Anna Maria Bigatti 15 days ago
- Related to Design #832: Generalize grading matrix added
#12 Updated by Anna Maria Bigatti 10 days ago
- Description updated (diff)
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
#13 Updated by Anna Maria Bigatti 10 days ago
- Estimated time set to 2.01 h
Added example in ex-PolyRing2.C
#14 Updated by John Abbott 10 days ago
I did slightly prefer the name I suggested in note 7 (but it is longer).
Anyway, this is a good improvement to the interface: easy-to-use correctly, and unlikely to be used wrongly.