I'm currently running into problems with imports.
Problem 1: Relative imports don't work in 2.6.
"from .module import blah" works, but "from ..module import blah" does not.
That's really a pity, I'd be all for doing all imports in a relative
fashion, but if 2.6 doesn't support it, I'd suggest g
Yes, erfinv
http://docs.sympy.org/dev/modules/functions/special.html#sympy.functions.special.error_functions.erfinv
On Sun, Oct 6, 2013 at 10:54 PM, Aaron Meurer wrote:
>
> On Oct 6, 2013, at 10:13 PM, Matthew Rocklin wrote:
>
> This fails in solve
>
> In [1]: from sympy.stats import *
>
> In
On Sun, Oct 6, 2013 at 9:31 PM, Aaron Meurer wrote:
> You can get similar speeds in regular SymPy. For me
>
> In [59]: R, x, y, z, w = ring("x,y,z,w", ZZ, lex)
>
> In [60]: %timeit (x + y + z + w)**60
> 1 loops, best of 3: 414 ms per loop
>
> in pycsympy the fastest time was 405 ms.
But be carefu
I guess solve() uses the inverse method, like
In [14]: tan(x).inverse()
Out[14]: sympy.functions.elementary.trigonometric.atan
So we just need to define that for erf and erfinv.
Aaron Meurer
On Mon, Oct 7, 2013 at 11:36 AM, Matthew Rocklin wrote:
> Yes, erfinv
>
> http://docs.sympy.org/dev/mo
On Sat, Oct 5, 2013 at 5:03 AM, Joachim Durchholz wrote:
> Am 04.10.2013 19:37, schrieb Ondřej Čertík:
>
>> On Thu, Oct 3, 2013 at 12:40 PM, Joachim Durchholz
>> wrote:
>>>
>>> Am 03.10.2013 17:04, schrieb Ondřej Čertík:
On Thu, Oct 3, 2013 at 1:50 AM, Joachim Durchholz
wrote
On Mon, Oct 7, 2013 at 11:42 AM, Ondřej Čertík wrote:
> On Sun, Oct 6, 2013 at 9:31 PM, Aaron Meurer wrote:
>> You can get similar speeds in regular SymPy. For me
>>
>> In [59]: R, x, y, z, w = ring("x,y,z,w", ZZ, lex)
>>
>> In [60]: %timeit (x + y + z + w)**60
>> 1 loops, best of 3: 414 ms per l
I just had a look at the Julia project http://julialang.org/
Have a look at how they manage operator overloading:
https://github.com/JuliaLang/julia/blob/master/examples/quaternion.jl
That is a great idea, it would keep code clear and readable, and avoid the
need of all those *if isinstance( )
I just had a look at the Julia project http://julialang.org/
Have a look at how they manage operator overloading:
https://github.com/JuliaLang/julia/blob/master/examples/quaternion.jl
That is a great idea, it would keep code clear and readable, and avoid the
need of all those *if isinstance( )
On Mon, Oct 7, 2013 at 12:07 PM, F. B. wrote:
> I just had a look at the Julia project http://julialang.org/
>
> Have a look at how they manage operator overloading:
>
> https://github.com/JuliaLang/julia/blob/master/examples/quaternion.jl
>
> That is a great idea, it would keep code clear and rea
On Mon, Oct 7, 2013 at 12:05 PM, Aaron Meurer wrote:
> On Mon, Oct 7, 2013 at 11:42 AM, Ondřej Čertík
> wrote:
>> On Sun, Oct 6, 2013 at 9:31 PM, Aaron Meurer wrote:
>>> You can get similar speeds in regular SymPy. For me
>>>
>>> In [59]: R, x, y, z, w = ring("x,y,z,w", ZZ, lex)
>>>
>>> In [60]
Am 07.10.2013 20:07, schrieb F. B.:
I just had a look at the Julia project http://julialang.org/
Have a look at how they manage operator overloading:
I just did and shuddered.
Unrestrained multple dispatch runs into modularity issues. It's one of
those mistakes that language designers make ov
On Monday, October 7, 2013 8:28:04 PM UTC+2, Joachim Durchholz wrote:
>
> Am 07.10.2013 20:07, schrieb F. B.:
> > I just had a look at the Julia project http://julialang.org/
> >
> > Have a look at how they manage operator overloading:
>
> I just did and shuddered.
> Unrestrained multple dis
Am 07.10.2013 21:06, schrieb F. B.:
On Monday, October 7, 2013 8:28:04 PM UTC+2, Joachim Durchholz wrote:
Am 07.10.2013 20:07, schrieb F. B.:
I just had a look at the Julia project http://julialang.org/
Have a look at how they manage operator overloading:
I just did and shuddered.
Unrestr
On Mon, Oct 7, 2013 at 2:09 PM, Joachim Durchholz wrote:
> Am 07.10.2013 21:06, schrieb F. B.:
>>
>>
>>
>> On Monday, October 7, 2013 8:28:04 PM UTC+2, Joachim Durchholz wrote:
>>>
>>>
>>> Am 07.10.2013 20:07, schrieb F. B.:
I just had a look at the Julia project http://julialang.org/
>>
Hello Aaron,
thanks for the info, in the meantime I found another way of dealing with
this expression. Not completely satisfied yet, but I am still sifting
through the sympy docs. Will try your other suggestions as well.
Cheers,
Francesco.
On 4 October 2013 04:23, Aaron Meurer wrote:
> I t
On Mon, Oct 7, 2013 at 11:33 AM, Joachim Durchholz wrote:
> I'm currently running into problems with imports.
>
> Problem 1: Relative imports don't work in 2.6.
> "from .module import blah" works, but "from ..module import blah" does not.
Really? I don't see any mention of this in the docs.
I di
> The code says that is supports simple clause learning, but it seems to
> always be disabled by default. Do you know why that is?
>
There are many forms of clause learning. The current implementation of
clause learning adds nothing to the solving power as the backtracking is
done in such a way
Can anyone give me a pointer as to what environment interactive traversal
(from iterables) works best in? I tried under a cmd window in Windows from
IPython and from an isympy session and although I see various codes
interspersed with the output, I don't get anything that is useful. And any
doc
Those are ANSI colors. It tries to color the expression in terminals
that support it. It should probably disable this in those that don't
(there is already code in the test framework to check for this).
By the way, it looks like this function wasn't updated for Python 3:
it still uses raw_input.
Am 08.10.2013 00:37, schrieb Aaron Meurer:
On Mon, Oct 7, 2013 at 11:33 AM, Joachim Durchholz wrote:
I'm currently running into problems with imports.
Problem 1: Relative imports don't work in 2.6.
"from .module import blah" works, but "from ..module import blah" does not.
Really? I don't se
On Mon, Oct 7, 2013 at 7:35 PM, Joachim Durchholz wrote:
> Am 08.10.2013 00:37, schrieb Aaron Meurer:
>
>> On Mon, Oct 7, 2013 at 11:33 AM, Joachim Durchholz
>> wrote:
>>>
>>> I'm currently running into problems with imports.
>>>
>>> Problem 1: Relative imports don't work in 2.6.
>>> "from .modul
Hi.
I want to generate some C code that evaluates a discontinuous, symbolic,
function for a given set of arguments. codegen works great, except for the
discontinuous bit. I tried defining the function as a Piecewise, but no
luck. Is there a better way to do this? Is this an easy fix? The best
Hi Nathan,
On Mon, Oct 7, 2013 at 8:47 PM, Nathan Woods wrote:
> Hi.
>
> I want to generate some C code that evaluates a discontinuous, symbolic,
> function for a given set of arguments. codegen works great, except for the
Can you post the function that you are trying to convert to a C code?
>
The sympy function (the output of printing the expression) is:
"t*x*y + x**2 + y**2 + Piecewise((0, x < 0.5), (1, x >= 0.5)) + cos(t) - 1"
The error message is:
TypeError: unsupported operand type(s) for |=: 'set' and 'Piecewise'
The whole error output is:
Traceback (most recent call last):
Nathan,
On Mon, Oct 7, 2013 at 10:52 PM, Nathan Woods wrote:
> The sympy function (the output of printing the expression) is:
> "t*x*y + x**2 + y**2 + Piecewise((0, x < 0.5), (1, x >= 0.5)) + cos(t) - 1"
>
> The error message is:
>
> TypeError: unsupported operand type(s) for |=: 'set' and 'Piece
/sympy/tensor/index_methods.pyc
I have never worked on this file. The real tensor module is
/sympy/tensor/tensor.py, the other files in that directory are tools for
code generation (I think), which are able to handle indexed data, but I
never used them.
On Tuesday, October 8, 2013 8:20:31 AM U
26 matches
Mail list logo
