Possible bug in ODE Solver?

[Manoj Kumar]

I came across this bug(?) while trying to solve Issue 3160 , http://code.google.com/p/sympy/issues/detail?id=3160 . Let us take this sample case.

>>>from sympy import *

>>>from sympy.abc import x

>>>f = Function('f')(x)  # F is my function

>>>d = Derivative(x * f , x)  # d(x * f(x)) / dx

>>>dsolve(d , f)

which gives the output as f = c1 / x , which is completely correct.


However , if I set preprocessing as False , because by observation it is just a simple integration , by which we get x * f(x) = k

>>>dsolve(d , f , prep = False)

it gives the output as f = c1 , which doesn't satisfy the equation for all values of c1.

Is this a bug? If not , why is the user given the option to process the equation?

P.S : I got to know this by setting prep = False to solve the above mentioned issue , to solve directly integrable equations. Is this the correct way to start working on the issue?

  

[Manoj Kumar]

I know my question sound really noobish , but it would be nice if someone could help me out with this error.

[Aaron Meurer]

Your question is fine. You need to give people at least 24 hours to
answer your questions on the mailing list. Remember that we are just
volunteers, and that we probably don't live in the same time zone as
you.

Regarding your question, I don't get the same thing. dsolve(d, f) and
dsolve(d, f, prep=False) both give f(x) = C1/x for me. Perhaps this
is some bug you introduced in your branch?

Aaron Meurer

> --
> 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.
>
>

[Manoj Kumar]

Thanks for your reply.

Yes I'm pretty sure, I haven't introduced any bug in my branch, And even if I did, I work in a separate directory and I don't compile it again , I just go that directory
and do "import sympy" , so there is no possibility of my build files being rewritten.

I also downloaded a zip file from the present master branch(sympy/sympy) , extracted it, went to that directory and ran the same program. It gives me the same output.
Even classify_ode gives me the same output , it identifies it as a 'nth_linear_constant_coeff_homogeneous equation. I think this may be due to the lack of preprocessing where x * f(x) may be identified as a single function.

Ive tried to work on this issue, such that derivatives of this form are directly integrated.  

[Stefan Krastanov]

Hi,

There are a few things that I find unclear, however I do reproduce
this behavior.

First, there is no need to download any zip files (I guess you did it
as a precaution). Please just use git so we can use the commit hashes
and know about what revisions of the code we are talking.

Then, be aware that there is no building/compiling in python. It is
interpreted language (there are some unimportant detail about .pyc
caches). If you have changed the code you are using the changed
version.

Here is what I got:

>>> f = f(x)

>>> d = Derivative(x * f , x)

>>> dsolve(d , f)
C₁
f(x) = ──
x

>>> dsolve(d , f , prep = False)

f(x) = C₁

I am quite sure that this happened because `d` was constructed as an
unevaluated derivative. After

d = d.doit()

all works well.


I am not sure whether this should be considered a bug. After all sympy
permits you to construct many unevaluated objects
(Add(evaluate=False), Mul(evaluate=False), Integral, Derivative, Sum)
but does not promise to work well with them.

[Manoj Kumar]

Thanks again on your timely reply.

1. I had indeed downloaded the zip file just as a precaution.

2. On playing around with the source code , I found out that, it is because of the unevaluated derivative , that leads to a wrong output.

But in cases like the above mentioned, I guess there should be an option, by which we can directly integrate it , something like dsolve(d, f, hint = 'direct') .

It maybe inconsequential in cases like above , but in cases like

Derivative(x* f(x), x , x , x) , where it could give a solution by direct integration (without preprocessing) ,and preprocessing would give a NotImplementedError  I think it would be helpful.

This is my attempt at solving the problem, https://github.com/sympy/sympy/pull/1814 .

--
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.

--
Regards,
Manoj Kumar,
Mech Undergrad.
BPGC
Blog

[Aaron Meurer]

I don't understand what this prep flag to dsolve does (other than give
wrong results, as you've identified). This must have been something
Chris added. When is it useful to have prep=False?

Aaron Meurer

[Chris Smith]

On Sat, Feb 23, 2013 at 5:46 AM, Aaron Meurer <asme...@gmail.com> wrote:
> I don't understand what this prep flag to dsolve does (other than give
> wrong results, as you've identified). This must have been something
> Chris added. When is it useful to have prep=False?

pertinent commits are at and near ebf09bb20b2d72fe57ad3cbf8525081f0379bdcb

[Aaron Meurer]

I get the point of preprocessing, but when would you ever want
prep=False? It seems like all it is good for is internal usage (which
means it shouldn't be on dsolve, but rather on the internal
functions).

Aaron Meurer

[Chris Smith]

On Sat, Feb 23, 2013 at 6:13 AM, Aaron Meurer <asme...@gmail.com> wrote:
> I get the point of preprocessing, but when would you ever want
> prep=False? It seems like all it is good for is internal usage (which
> means it shouldn't be on dsolve, but rather on the internal
> functions).

You would want it False whenever you want dsolve to put the equation
in some sort of canonical form for identification purposes. Allowing
the user to make it True allows that preprocessing to be
skipped...sometimes you don't want your equation to be changed around.
Maybe you don't want some derivatives calculated...sorry I don't
recall all the details.

[Aaron Meurer]

Well, the docstring doesn't make it clear either. I say we remove it
from the public API.

Aaron Meurer

[Aaron Meurer]

On Sat, Feb 23, 2013 at 2:55 PM, Aaron Meurer <asme...@gmail.com> wrote:
> On Fri, Feb 22, 2013 at 5:39 PM, Chris Smith <smi...@gmail.com> wrote:
>> On Sat, Feb 23, 2013 at 6:13 AM, Aaron Meurer <asme...@gmail.com> wrote:
>>> I get the point of preprocessing, but when would you ever want
>>> prep=False? It seems like all it is good for is internal usage (which
>>> means it shouldn't be on dsolve, but rather on the internal
>>> functions).
>>
>> You would want it False whenever you want dsolve to put the equation
>> in some sort of canonical form for identification purposes. Allowing
>> the user to make it True allows that preprocessing to be
>> skipped...sometimes you don't want your equation to be changed around.
>> Maybe you don't want some derivatives calculated...sorry I don't
>> recall all the details.
>
> Well, the docstring doesn't make it clear either. I say we remove it
> from the public API.
>
> Aaron Meurer

See https://github.com/sympy/sympy/pull/1833.

[Manoj Kumar]

Shouldn't prep go from classify_ode as well?

PR : https://github.com/sympy/sympy/pull/1835

You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/kl_j_xt1ZXI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, 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.