Opened 9 years ago
#614 new bug
inconsistency in handling size of free resolution
Reported by: | anne | Owned by: | Oleksandr |
---|---|---|---|
Priority: | minor | Milestone: | 4-1-0 and higher |
Component: | singular-kernel | Version: | 4-0-0 |
Keywords: | Cc: |
Description
As the following code shows, the handling of the size of a resolution is inconsistent between different methods for computing it and for storing it:
SINGULAR / Development A Computer Algebra System for Polynomial Computations / version 4.0.0 0< by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \ Dec 2013 FB Mathematik der Universitaet, D-67653 Kaiserslautern \ // ** executing /home/anne/Sources/Build/Singular/LIB/.singularrc ring r=0,(x,y,z),dp; ideal I=xy,xz,yz; size(nres(I,0)); //ok 2 size(mres(I,0)); //ok 2 size(lres(I,0)); //ok - not minimized 3 size(minres(lres(I,0))); //intentionally too long? 3 size(sres(I,0)); //ok - not minimized 3 size(minres(sres(I,0))); //intentionally too long? 3 def dn=nres(I,0); size(dn); //ok -remembers its size 2 dn[1]; _[1]=xy _[2]=xz _[3]=yz dn[2]; _[1]=y*gen(2)-z*gen(1) _[2]=x*gen(3)-z*gen(1) list li=dn; // assignment to list in 2 steps size(li); // ok - still remembers its size 2 list li2=nres(I,0); // direct assignment to list size(li2); // size changed by assignment 3
This inconsistency should
- at least be remarked in the documentation (of size, minres and resolution)
- preferably be changed to a more consistent behaviour,
as this might confuse users and can cause bugs in libraries which are hard to track down.
Some additional remarks: If minres does not cut down the size of a given resolution (if appropriate), this should be remarked in the documentation, because the user should then rather test for the last non-zero module instead of using size.
In general, it should not make any difference whether I assign the result of a computation directly to a list or in two steps. This again makes the command size untrustworthy.