genus of a curve

[draz...@gmail.com]

I tried the following code (in

'Sage Version 6.5, Release Date: 2015-02-17')

reset()
x,y,z = QQ['x,y,z'].gens()
C= Curve(x^3 - x^2*y - 2*x*y*z + y^2*z - z^3);
C.genus();

and got
 

4294967295

I suppose here sage must tell that the curve is reducible (and so the genus is not defined).
Costas

[Nils Bruin]

On Tuesday, March 31, 2015 at 9:51:36 AM UTC-7, draz...@gmail.com wrote:

I tried the following code (in

'Sage Version 6.5, Release Date: 2015-02-17')

reset()
x,y,z = QQ['x,y,z'].gens()
C= Curve(x^3 - x^2*y - 2*x*y*z + y^2*z - z^3);
C.genus();

and got
 

4294967295

 

Well, if we interpret that value as "-1" then it is equal to (3-1)*(3-2)/2 - degree(singular locus), so it might be telling you a bit more than that the curve is reducible (for one thing, it's compatible with defining the genus in terms of the Euler characteristic as chi=2-2*g, which is additive over components) Indeed, for

sage: C=Curve((x-y)*(y-z)*(z-x))
sage: C.genus()
4294967294

It may be noteworthy that on sage 5.10 I am getting -1 and -2, so we somewhere had a regression where a 32bit integer from singular lands in a 64bit integer and thus we lose the sign.

It drills down to:

sage: import sage.libs.singular.function_factory
sage: sing_genus = sage.libs.singular.function_factory.ff.normal__lib.genus
sage: I=C.defining_ideal()
sage: sing_genus(I)
4294967294
sage: type(sing_genus)
<type 'sage.libs.singular.function.SingularLibraryFunction'>

In singular itself we do get a negative number:

> LIB "normal.lib";
> ring r=0,(x,y,z),dp;
> ideal i=(x-y)*(y-z)*(z-x);
> genus(i);
-2

so it's really in our conversion:

The line sage.lib.singular.function.pyx:951 seems to be to blame:

        elif rtyp == INT_CMD:
            return <long>to_convert.data

so somehow, singular has a 32-bit signed int there, and sage thinks `long` means 64 bit. It's surprising to me that singular uses 32-bit integers there, because looking through the singular code a bit, it seems that functions that are listed as returning an "INT_CMD" do tend to cast their result to `(long)`, which in C++ should usually mean 64-bit on a 64-bit machine as well, I'd expect.  This is now:

http://trac.sagemath.org/ticket/18096

[draz...@gmail.com]

 thank you for the clarification.