## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Repo info
• • • • • • • • • • • • • • • • • • • • • • • • • ##### Activity
• 13:41
certik commented #22712
• 13:41
sympy-bot commented #22712
• 13:41
certik edited #22712
• 12:38
Upabjojr reopened #5858
• 12:38
Upabjojr closed #5858
• 12:38
Upabjojr commented #5858
• 11:01
oscarbenjamin commented #23533
• 09:45
wonderlandpark starred sympy/sympy
• 08:45
• 08:01
moorepants commented #23536
• 07:37
moorepants commented #23536
• 07:29
moorepants commented #23536
• 07:21
moorepants commented #23536
• 07:18
LukeWood starred sympy/sympy
• 07:04
moorepants labeled #23536
• 07:04
moorepants opened #23536
• 06:51
0sidharth commented #23499
• 06:41
Opticcss starred sympy/sympy
• 06:37
mcepl commented #23533
• 06:36
mcepl commented #23533 Aaron Meurer
@asmeurer
Can you use the fact that $\tanh ix = i\tan x$? Richard Pausch
@PrometheusPi

I am trying to simplify a general Taylor series of function f:

f = sym.Function('f')
x, x_0, h = sym.symbols("x x_0 h", real=True)
# works fine:
ts = sym.series(f(x),x, x_0, 4)

# but substituting x-x_0 by h
ts.subs(x-x_0,h)
# just returns 𝑂(1;𝑥→𝑥0)

Why is the (x-x0) in the Taylor series not substituted correctly? Parseval Gramalot
@PGramalot_gitlab
I thought people answered questions here. Seems like a ghost town. Good day. erentar2002
@erentar2002:matrix.org
[m]
yeah, happens
good luck for finding an answer Kalevi Suominen
@jksuom

@PrometheusPi subs will replace a sum like x - x_0 (= x + (-1)*x_0) in an expression only if that is also a sum that contains the same arguments:

In : (x - x_0 + 1).subs(x - x_0, h)
Out: h + 1

Otherwise, one must substitute x alone:

In : print(ts.subs(x, x_0 + h))
f(x_0) + h*Subs(Derivative(f(_xi_1), _xi_1), _xi_1, x_0) + h**2*Subs(Derivative(f(_xi_1), (_xi_1, 2)), _xi_1, x_0)/2 + h**3*Subs(Derivative(f(_xi_1), (_xi_1, 3)), _xi_1, x_0)/6 + O(h**4) Richard Pausch
@PrometheusPi
@jksuom Thanks a lot for your fast answer. That helped tremendously. (I was not aware of the fact, that subs requires the substitution to be part of a sum. And I did not think of just replacing a single variable instead.) Aaron Meurer
@asmeurer
@PGramalot_gitlab your question is a bit lengthy. You may be better off asking it on the mailing list. Megan Ly
@meganly
How can I modify the latex printer the print the standard basis vectors as \mathbf{i}, \mathbf{j}, and \mathbf{k}? Currently the vectors get printed as follows
>>> C = CoordSys3D('C')
>>> i, j, k = C.base_vectors()
>>> latex(i)
'\\mathbf{\\hat{i}_{C}}' Kalevi Suominen
@jksuom
@meganly The formatting of base vectors is hard-coded and cannot be given as a parameter. I would implement a subclass redefining the formatting. Something like this (untested):
class MyCoordSys3D(CoordSys3D):
def __init__(self):
self.latex_vects = [r'\mathbf{%s}' % n for n in self.vector_names] Aaron Meurer
@asmeurer
There's a parameter in the CoordSys3D that lets you set these
Also if you use a custom printer that should take precedence over the defaults.
I don't like how the vector module defines the printers on the objects. SymPy library classes should define printing on the printer classes. I also don't like how it precomputes the latex form at construction time. Vishesh Mangla
@Teut2711
import sympy as sm

s, Kc, tau_i = sm.symbols("s K_c tau_i")

Gc = Kc*(1+1/(tau_i*s))
Gv = 1
Gp =1/(s**2 + 2*s + 2)
Gm = 1

eq = 1 +Gc*Gv*Gp*Gm
How to get the eq's numerator with leading coefficient as 1? Megan Ly
@meganly

Thanks for the help @jksuom and @asmeurer . I tried

C= CoordSys3D('C', vector_names = ["\mathbf{i}", "\mathbf{j}", "\mathbf{k}"])

