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.Sun, 27 Sep 2020 23:32:57 +0200Assumption seems to break integrate(); is this a bug?https://ask.sagemath.org/question/52382/assumption-seems-to-break-integrate-is-this-a-bug/Consider the following Sage code (tested using Sage 8.6):
var('t')
var('a')
t.integrate(t, 0, a) # \int_{0}^{a} t dt
Output (as expected):
t
a
1/2*a^2
Next:
t.integrate(t, 0, 4*a - a^2) # 4*a - a^2 could be positive, negative, non-real(?)
Output (again, no problem):
1/2*a^4 - 4*a^3 + 8*a^2
Now suppose we give Sage a little more information. The following assumptions should guarantee that we're integrating over a real interval, and that the second (or "top") endpoint is strictly greater than the first ("bottom") endpoint. (Though as we have seen, Sage does not really need this information.)
assume(a, 'real')
assume(a > 1)
assume(a < 3) # now 0 < a < 4, so 4*a - a^2 > 0
t.integrate(t, 0, 4*a - a^2) # hangs, eventually produces RuntimeError
So, `.integrate()` succeeds when nothing is known about the endpoint, but then fails when given more information.
**My Question: Is this desired/expected behavior, or would it be considered a bug?**
Personally, I found it surprising: I expected that, if a command worked with no assumptions, then it should still work after adding assumptions (consistent assumptions that only narrow the scope of the problem).
*What follows is purely my own speculation; feel free to ignore.*
I also get a similar kind of problem if I do the following:
forget()
var('t'); var('a');
assume(a, 'real')
assume(a > 1)
assume(a < 3)
bool(4*a - a^2 > 0) # hangs, RuntimeError
It seems to me that $1 < a < 3$ implies $0 < a < 4$, which implies that $-a^2 + 4a > 0$. (The graph of the quadratic is a downward-opening parabola, with roots at $0$ and $4$.) I am not surprised that Sage has trouble constructing this argument, so I am not surprised that the `bool()` command hangs. But unfortunately this also seems to break `.integrate()`, which was working otherwise.
So, I speculate that maybe the `.integrate()` method, when faced with an integral whose endpoints are known to be real, first tries to figure out which endpoint is greater? But sometimes this process hangs, so the `.integrate()` process never terminates?
In our case, I think Sage assumes by default that `a` is complex-valued(?), and then it has no problem with the integral. So it seems like it should still work when `a` is in the real interval $(1, 3)$, which after all is a subset of $\mathbb{C}$.
By the way, the following works just fine:
forget()
var('t'); var('a');
assume(4*a - a^2 > 0)
print(bool(4*a - a^2 > 0))
t.integrate(t, 0, 4*a - a^2)
Or, this also works:
t.integrate(t, 0, 2*a - a^2, algorithm='sympy')
Asked also at [Math Stackexchange](https://math.stackexchange.com/questions/3739105/assumption-seems-to-break-sages-integrate-function-is-this-a-bug), but did not receive an answer there. Apologies if this kind of cross-posting is frowned upon.mathmandanThu, 09 Jul 2020 03:26:26 +0200https://ask.sagemath.org/question/52382/Bug with newton polygons of Puiseux series in 9.1?https://ask.sagemath.org/question/53628/bug-with-newton-polygons-of-puiseux-series-in-91/I've been playing with Puiseux series and noticed that zero coefficients are not being assigned the correct valuation of infinity, so that the Newton polygon is not always correct. A minimal example follows: the two newton polygons should be the same, but they are not. The polygon for f2 is correct, while that of f1 is in error.
R.<x> = PuiseuxSeriesRing(QQ)
S.<y> = PolynomialRing(R)
f1 = y^2+x
f2 = y^2+x*y+x
X1=f1.newton_polygon().plot()
X2=f2.newton_polygon().plot()
show(X1)
show(X2)
If you do the same thing with Laurent series as opposed to Puiseux series, there is no problem and the polygons are equal (as expected):
R.<x> = LaurentSeriesRing(QQ)
S.<y> = PolynomialRing(R)
f1 = y^2+x
f2 = y^2+x*y+x
X1=f1.newton_polygon().plot()
X2=f2.newton_polygon().plot()
show(X1)
show(X2)
Similarly if you work over a p-adic field, there is no problem:
K=pAdicField(2)
S.<y> = PolynomialRing(K)
f1 = y^2+2
f2 = y^2+2*y+2
X1=f1.newton_polygon().plot()
X2=f2.newton_polygon().plot()
show(X1)
show(X2)
So this does seem to be a problem specific to Puiseux series. I'm not sure how to post a bug report, so I'm documenting this here in the hope that someone can help. Thanks!cfrancSun, 27 Sep 2020 23:32:57 +0200https://ask.sagemath.org/question/53628/Error with rational input in IntegerVectorshttps://ask.sagemath.org/question/50814/error-with-rational-input-in-integervectors/ I discovered the following unexpected behavior of `IntegerVectors`:
sage: IntegerVectors(2,3).list()
[[2, 0, 0], [1, 1, 0], [1, 0, 1], [0, 2, 0], [0, 1, 1], [0, 0, 2]]
sage: IntegerVectors(2,3/1).list()
[[2, 0, 0], [1, 1, 0]]
The relevant code block in the implementation of `IntegerVectors` seems to be the following:
try:
return IntegerVectors_nnondescents(n, tuple(k))
except TypeError:
pass
return IntegerVectors_nk(n, k)
For `k=3/1` one has that `tuple(k)` does not give a `TypeError` (as opposed to `tuple(3)`) and thus the code never tries to interpret `k` as an integer.Johannes SchmittFri, 17 Apr 2020 18:26:59 +0200https://ask.sagemath.org/question/50814/Possible bug in CC needs confirmationhttps://ask.sagemath.org/question/47068/possible-bug-in-cc-needs-confirmation/Hello, Sage community. I just noticed what I believe is a bug in the implementation of `CC`, but I would like to receive confirmation.
When I try the following:
'hello' in RR
I get the natural answer: `False`. However, if I try the same with `CC`:
'hello' in CC
I get the following error message:
NameError: name 'hello' is not defined
Just in case, I am using SageMath v8.8, specifically, the binary version downloaded from the mirrors.
Can somebody confirm this is a bug? Thanks in advance!dsejasFri, 05 Jul 2019 04:05:28 +0200https://ask.sagemath.org/question/47068/