Issue 3253 in sympy: Test failure in geometry

2012-05-01 Thread sympy
Status: Valid Owner: Labels: Type-Defect Priority-Medium Geometry New issue 3253 by julien.r...@gmail.com: Test failure in geometry http://code.google.com/p/sympy/issues/detail?id=3253 There's a test failure in master with this specific random seed: 95778648 It occurs with 32- and 64-bit

Re: Issue 3253 in sympy: Test failure in geometry

2012-05-01 Thread sympy
Updates: Labels: -Priority-Medium Priority-Critical Comment #1 on issue 3253 by asmeu...@gmail.com: Test failure in geometry http://code.google.com/p/sympy/issues/detail?id=3253 (No comment was entered for this change.) -- You received this message because you are subscribed to the

Re: Issue 3249 in sympy: Difficulty with integrate(exp(I*x)/(1 + x**2), (x, -oo, oo))

2012-05-01 Thread sympy
Comment #6 on issue 3249 by ness...@gmail.com: Difficulty with integrate(exp(I*x)/(1 + x**2), (x, -oo, oo)) http://code.google.com/p/sympy/issues/detail?id=3249 Pull request: https://github.com/sympy/sympy/pull/1274 -- You received this message because you are subscribed to the Google

Re: Issue 2664 in sympy: sign(x) should reduce to x/abs(x) when x is known to not be 0

2012-05-01 Thread sympy
Updates: Status: Fixed Comment #4 on issue 2664 by smi...@gmail.com: sign(x) should reduce to x/abs(x) when x is known to not be 0 http://code.google.com/p/sympy/issues/detail?id=2664 Now, conjugate(x).diff(x) Derivative(conjugate(x), x) sign(1 + I) sign(1 + I) _.doit()

Re: Issue 2664 in sympy: sign(x) should reduce to x/abs(x) when x is known to not be 0

2012-05-01 Thread sympy
Updates: Owner: julien.r...@gmail.com Cc: asmeu...@gmail.com Comment #5 on issue 2664 by julien.r...@gmail.com: sign(x) should reduce to x/abs(x) when x is known to not be 0 http://code.google.com/p/sympy/issues/detail?id=2664 One could have sign(1 + I) reduce automatically

Re: Issue 2662 in sympy: conjugate(x).diff(x) is wrong

2012-05-01 Thread sympy
Updates: Status: Fixed Comment #5 on issue 2662 by smi...@gmail.com: conjugate(x).diff(x) is wrong http://code.google.com/p/sympy/issues/detail?id=2662 Now we have conjugate(x).diff(x) Derivative(conjugate(x), x) which, though not the same as above, is not wrong. So I will close

[sympy] writing lambda

2012-05-01 Thread smichr
I'm trying to wrap an expression into a lambda and notice that the dummy variable of the lambda doesn't match with the variable of the expression. Am I doing this right? Here, the lambda's i is not the same as the i in the expression I send: def f(fi): ... return lambda i: fi ... f(i+1)(1) i

Re: [sympy] Re: recursice call to cse and symbols

2012-05-01 Thread smichr
On Tuesday, May 1, 2012 1:03:37 AM UTC+5:45, Aaron Meurer wrote: Based on Chris's previous examples, it looks like you can just create a numbered_symbols generator from the start and pass that in each time. Because it is a generator, it will keep track of the symbols count as long as you

[sympy] mathematica to sympy

2012-05-01 Thread Comer Duncan
I have a set of Mathematica functions that I would like to translate to sympy. I see the parsing.mathematica method and wonder what the community thinks of the task of generalizing it to handle the conversion of Mathematica modules to sympy? As the parser stands now it seems to handle the

Re: [sympy] mathematica to sympy

2012-05-01 Thread krastanov.ste...@gmail.com
I doubt that any automated translation will produce quality code. The style of Mathematica code is much more functional than the object oriented python style. What you get from automatic translation will not be human-readable (it will be python but very obfuscated). So I am very pessimistic.

Re: [sympy] mathematica to sympy

2012-05-01 Thread Aaron Meurer
This probably is doable, but we would need an actual parser in SymPy, which is the difficult part. If we had that, adding rules for Mathematica functions would ideally not be hard. See https://github.com/sympy/sympy/wiki/parsing for some ideas on parsing. More realistically, in