> > I would like to avoid this if possible.
>
> OK, _sage_ and _sympy_ methods are fine with me. We'll try to
> implement that soon.
>
> Ondrej
OK, excellent. Let me know when you do, so I can add support
for them to some key SAGE classes (e.g., rational numbers, univariate
polynomials, etc.)
W
> SAGE uses mpfr for arbitrary precision reals and GMP for arbitrary
> precision integers and rationals. This is -- of course -- not the way
> to go for sympy, because of its design goals. Perhaps whatever
> you're doing with arbitrary precision reals might make it back into
> standard Python so
On 8/11/07, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> This is already fixed in the svn for some time, see the relevant issue
> for details:
>
> http://code.google.com/p/sympy/issues/detail?id=247
>
> when we release the 0.5.0 soon, it will be included.
>
> Note: all released versions use the ol
I think SymPy is going to be useful when a good geometry module is
released, and hopefully a trigonometry module will also come out. Once
that happens it won't take much to meet the needs of all high school
math classes since we already have really good symbolic support that
includes functions use
> (expecting 1/3 and 8 respectively), then I will not be able to run it
> in Python and thus will get stuck in SAGE environment, which is (I
> think) bad.
Just a clarification since I didn't write it clearly: I think the SAGE
environment is great, but getting stuck in any environment is
something
> -
> sage: from sympy import *
> sage: x = Symbol(1)
> sage: x + 1
> ---
> Traceback (most recent call last)
>
> /home/was/s/spkg/standard/ in ()
>
> /home/was/s/local/lib/python2.5/site-packages/sympy
