Opened 12 years ago

Closed 12 years ago

#377 closed bug (fixed)

deg(0)=1024 and 0 is NOT 0!!!

Reported by: ryutaroh@… Owned by: somebody
Priority: critical Milestone: 3-1-4 and higher
Component: dontKnow Version: 3-1-3
Keywords: Cc: ryutaroh@…

Description

Dear Researchers,

When I executed the attached Singular script, at the end of execution we get

target_poly + gb[1] is 
0
But target_poly + gb[1] == 0 is 
0
Because  deg(target_poly + gb[1]) is 
1024

I do not expect this kind of behavior at all, because under normal circumstance we have deg(0)=-1 and "0==0" gives 1. If this is a feature of Singular, please tell me so. The complete output will follow. The script file is attached as a separate file.

Ryutaroh Matsumoto, Ph.D., Associate Professor Department of Communications and Integrated Systems Tokyo Institute of Technology, 152-8552 Japan

ryutaroh@debian:~/aalborg/singular$ Singular -v singular-bug-example.txt
Singular for x86_64-Linux version 3-1-3 (3130- 14127M )  Apr  8 2011 19:55:17
with
	factory(@(#) factoryVersion = 3.1.2),libfac(3.1.3,March 2011),
	GMP(4.3),NTL(5.5.2),64bit,unknown fgets method,Plural,DBM,
	dynamic modules,dynamic p_Procs,OM_CHECK=0,OM_TRACK=0,random=1317803835
	CC= gcc -march=k8 -O3 -w -fomit-frame-pointer -pipe -DNDEBUG -DOM_NDEBUG -Dx86_64_Linux -DHAVE_CONFIG_H,
	CXX= g++ -march=k8 -O3 -w -fomit-frame-pointer --no-rtti -I.. -I/tmp/hannes -pipe -DNDEBUG -DOM_NDEBUG -Dx86_64_Linux -DHAVE_CONFIG_H (4.4.5)
argv[0]   :	/usr/lib/Singular/Singular
SearchPath:	/usr/lib/Singular/MOD:/usr/share/Singular/LIB
Singular  :	/usr/bin/Singular
BinDir    :	/usr/lib/Singular
RootDir   :	/usr/share/Singular
DefaultDir:	
InfoFile  :	/usr/share/doc/Singular/info/singular.hlp
IdxFile   :	/usr/share/doc/Singular/doc/singular.idx
HtmlDir   :	/usr/share/doc/Singular/html
ManualUrl :	(http is omitted) www.singular.uni-kl.de/Manual/3-1-3
ExDir     :	/usr/share/doc/Singular/examples
Path      :	/usr/lib/Singular:/usr/bin:/usr/local/bin:/bin:/usr/local/games:/usr/games
EmacsDir  :	/usr/share/Singular/emacs
Available HelpBrowsers: firefox, xinfo, info, builtin, dummy, emacs, 
Current HelpBrowser: firefox 
                     SINGULAR                                 /
 A Computer Algebra System for Polynomial Computations       /   version 3-1-3
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   March 2011
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \
// ** loaded /usr/share/Singular/LIB/decodegb.lib (13483,2010-10-13)
// ** loaded /usr/share/Singular/LIB/brnoeth.lib (14192,2011-05-04)
// ** loaded /usr/share/Singular/LIB/inout.lib (13499,2010-10-15)
// ** loaded /usr/share/Singular/LIB/hnoether.lib (14196,2011-05-04)
// ** loaded /usr/share/Singular/LIB/sing.lib (13787,2011-01-10)
// ** loaded /usr/share/Singular/LIB/primdec.lib (14192,2011-05-04)
// ** loaded /usr/share/Singular/LIB/ring.lib (12231,2009-11-02)
// ** loaded /usr/share/Singular/LIB/absfact.lib (14191,2011-05-04)
// ** loaded /usr/share/Singular/LIB/poly.lib (14203,2011-05-05)
// ** loaded /usr/share/Singular/LIB/elim.lib (13499,2010-10-15)
// ** loaded /usr/share/Singular/LIB/general.lib (14191,2011-05-04)
// ** loaded /usr/share/Singular/LIB/random.lib (14203,2011-05-05)
// ** loaded /usr/share/Singular/LIB/primitiv.lib (13499,2010-10-15)
// ** loaded /usr/share/Singular/LIB/triang.lib (13499,2010-10-15)
// ** loaded /usr/share/Singular/LIB/matrix.lib (13658,2010-11-16)
// ** loaded /usr/share/Singular/LIB/nctools.lib (14213,2011-05-12)
// ** loaded /usr/share/Singular/LIB/linalg.lib (13733,2010-12-06)
target_poly + gb[1] is 
0
But target_poly + gb[1] == 0 is 
0
Because  deg(target_poly + gb[1]) is 
1024
> quit;
Auf Wiedersehen.

Attachments (1)

singular-bug-example.txt (2.9 KB) - added by ryutaroh@… 12 years ago.
This script file make 0 != 0.

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by ryutaroh@…

Attachment: singular-bug-example.txt added

This script file make 0 != 0.

comment:1 Changed 12 years ago by Oleksandr

Dear Ryutaroh Matsumoto,

thank You for the report and confirm the bug. I also want to add that printing target_poly (normalization???!) changes the effect:

> deg(target_poly + gb[1]);
1024
> gb[1];
y*e2+a^2*y^2*x^6*e1+a^5*x*e2+a^5*y*x^7*e1+a*x^8*e1+a^2*y^2*x^5*e1+a^6*e2+a^2*y*x^6*e1+a^5*x^7*e1+a^2*y^2*x^4*e1+a^5*y*x^5*e1-x^6*e1+a^6*y^2*x^3*e1+a^6*x^5*e1-y^2*x^2*e1+y*x^3*e1+a*x^4*e1+a^7*y^2*x*e1-y*x^2*e1-x^3*e1-y^2*e1+a^3*y*x*e1+x^2*e1+a^2*x*e1-e1
> deg(target_poly + gb[1]);
1024
> target_poly;
-y*e2+a^6*y^2*x^6*e1+a*x*e2+a*y*x^7*e1+a^5*x^8*e1+a^6*y^2*x^5*e1+a^2*e2+a^6*y*x^6*e1+a*x^7*e1+a^6*y^2*x^4*e1+a*y*x^5*e1+x^6*e1+a^2*y^2*x^3*e1+a^2*x^5*e1+y^2*x^2*e1-y*x^3*e1+a^5*x^4*e1+a^3*y^2*x*e1+y*x^2*e1+x^3*e1+y^2*e1+a^7*y*x*e1-x^2*e1+a^6*x*e1+e1
> deg(target_poly + gb[1]);
-1
> basering;
//   # ground field : 9
//   primitive element : a
//   minpoly        : 1*a^2+2*a^1+2*a^0
//   number of vars : 4
//        block   1 : ordering wp
//                  : names    y x e2 e1
//                  : weights   4  3 1022 1000
//        block   2 : ordering C
// quotient ring from ideal
_[1]=y^3-x^4+y
_[2]=e1^2
_[3]=e2*e1
_[4]=e2^2
> deg(target_poly);
1026
> deg(gb[1]);
1026
> target_poly + gb[1];
0
> deg(target_poly + gb[1]);
-1

We may assume that the polynomial target_poly is NOT (internally) normalized and ditto the sum , e.g.:

> def t = target_poly + gb[1]; deg(t);
1024
> system("p", t);
a^3*y^3*x^4*e1+a^7*x^8*e1+y^3*x^3*e1-x^7*e1+a*y^3*x^2*e1+a^5*x^6*e1+a^3*y*x^4*e1+a^7*y^3*x*e1+a^3*x^5*e1+y*x^3*e1+a^7*y^3*e1+a^3*x^4*e1+a*y*x^2*e1+a^7*y*x*e1+a^7*y*e1

exp[0..3]
1024 65536 262147 0 
v0:0  v1:3 v2:4 v3:0 v4:1

exp[0..3]
1024 65536 524288 0 
v0:0  v1:0 v2:8 v3:0 v4:1
...
> t; ///// PRINTING DOES NORMALIZATION!
0
> deg(t);
-1
> system("p", t);
0

(using Singularg).

It would be nice to find out which polynomials were wrong in the first place (before target_poly) - simply printing that starting polynomials should make all consequent results correct... This way we may find the guilty code.

Oleksandr

Version 0, edited 12 years ago by Oleksandr (next)

comment:2 Changed 12 years ago by anonymous

Hi Oleksandr,

Thank you very much for very quick response. "print(target_poly)" just after its definition (line 92 of the originally attached file) makes the behavior normal, also on my laptop.

However, printing all the terms in target_poly (i.e., min_zero_mask_poly, info_poly, e1 and e2) does not make the behavior normal.

Before defining target_poly, its all ingredients seem correctly represented in the internal of Singular. Hope this helps.

Ryutaroh

comment:3 Changed 12 years ago by Oleksandr

Hi Ryutaroh,

Thanks for checking.

After a discussion with Hans, we suspect that the bug is due to a wrong handling of qring + option(qringNF) when all the polynomials should be "normalized" (== reduced w.r.t. quotient ideal, e.g. p = NF(p, std(0)); ). There seems to be a place where this normalization doesn't happen...

I suggest the following workaround:

poly target_poly = NF(e1*info_poly*min_zero_mask_poly-e2*min_zero_mask_poly, std(0));

I guess we will trace your computations and see where the property: p == NF(p, std(0)); fails for the first time: e.g. it doesn't hold already for e1*info_poly*min_zero_mask_poly!

O.

comment:4 in reply to:  3 Changed 12 years ago by ryutaroh@…

Hi Oleksandr,

Thank you very much for your workaround suggestion. It worked fine. Actually I worked arount it by dividing the target_poly by x10000.

What I really want to know is whether every other result given by Singular is almost always reliable (or not). If this is actually mishandling of only qringNF option, I can use results from Singular as scientifically valid experiments.

Ryutaroh

comment:5 Changed 12 years ago by hannes

Resolution: fixed
Status: newclosed

The results are correct: deg is the degree of the current representative in the residue class - which may be different due to different ways to compute them. option(qringNF) should fix this, but did not. Now (rev/ 14410) qringNF forces a "minimal" representative in each assignment or print-out.

Fixed with rev. 14410

Note: See TracTickets for help on using tickets.