Opened 12 years ago

Closed 6 years ago

# Bug with genus normal.lib

Reported by: Owned by: gorzel pfister major 3-2-0 and higher singular-libs 3-1-6 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)


### comment:1 Changed 10 years ago by gorzel

Cc: seelisch pfister removed 3-1-2 and higher → 3-2-0 and higher changed from laplange to somebody major → minor 3-1-1 → 3-1-6

The error message has changed, but the bug is not fixed. Perhaps the problem is located in hneother.lib:

> 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(f);
1
> genus((x+y)*f);
0
> genus(x*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
> 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


Nobody seems to have considered seriously this bug, so I change the owner to somebody.

### comment:2 follow-up:  5 Changed 10 years ago by boehm

Should have been fixed by Gerhard, has to be tested.

### comment:3 Changed 10 years ago by ren

Resolution: → fixed new → closed

### comment:4 Changed 10 years ago by gorzel

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 in reply to:  2 ; follow-up:  6 Changed 9 years ago by kroeker@…

Resolution: fixed closed → reopened

Should have been fixed by Gerhard, has to be tested.

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 in reply to:  5 ; follow-up:  7 Changed 9 years ago by gorzel

Should have been fixed by Gerhard, has to be tested.

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

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)

### comment:7 in reply to:  6 ; follow-up:  8 Changed 9 years ago by 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);
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 in reply to:  7 Changed 9 years ago by gorzel

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

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 gorzel

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 something wrong with the number of branches at infinity, it only gets 7 instead of 8 !

Last edited 9 years ago by gorzel (previous) (diff)

### comment:10 Changed 9 years ago by hannes

Resolution: → fixed reopened → closed

### comment:11 Changed 9 years ago by gorzel

Priority: minor → major fixed 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 ren

Owner: changed from somebody to pfister reopened → new

### comment:13 Changed 8 years ago by hannes

Resolution: → fixed new → closed

### comment:14 Changed 6 years ago by gorzel

Resolution: fixed 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";
...


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 hannes

Resolution: → fixed reopened → closed
Note: See TracTickets for help on using tickets.