ASKSAGE: Sage Q&A Forum - RSS feedhttps://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Tue, 18 Jul 2017 09:18:34 +0200Restricted usability of Singular after upgradehttps://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/Today I upgraded SageMath from 7.3 to 7.5.1, then I tried to continue yesterday's work: generating a sparse univariate polynomial using Singular, the polynomial has degree beyond that of toy polynomials. Yesterday, this worked fine,
today I get the error message
exponent overflow (117649)
How can this happen? And what can I do to get the previous facilities of Singular (possibly, this means the previous facilities of SageMath)?
Thanks in advance
Tue, 07 Feb 2017 19:28:01 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/Comment by kcrisman for <p>Today I upgraded SageMath from 7.3 to 7.5.1, then I tried to continue yesterday's work: generating a sparse univariate polynomial using Singular, the polynomial has degree beyond that of toy polynomials. Yesterday, this worked fine,
today I get the error message</p>
<p>exponent overflow (117649)</p>
<p>How can this happen? And what can I do to get the previous facilities of Singular (possibly, this means the previous facilities of SageMath)?</p>
<p>Thanks in advance</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36482#post-id-36482I think we'll need slightly more specific information to debug this. Perhaps a new Singular bug? The error sounds more like that of Singular - see https://groups.google.com/forum/#!topic/sage-devel/mZqNOX0NQuc which is probably it. I suspect this is your problem - hopefully someone else will answer here who knows how to allocate more memory for univariate.Tue, 07 Feb 2017 20:15:26 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36482#post-id-36482Answer by wjansen for <p>Today I upgraded SageMath from 7.3 to 7.5.1, then I tried to continue yesterday's work: generating a sparse univariate polynomial using Singular, the polynomial has degree beyond that of toy polynomials. Yesterday, this worked fine,
today I get the error message</p>
<p>exponent overflow (117649)</p>
<p>How can this happen? And what can I do to get the previous facilities of Singular (possibly, this means the previous facilities of SageMath)?</p>
<p>Thanks in advance</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?answer=36485#post-id-36485Meanwhile 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 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.Wed, 08 Feb 2017 12:46:46 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?answer=36485#post-id-36485Comment by kcrisman for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36486#post-id-36486I should again point out the issue in the thread I linked to - this may be intentional, I'm not sure.Wed, 08 Feb 2017 13:10:52 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36486#post-id-36486Comment by wjansen for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36491#post-id-36491On the one hand, 16-bit exponents seem to be intentional, i.e. intended by Singular. On the other hand, there is at least one Singular version that supports larger exponents. I do not understand who this version implemented (released as Singular version or implementation within SageMath only). Anyway, the version with larger exponents is not in the recent SageMath release.Wed, 08 Feb 2017 19:10:39 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36491#post-id-36491Comment by kcrisman for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36502#post-id-36502There seems to be a pretty good answer at https://groups.google.com/d/msg/sage-devel/mZqNOX0NQuc/mpH4sP4fAwAJ which should help you track it down.Thu, 09 Feb 2017 14:00:27 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36502#post-id-36502Comment by Dima for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36514#post-id-36514Why would you think this is Singular problem? Univariate polynomials are not handled by Singular in Sage, they are handled by either Flint, or NTL, or Givaro (the latter for finite fields only). We need more info to track your issue down. E.g. could you at least tell us the output of `type(f)` for your polynomial `f`?Thu, 09 Feb 2017 21:05:41 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36514#post-id-36514Comment by kcrisman for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36517#post-id-36517Only thought Singular because of the similarity in errors. I agree the OP should give more details.Thu, 09 Feb 2017 21:37:35 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36517#post-id-36517Comment by wjansen for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36626#post-id-36626It is a Singular problem since I misused Singular for its availability to handle sparse polynomials (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.
I cannot tell you the output of 'type(f)' since 'f' is not generated at all. For a polynomial of smaller degree the output is
<type 'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular'>
The "bug" is not a bug, it is a restriction 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 it appeared as a bug.Wed, 15 Feb 2017 13:36:28 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36626#post-id-36626Comment by kcrisman for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36629#post-id-36629Thanks for the clarification - that is very helpful. You should add this to your answer, and then accept it yourself (if you can, otherwise a moderator can for you).Wed, 15 Feb 2017 17:40:44 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36629#post-id-36629Comment by wjansen for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36632#post-id-36632I would like to "accept", but I do not know how to do (I do not see a button or the like named "accept").Wed, 15 Feb 2017 19:43:41 +0100https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=36632#post-id-36632Comment by Dima for <p>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). </p>
<p>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. </p>
<p>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. </p>
<hr>
<p>Addendum (15-02-2017) :</p>
<p>It is a Singular problem since I misused Singular for its ability to handle sparse polynomials, also univariate ones (FLINT, NTL don't). The polynomial ring is created for a given prime number <em>p</em> by <em>PolynomialRing(GF(p),1,"x")</em>. The second argument <em>1</em> forces SageMath to switch to Singular.</p>
<p>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 <em>PolynomialRing</em>?</p>
<p>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.</p>
https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=38294#post-id-38294there is a little 'V' field under the answer score counter on the right, which one ticks to accept the answer. I just did it here.Tue, 18 Jul 2017 09:18:34 +0200https://ask.sagemath.org/question/36480/restricted-usability-of-singular-after-upgrade/?comment=38294#post-id-38294