Florentin Jaffredo's profile - activity

Can you try without solve_across_charts? The integration is supposed to stop when exiting the chart. Are you saying it w

I am not entirely sure how to solve your issue. Indeed If I remove your chart transition, the geodesic declaration (M.in

Hi ! If you define across_charts=True you need to use geod.solve_across_charts instead of geod.solve. But I don't think

This is a bug, now tracked here. Thank you for reporting it. It seems there was an oversight when adding the solve_acro

Hi! Yes, it should be possible. You can find an example in this notebook. It's done by defining the initial 4-velocity

You are probably looking for the %run <file.ipynb> magic command.

Compilation time has been improved significantly with WSL2, it's not necessarily slower than on native linux.

Source

Because I want to display the stuff. I think a nice output makes it a lot simpler to understand a result. The latex output is usually superior to a simple print in this regard. Except when it's actively trying to confuse me, like in the first example I provided.

My problem is not really to obtain a perfect "LaTeXification", If I want to copy it in a document the width will probably be different anyway, but this is just mistake inducing from me (I just lost 30 minutes this morning trying to understand this particular example, until at one point I resized the window and it went away. I was very sad...)

Sorry for not providing a minimal example. Here is one: (sum(x^i for i in range(34)))*exp(x)/x. If I increase the max degree above 35, a line break occurs (It will depend on your screen real estate).

Once again, aligning the $e^x$ with the last line instead of the first would solve the ambiguity.

With %display latex, long expressions can read wrong due to weird line breaks.

For example, run for various values of n the following:

p = lambda n: sum(x^i for i in (0 .. n))*exp(x)/x
p(9)  # or more depending on window width

Why isn't the factor $e^x$ after the parenthesis on the second line instead?

Is this even a SageMath, a Jupyter, or a MathJax issue? Where to report it?

Versions: JupyterLab 2.2.9, SageMath 9.3beta4.

Looking at the code for preparse, it starts with

L = line.lstrip()
if len(L) > 0 and L[0] in ['#', '!']:
    return line

That code has been there since at least 2014, and perfectly explains the first observation. An easy fix would probably be to check here for a line break, but that doesn't explain why it was working before.

Thanks Eric for the quick reply. The same is true for Sage 9.0. I wonder what changed, and how was it working previously.

It probably depends on the polynomial. My guess is that it will become worse with increasing degree. One way to find the appropriate precision is to compare the result with a known root. Here for example I increase the precision in order to compute sqrt(2) with 7 digits of precision.

for i in range(1, 1000):
    R.<x> = PolynomialRing(ComplexField(i))
    P = R((x-sqrt(2))^7)
    UU = P.roots()
    if all([abs(x[0]-sqrt(2)).n() < 1e-7 for x in UU]):
        print(i)
        break

172 in this case.

You can always replace CDF[] by PolynomialRing(ComplexField(100)) to work with 100 bits of precision. In my case anything above 6 works.

Some of my code stopped working after I upgraded from version 9.0 to 9.3beta4. I tracked it to the following bug:

sage: preparse('1 # Comment \n 1.5^2')
"Integer(1) # Comment \n RealNumber('1.5')**Integer(2)"

sage: preparse('# Comment \n 1.5^2')
'# Comment \n 1.5^2'

The code is not getting preparsed if it starts with a comment. In practice it looks like this:

This seems like a big issue, and I would be surprised if it went unnoticed until now. Could it be caused by my Sage installation? (Compiled from source on WSL2 Ubuntu 20.04, which is not officially supported, but I didn't notice anything weird).
Can someone try this?

I'm trying to evaluate this cursed integral (finite for $ 0 < a < 1 $):

$$\int_0^1 \frac{x}{\log{\left(ax+(1-x)^2\right)}}{\rm d}x$$

using Sagemath 9.0 and 9.1:

sage: a = var('a')
sage: assume(a>0)
sage: assume(a<1)
sage: f = integrate(x*log(1/(a*x+(1-x)^2)), x, 0, 1)

leads to

RuntimeError: ECL says: C-STACK overflow at size 1048576. Stack can probably be resized. Proceed with caution.

Sympy gives a result even without the assumptions (which is odd by itself):

sage: f = integrate(x*log(1/(a*x+(1-x)*(1-x))), x, 0, 1, algorithm='sympy')

$$\frac{1}{4} {\left(a^{2} + \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 2\right)} \log\left(\frac{a^{2} + \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 4}{2 {\left(a - 2\right)}} + 1\right) - \frac{1}{4} {\left(a^{2} + \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 2\right)} \log\left(\frac{a^{2} + \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 4}{2 {\left(a - 2\right)}}\right) + \frac{1}{4} {\left(a^{2} - \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 2\right)} \log\left(\frac{a^{2} - \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 4}{2 {\left(a - 2\right)}} + 1\right) - \frac{1}{4} {\left(a^{2} - \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 2\right)} \log\left(\frac{a^{2} - \sqrt{{\left(a - 4\right)} a} {\left(a - 2\right)} - 4 a + 4}{2 {\left(a - 2\right)}}\right) - \frac{1}{2} a + \frac{1}{2} \log\left(\frac{1}{a}\right) + \frac{3}{2}$$

But then problems continue:

sage: f.simplify_full()

RuntimeError: ECL says: C-STACK overflow at size 1048576. Stack can probably be resized. Proceed with caution.

But:

sage: f.expand().simplify_full()

$$ -\frac{1}{2} {\left(2 \pi - {\left(\pi - \arctan\left(\frac{\sqrt{-a + 4}}{\sqrt{a}}\right) + \arctan\left(\frac{\sqrt{a} \sqrt{-a + 4}}{a - 2}\right)\right)} a - 2 \arctan\left(\frac{\sqrt{-a + 4}}{\sqrt{a}}\right) + 2 \arctan\left(\frac{\sqrt{a} \sqrt{-a + 4}}{a - 2}\right)\right)} \sqrt{a} \sqrt{-a + 4} + \frac{1}{4} {\left(a^{2} - 4 a\right)} \log\left(a\right) - \frac{1}{2} a + \frac{3}{2} $$ If I want to find the limit when $a\to 0$:

sage: f.limit(a=0)

RuntimeError: ECL says: C-STACK overflow at size 1048576. Stack can probably be resized. Proceed with caution.

and once again

 sage: f.limit(a=0, algorithm="sympy")

$$-i \pi + \frac{3}{2}$$

Which is only true for $a<0$.

I previously found this strange bug a while ago (fixed upstream, still present in Sagemath 9.1), this makes me think the assumption assume(a>0) is the root of it all, unfortunately it cannot be skipped to evaluate the integral properly.

Do you know when the updated version of Maxima will be included with Sagemath?
Do you think all these issues are linked to this old ticket or should it be investigated independently?

Using SageMath 8.8, I encountered a strange error involving boolean tests. The following code reproduces the issue:

x, y = var('x, y')
assume(x>0)
assume(y>0)
bool(y*(x-y)==0)

RuntimeError: ECL says: C-STACK overflow at size 1048576. Stack can probably be resized. Proceed with caution.

This code should obviously return False. Changing y*(x-y) to x*(y-x) indeed returns False, which means x and y cannot be exchanged. Without the assumptions, the code works as expected.

I initially thought it was due to my Sage installation, but running this code on https://sagecell.sagemath.org/ also produces asymmetric behavior, though no error comes out (just a blank answer).

Is this a known issue ? Can someone reproduce this ?

I had some hope, since this Maxima upgrade fixes quite a number of issues, including problems regarding assumptions and integration

Which version of sage are you using? Sage 9.2 is using an updated version of Maxima. I get the same kind of errors in 9.0. Sometimes Maxima can't even show that an exponential is positive, probably because symbolic variables are complex by default in sage, but using assumptions gives a good old segfault.

That's not a bug, your matrix is simply not invertible. You can see it by switching the ring to SR to perform exact computations:

test_S_SR = matrix(SR, 5)
for ix in range(0, 5):
    for iy in range(0, 5):
        test_S_SR[ix, iy] = sin(ix+iy)*sin(iy+1)

sage: test_S_SR

[            0 sin(2)*sin(1) sin(3)*sin(2) sin(4)*sin(3) sin(5)*sin(4)]
[     sin(1)^2      sin(2)^2      sin(3)^2      sin(4)^2      sin(5)^2]
[sin(2)*sin(1) sin(3)*sin(2) sin(4)*sin(3) sin(5)*sin(4) sin(6)*sin(5)]
[sin(3)*sin(1) sin(4)*sin(2) sin(5)*sin(3) sin(6)*sin(4) sin(7)*sin(5)]
[sin(4)*sin(1) sin(5)*sin(2) sin(6)*sin(3) sin(7)*sin(4) sin(8)*sin(5)]

sage: test_S_SR.determinant().trig_reduce() # can take a few seconds
0

The float version looks invertible but that's only due to machine precision. Since the internal mechanism are probably different for RR and CC, it's normal that you get different answers.

I don't understand what you want to achieve with your code. Are you looking for the gradient of y as a function of x?
In any case, does this question help?