59 views

Skip to first unread message

Jun 30, 2010, 5:49:59 PM6/30/10

to sage-devel

I was looking for a way to use Sage to do some symbolic summations,

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

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

Jul 1, 2010, 5:29:29 PM7/1/10

to sage-...@googlegroups.com

Hi Ryan,

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

Jul 2, 2010, 12:21:25 PM7/2/10

to sage-devel

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!

- 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

>

> >http://groups.google.com/group/sage-support/browse_thread/thread/e4ac...

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

>

Jul 2, 2010, 6:25:41 PM7/2/10

to sage-...@googlegroups.com

On Fri, 2 Jul 2010 09:21:25 -0700 (PDT)

Ryan Hinton <iob...@email.com> wrote:

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

Jul 6, 2010, 10:41:30 AM7/6/10

to sage-devel

>

> 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

Thank you very much for your work. Your guess is correct: I need to
> 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

Jul 13, 2010, 1:52:24 AM7/13/10

to sage-...@googlegroups.com

I like the slice syntax as well. I think it'd be nice to reserve the

__getitem__ notation for subscripts.

- Robert

Jul 13, 2010, 3:37:12 AM7/13/10

to sage-...@googlegroups.com

Hi Robert,

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

Jul 13, 2010, 12:05:06 PM7/13/10

to sage-...@googlegroups.com

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

Jul 13, 2010, 2:06:57 PM7/13/10

to sage-...@googlegroups.com

On Tue, Jul 13, 2010 at 9:05 AM, Robert Bradshaw

<robe...@math.washington.edu> wrote:

> I think indexing into operands by number is a bit brittle, and

> x.operands()[2] is much more explicit.

<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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu