Opened 10 years ago

Last modified 10 years ago

#9989 closed enhancement

easier access to operands of a symbolic expression — at Version 6

Reported by: burcin Owned by: burcin
Priority: major Milestone: sage-4.7.1
Component: symbolics Keywords: sd31
Cc: jpflori Merged in:
Authors: Burcin Erocal Reviewers: Robert Bradshaw
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by burcin)

Attached patch adds an op attribute to symbolic expressions which gives easy access to its operands. We now have:

sage: x,y,z = var('x,y,z')
sage: e = x + x*y + z^y + 3*y*z; e
x*y + 3*y*z + z^y + x
sage: e.op[1]
3*y*z
sage: e.op[1,1]
z
sage: e.op[-1]
x
sage: e.op[1:]
[3*y*z, z^y, x]

Using __getitem__() directly was not an option since it breaks conversion to numpy.

Apply trac_9989-operands.take2.patch

Change History (7)

Changed 10 years ago by burcin

comment:1 Changed 10 years ago by burcin

  • Status changed from new to needs_review

comment:2 follow-up: Changed 10 years ago by kcrisman

This looks like a good addition, after many sage-support queries - great! I hope to be able to review this eventually, though it will take some time because I am not a Cython expert and would want to be very careful.

What is the property thing in Python/Cython?? I haven't heard of that before (as opposed to def or cdef or class).

Does this depend at all on any of the Pynac 0.2.1 tickets' patches?

comment:3 in reply to: ↑ 2 Changed 10 years ago by burcin

Replying to kcrisman:

What is the property thing in Python/Cython?? I haven't heard of that before (as opposed to def or cdef or class).

I also found out about it while looking through the Sage library code for a way to make numpy work when I define __getitem__():

http://docs.cython.org/src/userguide/extension_types.html#properties

The function defined by __get__() is run when you access that property. This makes the syntax look much cleaner. You don't need to put () at the end any more, compared to the syntax needed for .operands().

Does this depend at all on any of the Pynac 0.2.1 tickets' patches?

No, it should be independent. Though I admit that there are a bunch of symbolics patches before this on my queue.

comment:4 Changed 10 years ago by jpflori

  • Cc jpflori added

comment:5 follow-up: Changed 10 years ago by robertwb

  • Status changed from needs_review to needs_work

The error "TypeError?: cannot index numeric, constant or symbol" is rather obscure, better to make it something like "... has no operands."

Any reason why expr.op isn't just a plain list?

comment:6 in reply to: ↑ 5 Changed 10 years ago by burcin

  • Description modified (diff)
  • Reviewers set to Robert Bradshaw
  • Status changed from needs_work to needs_review

Replying to robertwb:

The error "TypeError?: cannot index numeric, constant or symbol" is rather obscure, better to make it something like "... has no operands."

Done. The new message is: "expressions containing only a numeric coefficient, constant or symbol have no operands"

Any reason why expr.op isn't just a plain list?

I wanted to avoid traversing the vector storing the operands and creating a python object for each. A list wouldn't allow nested indexing either:

sage: x,y,z = var('x,y,z')
sage: e = x + x*y + z^y + 3*y*z; e
x*y + 3*y*z + z^y + x
sage: e.op[1]
3*y*z
sage: e.op[1,1]
z

This syntax was proposed in a discussion at Sage days 24 last summer.

Apply trac_9989-operands.take2.patch

Note: See TracTickets for help on using tickets.