make it possible to generate sequences of variables easily

[kcrisman]

People are always asking how to get sequences of variables, like a1,a2,a3,a4 or the like. See this ask.sagemath.org question, for example.

Jason Grout has an interesting possible solution that should find a home somewhere in Sage
(see sage-support discussion).

class VariableGenerator(object):
     def __init__(self, prefix):
         self.__prefix = prefix
     @cached_method
     def __getitem__(self, key):
         return SR.var("%s%s"%(self.__prefix,key))

Now just specify a prefix, and then you can index to your heart's
content to generate variables.

a = VariableGenerator('a') # some people may like 'a_' as the prefix
a[0], a[1], a[2] # all variables

Of course, this can easily be extended to using function call syntax:
a(0), or to using multiple indices: a[1,3]. Indeed, you can let your
imagination run wild and even do things like return full symbolic
matrices or vectors with slices: a[0:5, 0:5].

Apply attachment: trac_11576-indexed_expression.patch

CC: @jasongrout @gvol @orlitzky @eviatarbach @slel

Component: symbolics

Keywords: Cernay2012

Issue created by migration from https://trac.sagemath.org/ticket/11576

[burcin]

comment:1

GiNaC already has indexed expressions. We should try to use what is there instead of coming up with a pure python solution ourselves. This was discussed on sage-devel a while ago, I even put up an experimental patch for it:

http://groups.google.com/group/sage-devel/browse_thread/thread/69ab50fe11672111

[kcrisman]

comment:2

Thanks, Burcin! I must have missed this somehow.

Here is a link to the patch.

From that thread:

Note that GiNaC cannot take derivatives of indexed expressions. 

So that means one couldn't say that diff(a[1],a[1])==1? That would seem to be unfortunate.

By the way, note that Jason was just trying to find a way to make lots of GiNaC variables. I don't think that these approaches are necessarily that different - for instance, a class like Jason's for non-indexed, but still many, variables of similar names, would, be, useful. , , ,

[burcin]

comment:3

Replying to @kcrisman:

From that thread:

Note that GiNaC cannot take derivatives of indexed expressions. 

So that means one couldn't say that diff(a[1],a[1])==1? That would seem to be unfortunate.

I don't have time to test this right now, but if it really doesn't work, we could fix it or ask the GiNaC developers why they chose to omit this.

By the way, note that Jason was just trying to find a way to make lots of GiNaC variables. I don't think that these approaches are necessarily that different - for instance, a class like Jason's for non-indexed, but still many, variables of similar names, would, be, useful. , , ,

It would be useful to extend the var() syntax to support creating variables like 'a1, a2, ..., a10'. We should keep in mind the signature of other constructors like PolynomialRing() if we attempt this.

If we go further and try to support vectors and matrices with symbolic entries, it would be better to use the underlying GiNaC functionality. There is an example at the end of this page:

http://www.ginac.de/tutorial/Indexed-objects.html

If you can propose a basic user interface, I'd be happy to help with at least the first steps of interfacing C++.

[nbruin]

comment:4

Perhaps another motivation for using GiNaC functionality for this is that the alternative approach leaks. Watch the memory usage of

sage: for i in range(10^8):
....:    l=1+SR.symbol("a%s"%str(i))

Perhaps GiNaCs indexed variables are less prone to leaking?

[hivert]

Attachment: indexed_expression-experimental-fh.patch.gz

[hivert]

comment:6

Hi there,

As as said on sage-devel, I started to work on Burcin patch. My goal was to be
able to index a variable by any Sage object (eg: integers, group
element, matrices...). 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
on a fresh Sage-4.7.2 install. Then I can

sage: m1 = matrix([1,2]); m1.set_immutable()
sage: m2 = matrix([2,1]); m2.set_immutable()
sage: a = x.ind[m1]; b = 2*x.ind[m2]
sage: a + a
2*x.[1 2]
sage: a + b
x.[1 2] + 2*x.[2 1]

which is, in my view very cool !

However strange thing has occurred under the hood, in particular for a strange
reason I don't understand Sage added the two matrices ! This is apparent in

sage: a = x.ind[Permutation([3,2,1])]; b = 2*x.ind[1]
sage: a+b
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/data/Sage-Install/sage-4.7.2/devel/sage-review/sage/symbolic/<ipython console> in <module>()

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__add__ (sage/structure/element.c:11488)()

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression._add_ (sage/symbolic/expression.cpp:11082)()
   2186                            relational_operator(_right._gobj))
   2187         else:
-> 2188             x = gadd(left._gobj, _right._gobj)
   2189         return new_Expression_from_GEx(left._parent, x)
   2190 

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__sub__ (sage/structure/element.c:11816)()

/home/florent/src/Sage/sage/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/coerce.c:7489)()

TypeError: unsupported operand parent(s) for '-': '<class 'sage.combinat.permutation.Permutation_class'>' and 'Integer Ring'

To make thing crystal clear (I hope):

sage: class bla(SageObject):
...       def __add__(self, other):
...           print "Addition called"
sage: a, b = x.ind[m1],2*x.ind[m2]
sage: m1 = bla()
sage: m2 = bla()
sage: m1 + m2
Addition called
sage: m1*m2
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/data/Sage-Install/sage-4.7.2/devel/sage-review/sage/symbolic/<ipython console> in <module>()

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

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 ?

Any help greatly appreciated !

Cheers,

Florent

PS: crosspost on sage-devel.

[burcin]

Changed keywords from none to Cernay2012

[orlitzky]

comment:9

Allow me to throw my entry into the ring.

It's not nearly as ambitious as Burcin & Florent's patches, but it does scratch the itch that most people have, and it's working and tested already.

[kcrisman]

comment:10

I like a lot of it. Obviously needs tests in the new class. A few questions, which may betray ignorance:

• Is it okay that we don't overwrite the global variables? I like that in principle, but there is similar confusion at times with PolynomialRings that have an x which isn't in SR while sage: x still returns the symbolic x. Just asking.
• One thing I don't like, or need explanation for, is the confusion in multi-index situations between the string (not LaTeX) reps of x_{1}_{1} and x_{11}, which are apparently both x11. It's almost too flexible, because you don't have to say how many indices there will be ahead of time - which is useful, of course, but there might have to be something with the reps.
• Should SymbolSequence inherit from something?

[orlitzky]

Add tests for the individual class methods