2015-05-10 23 views
6

Korzystanie z najnowszej wersji (0.7.6) sympy pojawia się następujący zły wynik przy ustalaniu całkę funkcji z obsługą [0, y):Całka z funkcji odcinkowo daje błędny wynik

from sympy import * 
a,b,c,x,z = symbols("a,b,c,x,z",real = True) 
y = Symbol("y",real=True,positive=True) 
inner = Piecewise((0,(x>=y)|(x<0)|(b>c)),(a,True)) 
I = Integral(inner,(x,0,z)) 
Eq(I,I.doit()) 

http://mathurl.com/l8wrjcn.png

Jest to niepoprawne, ponieważ rzeczywisty wynik powinien zostać zamieniony na dwie ostatnie sprawy. Można to potwierdzić, sprawdzając pochodne:

Derivative(I.doit(),z).doit().simplify().subs(z,x) 

http://mathurl.com/mg4zpts.png

co zmniejsza 0 wszędzie.

Co ciekawe, gdy spada stan (b>c) zastępując inner = Piecewise((0,(x>=y)|(x<0)),(a,True)) otrzymuję TypeError:

TypeError: cannot determine truth value of 
-oo < y 

używam biblioteki nieprawidłowo lub jest to rzeczywiście poważny sympy bug?

Odpowiedz

4

Tak, sympy 0.7.6 jest w tym przypadku błędne, aw niektórych innych przypadkach. Ogólnie rzecz biorąc, nie znam żadnego symbolicznego pakietu matematycznego, któremu ufałbym, aby wykonać rachunek różniczkowy z określonymi funkcjami.

Należy zauważyć, że chociaż

inner = Piecewise((0, (x>=y)|(x<0)), (a,True)) 

rzuca TypeError w czasie integracji, logicznie równoważne definicji

inner = Piecewise((a, (x<y)&(x>=0)), (0,True)) 

prowadzi do prawidłowego wyniku

Piecewise((a*z, And(z < y, z >= 0)), (0, And(z <= 0, z >= -oo)), (a*y, True)) 

Nawiasem mówiąc, poprzedni wersja, sympy 0.7.5, obsługuje

inner = Piecewise((0, (x>=y)|(x<0)), (a,True)) 

bez TypeError, tworząc poprawny wynik (w innej formie):

Piecewise((0, z <= 0), (a*y, z >= y), (a*z, True)) 

Oto innym, prostszym przykładzie z wózkiem zachowania:

>>> Integral(Piecewise((1,(x<1)|(z<x)), (0,True)) ,(x,0,2)).doit() 
-Max(0, Min(2, Max(0, z))) + 3 

>>> Integral(Piecewise((1,(x<1)|(x>z)), (0,True)) ,(x,0,2)).doit() 
-Max(0, Min(2, Max(1, z))) + 3 

Pierwszy wynik jest niepoprawny (na przykład nie udaje się dla z = 0). Drugi jest poprawny. Jedyna różnica między dwoma wzorami to z<x vs x>z.

+0

Dzięki, że to potwierdza moje podejrzenia. Wszelki wgląd w to, dlaczego symboliczne pakiety matematyczne mają tak wiele problemów z określonymi funkcjami? Wierzyłbym, że to tylko kwestia podziału integralności i wyboru właściwych granic integracji. Czy nie powinieneś podnosić notImplementedError w funkcjach pofałdowanych, jeśli znane jest błędne zachowanie? – Lars

+0

Nie wiem symby internals. Po prostu wiem empirycznie, że CAS walczy z takimi rzeczami, na przykład [Wolfram Alpha] (http://www.wolframalpha.com/input/?i=integral+abs%28sin%28x%29%29) otrzymuje nieskończoną całość | sin x | źle. Jeśli masz dostęp do Maple lub Mathematica (obecnie nie mam), możesz porównać wyniki z ich wynikami. –

+0

W rzeczywistości wynik, który uzyskuję z wolfram alfa to znak -cos (x) (sin (x)) + c, który jest poprawnym pierwotnym (zauważ, że w określonym przypadku c musi wzrosnąć o 2 na każde pół Kropka). – Lars

Powiązane problemy