genus() bug in normal.lib

[kroeker@…]

Due to a missing option "withDelta" for the normal() call

list nor = normal(I); 

in normal.lib::genus() genus returns a wrong result:

LIB("normal.lib");
ring r=0,(y,x),dp;
ideal i = y5-y3-yx5-x9;
dim(std(i)); // =1 => call genus(i,1) is legitimate
genus(i); //=9, correct
genus(i,1); //=16, wrong

Four observations can be made:

1. Tests missed the bug and are insufficient.("/Manual/genus.tst", "/Short/normal.tst")
2. I guess the bug appeared due to a behaviour change of 'normal' => never do that, introduce wrappers for new default options instead(?)
3. Access to invalid position in list nor did result only in a warning =>should be always an error !!

4. I guess genus was never ever written to work over integers,

but a call is possible :

LIB("normal.lib");
ring r=integer,(y,x),dp;
ideal i= x, y5-y3-yx5;
i=std(i);
genus(i);

=> always check for supported rings and parameters in interfaces. If not, add a CAUTION paragraph to the documentation ( if same method is used internally and the parameter check is expensive, e.g. add an internal method version without the check!)

It is even possible to crash singular:

def initialop = option(get);
LIB("normal.lib");
ring r=integer,(y,x),dp;
ideal i=y5-y3-yx5-x9;
genus(i); 
genus(i); //crash

[anonymous]

@korecker: With Singular 3-1-6 I can't reprduce the crash that you mention.

Please post always also the output. (For making the results comparable as you have insisted).

[gorzel]

In case that the command genus will be revised, take also a look at

​http://www.singular.uni-kl.de:8002/trac/ticket/259#comment:4

At least it should be stated in the documentation that genus only works over the rational numbers.

[hannes]

fixed: example 3

> ring r=integer,(y,x),dp;
> ideal i=y5-y3-yx5-x9;
> genus(i); 
   ? not implemented for rings with rings as coeffients
   ? error occurred in or before primdec.lib::minAssPrimes line 2165: `  q = facstd(i);`
   ? leaving primdec.lib::minAssPrimes
   skipping text from `;` error at token `)`
   ? leaving primdec.lib::minAssGTZ
   ? leaving normal.lib::genus
> genus(i); //crash
   ? not implemented for rings with rings as coeffients
   ? error occurred in or before primdec.lib::minAssPrimes line 2165: `  q = facstd(i);`
   ? leaving primdec.lib::minAssPrimes
   skipping text from `;` error at token `)`
   ? leaving primdec.lib::minAssGTZ
   ? leaving normal.lib::genus

example 1

> ring r=0,(y,x),dp;
> ideal i = y5-y3-yx5-x9;
> dim(std(i)); // =1 => call genus(i,1) is legitimate
1
> genus(i); //=9, correct
9
> genus(i,1); //=16, wrong
   ? invalid option for genus
   ? leaving normal.lib::genus

example 2

> ring r=integer,(y,x),dp;
> ideal i= x, y5-y3-yx5;
> i=std(i);
> genus(i);
   ? not implemented for rings with rings as coeffients
   ? error occurred in or before primdec.lib::minAssPrimes line 2165: `  q = facstd(i);`
   ? leaving primdec.lib::minAssPrimes
   skipping text from `;` error at token `)`
   ? leaving primdec.lib::minAssGTZ
   ? leaving normal.lib::genus

[kroeker@…]

Clarification for "(3), Access to invalid position in list nor did result only in a warning )": The related origin code snipped in 'genus' was :

   ...
   list nor=normal(I);
   delt=nor[size(nor)][2];
   ...

Due to interface change of normal() there was no list entry 'nor[size(nor)][2]' and the 'normal' call in genus() became incorrect. This incorrect 'normal' call bug was then (partly) shadowed by Singular's behaviour to ignore invalid assignments and just printing a warning

// ** right side is not a datum, assignment ignored

instead throwing an error. Here is an example for this behaviour:

 >int intVal=5;
 >list l = 1,2;
 >intVal = l[3];
 //  ** right side is not a datum, assignment ignored

The problem here is, that a developer will probably get alerted by the warning, but a common user may overlook the message in a Singular session and

• get an incorrect result as above
• have little chance to report the bug since he overlooks it.