Re: [sage-devel] Indexed expressions again...

12 views
Skip to first unread message

Burcin Erocal

unread,
Nov 24, 2011, 6:06:03 PM11/24/11
to sage-...@googlegroups.com, pynac...@googlegroups.com
Hi Florent,

On Thu, 24 Nov 2011 22:20:26 +0100
Florent Hivert <Florent...@lri.fr> wrote:

> I'm working on #11576 "make it possible to generate sequences of
> variables easily". I actually need to achieve a larger goal: I need
> to have symbolic variables indexed by any Sage objects (eg: integers,
> group element, matrices...). As as said previously here, I started to
> work on Burcin patch. So I extended a little Burcin patch. Now I'm
> faced with the problem that GiNaC indexed variable seems to have a
> not trivial semantic that I don't understand at all. Moreover I don't
> know how to debug Cython / C++ code so I'm quite stuck. Here is the
> problem I have:
>
> To get it you should apply
> attachment:indexed_expression-experimental-fh.patch from #11576 on a
> fresh Sage-4.7.2 install. Then I can

Your changes seem to be based on an older version of my patch. The latest version was here:

http://sage.math.washington.edu/home/burcin/indexed_expression_20111118.patch

I used a dummy symbolic variable as the dimension when it's not
specified. This doesn't make any difference though.

> To make thing crystal clear (I hope):
>
> sage: class bla(SageObject):
> ... def __add__(self, other):
> ... print "Addition called"
<snip>

Your example was trying to multiply two instances of the class bla.
Here is what I guess you meant to write:

sage: m1 = bla()
sage: m2 = bla()
sage: a, b = x.ind[m1],2*x.ind[m2]
Traceback (most recent call last)
<snip>
in sage.symbolic.expression.Expression._add_
(sage/symbolic/expression.cpp:11082)()

TypeError: unsupported operand type(s) for -: 'bla' and 'bla'


Note that it is trying to subtract the objects. Probably trying to
check equality. :)

> WTF ! Why is it adding or multiplying my indices for nothing ! It is
> a problem of Ginac ? of the wrapper ? or behind the chair and the
> screen ?

Here is the backtrace:

Breakpoint 2, GiNaC::numeric::sub (this=0x7fffffffb4a0, other=...)
at numeric.cpp:1745
1745 {
(gdb) call this->dbgprint()
<class '__main__.bla'>
(gdb) call other.dbgprint()
<class '__main__.bla'>
(gdb) bt
#0 GiNaC::numeric::sub (this=0x7fffffffb4a0, other=...) at numeric.cpp:1745
#1 0x00007fffd687c599 in GiNaC::operator- (lh=<value optimized out>,
rh=<value optimized out>) at operators.cpp:97
#2 0x00007fffd6879226 in GiNaC::numeric::compare_same_type (this=0x4796060,
other=...) at numeric.cpp:1700
#3 0x00007fffd67ca25a in compare (this=0x3d9cd10, other=...) at ex.h:339
#4 GiNaC::idx::compare_same_type (this=0x3d9cd10, other=...) at idx.cpp:278
#5 0x00007fffd6ce0aad in compare (this=<value optimized out>,
other=<value optimized out>)
at /home/burcin/sage/sage-4.7.2/local/include/pynac/ex.h:339
#6 GiNaC::container<std::vector>::compare_same_type (
this=<value optimized out>, other=<value optimized out>)
at /home/burcin/sage/sage-4.7.2/local/include/pynac/container.h:625
#7 0x00007fffd67b5f5e in compare (this=0x45508e0, lh=<value optimized out>,
rh=...) at ex.h:339
#8 GiNaC::expairseq::construct_from_2_ex (this=0x45508e0,
lh=<value optimized out>, rh=...) at expairseq.cpp:887
#9 0x00007fffd6771beb in GiNaC::add::add (this=0x45508e0, lh=..., rh=...)
at add.cpp:70
#10 0x00007fffd687c46c in exadd (lh=..., rh=...) at operators.cpp:42
#11 GiNaC::operator+ (lh=..., rh=...) at operators.cpp:69
#12 0x00007fffd644e489 in
__pyx_f_4sage_8symbolic_10expression_10Expression__add_
(__pyx_v_left=0x4757050, __pyx_v_right=0x4757d40,


In English: it tries to normalize the resulting expression in construct_from_2_ex(). This means checking if the two arguments are equal. Going through idx::compare_same type(), it ends up in numeric::compare_same_type(). Here is the code for that function:

int numeric::compare_same_type(const basic &other) const
{
GINAC_ASSERT(is_exactly_a<numeric>(other));
const numeric &o = static_cast<const numeric &>(other);
int cmpval = (real() - o.real()).csgn();
if (cmpval != 0)
return cmpval;
return (imag() - o.imag()).csgn();
}

We should change this somehow. Maybe we could try PyObject_Compare and fall back to this if it fails.

Comments?

Cheers,
Burcin

Burcin Erocal

unread,
Dec 2, 2011, 8:42:13 AM12/2/11
to sage-...@googlegroups.com, pynac...@googlegroups.com
Hi Jean-Pierre,

thanks a lot for looking into this.

On Sat, 26 Nov 2011 13:13:49 -0800 (PST)
Jean-Pierre Flori <jpf...@gmail.com> wrote:

> By the way:
> - I used Burcin's patch, somehow I could not use Florent's one
> - The patch is based on pynac-0.2.2, but applies on 0.2.3
> Here is the output of the patch version
> sage: class bla(SageObject):
> ....: def __add__(self, other):
> ....: print "Add"
> ....:


> sage: m1 = bla()
> sage: m2 = bla()

> sage: a = x.ind[m1]
> sage: b = x.ind[m2]
> sage: a+b
> x.<class '__main__.bla'> + x.<class '__main__.bla'>
> sage: a+a
> 2*x.<class '__main__.bla'>

Your patch for pynac works great here. Starting from plain Sage-4.7.2
and pynac-0.2.3, doctesting the usual suspects
(sage/{symbolic,calculus,functions}) shows only a couple of printing
differences. Considering this change within the context of #9880, they
are mostly harmless. :)

I merged your patch in my pynac queue [1]. We'll have to sort out the
headers once #9880 is done and we're making the pynac release.


[1] https://bitbucket.org/burcin/pynac-patches/src


Florent, shall we create a temporary pynac spkg so you can carry on
with your work on indexed expressions?


Cheers,
Burcin

Reply all
Reply to author
Forward
0 new messages