1 | initial version |

Meanwhile I made more experiments. The smallest polynomial degree forcing the error is 2^16. So I expect that the currently installed Singular version uses unsigned 16-bit words for exponents (and that the previous version had a larger representation, there I generated polynomials up to a degree of 27 bits then my computer was at the edge of its memory).

I had also a look on Singular's home page but I did not find any hint on technical restrictions or on internal data representation.

As workaround, I will try to re-install SageMath-7.3 from the Git repository. I hope the repository contains besides SageMath's core also the then actual external libraries.

2 | No.2 Revision |

Meanwhile I made more experiments. The smallest polynomial degree forcing the error is 2^16. So I expect that the currently installed Singular version uses unsigned 16-bit words for exponents (and that the previous version had a larger representation, there I generated polynomials up to a degree of 27 bits then my computer was at the edge of its memory).

I had also a look on Singular's home page but I did not find any hint on technical restrictions or on internal data representation.

As workaround, I will try to re-install SageMath-7.3 from the Git repository. I hope the repository contains besides SageMath's core also the then actual external libraries.

Addendum (15-02-2017) :

It is a Singular problem since I misused Singular for its availability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number *p* by *PolynomialRing(GF(p),1,"x")*. The second argument *1* forces SageMath to switch to Singular.

The "bug" is not a bug, it is a restriction (16 bit exponents) implemented in Singular's official release. Unfortunately, Singular does not publish its restrictions (at least, I did not found one when reading its home page forth an back), so the violated restriction appeared as a bug. What about adding a comment in SageMath's documentation of *PolynomialRing*?

By contrast, version SageMath-7.3 included a modification of Singular where the restriction was set to 32 or 64 bit exponents, so the bug did not occur.

3 | No.3 Revision |

Meanwhile I made more experiments. The smallest polynomial degree forcing the error is 2^16. So I expect that the currently installed Singular version uses unsigned 16-bit words for exponents (and that the previous version had a larger representation, there I generated polynomials up to a degree of 27 bits then my computer was at the edge of its memory).

I had also a look on Singular's home page but I did not find any hint on technical restrictions or on internal data representation.

As workaround, I will try to re-install SageMath-7.3 from the Git repository. I hope the repository contains besides SageMath's core also the then actual external libraries.

Addendum (15-02-2017) :

It is a Singular problem since I misused Singular for its ~~availability ~~ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number *p* by *PolynomialRing(GF(p),1,"x")*. The second argument *1* forces SageMath to switch to Singular.

The "bug" is not a bug, it is a restriction (16 bit exponents) implemented in Singular's official release. Unfortunately, Singular does not publish its restrictions (at least, I did not found one when reading its home page forth an back), so the violated restriction appeared as a bug. What about adding a comment in SageMath's documentation of *PolynomialRing*?

By contrast, version SageMath-7.3 included a modification of Singular where the restriction was set to 32 or 64 bit exponents, so the bug did not ~~occur. ~~

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.