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.

Change History (0)

Note: See TracTickets for help on using tickets.