Opened 13 years ago
Closed 13 years ago
#377 closed bug (fixed)
deg(0)=1024 and 0 is NOT 0!!!
Reported by: | 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)
Change History (6)
Changed 13 years ago by
Attachment: | singular-bug-example.txt added |
---|
comment:1 Changed 13 years ago by
Dear Ryutaroh Matsumoto,
thank You for the report. I confirm the bug and 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
comment:2 Changed 13 years ago by
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 follow-up: 4 Changed 13 years ago by
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 Changed 13 years ago by
Hi Oleksandr,
Thank you very much for your workaround suggestion. It worked fine. Actually I worked arount it by dividing the target_poly by x^{10000. }
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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
This script file make 0 != 0.