[sympy] Why would using together() change the solution and why would simplify() return False?
What would case Eq.simplify() to return False? There isn't a lot of computation time before the result. Also why would using together() before substituting an expression lead to a numerically different result? I have a series of equations that I've been substituting in to each other building up a final symbolic result. My first pass at this gave a result that looks reasonable (though I haven't proven it correct) when I convert it to a numpy function after using Eq.subs(dictionary of values for symbols).simplify().n() and plot it. When I took the last symbolic equation to be substituted and use Eq.together() on it before substituting to get a simpler result, the Eq.subs().simplify() returns False. When I manipulate it differently to get it to successfully lambdify, the resulting plot is different (and appears wrong). Thanks-- -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/1c324cfc-6bb3-4951-8cd7-22394a8c4bcd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to equip a Symbol with an additional attribute?
Hi--
This seems as good a place as any to mention something I'd been trying to
do some time ago where I ran into the same battle versus __slots__.
I wanted to add a description attribute to my Symbols for documentation
purposes. I use Sympy almost exclusively inside of the IPython notebook
for engineering work, and wind up with long sheets of derivations,
substitutions, dead end attempts, etc. I'm also trying to build up a
personal library of formulas that I can import.
The problem I run in to is eventually, either due to complexity or time, I
can't keep track of what all my symbols mean. I like to keep the names
themselves short so the symbolic output is easily understandable, but that
relies on really strong conventions and a good memory to interpret-- which
aren't always present... =/
One solution was to put the description into the text of the notebook,
which I often do, but then I have to find the place where that Symbol was
defined to locate the descriptive text-- and then need to scroll back to
the active cell to edit, then back and forth.
The solution I was after was to add a x.desc string to the Symbol, so I
could just ask the Symbol itself what the hell I intended it to mean. I
then could modify Symbol to pretty print F_{B}: the force of the bat. If
I got really energetic, I'd change Expr to pretty print:
F_{B}=m_{b}*a_{b}
Newton's Second Law of Motion where:
F_{B} is the force of the bat
m_{b} is the mass of the ball
a_{b} is the acceleration of the ball
For all the maintenance reasons you describe, these are changes that should
happen in the Sympy library itself, but it's easier for me to experiment in
my own sandbox without upsetting the core code and the __slots__ prevents
this. There's also the chance that I can't convince enough people this
should be a core part of the library, or to implement it in the way I'd
like, and then I'm stuck.
Maintenance isn't quite as big an issue for me as I'm not building long
standing applications-- I'm generating documents. Sure, I'd like those to
remain viable for as long as possible so I can edit them in the future, but
it's not the same has having deployed a large codebase. If I have to go
through and change all my references from .desc to .desc2 for my notebook
to run, it's not the end of the world.
Storing all of this in an outside data structure does have the potential
advantage in that I could then look up a symbol if I knew what it meant but
not its symbolic representation:
SymbolIndex['accel ball']
or find all the formulas I have involving the ball:
ExpressionIIndex['ball']
ExpressionIndex[a_{b}]
but that would have required some deeper hacking into the Symbol creation
and destruction mechanisms.
Anyway, probably wandered off topic a bit, but I just wanted to put a vote
in for user attributes and the possible elimination of __slots__ if that
isn't a significant performance hit.
On Monday, May 18, 2015 at 10:29:42 AM UTC-7, Joachim Durchholz wrote:
Am 18.05.2015 um 15:56 schrieb Carsten Knoll:
I want to equip an Symbol with an additional attribute to store some
specific information right in place.
For 'normal' Python classes it is no problem to dynamically create an
additional attribute for an already existing instance.
However, for sympy Symbols if I try
x = Symbol('x')
x.k = 0
I get the error
AttributeError: 'Symbol' object has no attribute 'k'
That happens because we use __slots__ for performance reasons.
However, storing attributes in that way is a bad idea in general,
because you risk name conflicts with future versions of SymPy. (That's
also the reason why using subclasses to extend a library tends to break
over time.)
Alternative 1: You could set up a dict with a Symbol-to-attributes
mapping: Symbols are hashable (that's a guaranteed property).
Alternative 2: We could add a `userdict` attribute in Symbol, so that
SymPy users can store additional attributes there.
I'm not too happy with either alternative.
Maybe we can give you better help if you describe your use case in some
more detail.
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/c81f5af8-ef92-4ddb-add0-eb0053c51a5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] evalf behaves differently for E**x and exp(x)
Hey Aaron-- This bug came up to bite me again, so I tried your work around. The replace you suggested doesn't work (I get the same result back). What does seem to work is expr.replace(exp, lambda x: Pow(E, N(x))) That forces the evaluation of the argument to exp, and then carries on. Thanks-- On Saturday, April 4, 2015 at 11:36:57 PM UTC-7, Aaron Meurer wrote: You have to do evaluate=False because Pow(E, x) is automatically converted to exp() otherwise. You can use something like expr.replace(exp, lambda x: Pow(E, x, evaluate=False)). Aaron Meurer On Sat, Apr 4, 2015 at 11:36 PM, G B g.c.b@gmail.com javascript: wrote: If I'm understanding my problem correctly, I think I actually want it to evaluate... Is there a way to ask sympy to find all occurrences of exp() in an expression and replace them with Pow(E,...) or E**? I've tried messing with replace, but I'm not sure I've got the syntax right... Alternatively, can I force evalf to drill down into the exp() arguments? On Saturday, April 4, 2015 at 5:37:24 PM UTC-7, Aaron Meurer wrote: Seems like another thing that https://github.com/sympy/sympy/issues/4898 would fix. I think the only way to create E**x is to use Pow(E, x, evaluate=False). The lambdify thing might be a separate bug. Aaron Meurer On Sat, Apr 4, 2015 at 5:04 PM, G B g.c.b@gmail.com wrote: Hi-- exp() doesn't seem to evalf its arguments when evalf is called on it. This is probably a bug, and if so I'll file an issue. In the mean time, is there an easy way to get sympy to convert exp(x) expressions to E**x expressions? exp(t*sqrt(5)).n() - exp(t*sqrt(5)) E**(t*sqrt(5)).n() - E**(2.23606797749979*t) I think this is causing me some trouble when converting complex expressions to numpy via lambdify. I'm trying to lambdify a result from dsolve that includes square roots of very large integers (not sure where those large integers are coming from). When I try to execute the result, I get AttributeError: 'int' object has no attribute 'sqrt'. I'll see if I can get the lambdify to trip up with a simple set of inputs. Right now this is the culmination of a 100 cell IPython notebook... -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e312e981-3e7b-4e6f-ae69-984c7e7ad9fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/20ecfb7f-0284-4f69-9d0e-4bd8cb21dbbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/fd89cc36-cd6e-4261-8f8f-6a2a6f096046%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: dsolve returns solution involving IOUSes (Integers of Unusual Size)
Hey Ondrej-- I'll keep this in mind, but I don't think I can post these particular calculations as they're proprietary... One thing this experience suggests though is that it might speed up dsolve if the coefficients are replaced with simple symbols such as you had and then resubstituted after the solve. I don't know if that would be true in every case, or if it would prevent solutions in some cases... On Sunday, April 5, 2015 at 12:25:25 AM UTC-7, Ondřej Čertík wrote: On Sat, Apr 4, 2015 at 11:34 PM, G B g.c.b@gmail.com javascript: wrote: Thanks, Ondrej. In my case the coefficients are the result of a series of calculations earlier in the notebook. They are symbolic up until the call to dsolve, but I am substituting values in right before the dsolve because it takes several minutes to return a solution otherwise (and gives a very complicated solution over a segmented domain). I let it run to completion symbolically and tried substituting into the result and I do get something that looks more reasonable. I can also run it through lambdify and plot the result. So despite the slow computation, at least it looks like I can continue what I'm doing. Would you mind posting your whole calculation, if it is possible? We are developing a very fast C++ core (https://github.com/sympy/csympy) and I am always looking for examples of computations that people found to be slow in SymPy, like in your case. Any idea why the huge integers though? I seem to remember somewhere that Sympy will try to convert floats to rationals under certain conditions. Is that what's happening? Can I turn that behavior off? Any insight into why it won't evalf or lamdify if I substitute before dsolve rather than after? Aaron just answered these. Ondrej Thanks, again! On Saturday, April 4, 2015 at 9:27:07 PM UTC-7, G B wrote: Still wrestling with dsolve... Below is a call with an arbitrary differential equation. Any idea why dsolve is returning terms with these enormous integers? All of the coefficients are floats in this case. The expression is impervious to .n() (as mentioned in my earlier question). Converting to a numpy function to evaluate the results works, but throws an exception when called. I can't seem to get past this point in the analysis. Any idea how I can get this into a form I can continue working with? A=symbols(r'A',cls=Function) t=symbols(r't') Eq4=-123456.78*A(t)-9876.54*A(t).diff(t)-0.00032*A(t).diff(t,2)+1357908.64 soln=dsolve(Eq4) print(soln.n()) A(t) == C1*exp(125*t*(-33935533038108675 - sqrt(1151618536954453541512853661417481))/274877906944) + C2*exp(125*t*(-33935533038108675 + sqrt(1151618536954453541512853661417481))/274877906944) + 10.999060885923 fn=lambdify(t,soln.rhs,'numpy') fn(3.2) --- AttributeErrorTraceback (most recent call last) ipython-input-42-bde0572cbbe1 in module() 1 fn(3.2) //anaconda/lib/python3.4/site-packages/numpy/__init__.py in lambda(_Dummy_73) AttributeError: 'int' object has no attribute 'sqrt' -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6f3572d3-07dd-40b3-a3a9-7673eddf1c87%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/367442da-4a21-4ea7-a9f3-0688d261f1b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sympy] dsolve returns solution involving IOUSes (Integers of Unusual Size)
Still wrestling with dsolve... Below is a call with an arbitrary differential equation. Any idea why dsolve is returning terms with these enormous integers? All of the coefficients are floats in this case. The expression is impervious to .n() (as mentioned in my earlier question). Converting to a numpy function to evaluate the results works, but throws an exception when called. I can't seem to get past this point in the analysis. Any idea how I can get this into a form I can continue working with? A=symbols(r'A',cls=Function) t=symbols(r't') Eq4=-123456.78*A(t)-9876.54*A(t).diff(t)-0.00032*A(t).diff(t,2)+1357908.64 soln=dsolve(Eq4) print(soln.n()) A(t) == C1*exp(125*t*(-33935533038108675 - sqrt(1151618536954453541512853661417481))/274877906944) + C2*exp(125*t*(-33935533038108675 + sqrt(1151618536954453541512853661417481))/274877906944) + 10.999060885923 fn=lambdify(t,soln.rhs,'numpy') fn(3.2) ---AttributeError Traceback (most recent call last)ipython-input-42-bde0572cbbe1 in module() 1 fn(3.2) //anaconda/lib/python3.4/site-packages/numpy/__init__.py in lambda(_Dummy_73) AttributeError: 'int' object has no attribute 'sqrt' -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/88a9432e-a322-460b-9556-ddd85cdad519%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] evalf behaves differently for E**x and exp(x)
If I'm understanding my problem correctly, I think I actually want it to evaluate... Is there a way to ask sympy to find all occurrences of exp() in an expression and replace them with Pow(E,...) or E**? I've tried messing with replace, but I'm not sure I've got the syntax right... Alternatively, can I force evalf to drill down into the exp() arguments? On Saturday, April 4, 2015 at 5:37:24 PM UTC-7, Aaron Meurer wrote: Seems like another thing that https://github.com/sympy/sympy/issues/4898 would fix. I think the only way to create E**x is to use Pow(E, x, evaluate=False). The lambdify thing might be a separate bug. Aaron Meurer On Sat, Apr 4, 2015 at 5:04 PM, G B g.c.b@gmail.com javascript: wrote: Hi-- exp() doesn't seem to evalf its arguments when evalf is called on it. This is probably a bug, and if so I'll file an issue. In the mean time, is there an easy way to get sympy to convert exp(x) expressions to E**x expressions? exp(t*sqrt(5)).n() - exp(t*sqrt(5)) E**(t*sqrt(5)).n() - E**(2.23606797749979*t) I think this is causing me some trouble when converting complex expressions to numpy via lambdify. I'm trying to lambdify a result from dsolve that includes square roots of very large integers (not sure where those large integers are coming from). When I try to execute the result, I get AttributeError: 'int' object has no attribute 'sqrt'. I'll see if I can get the lambdify to trip up with a simple set of inputs. Right now this is the culmination of a 100 cell IPython notebook... -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e312e981-3e7b-4e6f-ae69-984c7e7ad9fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/20ecfb7f-0284-4f69-9d0e-4bd8cb21dbbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sympy] Re: dsolve returns solution involving IOUSes (Integers of Unusual Size)
Thanks, Ondrej. In my case the coefficients are the result of a series of calculations earlier in the notebook. They are symbolic up until the call to dsolve, but I am substituting values in right before the dsolve because it takes several minutes to return a solution otherwise (and gives a very complicated solution over a segmented domain). I let it run to completion symbolically and tried substituting into the result and I do get something that looks more reasonable. I can also run it through lambdify and plot the result. So despite the slow computation, at least it looks like I can continue what I'm doing. Any idea why the huge integers though? I seem to remember somewhere that Sympy will try to convert floats to rationals under certain conditions. Is that what's happening? Can I turn that behavior off? Any insight into why it won't evalf or lamdify if I substitute before dsolve rather than after? Thanks, again! On Saturday, April 4, 2015 at 9:27:07 PM UTC-7, G B wrote: Still wrestling with dsolve... Below is a call with an arbitrary differential equation. Any idea why dsolve is returning terms with these enormous integers? All of the coefficients are floats in this case. The expression is impervious to .n() (as mentioned in my earlier question). Converting to a numpy function to evaluate the results works, but throws an exception when called. I can't seem to get past this point in the analysis. Any idea how I can get this into a form I can continue working with? A=symbols(r'A',cls=Function) t=symbols(r't') Eq4=-123456.78*A(t)-9876.54*A(t).diff(t)-0.00032*A(t).diff(t,2)+1357908.64 soln=dsolve(Eq4) print(soln.n()) A(t) == C1*exp(125*t*(-33935533038108675 - sqrt(1151618536954453541512853661417481))/274877906944) + C2*exp(125*t*(-33935533038108675 + sqrt(1151618536954453541512853661417481))/274877906944) + 10.999060885923 fn=lambdify(t,soln.rhs,'numpy') fn(3.2) ---AttributeError Traceback (most recent call last)ipython-input-42-bde0572cbbe1 in module() 1 fn(3.2) //anaconda/lib/python3.4/site-packages/numpy/__init__.py in lambda(_Dummy_73) AttributeError: 'int' object has no attribute 'sqrt' -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6f3572d3-07dd-40b3-a3a9-7673eddf1c87%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sympy] evalf behaves differently for E**x and exp(x)
Hi-- exp() doesn't seem to evalf its arguments when evalf is called on it. This is probably a bug, and if so I'll file an issue. In the mean time, is there an easy way to get sympy to convert exp(x) expressions to E**x expressions? exp(t*sqrt(5)).n() - exp(t*sqrt(5)) E**(t*sqrt(5)).n() - E**(2.23606797749979*t) I think this is causing me some trouble when converting complex expressions to numpy via lambdify. I'm trying to lambdify a result from dsolve that includes square roots of very large integers (not sure where those large integers are coming from). When I try to execute the result, I get AttributeError: 'int' object has no attribute 'sqrt'. I'll see if I can get the lambdify to trip up with a simple set of inputs. Right now this is the culmination of a 100 cell IPython notebook... -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e312e981-3e7b-4e6f-ae69-984c7e7ad9fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: solve traceback
Ok, I'll see if I can put together a simple test case.
On Thursday, April 2, 2015 at 2:47:27 PM UTC-7, Sudhanshu Mishra wrote:
Hi,
This seems interesting and might be a bug. Could you please create an
issue here https://github.com/sympy/sympy/issues with your *equations*
and traceback.
Sudhanshu Mishra
On Fri, Apr 3, 2015 at 3:07 AM, G B g.c.b@gmail.com javascript:
wrote:
It looks like the root cause of this is that the Function doesn't have
all the assumptions set. I don't fully understand how assumptions are
wired in, and I know the assumptions system is in flux, but it looks like
None is a flag for exists but not set. Would it be better to have FactKB
inherit from defaultdict, rather than dict, so that all unset assumptions
return None? That could prevent these types of exceptions...
If I do:
Qinit=symbols('Qinit')
InitCond1.subs(Q(0),Qinit)
then solve succeeds.
Looking at Q(0)._assumptions:
{'commutative': True, 'complex': True}
And Qinit._assumptions:
{'algebraic': None,
'antihermitian': None,
'commutative': True,
'complex': None,
'even': None,
'finite': None,
'hermitian': None,
'imaginary': None,
'infinite': None,
'integer': None,
'irrational': None,
'negative': None,
'nonnegative': None,
'nonpositive': None,
'odd': None,
'polar': None,
'positive': None,
'rational': None,
'real': None,
'zero': None}
On Tuesday, March 31, 2015 at 7:44:52 PM UTC-7, G B wrote:
Hi--
I'm trying to solve a system of 2 equations. They are the result of
substituting initial conditions into the solution returned from dsolve are
of the form f(0)=expr, where f is a Function, and 0 is zero.
I'm calling it with solve([InitCond1,InitCond2],(C1,C2))
What is interesting is that it fails the first time, but succeeds when I
call it a second time and then succeeds every time after. I haven't
verified the that the solution is accurate.
The traceback follows:
---KeyError
Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'zero'
During handling of the above exception, another exception occurred:
KeyError Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'zero'
During handling of the above exception, another exception occurred:
KeyError Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'real'
During handling of the above exception, another exception occurred:
TypeError Traceback (most recent call
last)ipython-input-30-b2993472ce67 in module() 1
initConds=solve([InitCond1,InitCond2],(C1,C2)) 2 initConds
//anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in solve(f,
*symbols, **flags)909 solution = _solve(f[0], *symbols,
**flags)910 else:-- 911 solution = _solve_system(f,
symbols, **flags)912 913 #
//anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in
_solve_system(exprs, symbols, **flags) 1446 i, d = _invert(g,
*symbols) 1447 g = d - i- 1448 g = g.as_numer_denom()[0]
1449 if manual: 1450 failed.append(g)
//anaconda/lib/python3.4/site-packages/sympy/core/add.py in
as_numer_denom(self)433 denoms, numers = [list(i) for i in
zip(*iter(nd.items()))]434 n, d = self.func(*[Mul(*(denoms[:i]
+ [numers[i]] + denoms[i + 1:]))-- 435for i in
range(len(numers))]), Mul(*denoms)436 437 return
_keep_coeff(ncon, n), _keep_coeff(dcon, d)
//anaconda/lib/python3.4/site-packages/sympy/core/add.py in listcomp(.0)
433 denoms, numers = [list(i) for i in zip(*iter(nd.items()))]
434 n, d = self.func(*[Mul(*(denoms[:i] + [numers[i]] + denoms[i +
1:]))-- 435for i in range(len(numers))]), Mul(*denoms)
436 437 return _keep_coeff(ncon, n), _keep_coeff(dcon, d)
//anaconda/lib/python3.4/site-packages/sympy/core/operations.py in
__new__(cls, *args, **options) 39 return args[0] 40
--- 41 c_part, nc_part, order_symbols = cls.flatten(args) 42
is_commutative = not nc_part 43 obj =
cls._from_args(c_part + nc_part, is_commutative)
//anaconda/lib/python3.4/site-packages/sympy/core
[sympy] dsolve fails for system of equations
I'm having trouble getting dsolve to work with a system of equations. If possible I'd like to find a work around so I can continue the work I'm doing... I'm using IPython 3.4. Here's a simple test case: from sympy import * t,c,d=symbols(r't,c,d') A,B=symbols(r'A,B',cls=Function) Eq1=Eq(A(t).diff(t),B(t)-B(t).diff(t)+c) Eq2=Eq(A(t),B(t).diff(t)+A(t).diff(t)+d) Now, I've tried this both with and without providing the functions to solve for, and get different exceptions each way. If I try without: dsolve([Eq1,Eq2]) I get traceback: == ---AttributeError Traceback (most recent call last)ipython-input-16-5b402de4ba25 in module() 1 dsolve([Eq1,Eq2]) //anaconda/lib/python3.4/site-packages/sympy/solvers/ode.py in dsolve(eq, func, hint, simplify, ics, xi, eta, x0, n, **kwargs)577 578 if iterable(eq):-- 579 match = classify_sysode(eq, func)580 eq = match['eq']581 order = match['order'] //anaconda/lib/python3.4/site-packages/sympy/solvers/ode.py in classify_sysode(eq, funcs, **kwargs) 1445 if matching_hints['no_of_equation'] == 2: 1446 if order_eq == 1:- 1447 type_of_equation = check_linear_2eq_order1(eq, funcs, func_coef) 1448 elif order_eq == 2: 1449 type_of_equation = check_linear_2eq_order2(eq, funcs, func_coef) //anaconda/lib/python3.4/site-packages/sympy/solvers/ode.py in check_linear_2eq_order1(eq, func, func_coef) 14851486 def check_linear_2eq_order1(eq, func, func_coef):- 1487 x = func[0].func 1488 y = func[1].func 1489 fc = func_coef AttributeError: 'list' object has no attribute 'func' == If I try with, I get: dsolve([Eq1,Eq2],[A(t),B(t)]) = ---KeyError Traceback (most recent call last)ipython-input-17-6cffcb27ff03 in module() 1 dsolve([Eq1,Eq2],[A(t),B(t)]) //anaconda/lib/python3.4/site-packages/sympy/solvers/ode.py in dsolve(eq, func, hint, simplify, ics, xi, eta, x0, n, **kwargs)577 578 if iterable(eq):-- 579 match = classify_sysode(eq, func)580 eq = match['eq']581 order = match['order'] //anaconda/lib/python3.4/site-packages/sympy/solvers/ode.py in classify_sysode(eq, funcs, **kwargs) 1364 func_dict = dict() 1365 for func in funcs:- 1366 if not order[func]: 1367 max_order = 0 1368 for i, eqs_ in enumerate(eq): KeyError: A(t) == -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/9c7fd385-0b1e-4505-8443-669f686f7054%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sympy] Re: solve traceback
It looks like the root cause of this is that the Function doesn't have all
the assumptions set. I don't fully understand how assumptions are wired
in, and I know the assumptions system is in flux, but it looks like None is
a flag for exists but not set. Would it be better to have FactKB inherit
from defaultdict, rather than dict, so that all unset assumptions return
None? That could prevent these types of exceptions...
If I do:
Qinit=symbols('Qinit')
InitCond1.subs(Q(0),Qinit)
then solve succeeds.
Looking at Q(0)._assumptions:
{'commutative': True, 'complex': True}
And Qinit._assumptions:
{'algebraic': None,
'antihermitian': None,
'commutative': True,
'complex': None,
'even': None,
'finite': None,
'hermitian': None,
'imaginary': None,
'infinite': None,
'integer': None,
'irrational': None,
'negative': None,
'nonnegative': None,
'nonpositive': None,
'odd': None,
'polar': None,
'positive': None,
'rational': None,
'real': None,
'zero': None}
On Tuesday, March 31, 2015 at 7:44:52 PM UTC-7, G B wrote:
Hi--
I'm trying to solve a system of 2 equations. They are the result of
substituting initial conditions into the solution returned from dsolve are
of the form f(0)=expr, where f is a Function, and 0 is zero.
I'm calling it with solve([InitCond1,InitCond2],(C1,C2))
What is interesting is that it fails the first time, but succeeds when I
call it a second time and then succeeds every time after. I haven't
verified the that the solution is accurate.
The traceback follows:
---KeyError
Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'zero'
During handling of the above exception, another exception occurred:
KeyError Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'zero'
During handling of the above exception, another exception occurred:
KeyError Traceback (most recent call
last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)216 try:-- 217 return
self._assumptions[fact]218 except KeyError:
KeyError: 'real'
During handling of the above exception, another exception occurred:
TypeError Traceback (most recent call
last)ipython-input-30-b2993472ce67 in module() 1
initConds=solve([InitCond1,InitCond2],(C1,C2)) 2 initConds
//anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in solve(f,
*symbols, **flags)909 solution = _solve(f[0], *symbols, **flags)
910 else:-- 911 solution = _solve_system(f, symbols, **flags)
912 913 #
//anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in
_solve_system(exprs, symbols, **flags) 1446 i, d = _invert(g,
*symbols) 1447 g = d - i- 1448 g = g.as_numer_denom()[0]
1449 if manual: 1450 failed.append(g)
//anaconda/lib/python3.4/site-packages/sympy/core/add.py in
as_numer_denom(self)433 denoms, numers = [list(i) for i in
zip(*iter(nd.items()))]434 n, d = self.func(*[Mul(*(denoms[:i] +
[numers[i]] + denoms[i + 1:]))-- 435for i in
range(len(numers))]), Mul(*denoms)436 437 return
_keep_coeff(ncon, n), _keep_coeff(dcon, d)
//anaconda/lib/python3.4/site-packages/sympy/core/add.py in listcomp(.0)
433 denoms, numers = [list(i) for i in zip(*iter(nd.items()))]434
n, d = self.func(*[Mul(*(denoms[:i] + [numers[i]] + denoms[i +
1:]))-- 435for i in range(len(numers))]), Mul(*denoms)
436 437 return _keep_coeff(ncon, n), _keep_coeff(dcon, d)
//anaconda/lib/python3.4/site-packages/sympy/core/operations.py in
__new__(cls, *args, **options) 39 return args[0] 40 ---
41 c_part, nc_part, order_symbols = cls.flatten(args) 42
is_commutative = not nc_part 43 obj = cls._from_args(c_part +
nc_part, is_commutative)
//anaconda/lib/python3.4/site-packages/sympy/core/mul.py in flatten(cls, seq)
181 a, b = b, a182 assert not a is
S.One-- 183 if not a.is_zero and a.is_Rational:184
r, b = b.as_coeff_Mul()185 if b.is_Add:
//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in
getit(self)219 if self._assumptions is
self.default_assumptions:220 self
[sympy] solve traceback
Hi-- I'm trying to solve a system of 2 equations. They are the result of substituting initial conditions into the solution returned from dsolve are of the form f(0)=expr, where f is a Function, and 0 is zero. I'm calling it with solve([InitCond1,InitCond2],(C1,C2)) What is interesting is that it fails the first time, but succeeds when I call it a second time and then succeeds every time after. I haven't verified the that the solution is accurate. The traceback follows: ---KeyError Traceback (most recent call last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in getit(self)216 try:-- 217 return self._assumptions[fact]218 except KeyError: KeyError: 'zero' During handling of the above exception, another exception occurred: KeyError Traceback (most recent call last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in getit(self)216 try:-- 217 return self._assumptions[fact]218 except KeyError: KeyError: 'zero' During handling of the above exception, another exception occurred: KeyError Traceback (most recent call last)//anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in getit(self)216 try:-- 217 return self._assumptions[fact]218 except KeyError: KeyError: 'real' During handling of the above exception, another exception occurred: TypeError Traceback (most recent call last)ipython-input-30-b2993472ce67 in module() 1 initConds=solve([InitCond1,InitCond2],(C1,C2)) 2 initConds //anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in solve(f, *symbols, **flags)909 solution = _solve(f[0], *symbols, **flags) 910 else:-- 911 solution = _solve_system(f, symbols, **flags) 912 913 # //anaconda/lib/python3.4/site-packages/sympy/solvers/solvers.py in _solve_system(exprs, symbols, **flags) 1446 i, d = _invert(g, *symbols) 1447 g = d - i- 1448 g = g.as_numer_denom()[0] 1449 if manual: 1450 failed.append(g) //anaconda/lib/python3.4/site-packages/sympy/core/add.py in as_numer_denom(self)433 denoms, numers = [list(i) for i in zip(*iter(nd.items()))]434 n, d = self.func(*[Mul(*(denoms[:i] + [numers[i]] + denoms[i + 1:]))-- 435for i in range(len(numers))]), Mul(*denoms)436 437 return _keep_coeff(ncon, n), _keep_coeff(dcon, d) //anaconda/lib/python3.4/site-packages/sympy/core/add.py in listcomp(.0) 433 denoms, numers = [list(i) for i in zip(*iter(nd.items()))]434 n, d = self.func(*[Mul(*(denoms[:i] + [numers[i]] + denoms[i + 1:]))-- 435for i in range(len(numers))]), Mul(*denoms)436 437 return _keep_coeff(ncon, n), _keep_coeff(dcon, d) //anaconda/lib/python3.4/site-packages/sympy/core/operations.py in __new__(cls, *args, **options) 39 return args[0] 40 --- 41 c_part, nc_part, order_symbols = cls.flatten(args) 42 is_commutative = not nc_part 43 obj = cls._from_args(c_part + nc_part, is_commutative) //anaconda/lib/python3.4/site-packages/sympy/core/mul.py in flatten(cls, seq) 181 a, b = b, a182 assert not a is S.One-- 183 if not a.is_zero and a.is_Rational:184 r, b = b.as_coeff_Mul()185 if b.is_Add: //anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in getit(self) 219 if self._assumptions is self.default_assumptions:220 self._assumptions = self.default_assumptions.copy()-- 221 return _ask(fact, self)222 223 getit.func_name = as_property(fact) //anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in _ask(fact, obj)262 pass263 else:-- 264 a = evaluate(obj) 265 if a is not None:266 assumptions.deduce_all_facts(((fact, a),)) //anaconda/lib/python3.4/site-packages/sympy/core/mul.py in _eval_is_zero(self) 989 zero = infinite = False990 for a in self.args:-- 991 z = a.is_zero992 if z:993 if infinite: //anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in getit(self) 219 if self._assumptions is self.default_assumptions:220 self._assumptions = self.default_assumptions.copy()-- 221 return _ask(fact, self)222 223 getit.func_name = as_property(fact) //anaconda/lib/python3.4/site-packages/sympy/core/assumptions.py in _ask(fact, obj)274 continue275 if pk in
[sympy] Re: How to give a Function a latex representation?
Interesting.
Function('V_{C}')
returns a string (V_{C})
Function('V_{C}')(t)
returns proper latex. It must be how it's handled in the printer...
On Sunday, March 29, 2015 at 10:13:36 PM UTC-7, G B wrote:
Hi--
I can give a symbol a latex representation with:
x1=symbols(r'x_{1}')
How do I create a function with a latex representation?
Ic=symbols(r'I_{C}',cls=Function)
Ic=Function(r'I_{C}')
Don't seem to work... They pretty print as strings.
Thanks--
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/02276aae-b6ae-4518-a559-1cdf97c87b01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[sympy] How to give a Function a latex representation?
Hi--
I can give a symbol a latex representation with:
x1=symbols(r'x_{1}')
How do I create a function with a latex representation?
Ic=symbols(r'I_{C}',cls=Function)
Ic=Function(r'I_{C}')
Don't seem to work... They pretty print as strings.
Thanks--
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/a72deaa7-8ace-4bcc-8767-f5f48eaba5a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[sympy] Custom latex printing for Function subclass
I haven't moved to 0.7.6 yet, so I'm still using 0.7.5. I'm trying to create a custom subclass of Function, which is sure to emit more questions later, but for now the question is: how do I the LatexPrinter to display it as anything but name(x,y)? It looks like that's the behavior if there isn't a _print_name() function in LatexPrinter itself, and LatexPrinter doesn't appear easily extensible. Is there a method I can add to my custom subclass that describes how it should be printed? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/524cd627-5aa2-4002-85da-1d960555bf12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[sympy] How to set up NumberSymbols?
I'd like to set up values that display as symbols but evaluate to numbers when called with .n(). I think this is similar to how pi and E are handled. In my case it's constants such as the speed of light, and Boltzmann's constant. When I look at the symbolic representation, I'd like to see these values represented as symbols (c, k_B), but when I evaluate I'd like their true value used without the need for explicit substitution. Is there an easy way to set up such values? Looking through the source, I found Pi and Exp1 defined in sympy.core.numbers-- and it looks like each is a custom class. Is there a trick to setting up _as_mpf_val and approximation_interval for physical constants such as these? Does _sage_ need to be implemented if I'm not running within Sage? Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] How to set up NumberSymbols?
Ok, I tried this and it seems to behave well at a basic level: from sympy.core.singleton import Singleton class BoltzmannConstant(NumberSymbol): __metaclass__ = Singleton is_real = True is_positive = True is_negative = False is_irrational = None __slots__ = [] @staticmethod def __abs__(): return S.BoltzmannConstant def __int__(self): return 0 def _eval_evalf(self,prec): return N(1.3806488e-23,prec) kB = S.BoltzmannConstant Does that look like a reasonable implementation? How would I associate the symbol k_B with this Singleton? Right now when I enter kB, it displays as 'BoltzmannConstant()' (whereas pi somehow knows to display as \pi). On Sunday, February 2, 2014 5:40:21 PM UTC-8, Aaron Meurer wrote: I don't think pi and Exp1 are good examples because they are already implemented in mpmath, and can be computed to an arbitrary number of digits. That's what the mpf stuff is doing. For your case, I think you just need to define _eval_evalf(self, prec), which should return a Float to prec digits. _sage_ is just to convert the objects to Sage equivalents. If you don't intend for you code to ever be used within Sage you don't need to worry about it. Aaron Meurer On Sun, Feb 2, 2014 at 7:12 PM, G B g.c.b@gmail.com javascript: wrote: I'd like to set up values that display as symbols but evaluate to numbers when called with .n(). I think this is similar to how pi and E are handled. In my case it's constants such as the speed of light, and Boltzmann's constant. When I look at the symbolic representation, I'd like to see these values represented as symbols (c, k_B), but when I evaluate I'd like their true value used without the need for explicit substitution. Is there an easy way to set up such values? Looking through the source, I found Pi and Exp1 defined in sympy.core.numbers-- and it looks like each is a custom class. Is there a trick to setting up _as_mpf_val and approximation_interval for physical constants such as these? Does _sage_ need to be implemented if I'm not running within Sage? Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] How to set up NumberSymbols?
On Sunday, February 2, 2014 6:21:45 PM UTC-8, Aaron Meurer wrote:
A few comments:
- You should wrap the float in a string, so that you don't lose
precision from Python's float.
Thanks.
- Why have you made __abs__ a staticmethod? Also, SymPy's Abs uses
_eval_Abs. But you won't need it anyway, because you've defined it to
be positive.
The only worked examples I could find are in sympy.core.numbers and both Pi
and Exp1 have an __abs__ staticmethod.
- To get printing, you need to define the printing methods. See
http://docs.sympy.org/latest/modules/printing.html. You need to define
the printmethod for each printer that you care about. The most
common ones are the string printer, the ASCII pretty printer, the
Unicode pretty printer, and the LaTeX printer. If you want it to work
with lambdify() you'll need to use the LambdaPrinter. If you want it
to work with the code generation you'll need to define the relevant
printer for the languages you are interested in.
Ok, I think I've go this mostly working. The main difference is that
print(kB) returns the float value while print(pi) returns the string pi.
This was
necessary to get LambdaPrinter to work, because LambdaPrinter looks to use
the _sympystr method. Pi is happy, presumably because numpy
has a pi value, so the string is interpreted later in the chain. Pretty
print and latex do as I'd like, so that's good enough for now.
- Making it a Singleton is not required. This is done in SymPy for
efficiency purposes. Neither is setting __slots__ to []. They
shouldn't hurt either way, though. If you want your code to work in
Python 3 you'll need to use with_metaclass.
- Defining __int__ shouldn't be necessary. If it is, that's a bug,
because the superclass should have that defined in such a way that it
figures it out automatically from the evalf() value.
Again, I just mimicked what I saw for pi and E. (I'm still using 0.72, if
that makes a difference)
What I have now is:
class BoltzmannConstant(NumberSymbol):
is_real = True
is_positive = True
is_negative = False
is_irrational = None
val='1.3806488e-23'
def _eval_evalf(self,prec):
return N(self.val,prec)
def __str__(self,*args):
return 'kB'
def _sympystr(self,*args):
return self.val
def _latex(self,*args):
return 'k_{B}'
kB = BoltzmannConstant()
I took a stab at writing code to simplify the creation of these types of
constants, but I don't completely understand the architecture. It's not
clear to me why values such as Pi are classes derived from NumberSymbol
rather than instances of NumberSymbol.
Thanks for the help--
Greg
Aaron Meurer
On Sun, Feb 2, 2014 at 8:12 PM, G B g.c.b@gmail.com javascript:
wrote:
Ok, I tried this and it seems to behave well at a basic level:
from sympy.core.singleton import Singleton
class BoltzmannConstant(NumberSymbol):
__metaclass__ = Singleton
is_real = True
is_positive = True
is_negative = False
is_irrational = None
__slots__ = []
@staticmethod
def __abs__():
return S.BoltzmannConstant
def __int__(self):
return 0
def _eval_evalf(self,prec):
return N(1.3806488e-23,prec)
kB = S.BoltzmannConstant
Does that look like a reasonable implementation?
How would I associate the symbol k_B with this Singleton? Right now
when
I enter kB, it displays as 'BoltzmannConstant()' (whereas pi somehow
knows
to display as \pi).
On Sunday, February 2, 2014 5:40:21 PM UTC-8, Aaron Meurer wrote:
I don't think pi and Exp1 are good examples because they are already
implemented in mpmath, and can be computed to an arbitrary number of
digits. That's what the mpf stuff is doing. For your case, I think you
just need to define _eval_evalf(self, prec), which should return a
Float to prec digits.
_sage_ is just to convert the objects to Sage equivalents. If you
don't intend for you code to ever be used within Sage you don't need
to worry about it.
Aaron Meurer
On Sun, Feb 2, 2014 at 7:12 PM, G B g.c.b@gmail.com wrote:
I'd like to set up values that display as symbols but evaluate to
numbers
when called with .n(). I think this is similar to how pi and E are
handled.
In my case it's constants such as the speed of light, and Boltzmann's
constant. When I look at the symbolic representation, I'd like to
see
these
values represented as symbols (c, k_B), but when I evaluate I'd like
their
true value used without the need for explicit substitution.
Is there an easy way to set up such values?
Looking through the source, I found Pi and Exp1 defined in
sympy.core.numbers-- and it looks like each is a custom class. Is
there
a
trick
[sympy] Which issue tracker?
Are the issue trackers from Github and code.google coordinated? Which is the preferred one to use? Thanks! -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] solve eager to round to zero?
I'm not sure what's causing this, but solve seems to want to call small
constants zero:
In [1]: from sympy import *
In [2]: E,m,c=symbols('E,m,c')
In [3]: Energy=Eq(E,m*c**2)
In [4]: solve(Energy,E)
Out[4]: [c**2*m]
In [5]: E2=Energy.subs(c,3e8)
In [6]: solve(E2,E)
Out[6]: [9.0e+16*m]
In [7]: e2=Energy.subs(c,3e-8)
In [8]: solve(e2,E)
Out[8]: [0.0]
I'm not sure why that happens with very small coefficients. It doesn't
happen with less small ones:
In [9]: e3=Energy.subs(c,0.5)
In [10]: solve(e3,E)
Out[10]: [0.25*m]
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Re: solve eager to round to zero?
This appears to have been introduced in 0.7.3. I reverted to 0.7.2 and get
the expected results.
On Wednesday, September 11, 2013 3:27:22 PM UTC-7, G B wrote:
I'm not sure what's causing this, but solve seems to want to call small
constants zero:
In [1]: from sympy import *
In [2]: E,m,c=symbols('E,m,c')
In [3]: Energy=Eq(E,m*c**2)
In [4]: solve(Energy,E)
Out[4]: [c**2*m]
In [5]: E2=Energy.subs(c,3e8)
In [6]: solve(E2,E)
Out[6]: [9.0e+16*m]
In [7]: e2=Energy.subs(c,3e-8)
In [8]: solve(e2,E)
Out[8]: [0.0]
I'm not sure why that happens with very small coefficients. It doesn't
happen with less small ones:
In [9]: e3=Energy.subs(c,0.5)
In [10]: solve(e3,E)
Out[10]: [0.25*m]
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
[sympy] setting latex mul_symbol via init_printing()
I'm running an IPython session using Sympy, and have started up the pretty print module using init_printing(). The output is getting hard to parse because the default multiplication symbol is None, and I'd like to set it to something else. Is there a way to do that? It looks like the latex printer accepts mul_symbol as an argument, but I'm not sure how to set that for the default printer... Thanks-- -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] collect Euler's formula?
Hi--
If I have:
x,f=symbols('x,f',real=True)
exp1=E**(-I*2*pi*f*x)
exp2=exp1.expand(complex=True)
exp2 returns:
-I*sin(2*pi*f*x) + cos(2*pi*f*x)
Is there a way to go from exp2 back to exp1?
Thanks--
Greg
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Re: collect Euler's formula?
That did it! And made it clear I misunderstood what rewrite does... Thanks! Greg On Apr 1, 2013, at 0:51, Manoj Kumar manojkumarsivaraj...@gmail.com wrote: I'm relatively new over here, but I think this should do. exp2.rewrite(exp) exp(-2*I*pi*f*x) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Re: lambdify DiracDelta and Heaviside as Piecewise?
Sorry if this winds up being a duplicate post-- I thought I sent this earlier, but I haven't seen it come through. How exactly are you using it? DiracDelta is not really a function. It's a formalism that lets you use integration to get the value of a function at a point. That makes it inherently symbolic. I don't expect there will be an easy numeric version. You'll need to do some preprocessing to get what you really want later on when you (assumedly) integrate. SymPy can likely help you here, as it can symbolically manipulate Dirac deltas. I'm using the DiracDelta as one half of a convolution, so you're right, I don't really need a numeric representation. Getting Heaviside to work is enough. The likelihood of sampling the interesting part of the delta is numerically zero anyway. As long as I was doing Heaviside though, DiracDelta seemed like an easy throw-in since it should have followed a similar pattern, but with inf being only a half step from nan, it's treacherous territory. I'd put the priority on fixing Piecewise, I think. Cheers-- Greg On Monday, March 4, 2013 3:10:23 PM UTC-8, Aaron Meurer wrote: On Mar 4, 2013, at 4:02 PM, G B g.c.b@gmail.com javascript: wrote: Now having tried it, it looks like the current implementation of Piecewise using a if test else b expressions doesn't work with numpy. The test clause returns an array result, which doesn't like being tested as a unit. I've implemented _print_Heaviside like this: def _print_Heaviside(self,expr): a=expr.args retVal= ((%s)*(%s) + (%s)*(%s) + (%s)*(%s)) % (self._print(S(0)), self._print(Lt(a[0],0)), self._print(div(1,2)), self._print(Eq(a[0],0)), self._print(S(1)), self._print(Gt(a[0],0))) return retVal I suspect that those self._print(S(constant)) calls are overkill, but this design seems to work. I'd recommend recrafting Piecewise in a similar way-- though it might be tricky given that Piecewise as documented allows overlapping conditions. Ideally you could just call .rewrite(Piecewise). But it isn't implemented (issue 3478). It's easy to fix, though. I'm having a different problem with _print_DiracDelta, which I tried this way: def _print_DiracDelta(self,expr): a=expr.args retVal=((%s)*(%s) + (%s)*(%s)) % (self._print(oo), self._print(Eq(a[0],0)), self._print(S(0)), self._print(Ne(a[0],0))) return retVal The problem being that oo*0 returns nan which, in turn, seizes the rest of my code by the brainstem. Anybody have a clever idea of how to get around this? How exactly are you using it? DiracDelta is not really a function. It's a formalism that lets you use integration to get the value of a function at a point. That makes it inherently symbolic. I don't expect there will be an easy numeric version. You'll need to do some preprocessing to get what you really want later on when you (assumedly) integrate. SymPy can likely help you here, as it can symbolically manipulate Dirac deltas. Aaron Meurer I could do some sort of clever indexing to solve the problem in a numpy way, I think, but I'd like to find a general solution. Thanks-- Greg On Monday, March 4, 2013 1:35:11 AM UTC-8, G B wrote: As is probably becoming apparent, I've been busy lambdifying stuff... My latest runtime problem is trying to convolve things with DiracDeltas. The result comes back with a Heaviside function. A quick look through the numpy docs doesn't show a numpy equivalent function for either DiracDelta or Heaviside-- does it makes sense to print these as Piecewise functions? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Heaviside integrates to zero
Maybe this is a symptom of: http://code.google.com/p/sympy/issues/detail?id=1696 but this command: integrate(Heaviside(x-0.2)-Heaviside(x-0.5),(x,0.,1.)) returns zero for me. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Re: Heaviside integrates to zero
Just following up with more information-- I get the feeling this is different than Issue 1696. I get this behavior, all of which I find unexpected: In [1]: from sympy import * In [2]: from sympy.abc import x ## I would expect this to return S(1) without needing to evalf: In [3]: integrate(Heaviside(x),(x,-1,1)) Out[3]: Integral(Heaviside(x), (x, -1, 1)) In [4]: integrate(Heaviside(x),(x,-1,1)).n() Out[4]: 1.00 ## I would expect this to return Rational(1,2), strangely it doesn't even return an ## unevaluated integral, it seems certain the answer here is precisely zero. In [5]: integrate(Heaviside(x-Rational(1,2)),(x,-1,1)) Out[5]: 0 ## I would expect this to return S(1), what I get is far more complicated: In [6]: integrate(Heaviside(x-S(1)),(x,-1,2)) Out[6]: -meijerg(((2, 1), ()), ((), (1, 0)), 1) + meijerg(((2, 1), ()), ((), (1, 0)), 2) ## ...but evaluates correctly In [7]: integrate(Heaviside(x-S(1)),(x,-1,2)).n() Out[7]: 1.00 I get correct results spot evaluating Heaviside(x-Rational(1,2)) at various points. Is the problem in integrate? On Tuesday, March 5, 2013 12:43:11 AM UTC-8, G B wrote: Maybe this is a symptom of: http://code.google.com/p/sympy/issues/detail?id=1696 but this command: integrate(Heaviside(x-0.2)-Heaviside(x-0.5),(x,0.,1.)) returns zero for me. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] lambdify DiracDelta and Heaviside as Piecewise?
As is probably becoming apparent, I've been busy lambdifying stuff... My latest runtime problem is trying to convolve things with DiracDeltas. The result comes back with a Heaviside function. A quick look through the numpy docs doesn't show a numpy equivalent function for either DiracDelta or Heaviside-- does it makes sense to print these as Piecewise functions? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Re: lambdify DiracDelta and Heaviside as Piecewise?
Now having tried it, it looks like the current implementation of Piecewise using a if test else b expressions doesn't work with numpy. The test clause returns an array result, which doesn't like being tested as a unit. I've implemented _print_Heaviside like this: def _print_Heaviside(self,expr): a=expr.args retVal= ((%s)*(%s) + (%s)*(%s) + (%s)*(%s)) % (self._print(S(0)), self._print(Lt(a[0],0)), self._print(div(1,2)), self._print(Eq(a[0],0)), self._print(S(1)), self._print(Gt(a[0],0))) return retVal I suspect that those self._print(S(constant)) calls are overkill, but this design seems to work. I'd recommend recrafting Piecewise in a similar way-- though it might be tricky given that Piecewise as documented allows overlapping conditions. I'm having a different problem with _print_DiracDelta, which I tried this way: def _print_DiracDelta(self,expr): a=expr.args retVal=((%s)*(%s) + (%s)*(%s)) % (self._print(oo), self._print(Eq(a[0],0)), self._print(S(0)), self._print(Ne(a[0],0))) return retVal The problem being that oo*0 returns nan which, in turn, seizes the rest of my code by the brainstem. Anybody have a clever idea of how to get around this? I could do some sort of clever indexing to solve the problem in a numpy way, I think, but I'd like to find a general solution. Thanks-- Greg On Monday, March 4, 2013 1:35:11 AM UTC-8, G B wrote: As is probably becoming apparent, I've been busy lambdifying stuff... My latest runtime problem is trying to convolve things with DiracDeltas. The result comes back with a Heaviside function. A quick look through the numpy docs doesn't show a numpy equivalent function for either DiracDelta or Heaviside-- does it makes sense to print these as Piecewise functions? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] lambdify a constant in numpyland?
Ah thanks-- always comforting to know I'm not the first person to complain... =) And the broadcasting argument makes the current design less mystifying. In my case, I have a sympy equation that I lambdify to a function that I then want to plot. I wind up with something like this: xx=linspace(...) f=lambdify(x,exp,numpy) y=f(xx) plot(xx,y) That snippet of code worked fine until it ran on an expression that simplified to a constant. I could solve the problem by placing special handling around y before plot, but that feels inelegant. I understand the broadcasting argument from a numpy centric view, but is that the model that lambdify should follow? I feel as though in numpyland you're more likely to know the shape of your function, and thus would know from the outset whether y needed to be reshaped. In sympyland, the function itself is a variable, so special handling of y becomes necessary boilerplate. Of course, I've explicitly told lambdify to create a numpy function, so it's not unreasonable that it behave in the numpy way. Maybe this is a place for a keyword argument? Maybe I'm giving too much weight to my own particular use case, but is this a discussion worth reopening? On Saturday, March 2, 2013 12:21:20 AM UTC-8, Aaron Meurer wrote: See https://code.google.com/p/sympy/issues/detail?id=2543 for some discussion on this. Aaron Meurer On Fri, Mar 1, 2013 at 8:53 PM, G B g.c.b@gmail.com javascript: wrote: This is kind of a degenerate case, but personally I think it should behave differently than it does currently. f1=lambdify(x,2*x,numpy) f2=lambdify(x,S(1),numpy) f1(array([1,2,3]) -- [2,4,6] f2(array([1,2,3]) -- [1] I feel that f2 should return [1,1,1] in that situation. Am I misinterpreting that? Cheers-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] lambdify a constant in numpyland?
This is kind of a degenerate case, but personally I think it should behave differently than it does currently. f1=lambdify(x,2*x,numpy) f2=lambdify(x,S(1),numpy) f1(array([1,2,3]) -- [2,4,6] f2(array([1,2,3]) -- [1] I feel that f2 should return [1,1,1] in that situation. Am I misinterpreting that? Cheers-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] adding Mod to lambdify
I'll give this a shot this weekend if I can. I haven't submitted a pull request before, but at some point I'd like to figure it out… Cheers— Greg On Feb 26, 2013, at 7:46 PM, Aaron Meurer asmeu...@gmail.com wrote: Great. If you could make a pull request with this change, that would be great. This is a change that would obviously benefit everyone. Aaron Meurer On Tue, Feb 26, 2013 at 7:23 PM, G B g.c.b.at.w...@gmail.com wrote: Thanks, Aaron. I put the following into LambdaPrinter, and it seems to be doing the job nicely: def _print_Mod(self,expr): a=expr.args retVal= ((%s)%%(%s)) % (self._print(a[0]),self._print(a[1])) return retVal On Monday, February 25, 2013 10:04:08 AM UTC-8, Aaron Meurer wrote: Wouldn't it be better to make it print using %. That would be universal, not just for Numpy (and it should therefore just be added to the LambdaPrinter). Aaron Meurer On Feb 25, 2013, at 1:53 AM, G B g.c.b@gmail.com wrote: I went and tried to lamdify an expression with a Mod operator using the numpy module, and it didn't like it. Is fixing this as easy as adding Mod:mod, to the NUMPY_TRANSLATIONS dictionary in utilities/lambdify.py? I just discovered lambdify, and now I can't stop using it for everything... I'd had my own implementation using a hacked together sequence of substitutions, solves and closures, but this is much more satisfying! Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com. To post to this group, send email to sy...@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] more Mod problems
I'm not sure it matters in the end, but it looks like Mod(Rational(15,7),1).n() works ok too. I think what's happening is that when pi isn't in the argument list, it basically gets simplified when the class construction calls Mod.eval but Mod.eval doesn't know how to simplify with pi. I've patched this into my Mod class: def _eval_evalf(self,prec): return N(mpmath.fmod(*[N(x,prec) for x in self.args]),prec) It solves my immediate problem, but given how complex the evalf functions are for everything else, I get the feeling I've done something horribly, inexcusably naive here. Am I missing anything? I tried Chris' examples and Mod(1e-40,1) returns 0 with my method even though mpmath.fmod(1e-40,1) returns 1e-40. It also returns zero if I write it as Mod(Float(1e-40),S(1)). I get the proper results with Mod(1e-40,1,evaluate=False).n(). Again, the problem appears to be in Mod.eval, but I'm not sure where. The other thing I noticed going through EvalfMixin.evalf is that the options parameter isn't passed to self._eval_evalf, which means that subs parameters won't get passed unless _eval_evalf is in the evalf_table. I don't know if this was intentional or an oversight. Cheers-- Greg On Wednesday, February 27, 2013 3:40:57 PM UTC-8, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 1:41 PM, Chris Smith smi...@gmail.comjavascript: wrote: It looks like Mod doesn't implement evalf at all, and it doesn't work automatically (that only happens if the function name is the same as the mpmath function name). It should be easy. Just evaluate the arguments, and then take the mod of them. In general this is not going to work: ``` Mod(1e-30,3) 1.00e-30 Mod(1e-40,3) 0.0 ``` whereas ``` 1e-40 % 3 9.9993e-41 ``` Isn't that just a roundoff error. If you use Float, you get 1e-40. Aaron Meurer Something like this might work when a b (when a b the answer is `a`): ``` a,b=pi**3,S(3) (a - round(a/b)*b).n() 1.00627668029982 a.n() % b.n() 1.00627668029982 ``` -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.comjavascript:. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] more Mod problems
Why not just convert each arg to Float and use %, and leave the details up to Float.__mod__. In all honesty, because I have very little idea what I'm doing... =) I just tried this, but it failed: def _eval_evalf(self,prec): args=[Float(x,prec) for x in self.args] return N(args[0] % args[1],prec) I put the traceback at the bottom of my message to avoid clutter... I may not be clear what you're saying, but _eval_evalf only takes two arguments, self and prec. So where would subs be passed to? Sorry, I should have been more clear. As I read the code in EvalfMixin.evalf, it first tries to call evalf(self,prec+4,options). I believe this evalf is in the evalf.py source file itself. This version uses evalf_table for dispatch, rather than relying on self to have its own implementation. One of the fields of 'options' is the subs parameter passed to EvalfMixin.evalf If this version of evalf raises NotImplementedError, then EvalfMixin.evalf tries to call self._eval_evalf(prec). It doesn't try to pass the options parameter to the _eval_evalf implemented in self, and therefore can't carry the subs parameter passed to the EvalfMixin.evalf(self,n,subs,...) call. I don't know the reason for the different calling conventions. It appears like the dispatch table would best handle classes that can't be extended with _eval_evalf, while leaving each class responsible for it's own implementation otherwise. The options seem equally useful to both implementation routes. I'm guessing this was an oversight, but I don't know the history. Cheers-- Greg Here's that traceback: --- 100 def _eval_evalf(self,prec): -- 101 args=[Float(x,prec) for x in self.args] 102 return N(args[0] % args[1],prec) 103 #return N(mpmath.fmod(*[N(x,prec) for x in self.args]),prec) /Library/Python/2.7/site-packages/sympy/core/numbers.pyc in __new__(cls, num, prec) 589 _mpf_ = mpf_norm(_mpf_, prec) 590 else: -- 591 _mpf_ = mpmath.mpf(num)._mpf_ 592 593 if not num: /Library/Python/2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in __new__(cls, val, **kwargs) 75 else: 76 v = new(cls) --- 77 v._mpf_ = mpf_pos(cls.mpf_convert_arg(val, prec, rounding), prec, rounding) 78 return v 79 /Library/Python/2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in mpf_convert_arg(cls, x, prec, rounding) 94 return a 95 raise ValueError(can only create mpf from zero-width interval) --- 96 raise TypeError(cannot create mpf from + repr(x)) 97 98 @classmethod TypeError: cannot create mpf from acos(cos(39*pi/115))/(2*pi) On Wednesday, February 27, 2013 4:55:46 PM UTC-8, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 5:46 PM, G B g.c.b@gmail.com javascript: wrote: I'm not sure it matters in the end, but it looks like Mod(Rational(15,7),1).n() works ok too. I think what's happening is that when pi isn't in the argument list, it basically gets simplified when the class construction calls Mod.eval but Mod.eval doesn't know how to simplify with pi. I've patched this into my Mod class: def _eval_evalf(self,prec): return N(mpmath.fmod(*[N(x,prec) for x in self.args]),prec) You're passing SymPy Floats to the mpmath function, which is not really correct (though I guess it works). Why not just convert each arg to Float and use %, and leave the details up to Float.__mod__. It solves my immediate problem, but given how complex the evalf functions are for everything else, I get the feeling I've done something horribly, inexcusably naive here. Am I missing anything? I tried Chris' examples and Mod(1e-40,1) returns 0 with my method even though mpmath.fmod(1e-40,1) returns 1e-40. It also returns zero if I write it as Mod(Float(1e-40),S(1)). I get the proper results with Mod(1e-40,1,evaluate=False).n(). Again, the problem appears to be in Mod.eval, but I'm not sure where. The other thing I noticed going through EvalfMixin.evalf is that the options parameter isn't passed to self._eval_evalf, which means that subs parameters won't get passed unless _eval_evalf is in the evalf_table. I don't know if this was intentional or an oversight. I may not be clear what you're saying, but _eval_evalf only takes two arguments, self and prec. So where would subs be passed to? Aaron Meurer Cheers-- Greg On Wednesday, February 27, 2013 3:40:57 PM UTC-8, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 1:41 PM, Chris Smith smi...@gmail.com wrote: It looks like Mod doesn't implement evalf at all, and it doesn't work automatically (that only happens if the function name is the same as the mpmath function
Re: [sympy] more Mod problems
It looks like this works, and degrades more gracefully than the other methods I've shown when the arguments can't be reduced to Floats: def _eval_evalf(self,prec): args=[N(x,prec) for x in self.args] return N(args[0] % args[1],prec) On Wednesday, February 27, 2013 6:28:54 PM UTC-8, G B wrote: Why not just convert each arg to Float and use %, and leave the details up to Float.__mod__. In all honesty, because I have very little idea what I'm doing... =) I just tried this, but it failed: def _eval_evalf(self,prec): args=[Float(x,prec) for x in self.args] return N(args[0] % args[1],prec) I put the traceback at the bottom of my message to avoid clutter... I may not be clear what you're saying, but _eval_evalf only takes two arguments, self and prec. So where would subs be passed to? Sorry, I should have been more clear. As I read the code in EvalfMixin.evalf, it first tries to call evalf(self,prec+4,options). I believe this evalf is in the evalf.py source file itself. This version uses evalf_table for dispatch, rather than relying on self to have its own implementation. One of the fields of 'options' is the subs parameter passed to EvalfMixin.evalf If this version of evalf raises NotImplementedError, then EvalfMixin.evalf tries to call self._eval_evalf(prec). It doesn't try to pass the options parameter to the _eval_evalf implemented in self, and therefore can't carry the subs parameter passed to the EvalfMixin.evalf(self,n,subs,...) call. I don't know the reason for the different calling conventions. It appears like the dispatch table would best handle classes that can't be extended with _eval_evalf, while leaving each class responsible for it's own implementation otherwise. The options seem equally useful to both implementation routes. I'm guessing this was an oversight, but I don't know the history. Cheers-- Greg Here's that traceback: --- 100 def _eval_evalf(self,prec): -- 101 args=[Float(x,prec) for x in self.args] 102 return N(args[0] % args[1],prec) 103 #return N(mpmath.fmod(*[N(x,prec) for x in self.args]),prec) /Library/Python/2.7/site-packages/sympy/core/numbers.pyc in __new__(cls, num, prec) 589 _mpf_ = mpf_norm(_mpf_, prec) 590 else: -- 591 _mpf_ = mpmath.mpf(num)._mpf_ 592 593 if not num: /Library/Python/2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in __new__(cls, val, **kwargs) 75 else: 76 v = new(cls) --- 77 v._mpf_ = mpf_pos(cls.mpf_convert_arg(val, prec, rounding), prec, rounding) 78 return v 79 /Library/Python/2.7/site-packages/sympy/mpmath/ctx_mp_python.pyc in mpf_convert_arg(cls, x, prec, rounding) 94 return a 95 raise ValueError(can only create mpf from zero-width interval) --- 96 raise TypeError(cannot create mpf from + repr(x)) 97 98 @classmethod TypeError: cannot create mpf from acos(cos(39*pi/115))/(2*pi) On Wednesday, February 27, 2013 4:55:46 PM UTC-8, Aaron Meurer wrote: On Wed, Feb 27, 2013 at 5:46 PM, G B g.c.b@gmail.com wrote: I'm not sure it matters in the end, but it looks like Mod(Rational(15,7),1).n() works ok too. I think what's happening is that when pi isn't in the argument list, it basically gets simplified when the class construction calls Mod.eval but Mod.eval doesn't know how to simplify with pi. I've patched this into my Mod class: def _eval_evalf(self,prec): return N(mpmath.fmod(*[N(x,prec) for x in self.args]),prec) You're passing SymPy Floats to the mpmath function, which is not really correct (though I guess it works). Why not just convert each arg to Float and use %, and leave the details up to Float.__mod__. It solves my immediate problem, but given how complex the evalf functions are for everything else, I get the feeling I've done something horribly, inexcusably naive here. Am I missing anything? I tried Chris' examples and Mod(1e-40,1) returns 0 with my method even though mpmath.fmod(1e-40,1) returns 1e-40. It also returns zero if I write it as Mod(Float(1e-40),S(1)). I get the proper results with Mod(1e-40,1,evaluate=False).n(). Again, the problem appears to be in Mod.eval, but I'm not sure where. The other thing I noticed going through EvalfMixin.evalf is that the options parameter isn't passed to self._eval_evalf, which means that subs parameters won't get passed unless _eval_evalf is in the evalf_table. I don't know if this was intentional or an oversight. I may not be clear what you're saying, but _eval_evalf only takes two arguments, self and prec. So where would subs be passed
Re: [sympy] adding Mod to lambdify
Thanks, Aaron. I put the following into LambdaPrinter, and it seems to be doing the job nicely: def _print_Mod(self,expr): a=expr.args retVal= ((%s)%%(%s)) % (self._print(a[0]),self._print(a[1])) return retVal On Monday, February 25, 2013 10:04:08 AM UTC-8, Aaron Meurer wrote: Wouldn't it be better to make it print using %. That would be universal, not just for Numpy (and it should therefore just be added to the LambdaPrinter). Aaron Meurer On Feb 25, 2013, at 1:53 AM, G B g.c.b@gmail.com javascript: wrote: I went and tried to lamdify an expression with a Mod operator using the numpy module, and it didn't like it. Is fixing this as easy as adding Mod:mod, to the NUMPY_TRANSLATIONS dictionary in utilities/lambdify.py? I just discovered lambdify, and now I can't stop using it for everything... I'd had my own implementation using a hacked together sequence of substitutions, solves and closures, but this is much more satisfying! Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com javascript:. To post to this group, send email to sy...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] adding Mod to lambdify
I went and tried to lamdify an expression with a Mod operator using the numpy module, and it didn't like it. Is fixing this as easy as adding Mod:mod, to the NUMPY_TRANSLATIONS dictionary in utilities/lambdify.py? I just discovered lambdify, and now I can't stop using it for everything... I'd had my own implementation using a hacked together sequence of substitutions, solves and closures, but this is much more satisfying! Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Re: adding Mod to lambdify
Just to follow up, I've made this simple change and everything *appears* to be working fine. I haven't gone through the lambdify code in depth-- are there any unforeseen consequences? I also noticed that lambdify doesn't like symbols with prime notations-- the single quote seems to mess something up. tp=symbols(t') #works fine in most places, but lambdify chokes Cheers-- Greg On Monday, February 25, 2013 12:53:38 AM UTC-8, G B wrote: I went and tried to lamdify an expression with a Mod operator using the numpy module, and it didn't like it. Is fixing this as easy as adding Mod:mod, to the NUMPY_TRANSLATIONS dictionary in utilities/lambdify.py? I just discovered lambdify, and now I can't stop using it for everything... I'd had my own implementation using a hacked together sequence of substitutions, solves and closures, but this is much more satisfying! Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Subtracting equations?
Sorry if this is covered in the documentation somewhere, I tried to check...
Is there a way to subtract one equation from another? What I'm looking to
do boils down to:
a,b,r,s=symbols('a,b,r,s')
eq1=Eq(a,r) #a==r
eq2=Eq(b,s)#b==s
eq3=eq1-eq2
I'd very much like eq3 to be:
a-b==r-s
In effect, I'm trying to step through equation manipulations, but
selectively under my control.
Thanks--
Greg
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sympy] Add assumption to symbol?
I apologize if this is obvious, but how to I add an assumption to a symbol? I
know there are two dueling assumptions systems for the time being, and the
solver seems to use the older one.
if I create a symbol:
s=symbol('s',real=True)
and later want to add the assumption that 's' is also positive, what is the
right way to do that?
Thanks—
Greg
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Data analysis tools
I don't think we should build analysis tools. I do think that we should do more outreach. Speaking as a noob with a lot of this, I wonder if one way to start would be to move documentation closer together. Perhaps even interlink a bit. I generally agree with the division of labor among these different packages, but I understand where the instinct comes from to make SymPy expand its role-- its easy to feel like each package is its own island. As I'm trying to find a way to do something, I need to make a conscious effort to jump to a different documentation tree on a different site. Having a shared hub for what I'd call scientific computing packages might help me, at least, take in more of whats available and give a better perspective to what functionality belongs in which package. On Fri, Oct 5, 2012 at 10:40 AM, Matthew Rocklin mrock...@gmail.com wrote: I think that data analysis should be done in some of the other popular python packages (numpy, pandas, statsmodels). I think that SymPy should see how it can serve and connect with these other packages. You mention distributions so I'll speak about sympy.stats for a moment. A while ago I talked with the statsmodels folks. They could use sympy in a couple of ways. They built their own rudimentary symbolic stats system that we could replace with sympy.stats. They also badly need symbolic derivatives which we could supply with sympy.core. Skipper, one of the developers of statsmodels started working on this connection a while agohttps://groups.google.com/forum/?fromgroups=#!searchin/sympy/skipper/sympy/DViO43-qtM4/6jMMew5twF8Jbut stopped. I probably could have made this work if I put more work in on the SymPy side. I don't think we should build analysis tools. I do think that we should do more outreach. On Fri, Oct 5, 2012 at 12:27 PM, Sachin Joglekar srjoglekar...@gmail.comwrote: It was recently pointed out to me that though Sympy has much of the theoretical classes used in data analysis, there are no straightforward analysis tools in any module of Sympy. Something like those present in the statistical analysis language R. Sympy already has classes for all important distributions. It would just be a question of providing an 'interface' to make analysis easier, for eg, dealing with .csv files, etc. Would it be a useful addition to the code base? -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/ThBVoQL-0W4J. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] expand(trig=True) doesn't like difference of angles
I'm still new to sympy, so I might be doing something stupid, but I think
there's a problem here:
In [1]: from sympy import *
In [2]: x,y=symbols('x,y')
In [3]: cos(x+y).expand(trig=True)
Out[3]: -sin(x)*sin(y) + cos(x)*cos(y)
So far so good. but then:
In [4]: cos(x-y).expand(trig=True)
Leads to a long traceback that culminates with: AttributeError: 'Mul'
object has no attribute '_eval_expand_trig'
For giggles, I also tried:
In [5]: cos(x + (-y)).expand(trig=True)
Which fails in the same way. I can post the full traceback if it helps.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/-Z8Y7YC_PuEJ.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] expand(trig=True) doesn't like difference of angles
Oh, so that's where the broken Mul comes from... =) Makes sense, of
course, but I was looking at my code saying there's no multiplication!.
I've submitted the issue.
On Wednesday, September 19, 2012 7:02:11 PM UTC-7, Aaron Meurer wrote:
Ah, that is a bug. You should report that at
http://code.google.com/p/sympy/issues/. The reason it happens is that
it tries to do the expansion recursively, but sin(-x) becomes -sin(x).
The fix is not too hard either, if you want to give it a shot.
The work around is to do the expansion with +y and then do
expr.subs(y, -y) at the end.
By the way, x - y and x + -y are exactly the same thing in SymPy.
Both are represented internally as Add(x, Mul(-1, y)).
Aaron Meurer
On Wed, Sep 19, 2012 at 7:55 PM, G B g.c.b@gmail.com javascript:
wrote:
I'm still new to sympy, so I might be doing something stupid, but I
think
there's a problem here:
In [1]: from sympy import *
In [2]: x,y=symbols('x,y')
In [3]: cos(x+y).expand(trig=True)
Out[3]: -sin(x)*sin(y) + cos(x)*cos(y)
So far so good. but then:
In [4]: cos(x-y).expand(trig=True)
Leads to a long traceback that culminates with: AttributeError: 'Mul'
object
has no attribute '_eval_expand_trig'
For giggles, I also tried:
In [5]: cos(x + (-y)).expand(trig=True)
Which fails in the same way. I can post the full traceback if it helps.
--
You received this message because you are subscribed to the Google
Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/-Z8Y7YC_PuEJ.
To post to this group, send email to sy...@googlegroups.comjavascript:.
To unsubscribe from this group, send email to
sympy+un...@googlegroups.com javascript:.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/CZlR3N-VhIAJ.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Solving Eqs with inverse-trig functions?
I agree it probably is cleaner to have the functions responsible for their own inverses, and also agree that it will require some thought to handle the ambiguities. In particular the cases where the ambiguities don't lead to a finite solution set (inverting asin, for example?). I know some CASes will return solutions with an additional parameter to handle that case. In the specific case of atan2, I think there's a short term solution in the sense that atan2(y,x) can be seen as a form of atan(y/x). Perhaps, at least temporarily, it can be treated as nested operations for the sake of inversion which saves us the headache of dealing separately with the 3 cases Joachim enumerates? On Aug 25, 2012, at 1:57 AM, Joachim Durchholz j...@durchholz.org wrote: Am 25.08.2012 06:56, schrieb Aaron Meurer: I think this is doable. We just need to extend the algorithm to handle inverses of multi-argument functions. By the way, we also should think of an API to let functions define their own inverses which would be recognized by solve(). That would be better than the dict that lives in solvers.py, line 2123. Sounds like the approach to go. The inversion API looks nontrivial to me: 1) I don't know how solve() deals with ambiguous inverses like sqrt(x) or complex logarithm. However, if we provide an inversion API, it should include information about the kind of ambiguity involved. 2) For multi-argument functions, there are multiple kinds of inverses. z = atan2 (x, y) could be inverted for x, y, or (x,y). I'm not sure how this should be dealt with, mostly because I know far too little about solve(). I guess it depends on what kinds of inverses solve() ever needs, and whether it can deal with equation systems or just single equations, and what kinds of tasks the algorithms inside solve() are suited for. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Solving Eqs with inverse-trig functions?
I'm brand new to sympy, but I've noticed that solve(Eq(y,sin(x)),x) returns [asin(y)], but solve(Eq(y,asin(x)),x) barfs. Is there a way for me to work around that? I'm running 0.7.1, python 2.7. Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/9V50C7UVgbUJ. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Solving Eqs with inverse-trig functions?
Excellent, thank you! I've pulled down the latest version from git and I'm getting the same results. Don't know how hard this is to resolve, but you might want to extend it to cover atan2 as well: solve(Eq(theta,atan(y/x)),x) == [x*tan(theta)] solve(Eq(theta,atan2(y,x)),x) == barf Should those return the same results? On Friday, August 24, 2012 7:04:30 PM UTC-7, Aaron Meurer wrote: This works in the development version, and will work in the next version (to be released some time next month): In [1]: solve(Eq(y,asin(x)),x) Out[1]: [sin(y)] Aaron Meurer On Fri, Aug 24, 2012 at 7:43 PM, G B g.c.b@gmail.com javascript: wrote: I'm brand new to sympy, but I've noticed that solve(Eq(y,sin(x)),x) returns [asin(y)], but solve(Eq(y,asin(x)),x) barfs. Is there a way for me to work around that? I'm running 0.7.1, python 2.7. Thanks-- Greg -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/9V50C7UVgbUJ. To post to this group, send email to sy...@googlegroups.comjavascript:. To unsubscribe from this group, send email to sympy+un...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups sympy group. To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/twjyNFVsneAJ. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
