Spurious "1*" coefficients appearing in characteristic 2

[Jean-Pierre Flori]

Dear all,

In char 2, it seems that the way Singular prints monomials changed in version 4 and now prints 1*x instead of "just" x.
That's mathematically ok but not so pleasant for the eye.
I guess the following line is the culprit:
https://github.com/Singular/Sources/blob/spielwiese/libpolys/polys/polys0.cc#L49
In char 2, 1 == -1 so I guess that's the place where the new "1*" comes from.
Would you consider filtering out "1" of this part of the code?

Best,
JPF

[han...@mathematik.uni-kl.de]

On Fri, Aug 19, 2016 at 03:39:33AM -0700, Jean-Pierre Flori wrote:
> Dear all,
>
> In char 2, it seems that the way Singular prints monomials changed in
> version 4 and now prints 1*x instead of "just" x.

...
I cannot reproduce this behaviour: do you have an example?
> ring r=2,x,dp;
> poly p=x;
> p;
x
> p=x2+x+1;
> p;
x^2+x+1

n_IsMOne is only used for printing, and npIsMOne (which is used in char
2) gives FALSE for 1 (in contrast to its name).
see:
BOOLEAN npIsMOne (number a, const coeffs r)
{
n_Test(a, r);
return ((r->npPminus1M == (long)a)&&(1L!=(long)a));
}

Hans

[Jean-Pierre Flori]

Hummm, I'll investigate it further this afternoon.

[Jean-Pierre Flori]

This is what I get in Sage:
 sage: GF(2)['x,y'].gens()
(x, y)
sage: Integers(2)['x,y'].gens()
(1*x, 1*y)

Note that in the second case, Sage is not aware that Z/2Z is a field so different Sage and Singular objects get used.
I'll track down what different stuff we use in Singular.

[Jean-Pierre Flori]

In the second case for some reason we are using the n_Znm type.
I seem to remember that we explicitly did not use n_Z2m for some reason.
For sure we could just use a finite field structure here rather than pretending that we did not realize that the characteristic was prime...

[Jean-Pierre Flori]

I get the same behavior (1*) using the more general n_Zn type.
You might want to modify this.

Anyway, I modified Sage so that it uses a finite field structure in singular when the characteristic is prime so it's not completely necessary for us.

[han...@mathematik.uni-kl.de]

On Fri, Aug 19, 2016 at 07:28:05AM -0700, Jean-Pierre Flori wrote:
> In the second case for some reason we are using the n_Znm type.
> I seem to remember that we explicitly did not use n_Z2m for some reason.
> For sure we could just use a finite field structure here rather than
> pretending that we did not realize that the characteristic was prime...

fixed, see
http://www.singular.uni-kl.de:8002/trac/changeset/961c76da92efc86885b6506c8c83262f14e705ff/git

Hans

[Jean-Pierre Flori]

Thanks!