Bug #1789
GradingMat with negative weights should complain (or deal with them properly!!)
Description
W:=mat([[0,1],[1, -1]]); O:=MakeTermOrdMat(W); P:=NewPolyRing(QQ,"x,y",O,2); Use P; wdeg(y); ----> [1, 0] WRONG
2024-03 new function name: NewPolyRingWeights(QQ,"x,y",W);
Related issues
History
#1
Updated by Anna Maria Bigatti about 2 months ago
Updated by - % Done changed from 0 to 20
I investigated and found the confusion: in the lines
W:=mat([[0,1],[1, -1]]); O:=MakeTermOrdMat(W); P:=NewPolyRing(QQ,"x,y",O,2); Use P; wdeg(y); ----> [1, 0] WRONG
The call
O:=MakeTermOrdMat(W); actually changes W (because it just makes a new ordering compatible with W): O is [[0, 1], [1, 0]] and it is passed as OrdMat.
However the problem presists (I guess for the same internal implementation) in the shortcut call
/**/ P := NewPolyRing(QQ,"x,y", mat([[0,1],[3,-4]])); use P; /**/ wdeg(y); [1, 0]
whereas it is properly detected in the complete call:
/**/ P := NewPolyRing(QQ,"x,y", mat([[0,1],[3,-4]]), 2); use P; --> ERROR: NOT YET IMPLEMENTED -- please be patient, we're working on it --> [CoCoALib] MatrixOrdering32bitImpl: temporarily requiring weights to be non-negative --> P := NewPolyRing(QQ,"x,y", mat([[0,1],[3,-4]]), 2); use P; --> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#2
Updated by John Abbott about 2 months ago
Updated by - Status changed from New to In Progress
The documentation says that if the grading-dim is not specified then it is taken to be 0. Perhaps this is misleading default behaviour? Maybe the default should be the number of rows? [do we require the rows to be in lin indep?]
#3
Updated by John Abbott about 2 months ago
- Description updated (diff)
#4
Updated by John Abbott about 1 month ago
- Related to Support #1761: MakeTermOrdMat: improve error mesg added
#5
Updated by John Abbott about 1 month ago
- Related to Design #832: Generalize grading matrix added
#6
Updated by Anna Maria Bigatti about 1 month ago
- Related to Feature #823: NewPolyRing with weights -- better interface? added
#7
Updated by Anna Maria Bigatti about 1 month ago
John Abbott wrote:
The documentation says that if the grading-dim is not specified then it is taken to be 0. Perhaps this is misleading default behaviour? Maybe the default should be the number of rows? [do we require the rows to be in lin indep?]
I cannot find the documentation. But it does take the number of rows.
The implementation in SparsePolyRing.C
SparsePolyRing NewPolyRing(const ring& CoeffRing, const std::vector<symbol>& IndetSyms, ConstMatrixView Ws)
does the trivial thing (calling
MakeTermOrdMat(Ws)) and no specific checks whatsoever.
We had suggested, in #823, to call such function NewPolyRingWeights (or NewPolyRingWithWeights), and now I do think we should, because calling NewPolyRing with a square matrix (say, LexMat(n)) would give GradingDim=n, and I think that is unexpected.
#8
Updated by Anna Maria Bigatti about 1 month ago
- Description updated (diff)
John Abbott wrote:
[do we require the rows to be in lin indep?]
yes
#9
Updated by Anna Maria Bigatti about 1 month ago
- % Done changed from 20 to 60
Added check in the definition of NewPolyRing(K, X, WeightsMat).
Should I rename it NewPolyRingWeights? (not yet documented, I believe)
#10
Updated by Anna Maria Bigatti about 1 month ago
- Description updated (diff)
- Status changed from In Progress to Resolved
- % Done changed from 60 to 80
Anna Maria Bigatti wrote:
Added check in the definition of NewPolyRing(K, X, WeightsMat).
Should I rename it NewPolyRingWeights? (not yet documented, I believe)
Yes, I called it NewPolyRingWeights to emphasize its meaning.
Also in CoCoA-5.
Document in CoCoALib and CoCoA-5, then close this issue.
#11
Updated by Anna Maria Bigatti about 1 month ago
- Status changed from Resolved to Closed
- % Done changed from 80 to 100