On Nov 27, 2007 5:44 AM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 26, 2007, at 8:23 PM, William Stein wrote:
>
> >>
> >> See
> >>
> >> http://sagetrac.org/sage_trac/attachment/ticket/1189/sympy-
> >> coerce.patch
> >>
> >> This on top of 2.8.14 + sympy.patch works great. (I wasn't a
On Nov 26, 2007, at 8:23 PM, William Stein wrote:
>>
>> See
>>
>> http://sagetrac.org/sage_trac/attachment/ticket/1189/sympy-
>> coerce.patch
>>
>> This on top of 2.8.14 + sympy.patch works great. (I wasn't able to
>> cleanly apply sympy2.patch which looks like it had some useful non-
>> coercio
On Nov 26, 2007 7:51 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> On Nov 26, 2007, at 2:04 PM, Ondrej Certik wrote:
>
> >>
> >> I still think _verify_canonical_coercion_c is the wrong thing to use
> >> here, there is no reason that x._sage_() and y._sage_() should have
> >> the same parent (
On Nov 26, 2007, at 2:04 PM, Ondrej Certik wrote:
>>
>> I still think _verify_canonical_coercion_c is the wrong thing to use
>> here, there is no reason that x._sage_() and y._sage_() should have
>> the same parent (e.g. one could be an element of SR, the other a sage
>> Integer), and at this poi
> > $ apt-get install sage
> > $ python
> > Python 2.5.1 (r251:54863, Aug 17 2007, 00:51:07)
> > [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from sage.all import *
> > >>> print x**2
> >
> > And I
On Nov 26, 2007, at 1:11 PM, Ondrej Certik wrote:
>> It is wrong / abusive to call _verify_canonical_coercion_c because
>> that
>> function is never supposed to fail. You should check that the
>> parents
>> are the same explicitly and if not pass through to the next case.
>
> Agree. That's w
On Nov 26, 2007 1:11 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> exactly what I need, but fortnuately, this will improve,
> when SAGE becomes more famous, and more people like Michael Abshoff
> are going to join. I am looking forward to a time,
> when I do in Debian:
>
> $ apt-get install sage
> $ sage -ipython
> >>> import sage.all
>
> I've done this in the past several times and each time greatly sped things up.
We did it too several times already in SymPy.
> When I'm actually doing real work, research, teaching, etc. this
> hugeness is not a wart to me at least in any way at al
On Nov 26, 2007 6:34 AM, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> Well, if I had to pick a nasty point to sage I would agree that it's huge-ness
> is seriously annoying. The slow import of "sage.all" really kills the
> pleasure for writing python programs which you want to use from bash, but I
> I'm not seeing clearly what the problem is, could you please clarify
> some more. Thanks.
If you apply my first patch, you will get these segfaults:
sage -t devel/sage-main/sage/schemes/generic/spec.py sh: line
1: 2816 Segmentation fault
/home/ondrej/ext/sage-2.8.13-x86_64-Linux/local/
On Nov 26, 2007, at 10:40 AM, Ondrej Certik wrote:
> On Nov 26, 2007 7:36 PM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>> I think the code here should simply be
>>
>> 330 if PY_TYPE_CHECK(xp, type) or PY_TYPE_CHECK(yp,
>> type):
>> 331 if hasattr(
On Nov 26, 2007 7:36 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 25, 2007, at 8:15 PM, William Stein wrote:
>
> > On Nov 25, 2007 6:33 PM, David Roe <[EMAIL PROTECTED]> wrote:
> >> Addition not commuting there bothers me. I can see why it's
> >> happening: a
> >> SymPy object does
On Nov 25, 2007, at 8:15 PM, William Stein wrote:
> On Nov 25, 2007 6:33 PM, David Roe <[EMAIL PROTECTED]> wrote:
>> Addition not commuting there bothers me. I can see why it's
>> happening: a
>> SymPy object doesn't call into the coercion system. One possible
>> solution
>> is to have coer
> Well, if I had to pick a nasty point to sage I would agree that it's huge-ness
> is seriously annoying. The slow import of "sage.all" really kills the
> pleasure for writing python programs which you want to use from bash, but I
That's exactly how I want to write Python programs. And I am sure
On Mon, Nov 26, 2007 at 02:31:31PM +0100, Ondrej Certik wrote:
> > (In reality, I think that sympy and sage should simply merge. However, I
> > don't know enough about sympy to know how feasible that is. I put this in
> > parenthesis, because I fear it's kind of a demeaning thing to say. I don'
> I want results of operations with sage objects to be sage objects. This is
> the same as it is with python objects now:
> sage_int+python_int=python_int+sage_int=sage_int
> Very simply, this is because I'm a sage user not a sympy user. I think that
> the sage SymbolicExpressionRing needs to ha
On Monday 26 November 2007 07:34, Ondrej Certik wrote:
> David Roe:
> > I would prefer that direction too. In order to make that happen, the
> > SymPy __add__ function has to recognize a sage element and call its
> > __add__ method instead. This sounds like it should be doable.
>
> I am not sure
On Nov 26, 2007 5:15 AM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Nov 25, 2007 6:33 PM, David Roe <[EMAIL PROTECTED]> wrote:
> > Addition not commuting there bothers me. I can see why it's happening: a
> > SymPy object doesn't call into the coercion system. One possible solution
> > is to
> I don't think so, since probably sage/maxima have special functions
> sympy doesn't. And even if it could be, the functions provided by
> SymPy are different
> than the ones provided by SymbolicRing.
>
> If sympy('x') + x and x + sympy('x') are totally different in Sage I
> will be unhappy about
On Nov 25, 2007 6:33 PM, David Roe <[EMAIL PROTECTED]> wrote:
> Addition not commuting there bothers me. I can see why it's happening: a
> SymPy object doesn't call into the coercion system. One possible solution
> is to have coercion map sage objects into sympy, so both s+o and o+s (in
> line 1
Addition not commuting there bothers me. I can see why it's happening: a
SymPy object doesn't call into the coercion system. One possible solution
is to have coercion map sage objects into sympy, so both s+o and o+s (in
line 134 and 135 of test_sympy.py) would be SymPy objects. Is SymPy and the
21 matches
Mail list logo
