its commit:bfbd7711354ea4826a231e6712d34f8bb2801d44
In [8]: hint = 'nth_linear_constant_coeff_variation_of_parameters' In [9]: eq6 = f(x).diff(x, 2) - 2*f(x).diff(x) - 8*f(x) - 9*x*exp(x) - 10*exp(-x) In [10]: sol6 = Eq(f(x), -x*exp(x) - 2*exp(-x) + C1*exp(-2*x) + C2*exp(4*x)) In [11]: d6 = dsolve(eq6, f(x), hint=hint) In [12]: d6 == sol6 Out[12]: False In [13]: d6 Out[13]: -x / -5*x -3*x -3*x\ / x\ x 5*e -2*x | e e x*e | 4*x f(x) = |1/6 - -|*e - ----- + C1*e + |C2 - ----- - ----- - -------|*e \ 2/ 3 \ 3 6 2 / In [14]: sol6 Out[14]: x -x -2*x 4*x f(x) = - x*e - 2*e + C1*e + C2*e -- Andy On Thu, Aug 20, 2009 at 11:43 AM, Aaron S. Meurer<asmeu...@gmail.com> wrote: > > What is your SHA1 hash of HEAD? This test passes just fine on my > machine. Could you maybe copy eq6 from the test file and run > > dsolve(eq6, f(x), > hint='nth_linear_constant_coeff_variation_of_parameters') > > and paste the result here? > > Aaron Meurer > On Aug 20, 2009, at 9:44 AM, Andy Ray Terrel wrote: > >> >> Running tests on HEAD I get the following error: >> >> sympy/solvers/tests/ >> test_ode.py:test_nth_linear_constant_coeff_variation_of_parameters >> File "/Users/aterrel/workspace/sympy/sympy/solvers/tests/ >> test_ode.py", >> line 899, in test_nth_linear_constant_coeff_variation_of_parameters >> assert dsolve(eq6, f(x), hint=hint) == sol6 >> AssertionError >> >> tests finished: 1615 passed, 1 failed, 2 skipped, 44 xfailed, 1 >> xpassed in 333.83 seconds >> >> >> -- Andy >> >> On Thu, Aug 20, 2009 at 6:23 AM, Vinzent >> Steinberg<vinzent.steinb...@googlemail.com> wrote: >>> Thank you, this is an impressive result. :) >>> >>> 2009/8/20 Aaron S. Meurer <asmeu...@gmail.com> >>>> >>>> I have finished up my Google Summer of Code 2009 project, which >>>> was to >>>> implement various ODE solvers in SymPy. Please pull >>>> fromhttp://github.com/asmeurer/sympy/tree/odes-review >>>> . Note that I have elected to do only moderate rebasing from my >>>> original tree (branch odes), so you should really only be reviewing >>>> the HEAD. >>>> >>>> This includes the following features: >>>> >>>> - All ODE solving now happens in ode.py, instead of solvers.py where >>>> it was crowding stuff. >>>> - dsolve() remains the function to use to solve an ODE. The >>>> syntax is >>>> the same for default solving: dsolve(ode, func). >>>> For example: >>>> >>> dsolve(diff(f(x), x, 2) - 1, f(x)) >>>> f(x) == C1 + C2*x + x**2/2 >>>> >>>> dsolve() always returns an Equality instance, because it very often >>>> cannot solve for f(x) and must return an implicit solution. >>>> >>>> - The function classify_ode() was added. This function classifies >>>> ODEs into the various methods (or "hints", as I also call them) that >>>> dsolve() can use to solve them. >>>> For example: >>>> >>> classify_ode(f(x).diff(x) - 1, f(x)) >>>> ('separable', '1st_exact', '1st_linear', 'Bernoulli', >>>> '1st_homogeneous_coeff_best', >>>> '1st_homogeneous_coeff_subs_indep_div_dep', >>>> '1st_homogeneous_coeff_subs_dep_div_indep', >>>> 'nth_linear_constant_coeff_undetermined_coefficients', >>>> 'nth_linear_constant_coeff_variation_of_parameters', >>>> 'separable_Integral', '1st_exact_Integral', '1st_linear_Integral', >>>> 'Bernoulli_Integral', >>>> '1st_homogeneous_coeff_subs_indep_div_dep_Integral', >>>> '1st_homogeneous_coeff_subs_dep_div_indep_Integral', >>>> 'nth_linear_constant_coeff_variation_of_parameters_Integral') >>>> >>>> - The function deriv_degree() remains the function to use for >>>> determining the degree, or order, of an ODE. >>>> For example: >>>> >>> deriv_degree(f(x).diff(x, 5) + sin(x) + f(x).diff(x, 2), f(x)) >>>> 5 >>>> >>>> - The new function checkodesol() checks if a solution to an ODE is >>>> valid by substituting it in and either returning True if it finds 0 >>>> equivalence or the expression that it could not reduce to 0. >>>> For example: >>>> >>> checkodesol(f(x).diff(x, 2) - 1, f(x), Eq(f(x), C1 + C2*x + >>>> x**2/2)) >>>> True >>>> >>> checkodesol(f(x).diff(x, 2) - 1, f(x), Eq(f(x), C1 + C2*x + >>>> x**2)) >>>> 1 >>> >>> This is problematic, because this way >>> >>> if not checkodesol(...): >>> print 'not a solution' >>> >>> does not work, because most expressions evaluate to True. I'd prefer >>> returning just 0 instead of True, this is more consistent and useful. >>> >>>> >>>> - The function separatevars(), which I wrote to help with the 1st >>>> order separable method, attempts to intelligently separate variables >>>> an expression multiplicatively. >>>> For example: >>>> >>> separatevars(x**2 + x**2*sin(y)) >>>> x**2*(1 + sin(y)) >>>> >>> separatevars(exp(x + y)) >>>> exp(x)*exp(y) >>>> >>>> This function resides in simplify.py. >>>> >>>> - The new function homogeneous_order(), which I wrote to help with >>>> the >>>> 1st order ODE with homogeneous coefficients method, determines the >>>> homogeneous order of an expression. An expression F(x, y, ...) is >>>> homogeneous of order n if F(x*t, y*t, t*...) == t**n*F(x, y, ...). >>>> For example: >>>> >>> homogeneous_order(x**2*sqrt(x**2 + y**2) + x*y**2*sin(x/y), >>>> x, y) >>>> 3 >>>> >>>> - dsolve() will simplify arbitrary constants, and renumber them in >>>> order in the expression. You should never see something like x + >>>> 2*C1 >>>> or 1 + C2*x + C1*x**2 returned from dsolve(). You can disable >>>> this by >>>> using simplify=False in dsolve(). >>>> >>>> - Internally, the solving engine has been completely refactored. >>>> The >>>> old way was to match the ODE to various solvers in a predetermined >>>> order, and as soon as it matched one, it would solve it using that >>>> method and return a result. This had several problems with it. >>>> >>>> First, several ODEs can be solved with more than one method (c.f. >>>> the >>>> simple ODE in the classify_ode() example above), and sometimes you >>>> want to see the result from a different method. >>>> >>>> Second, sometimes the default solver would return a result that was >>>> much more complex than another one would have returned if the ODE >>>> had >>>> gotten to it. For example, it may return an implicit solution >>>> that is >>>> difficult for solve() to solve, whereas the other method would >>>> return >>>> the equation already solver. >>> >>> >>> typo >>> >>>> >>>> Another common case is that one method >>>> would set up an integral that integrate() could not do, whereas >>>> another method would set up a simpler integral. That leads to the >>>> third point. >>>> >>>> Third, whenever a solver would set up a hard integral, integrate() >>>> would either hand for a while then return an Integral, or it would >>>> hang forever. Either way, you would get an unevaluatable (by SymPy) >>>> integral, when sometimes another method might not give you that. >>>> >>>> Fourth, there was a lot of code duplicated this way. For example, >>>> whenever a method had the potential to return an implicit >>>> solution, it >>>> had to duplicate the same code chunk that tried to solve it and >>>> return >>>> a solved solution if it could be solved or else an implicit >>>> solution. >>>> >>>> The new way is for dsolve to have an optional hint argument that you >>>> can use to specify whatever method you want to use, if it fits. >>>> dsolve() calls classify_ode() on the ODE and gets all of the >>>> possible >>>> hints. By default, hint="default" is used, which uses a >>>> predetermined >>>> order, much like the old way. But you can easily use something like >>>> hint="1st_exact" to change the hint from the default method to the >>>> 1st >>>> order exact ODE solver. Aside from "default", there are also some >>>> other 'meta-hints' that you can use. "all" will return a dictionary >>>> of hint: solution terms for all matching hints. "best" will use a >>>> heuristic to return the simplest of all possible solutions. This >>>> heuristic is based on whether the solution has unevaluated Integrals >>>> in it, whether it can be solved explicitly, and finally, just which >>>> one is the shortest. All hints that set up integrals also have a >>>> coresponding "hint_Integral" hint, which will not attempt to >>>> evaluate >>>> the integrals but instead return unevaluated Integrals in the >>>> solution. "all_Integral" acts like "all", but it skips hints that >>>> attempt to evaluate integrals. This is so you can quickly get an >>>> unevaluated integral of something you know SymPy cannot do, >>>> instead of >>>> letting integrate() hang. It also lets you discover how the solvers >>>> work by showing you what integrals they do. >>>> >>>> - Along with extensive documentation on all of the functions, I have >>>> included a guide in the module docstring on how to add more >>>> methods to >>>> the module using the hints system. It can give you an idea of how >>>> the >>>> system works internally. >>>> >>>> >>>> The following ODE solving methods have been implemented. See the >>>> internal docstrings for more information on each method: >>>> - 1st order separable differential equations >>>> - 1st order differential equations whose coefficients or dx and dy >>>> are functions homogeneous of the same order. >>>> - 1st order exact differential equations. >>>> - 1st order linear differential equations. (this is already >>>> implemented in the current SymPy) >>>> - 1st order Bernoulli differential equations. (this is already >>>> implemented in the current SymPy by a patch I sent in in the spring) >>>> - 2nd order Liouville differential equations. >>>> - nth order linear homogeneous differential equation with constant >>>> coefficients. >>>> - nth order linear inhomogeneous differential equation with constant >>>> coefficients using the method of undetermined coefficients. >>>> - nth order linear inhomogeneous differential equation with constant >>>> coefficients using the method of variation of parameters. >>>> >>>> In addition to the ode module, this branch includes fixes to the >>>> following issues, which were necessary for me throughout my work: >>>> - Issues 1582, 1566, 1530, and 1429 (the first part only). >>>> - Integral.__getnewargs__ now properly works. If r is an Integral >>>> instance, then r == r.new(r.__getnewargs__(r.args)) should always be >>>> True. >>>> - Changed two assertions and one raise TypeError in solve() to raise >>>> NotImplementedError. This way, you do not have to check for >>>> AssertionError or TypeError to see if solve() has failed, only >>>> NotImplementedError. See issues 1425 and 1338. >>> >>> I'll have to play around with this. :) >>> >>> Vinzent >>> >>>> >>> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patches@googlegroups.com To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en -~----------~----~----~----~------~----~------~--~---