Opened 12 years ago
Closed 6 years ago
#259 closed bug (fixed)
Bug with genus normal.lib
Reported by: | gorzel | Owned by: | pfister |
---|---|---|---|
Priority: | major | Milestone: | 3-2-0 and higher |
Component: | singular-libs | Version: | 3-1-6 |
Keywords: | Cc: | pfister |
Description
Here I consider a smooth and absolutely irreducible elliptic curve {f=0} As its genus is 1,
the genus of the union of this elliptic curve with any rational curve is 0.
But normal::genus does not compute this correctly.
The problem seems to be that factors x,y are not treated correctly.
> ring r=0,(x,y),dp; > poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; > genus(f); 1 // OK > genus((x+y)*f); 0 // OK since x+y=0 has genus zero > genus(x*f); The given polynomial is zero! // Message from hnoether.lib 1 // Wrong, should give 0 again > genus(y*f); The given polynomial is zero! 1 // Also false > genus(y*x); -1 // This, for the two rational components, is correct > TRACE = 1; > genus(x*f); entering pre_HN (level 4) The given polynomial is zero! leaving pre_HN (level 4)
Attachments (2)
Change History (17)
comment:1 Changed 9 years ago by
Cc: | seelisch pfister removed |
---|---|
Milestone: | 3-1-2 and higher → 3-2-0 and higher |
Owner: | changed from laplange to somebody |
Priority: | major → minor |
Version: | 3-1-1 → 3-1-6 |
comment:2 follow-up: 5 Changed 9 years ago by
Should have been fixed by Gerhard, has to be tested.
https://github.com/Singular/Sources/commit/9e28895c9e3c3e6df68b285ce0a02784ef7ce39f
comment:3 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 Changed 9 years ago by
Cc: | pfister added |
---|
Let me remind that genus only works for baserings without minpoly. That is, during the compuations the minpoly will be forget if it was set by the basering.
Some years ago I added to normal.lib all the minpoly = ...; lines and sent this to KL. But after a major revision all this is lost again. Perhaps, some procedures do not allow the minpoly, e.g. proc radical!?
But in the present form the usage of genus is limited, since highly singular curves with degree >= 6 are usally defined over number fields.
For instance, all irreducible plane sextics with total Milnor number 19 are rational curves. One example from the literature Artal et al, Braid invariants: Tansact AMS, example 4.2 An irreducible rational sextics with E8+E7+A4, which Singular does not recognize:
ring rs = (0,s),(x,y),dp; minpoly = s^2+1; poly f = (s+5)*x^6+(-2*s-11)*x^5*y+(28*s-12)*x^5+(-52*s+16)*x^4*y+(-36*s-52)*x^4+(24*s+108)*x^3*y+(16*s-48)*x^2*y^2+(-32*s+32)*x^3+(96*s)*x^2*y+(-48*s-48)*x*y^2+16*y^3; genus(f); // 3 // wrong
comment:5 follow-up: 6 Changed 9 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Replying to boehm:
Should have been fixed by Gerhard, has to be tested.
https://github.com/Singular/Sources/commit/9e28895c9e3c3e6df68b285ce0a02784ef7ce39f
Dear Gerhard and Janko,
genus(x*f); seems ok in master/spielwiese now,
but 'genus(y*f)' seems not (or the comment by Gorzel is not correct)
Full example code:
LIB"normal.lib"; ring r=0,(x,y),dp; poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; //other equations also fail genus(y*f); // 1 is wrong due to Gorzel
Remark: I would like to see a bugfree genus() to have a test for 'normal()' ( genus should not change after normalization? )
Thanks,
Jakob
comment:6 follow-up: 7 Changed 9 years ago by
Replying to kroeker@…:
Replying to boehm:
Should have been fixed by Gerhard, has to be tested.
https://github.com/Singular/Sources/commit/9e28895c9e3c3e6df68b285ce0a02784ef7ce39f
Dear Gerhard and Janko,
genus(x*f); seems ok in master/spielwiese now,
but 'genus(y*f)' seems not (or the comment by Gorzel is not correct)
Full example code:
LIB"normal.lib"; ring r=0,(x,y),dp; poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; //other equations also fail genus(y*f); // 1 is wrong due to GorzelRemark: I would like to see a bugfree genus() to have a test for 'normal()' ( genus should not change after normalization? )
Thanks,
Jakob
1.) Once again: Could you also post the output which you get on this example?
I am not using the git-version, so I can't verify what the actual result is.
I thought it had been fixed succesfully, may be the patch has not been committed?
2.) What should " 1 is wrong due to Gorzel" mean?
Neither the bug, nor the the fact that 1 is wrong is due to me, it is just a matter of the genus formula:
The absolutely irreducible curve defined by f=0 has (geometric) genus 1, the second factor, a linear polynomial, has genus 0. Then the genus formula (see e.g. B-P-V) gives for the product, i.e. the union of theses curves,
g = (g_1 -1) + (g_2 -1) + 1 = (1-1) + (0-1) +1 = 0
Thus for any a,b \in K, genus(f*(a*x+b*y)) has to be 0.
3.) I'm interested in to have a genus command which works correctly over algebraic extensions.
(see comment 4)
Changed 9 years ago by
Attachment: | normal.lib added |
---|
Changed 9 years ago by
Attachment: | normal.2.lib added |
---|
comment:7 follow-up: 8 Changed 9 years ago by
Could you also post the output which you get on this example?
I am not using the git-version, so I can't verify what the actual result is.
@gorzel On recent 'spielwiese' the output is '1' for genus(y*f); and is wrong due to your previous post
>LIB"normal.lib"; >ring r=0,(x,y),dp; >poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; >genus(y*f); 1
while the result for 'genus(x*f)
' is ok now (=0)
I thought it had been fixed succesfully, may be the patch has not been committed?
No, it seems that the issue is only partially fixed or there is another one.
Jakob
comment:8 Changed 9 years ago by
Replying to kroeker@…:
Could you also post the output which you get on this example?
I am not using the git-version, so I can't verify what the actual result is.
@gorzel On recent 'spielwiese' the output is '1' for genus(y*f); and is wrong due to your previous post
>LIB"normal.lib"; >ring r=0,(x,y),dp; >poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; >genus(y*f); 1while the result for '
genus(x*f)
' is ok now (=0)
I thought it had been fixed succesfully, may be the patch has not been committed?
No, it seems that the issue is only partially fixed or there is another one.
Jakob
So as this error message dissapeared
> genus(y*f); ? exponent must be non-negative ? error occurred in or before normal.lib::deltaLoc line 2707: ` poly g=f+var(1)^mu+var(2)^mu; //to obtain a convenient Newton-polygon` ? expected poly-expression. type 'help poly;' ? leaving normal.lib::deltaLoc skipping text from `[` error at token `]` ? leaving normal.lib::deltaLoc ? leaving normal.lib::genus
it should indicate that there is another problem now.
comment:9 Changed 9 years ago by
Some partial analysis of the problem:
It is clear that the problem for genus(f*y) occurs at the point xoo:=[1:0:0].
The polynomial f has degree 10, the curve defined by f = 0 is smooth in the affine part and at infinity it has the following data (computed separately with Singular, and checked with Maple)
== at xoo: mu = 27 | delta = 14 | r = 2 == at yoo: mu = 42 | delta = 21 | r = 1
The genus is then g = 9*8/2 - 14 -21 = 1
The polynomial f*y =0 then has three branches at xoo
== at xoo: mu = 42 | delta = 22 | r = 3 == at yoo: mu = 42 | delta = 21 | r = 1
and two additional nodes in the affine part:
Maple's result in the form [point, [mult, delta,r]], also checked with Singular:
[[1, 0, 0], 5, 22, 3], [[0, 1, 0], 6, 21, 1], [[0, 0, 1], 2, 1, 2], [[-1/3, 0, 1], 2, 1, 2]
Note that the total number of local branches is 8
This alltogether gives the correct genus g = 10*11/2 - 22 -21 - 1 -1 = 0.
Now set printlevel = 10; and call genus(f*y); The final output is:
The projected plane curve has locally: singularities: 4 branches: 7 nodes: 2 cusps: 0 Tjurina number: 73 Milnor number: 85 delta of the projected curve: 44 delta of the curve: 44 genus: 1
As one sees, Singular does not something wrong with the number of branches at infinity.
comment:10 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
fixed with 224b2e921d6c7b67544a659057dc7a1821e104b5 (master)
dc2e7d521c529b1881baa1cbaeb461c0e7d3c88c (spielwiese)
comment:11 Changed 9 years ago by
Priority: | minor → major |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Hm, your are cheating a bit, as I will explain.
I have downloaded the new normal.lib from the gitresources. The solution, which you provide is
to factorize first the equation, then to compute the geometric genus separately, and finally to compute the genus by the sum as displyaed above.
This does now work, but it didn't really solve the bug, in particular the proc deltaLoc which is not a static one, in which the bug is located, is still not fixed.
To see what is going on, let us call deltaLoc for the local equation at the point xoo = [1:0:0] with coordinates (y,z). That is we homogenize and dehomogenize by setting x=1. (Either do it for f or directly for f*y.)
ring r=0,(x,y),dp; poly f = x6y4+4x5y3+3x4y3+6x4y2+19/3x3y2+4x3y+3x2y2+11/3x2y+x2+2xy+1/3x+y; poly fy = f*y; ring r3 = 0,(x,y,z),dp; poly Fy = subst(homog(imap(r,fy),z),x,1); ring ryzdp = (0),(y,z),(dp(2),C); poly Fy = imap(r3,Fy); Fy; short =0; // y^2*z^9+2*y^2*z^8+1/3*y*z^9+3*y^3*z^6+11/3*y^2*z^7+y*z^8+19/3*y^3*z^5+4*y^2*z^6+3*y^4*z^3+6*y^3*z^4+4*y^4*z^2+y^5
Note that this polynomial is divisible by y, which is the first varible. If you prefer, we can also change to other variables names X and Y.
ring RXY = 0,(X,Y),dp; poly Fy = fetch(ryzdp,Fy); Fy; // X^2*Y^9+2*X^2*Y^8+1/3*X*Y^9+3*X^3*Y^6+11/3*X^2*Y^7+X*Y^8+19/3*X^3*Y^5+4*X^2*Y^6+3*X^4*Y^3+6*X^3*Y^4+4*X^4*Y^2+X^5
(This may avoid confusion, when inspectig the code, since inside of the proc deltaLoc, you are using variables names x,y in this order.)
We continue with this polynomial Fy and define a useful proc:
proc flip(poly f) {return(substitute(f,maxideal(1),ideal(var(2),var(1))));}
When calling deltaLoc for Fy, which is divisible the first variable, one gets a wrong result, whereas, if called with the interchanged variables, so that the polynomial becomes now divisible by the last variable, the result is correct.
> deltaLoc(Fy,maxideal(1)); [1]: 21 [2]: 36 [3]: 2 > deltaLoc(flip(Fy),maxideal(1)); [1]: 22 [2]: 36 [3]: 3
The buggy part is this:
// the following can certainly be made more efficient when replacing // 'hnexpansion' (used only for computing number of branches) by // successive blowing-up + test if Newton polygon degenerate: if(s>2) // splitting of f { if(w>=1){"Newton polygon can be used for splitting";"";} intvec v=NP[1][2]-NP[2][2],NP[2][1]; int de=w_deg(g,v); //int st=w_deg(hc,v)+v[1]+v[2]; int st=w_deg(var(1)^NP[size(NP)][1],v)+1; poly f1=var(2)^NP[2][2]; poly f2=jet(g,de,v)/var(2)^NP[2][2]; poly h=g-f1*f2; de=w_deg(h,v); poly k; ideal wi=var(2)^NP[2][2],f2; matrix li; while(de<st) { k=jet(h,de,v); li=lift(wi,k); f1=f1+li[2,1]; f2=f2+li[1,1]; h=g-f1*f2; de=w_deg(h,v); } nb=deltaLoc(f1,maxideal(1))[3]+deltaLoc(f2,maxideal(1))[3]; setring R; option(set,save_opt); return(list(d*(mu+nb-1) div 2,d*tau,d*nb)); }
The code is not symmetric in X,Y, that is: When calling flip(Fy) the polynomial h is not flip(h) from calling with Fy. I guess, now you can find out what is going wrong, ...
So the bug is, as I said above, that a local branch is forgotten, which results in a false delta value.
comment:12 Changed 9 years ago by
Owner: | changed from somebody to pfister |
---|---|
Status: | reopened → new |
comment:13 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
fixed with 5ea16e64a937f2fe750ed01befb68c7102c6c33c
comment:14 Changed 6 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
There is still a bug with genus. Tested with the most recent Singular 4.1.0
SINGULAR / Development A Computer Algebra System for Polynomial Computations / version 4.1.0 0< by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann \ Nov 2016 FB Mathematik der Universitaet, D-67653 Kaiserslautern \ Singular for x86_64-Linux version 4.1.0 (4100, 64 bit) Nov 22 2016 15:40:26 #8b4e972 with GMP(5.0.5),NTL(5.5.2),FLINT(2.4.4),factory(@(#) factoryVersion = 4.0.1), fgets,Plural,DBM, > LIB "normal.lib"; // ** loaded /data/home/gorzelc/Downloads/SING410/bin/../share/singular/LIB/normal.lib (4.0.1.1,Dec_2014) // ** loaded /data/home/gorzelc/Downloads/SING410/bin/../share/singular/LIB/curveInv.lib (1.0.0.5,Aug_2015) ...
Any plane curve consisting of d rational components has genus 1-d. We study a nodal cubic, combined with 3 resp. 4 lines. The genus then has to be -3 resp. -4.
> ring rdp = 0,(x,y),dp; > poly NC = (3*x^2*y+4*y^3-x^2-3*y+1); // nodal cubic > genus(NC); // OK 0 > poly F = (x-1) * (x+1) * (3*y-1)* NC; // 3A_5 + 4A_1 > genus(F); // OK -3 > genus(F*y); // Wrong with horizontal line -5 > genus(F/(x-1)); // OK -2 > genus(F/(x-1)*y); // OK -3 > genus(F*(y+1)); // Wrong with horizontal line -5 > genus(F*(y+x)); // OK with non-horizontal line -4
The problem still seems to be at the point (1:0:0).
comment:15 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
fixed by G.Pfister with ce4610f1976773a91f366014d99b667b3f9aac31, test in 352a84b1691397c59edb46bfca0e4e237f6a1778
The error message has changed, but the bug is not fixed. Perhaps the problem is located in hneother.lib:
Nobody seems to have considered seriously this bug, so I change the owner to somebody.