Tony-64's profile - activity

Not an answer, but here is some additional code that avoids the preparser problem. The numbers used in this code are no

Not an answer, but here is some additional code that avoids the preparser problem. The numbers used in this code are no

Not an answer, but here is some additional code that avoids the preparser problem. The numbers used in this code are no

The unformatted version is identical to your g(x) above.

Thanks for confirming. I didn't run into the preparer issue. f(x) resulted from solving a set of equations, each of whi

Thanks for confirming. I didn't run into the preparer issue. f(x) resulted from solving a set of equations, each of whi

Not sure what 'tour copy seems incorrect' means. You can get the reported output by pasting the above code in SageMathC

Thanks for the answer!

Wrong result after using factor(): known Sage bug? It looks like factor() doesn't play well with complicated expressions

Wrong result after using factor(): known Sage bug? It looks like factor() doesn't play well with complicated expressions

Bug when using factor() (UPDATED) Edit: solved some issues with the code, added a few more cases and improved the descri

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? (UPDATED) Edit: solved some issues with the code, added a few more cases a

Bug using factor() and complicated constants? Here is the output of the code below. Case 1 - original code 10.488787596

Bug using factor() and complicated constants? Here is the output of the code below. Case 1 - original code 10.488787596

MacOS: Is there a difference between SageMath 9.3 and SageMath9.3 app notebooks? When creating a new SageMath 9.3 notebo

On my local 9.1 installation, the expression show(real_expr_3.subs(f=2*beta)) does not return either. However, I see python3.7 memory usage growing to roughly 4 GB after one minute, 5 GB after two minutes, 3 GB after three minutes, and staying between 3 and 4 GB for several more minutes, after which I restarted the kernel. I ran into the MemoryError on SageCell, presumably because it limits the amount of memory available:

MemoryError: failed to allocate 25165848 bytes
Exception ignored in: 'sage.libs.pynac.pynac.py_repr'
Traceback (most recent call last):
  File "sage/rings/integer.pyx", line 1013, in sage.rings.integer.Integer.__repr__(build/cythonized/sage/rings/integer.c:8430)

Thanks for the response. However, Sagemath 9.1 and 9.2 also yield True when testing the three expressions for equality; see the updated code in my original question. The problem is with the substitution (third line of the three approaches). How does Sagemath 9.3beta5 handle this?

BTW: Thanks for showing the shortcut domain='positive'; I didn't know this one yet.

Hi, I recently ran into a weird problem where substituting one equation into another sometimes fails with a MemoryError, depending on how the original equation was derived. In the code below I have been able to isolate the issue (my actual code sometimes stumbles on the third approach, and I will have to see how I can change its structure to work around the issue).

In all three approaches, the printout of real_expr is identical. However, when trying to execute the subsequent substitution, it looks like there must be a difference between the three, at least in their internal representation. Note that the MemoryError does not occur when the substitution is simpler, i.e. expr_real.subs(f=2) works fine.

Am I missing something, or is this just a bug?

BTW: I am running Sage 9.1, but the problem also occurs on SageCell (which I presume is running 9.2).

Updated code

# First declare a bunch of variables
var('A, L, G, R', domain='positive')
var('f, k, n, q, u', domain='positive')
var('beta', domain='positive')
var('gamma', domain='positive')

# Here is a complex expression
expr_complex = (I*R^2*f^3*k*q*A*u
                /((2*pi*L*R^2*G*f^4*k^2*q
                   - 2*pi*L*R^2*G*f^4*q
                   - 2*pi*L*R^2*beta^2*G*q
                   + (2*I*pi*L*R^2*beta*gamma*q + 2*I*pi*L*R*(beta + q))*G*f^3
                   + 2*(pi*(beta^2 + 1)*L*R^2*q + pi*L*R*beta*gamma*q + pi*L*beta)*G*f^2
                   + (-2*I*pi*L*R^2*beta*gamma*q - 2*I*pi*(beta^2*q + beta)*L*R)*G*f)*n))

# Use three different approaches to derive a real expression from the complex one

# This approach works well
expr_real_1 = (expr_complex.real()^2+expr_complex.imag()^2).factor()
show(expr_real_1)
show(expr_real_1.subs(f=2*beta))

# This approach is fine too
expr_real_2 = (sqrt(expr_complex.real()^2+expr_complex.imag()^2)^2).factor()
print(bool(expr_real_1 == expr_real_2))
show(expr_real_2.subs(f=2*beta))

# This approach causes Sage to run out of memory
expr_real_3 = ((sqrt(expr_complex.real()^2+expr_complex.imag()^2).factor())^2).factor()
print(bool(expr_real_3 == expr_real_1))
print(bool(expr_real_3 == expr_real_2))
show(expr_real_3.subs(f=2*beta)) # This step yields a MemoryError (verified on SageCell)

Thanks again. The updated approach works when we know the expressions up front. However, one step more difficult is when they result from a computation. Here is another example. Interestingly enough, when solving the equation for x, the .find(I*w0) approach works. However, when solving for y, it doesn't.

w0 = SR.wild(0)

var('y')
assume(x, 'real')
assume(y, 'real')



eqn = (x^3 + y^3 / 27 == 1)

sols = solve(eqn, x)

f, g, h = [sol.rhs() for sol in sols]

expressions = [f, g, h]

for expr in expressions:
    print(expr.find(I*w0))



sols = solve(eqn, y)

f, g, h = [sol.rhs() for sol in sols]

expressions = [f, g, h]

for expr in expressions:
    print(expr.find(I*w0)

Thanks for the answer. You are correct that I meant x to be a real number. I thought of this approach too, but unfortunately, it breaks down when the expression becomes a more complex. Here is an example.

w0 = SR.wild(0)

f = sqrt(1-x^2) + I*(1-x^3)^(1/3)
g = sqrt(1-x^2) + 2*I*(1-x^3)^(1/3)

assume(x, 'real')

print(f.find(I*w0))
print(g.find(I*w0))

print(f.imag())
print(g.imag())

In this example, .find(I*w0) yields the term containing the cube root from f, but not from g. However, .imag() yields complicated expressions for both f and g because it takes into account that abs(x) may be greater than 1.

How do I go about finding terms in a symbolic expression containing arbitrary complex constants? I had hoped that the code fragment below would yield something like [2Ix], [Ix], [I], and [2I]. However, instead it yields [], [I*x], [], and []. Is there another way to isolate the terms containing an arbitrary complex constant?

w0 = SR.wild(0)

f = x^2 + 2*I*x + 1
g = x^2 + I*x + 1
h = x^2 + 2*x + I
k = x^2 + x + 2*I

print(f.find(I*w0))
print(g.find(I*w0))
print(h.find(I*w0))
print(k.find(I*w0))

I understand about the second case. However, it is the first example that is puzzling me.

def testing(fn):
    print(fn(1))
    return

expr=x
testing(expr) # DeprecationWarning
print(expr(1)) # No DeprecationWarning

See the question in the example below. What is the cause off the inconsistency with respect to generating the DeprecationWarning?

 def testing(fn):
    print(fn(1))
    return

expr=x
testing(expr) # Yields DeprecationWarning: Substitution using function-call syntax and unnamed arguments ...
print(expr(1)) # No deprecation warning here. Why?

fn(x)=x
testing(fn) # No deprecation warnings here either.
print(fn(1))