Feature #1206
syz, SyzOfGens: which shifts for zero?
Description
It makes to be able to compute
/**/ use R ::= QQ[x,y,z]; /**/ I := ideal([x, y, x+y, 0]); /**/ SyzOfGens(I);
Because the list of generators might have some meaning (e.g. partial derivatives)
but syzygies are shifted with the degrees of the generators, and what's the degree of 0?
If the generators are homogeneous and some are 0, these are probably meant with some particular degree.
Should we try to "guess" sometimes? for example if all gens have the same degree?
2024-03 Final decisions:
Pass the FreeModule with the desired shifts if some entry is 0.
Do not implement syz0 (which should guess)
Keep SyzOfGens (more convenient for CoCoA-5)
Related issues
History
#1 Updated by Anna Maria Bigatti over 5 years ago
- Related to Bug #1205: SyzOfGens: bug with zero generators added
#2 Updated by Anna Maria Bigatti over 5 years ago
- Related to Bug #509: SyzOfGens (CoCoA-5) does not have correct shifts added
#3 Updated by John Abbott about 5 years ago
- Target version changed from CoCoALib-0.99650 November 2019 to CoCoALib-1.0
#4 Updated by Anna Maria Bigatti 3 months ago
- Related to Design #1647: Suppress zero from ideal generators? Detect 1 and simplify generators? added
#5 Updated by Anna Maria Bigatti 3 months ago
- Status changed from New to In Progress
- Target version changed from CoCoALib-1.0 to CoCoALib-0.99850
- % Done changed from 0 to 10
Currently we have decided to forbid generator 0 in ideals (#1647), so SyzOfGens
will never find a 0, keeping in mind that gens(I)
might be different from the list given in I := ideal(L);
.
We can arrange syz
to work with 0s (they were dealt with only by SyzOfGens
, we still have the code for shifting components).
Do we really need syzygies of a list L a 0 element?
Probably yes, because L might come as a result from another computation...
#6 Updated by Anna Maria Bigatti 3 months ago
- Subject changed from SyzOfGens: which shifts for zero generators? to syz, SyzOfGens: which shifts for zero?
- % Done changed from 10 to 30
This is my suggestion: implement a new function syz0
which allows 0s in the input (giving them conventional weights), and leave syz
as is, not allowing 0s (and no surprises).
Example:
/**/ syz([x, 0, y]); --> error /**/ syz0([x, 0, y]); --> [0, 1, 0], [y, 0, -x]
#7 Updated by Anna Maria Bigatti 3 months ago
Should we make SyzOfGens
obsolescent? does it do anything more than calling syz(gens(I))
?
(apart from fixing the 0s)
#8 Updated by John Abbott 3 months ago
OK to require that input to syz
are all non-zero.
Also OK for a new fn which accepts zero -- not sure how this solves the degree issue mentioned at the start.
The name syz0
is OK, but can we find a better/more meaningful name?
AnnA will check whether SyzOfGens
stores a GBasis...
#9 Updated by Anna Maria Bigatti about 1 month ago
- Related to Design #1649: Add file SparsePolyOps-vector.C added
#10 Updated by Anna Maria Bigatti about 1 month ago
- Related to deleted (Design #1649: Add file SparsePolyOps-vector.C)
#11 Updated by Anna Maria Bigatti about 1 month ago
- Related to Feature #1072: syz: apply to ModuleElem? added
#12 Updated by Anna Maria Bigatti about 1 month ago
Anna Maria Bigatti wrote:
This is my suggestion: implement a new function
syz0
which allows 0s in the input (giving them conventional weights), and leavesyz
as is, not allowing 0s (and no surprises).
I update my suggestion (along the lines of #1205-2), where F is a suitable FreeModule:syz(L)
doesn't allow 0 entriessyz(F, L)
allows 0 entries
#13 Updated by Anna Maria Bigatti about 1 month ago
- Related to Feature #1805: Add CoCoA-5 syntax: syz(<F,> list of ModuleElem) added
#14 Updated by Anna Maria Bigatti about 1 month ago
Anna Maria Bigatti wrote:
Should we make
SyzOfGens
obsolescent? does it do anything more than callingsyz(gens(I))
?
I changed my mind. Even though in CoCoALib they are equivalent (gens(I) is a reference), in CoCoA5 it seems pointless to create e CoCoA-5 LIST to be passed to syz
.
Moreover, as we do not yet have syz(LIST of MODULEELEM)
, that's the only way to call it.
So, along the lines that we want CoCoALib and CoCoA-5 to be as similar as possibile, I'm now in favour of keeping SysOfGens
.
#15 Updated by Anna Maria Bigatti about 1 month ago
- Description updated (diff)
- Status changed from In Progress to Resolved
- % Done changed from 30 to 70
Still to do: documentations showing how to deal with 0 entries, in CoCoALib and in CoCoA5
#16 Updated by Anna Maria Bigatti about 1 month ago
- Related to Feature #598: Syzygy for modules: non-homogeneous module added
#17 Updated by Anna Maria Bigatti about 1 month ago
- Description updated (diff)
added documentation for CoCoA-5
#18 Updated by Anna Maria Bigatti about 1 month ago
- Description updated (diff)
restored "final decisions" in description removed by mistake.
#19 Updated by Anna Maria Bigatti about 1 month ago
- Related to Feature #1809: Make ex-syz.C added
#20 Updated by Anna Maria Bigatti 30 days ago
- Status changed from Resolved to Closed
- % Done changed from 70 to 100
Updated documentation submodule.txt (need proper example ex-syz.C)
Updated CoCoA-5 test test-syz, cvs-ed and included in official CoCoA-5 tests
Updated CoCoA-5 test test-ArrAndPosets (which uses syz for modules), cvs-ed and included in official CoCoA-5 tests