Ask Your Question

mpmath not working with sage equations

asked 2022-01-08 09:14:05 +0100

jaia gravatar image

I'm trying to get a numerical solution to a problem similar to the one discussed in this old post but somewhat messier -- there are decimals and the variables to solve for are in an exponent. I ran the example given in the old post, with som syntactical updating and using import mpmath as mp and everything works exactly as shown. But when I switch to my problem, I get a "TypeError: cannot evaluate symbolic expression numerically" error. What's the difference between the two cases and what should I do? I've tried changing ^ to ** and restarting the kernel.

Here's my code:

import mpmath as mp


eq0 = 101/4563863823**(32.4*Vmax/Km) - 71.85 == 0
eq1 = 96.3/85080567**(2.4*Vmax/Km) - 74.25 == 0

f = [lambda Vmax,Km: eq0.lhs().subs(Vmax=RR(Vmax), Km=RR(Km)),
 lambda Vmax,Km: eq1.lhs().subs(Vmax=RR(Vmax), b=RR(Km))]

found_root = mp.findroot(f, (2, 2))
found_root = Matrix(RR, found_root.tolist())

fa,fb = found_root.list()

#Check results
edit retag flag offensive close merge delete



You have a typo: b=RR(Km) should be Km=RR(Km). If you fix it, you get a different error :)

rburing gravatar imagerburing ( 2022-01-08 10:26:02 +0100 )edit

At least that's a mathematical one. Can't believe I missed that typo!

jaia gravatar imagejaia ( 2022-01-08 19:26:44 +0100 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2022-01-08 16:04:15 +0100

Emmanuel Charpentier gravatar image

Your system seems to have no real solutions :

sage: var("Vmax, Km")
(Vmax, Km)
sage: eq0 = 101/4563863823**(32.4*Vmax/Km) - 71.85 == 0
sage: eq1 = 96.3/85080567**(2.4*Vmax/Km) - 74.25 == 0

Solve eq0 for Vmax

sage: %time S0=solve(eq0, Vmax)
CPU times: user 5.5 s, sys: 7.6 ms, total: 5.5 s
Wall time: 5.15 s
sage: len(S0)

Of these, only one is real :

sage: time with assuming(Km,"real"): S0r = [u for u in S0 if u.rhs().is_real()]
CPU times: user 6.44 ms, sys: 0 ns, total: 6.44 ms
Wall time: 6.42 ms
sage: len(S0r)
sage: S0r
[Vmax == 5*Km*log(1/1437*1437^(161/162)*505^(1/162)*2^(1/81))/log(4563863823)]

Substituting this real solution in eq1 yelds an equation with no variables :

sage: eq1.subs(S0r[0])
96.3000000000000/85080567^(12.0000000000000*log(1/1437*1437^(161/162)*505^(1/162)*2^(1/81))/log(4563863823)) - 74.2500000000000 == 0

And since the left hand is not numerically null :

sage: eq1.subs(S0r[0]).lhs().n()

eq1 isn't satisfied and the system has no solutions with real Vmax.

BTW, your system seems to have no solution at all :

sage: time S01 = [eq1.subs(s).solve(Km) for s in S0]
CPU times: user 677 ms, sys: 3.96 ms, total: 681 ms
Wall time: 576 ms

All these solutions are empty :

sage: all(len(u)==0 for u in S01)

To understand this, let's rewrite this system symbolically (easier to follow) :

Eq0 = c0/c1^(c2*Vmax/Km) + c3
Eq1 = c4/c5^(c6*Vmax/Km) + c7

Again, solving Eq1 for Vmax yelds a solution :

sage: %time Ss0=solve(Eq0, Vmax) ; Ss0
CPU times: user 6.77 ms, sys: 0 ns, total: 6.77 ms
Wall time: 6.75 ms
[Vmax == Km*log(-c0/c3)/(c2*log(c1))]

which, substituted in Eq1, yields an equation with no variable :

sage: Eq1.subs(Ss0[0])
c7 + c4/c5^(c6*log(-c0/c3)/(c2*log(c1))) == 0

The satisfaction of this equation do not depend on Km, but only on your numerical constants.


edit flag offensive delete link more


That's good to know, but I wonder why I couldn't get that result after trying the same things you did. I'm running Sage 9.0.

jaia gravatar imagejaia ( 2022-01-08 19:25:25 +0100 )edit

I couldn't get that result after trying the same things you did

What do you mean ?

Wht did you try, and what was the result ?

Emmanuel Charpentier gravatar imageEmmanuel Charpentier ( 2022-01-08 20:31:49 +0100 )edit

When I ran solve, it wouldn't halt. That's why I was trying mpmath.

jaia gravatar imagejaia ( 2022-01-08 20:50:52 +0100 )edit

Yiu may have noted that I timed the calls to solve. 5.5 seconds to solve with Python is no small potatoes ; add to that the overhead of going to mpmath and solve with (potentially very high precision) multiple-precision float arithmetic can be very high, and you may prepare for a wait of minutes, if not hours.

Brute force is expensive. Especially when trying to find a nonexistent solution (as learned a lot of politicians in human history...).

Emmanuel Charpentier gravatar imageEmmanuel Charpentier ( 2022-01-08 23:13:57 +0100 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2022-01-08 09:14:05 +0100

Seen: 23 times

Last updated: Jan 08