Can I use GiNaC indexed expressions?
Ryan Hinton
products, exponentiation, etc. For background, see
http://groups.google.com/group/sage-support/browse_thread/thread/e4ac1eabec630f99/81e1a71e4344b249?hl=en
I think what I want is a GiNaC indexed expression. Are these hooked
up in Pynac/Sage?
Thanks!
- Ryan
Burcin Erocal
Can you give a sample session demonstrating how you want to use indexed
expressions here?
They are not wrapped in Sage, but it is fairly easy to do this. If
you can work out the user interface, I can do the rest quickly. I don't
have time to think about a user interface however.
Cheers,
Burcin
Ryan Hinton
understand how to *use* the tool to *design the interface* to the
tool. But since I'm rarely bothered by my own ignorance, I'll charge
ahead. :-)
After writing a long, detailed email, I realized it's probably better
to start a wiki page instead. See
<http://wiki.sagemath.org/symbolics/Indexed expressions>
for my thoughts. Thanks for your help!
- Ryan
On Jul 1, 3:29 pm, Burcin Erocal <bur...@erocal.org> wrote:
> Hi Ryan,
>
> On Wed, 30 Jun 2010 14:49:59 -0700 (PDT)
>
> Ryan Hinton <iob...@email.com> wrote:
> > I was looking for a way to use Sage to do some symbolic summations,
> > products, exponentiation, etc. For background, see
>
Burcin Erocal
Ryan Hinton <iob...@email.com> wrote:
> Well, it's a little dangerous for someone (me) who doesn't really
> understand how to *use* the tool to *design the interface* to the
> tool. But since I'm rarely bothered by my own ignorance, I'll charge
> ahead. :-)
>
> After writing a long, detailed email, I realized it's probably better
> to start a wiki page instead. See
>
> <http://wiki.sagemath.org/symbolics/Indexed expressions>
>
> for my thoughts. Thanks for your help!
The wiki page is a good idea. Thanks for taking the time to write your
ideas up.
Here is a patch with the first steps to use indexed expressions:
http://sage.math.washington.edu/home/burcin/indexed_expression.patch
I used the slice notation to denote dimensions. If you have a
variable x, and you want an index with dimension 3, you write:
sage: var('i')
i
sage: x[i:3]
x.i
Dimensions are not printed, but they are there. :)
I'm afraid I don't understand what you expect sum() to do. We already
have a sum() method for symbolic expressions. Please take that into
account as well.
Note that GiNaC cannot take derivatives of indexed expressions [1].
Perhaps this is a show stopper for you.
[1] http://www.ginac.de/reference/classGiNaC_1_1indexed.html#a0c7f2f4501ee8085e29e1279ba88894a
On a completely different note... I prefer to use the brackets to access
the operands of an expression, instead of creating indexed expressions.
There has been several complaints about not being able to access the
operands lately, and I think this is the most natural way to do so.
You will see that there is already a __getitem__() method in
expression.pyx which was commented during the symbolics switch. I
suggest we uncomment that and use a different method (.indexed()?) for
the indexed expressions.
Cheers,
Burcin
Ryan Hinton
> On a completely different note... I prefer to use the brackets to access
> the operands of an expression, instead of creating indexed expressions.
> There has been several complaints about not being able to access the
> operands lately, and I think this is the most natural way to do so.
>
> You will see that there is already a __getitem__() method in
> expression.pyx which was commented during the symbolics switch. I
> suggest we uncomment that and use a different method (.indexed()?) for
> the indexed expressions.
>
> Cheers,
> Burcin
take derivatives. What I want is something like the following.
sage: var('x, d, i, n')
sage: monomial = (x[i:n] ^ d[i:n]).product() # form a product of all
the x[i]^d[i]
sage: partial = monomial.derivative(x[i])
So ``partial`` should look something like
d[i] * x[1]^d[1] * x[2]^d[2] * ... * x[i]^(d[i] - 1) * ... * x[n]^d[n]
but I don't know how this would be calculated or displayed. Of
course, then I need to weight and sum several (another symbolic
dimension) of these monomials, take derivatives of these sums, etc.
As for syntax, I think the slice syntax is clever and fairly
intuitive. I can also understand using brackets to access operands in
an expression. Personally, I think the brackets make more sense for
indexing, but they would probably see more use for operand access. It
wouldn't bother me to use an ``indexed()`` method instead. I would be
happy to review a patch to add either one.
Thanks again!
- Ryan
Robert Bradshaw
I like the slice syntax as well. I think it'd be nice to reserve the
__getitem__ notation for subscripts.
- Robert
Burcin Erocal
On Mon, 12 Jul 2010 22:52:24 -0700
Robert Bradshaw <robe...@math.washington.edu> wrote:
> > As for syntax, I think the slice syntax is clever and fairly
> > intuitive. I can also understand using brackets to access operands
> > in an expression. Personally, I think the brackets make more sense
> > for indexing, but they would probably see more use for operand
> > access. It wouldn't bother me to use an ``indexed()`` method
> > instead. I would be happy to review a patch to add either one.
>
> I like the slice syntax as well. I think it'd be nice to reserve the
> __getitem__ notation for subscripts.
We don't have to use __getitem__ to have access to the slice notation.
I suggest keeping __getitem__ to index operands of an expression and
adding an .index property, which provides __getitem__, to get indexed
expressions. For example:
sage: var('x,y,z')
(x, y, z)
sage: t = x+y+z; t
x + y + z
sage: t[0]
x
sage: t[1:]
[y, z]
sage: x.index[i:3] #indexed expression
x.i
Comments?
Cheers,
Burcin
Robert Bradshaw
I was thinking
sage: latex(x[1], x[2], x[i])
(x_1, x_2, x_i)
The index notation would be a convenient way to get many new (related)
variables, much cleaner IMHO than creating a string to pass to vars. I
think this is what Mathematica and/or Maple to as well.
I think indexing into operands by number is a bit brittle, and
x.operands()[2] is much more explicit.
- Robert
Mike Hansen
<robe...@math.washington.edu> wrote:
> I think indexing into operands by number is a bit brittle, and
> x.operands()[2] is much more explicit.
On the other hand, then you get expressions like
x.operands()[0].operands()[2].operands()[1].operands()[0]
which are a bit unwieldy especially since none of the later
.operands() tab-complete. One is more likely to need a deeper call of
operand calls the index calls.
--Mike