and now the latex for the base vector i is '\mathbf{\hat{\mathbf{i}}_{C}}'.
However, implementing a subclass to do custom printing should work. thorek1
@thorek1
under which conditions does the follwoing simplify to y? simplify((y^(1/(1-alpha)))^(1 - alpha)) Aaron Meurer
@asmeurer
Look at the docstring of powdenest.
You need assumptions on either y or alpha. thorek1
@thorek1
@vars alpha positive = true
@vars y real = true
still doesnt work
it seems i would need sympy to understand that 0 < alpha < 1
but i dont know how
powdenest((y^(1/(alpha)))^(alpha),force=true) works finde Aaron Meurer
@asmeurer
I don't think that is sufficient. Consider y = -1 and alpha = 1/2 thorek1
@thorek1
true, in fact y > 0 and 0<alpha<1
docstring of powdenest doesnt help much in this case it seems Aaron Meurer
@asmeurer
SymPy doesn't currently have a way to tell powdenest that alpha is less than 1. Using force=True is the best way, after manually verifying that the simplification is mathematically correct. thorek1
@thorek1
ok, what is the best workaround then? Aaron Meurer
@asmeurer
force=True thorek1
@thorek1
doesnt get me there
@vars alpha y positive = true
powdenest((y^(1/(1-alpha)))^(1 - alpha)) Aaron Meurer
@asmeurer
only other option is to do a change of variables that lets you use the assumptions that sympy supports, like positive=True
oh hmm thorek1
@thorek1
hmm, manually catch all int +/- var cases and replace them Aaron Meurer
@asmeurer
that's a bug I guess
This seems related sympy/sympy#19627
I guess you can do something with replace with a pattern.
>>> a, b, c = Wild('a'), Wild('b'), Wild('c')
>>> expr.replace((a**b)**c, a**(b*c))
y thorek1
@thorek1
yeah thats probably a good way to go
I get the solution assuming alpha is an integer but that doesnt seem very safe thorek1
@thorek1 laolux
@laolux:privacytools.io
[m]
I have some issue with integrating the Heaviside function. Usually I would expect integrate(Heaviside(x,0), (x,-1,1) =1, but instead sympy returns Integral(Heaviside(x, 0), (x, -1, 1)). Works fine if I omit the second argument of Heaviside, but I think it should work in any case, as the value at x=0 is irrelevant for the integration (set of measure zero).
Is there something I am missing, or should I report it as a bug? Kalevi Suominen
@jksuom

@laolux:privacytools.io Many integrators like meijerint work by looking up the results in a table. The table may contain Heaviside(x) but not Heaviside(x, 0) which is a different object.

>>> Heaviside(x) == Heaviside(x, 0)
False

It may be possible to extend the matching code to handle this but that may not be easy to implement. Another entry should probably be added. laolux
@laolux:privacytools.io
[m]
@jksuom Thanks for the explanation. I read im the documentation that “Heaviside(x)==Heaviside(x, None)”, but for integration that should not matter. But now I understand that sympy takes different ways to evaluate these functions. Anyways, “meijerint” seems to have some more issues with Heaviside, as I commented on github: JSS95
@JSS95
@asmeurer can you take a look at #21423, please? Richard Pausch
@PrometheusPi

I ran into the following issue/error while trying to get the extrema of a simple 4th order polynomial:

import sympy as sym

x_sym = sym.symbols("x", real=True) # single variable

pot_sym = x_sym**4 - x_sym**2 + x_sym * 1/10 # function f
pot_prime_sym = sym.diff(pot_sym, x_sym) # first derivative of function df/fx

extrema = sym.solve(pot_prime_sym) # get extrema via df/dx == 0
for extremum in extrema:
print(sym.N(extremum), " == ", sym.N(sym.simplify(extremum))) # print values

returns:

0.050253826762553 - 0.e-23*I  ==  0.050253826762553 + 3.70576914423756e-22*I
0.680639276423668 + 0.e-23*I  ==  0.680639276423668
-0.730893103186221 + 0.e-23*I  ==  -0.730893103186221

The last two results are equal, but the first entry does seem to cause an error of I simplify the result before returning its numeric value. There should be no complex contribution 3.7e-22*I, thus something goes wrong here.

Is this a know issue, did I do something wrong, or is this a not-yet know issue and I should open a issue on github?

I am using sympy 1.7.1. Kalevi Suominen
@jksuom
It is a known issue that is hard to avoid when working with complex floating point numbers. (There is an imaginary part because solve does not know that the result should be real.) For real floating point roots, it is often better to use nroots. Richard Pausch
@PrometheusPi
@jksuom Thanks for the fast reply. nroots worked like a charm :+1:. If it is a know issue, I will refrain from opening another issue on GitHub.