> 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 someday.
Yes, we should do that, but later, when it is well tested.
> My only remark is that the vast majority of SAGE users prefer
> having the mild preparsing as a convenience. Those that don't
> certainly don't have to use it. There are numerous ways to
> turn off using the preparser, Some other remarks:
>
> (1) The preparser is essentially irrelevant to most of the SAGE
> Python library,
> since that library is implemented in 100% standard Python (and Cython),
>
> (2) If one creates a file foo.sage that contains code meant to run through
> the preparser, then run it, e.g., by typing "sage foo.sage", then a file
> foo.py is created, which contains the preparsed version of foo.sage, which
> can then safely be used as standard Python code.
I didn't know (2), in this case I think it is justified to use the
preparsing for SAGE.
> They are well known to Python programers, not to most users of
> SAGE (in my experience most first-time SAGE users have never touched
> Python before). For Sympy, on the other hand, the target audience
> is Python programmers, so again for them preparsing probably isn't
> relevant.
If SAGE could bring more people to Python, then I think a lot of
things could be justified. :)
> It is always very easy in SAGE to go from what you would type in SAGE
> to what you would type in the standard Python environment, as I mentioned
> above. Also, at the command line in SAGE you can type preparse('...') and
> the input string is preparsed and the preparsed version is displayed:
>
> sage: preparse('2^3')
> 'Integer(2)**Integer(3)'
>
> If SAGE users had to type
>
> sage: Integer(2) ** Integer(3)
>
> Just to compute 8 using SAGE integers, the experience of using SAGE would
> simply
> by far too cumbersome.
I understand the point, but I don't know how to solve it without
preparsing. In SymPy, one can use normal python ints and they are
automatically converted to SymPy Integers, like this:
In [2]: a=Rational(2)**3
In [3]: a
Out[3]: 8
In [4]: type(a)
Out[4]: <class 'sympy.core.numbers.Integer'>
But at least some part of the expression must be a SymPy instance, so
that the Python integers are converted.
> > _sympy_ could be implemented in SAGE to return SymPy expression, the
> > same way like _maxima_ works. But as I said above, the general Python
> > philosophy is not to check for int, but rather try to use it like int.
> > Thus what we do, is that we try to convert the expression to string
> > (which both Python and SAGE ints can do) and then we parse the string
> > to SymPy expression.
>
> I do not like that as the only choice. Some issues:
>
> (1) String conversions can be very slow. Already converting a number with
> just over 100000 digits in Python to a string and back takes a very long time:
>
> In [1]: a = 13 ** 100000
> In [2]: time b=eval(str(a))
> CPU times: user 5.61 s, sys: 0.04 s, total: 5.65 s
> Wall time: 8.27
> In [3]: len(str(a))
> Out[3]: 111395
>
> For comparison, converting the same SAGE integer to a Python integer
> is quite fast:
>
> In [1]: from sage.all import Integer
> In [2]: a = Integer(13) ** Integer(100000)
> In [3]: time b = int(a)
> CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
> Wall time: 0.00
> In [4]: time c = Integer(b)
> CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
> Wall time: 0.00
>
> It would be much better if you only use strings after checking for a
> _sympy_ method.
>
> (2) What about rational numbers or expressions that involve rationals? E.g.,
>
> In [11]: from sage.all import Rational
> In [12]: a = Rational( (1, 3) )
> In [13]: a
> Out[13]: 1/3
> In [14]: eval(str(a))
> Out[14]: 0
>
> Using strings and eval'ing in Sympy will result in seriously incorrect
> results, because you don't use any sort of preparsing, and SAGE prints
> the rational number 1/3 as "1/3", which is reasonable for SAGE.
> If there were the possibility of a _sympy_ method to do the convertion,
> I could implement it to return
>
> In [17]: sympy.Rational(1,3)
> Out[17]: 1/3
>
> Ahh, notice that even sympy's own rationals will break under the str --> eval
> conversion procedure.
Yes, those are relevant issues. The repr() should return a string,
that, when evaluated using eval(), will return a SymPy/SAGE expression
again. We want to create something like a Python printer, that would
do exactly that (thus returning something like Rational(1)/3).
>
> So, in fact, I would prefer that you do not have the string conversions
> at all. Best would be to raise an error and offer the user the chance
> to define _sympy_. The problem is that if a user defines some sort
> of objects that print with something like "1/3" in them, and you eval
> their string representation, a subtle bug will result.
We could definitely try _sympy_ first, that makes sence. If it fails,
I however think, that it should work, if the instance implements
__int__ or __float__. So we should try that as well. The str thing is
more like a current implementation, that just works, but I agree with
you that some more robust implementation should be done.
> In SAGE, there are cases where evaling the print representation is
> the default way to do conversions -- but we always eval after preparsing,
> so it generally works with other CAS's.
Right. Maybe the repr() could return Rational(1)/3, and str() 1/3 in
SymPy, that would solve the problem.
> A way to deal with this might be for me to create a SAGE
> parent object (SympyRing) that contains all Sympy expressions, and a
> SAGE extension
> class whose elements are a pointer to an instance of that parent object
> and a pointer to an actual sympy expression. This will, of course,
> still require the existence of an _sage_ method like you suggest above.
> It might make sense to wait on this for a while.
I would wait with this as well.
> > Or maybe, since both SAGE and SymPy should be able to parse strings,
> > the _sympy_ and _sage_ methods can just return a string, and then it
> > will get parsed. That is probably the easiest and most clean solution
> > (maybe not the fastest).
>
> 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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
