Opened 10 years ago
Closed 4 years ago
#10034 closed enhancement (fixed)
Make evaluation possible for 'hold' objects
Reported by:  kcrisman  Owned by:  burcin 

Priority:  major  Milestone:  sage6.10 
Component:  symbolics  Keywords:  
Cc:  eviatarbach, paulmasson  Merged in:  
Authors:  Eviatar Bach, Ralf Stephan  Reviewers:  Paul Masson 
Report Upstream:  N/A  Work issues:  
Branch:  6e4c716 (Commits)  Commit:  6e4c71610ff7914ccdbeb6ea23825bbd223fce91 
Dependencies:  Stopgaps: 
Description
See #9879, where it is now possible to 'hold' a symbolic expression:
sage: a = (pi/12).tan(hold=True) sage: a tan(1/12*pi)
However, without going through Maxima and a.simplify()
, it isn't clear how to get the actual answer for this. Either by changing simplify()
to try simplifying through Pynac first, or by adding something like an a.eval()
method, we should make that possible without Maxima.
Attachments (2)
Change History (29)
comment:1 Changed 10 years ago by
comment:2 Changed 7 years ago by
 Cc eviatarbach added
comment:3 Changed 7 years ago by
 Status changed from new to needs_review
Here's a patch which makes evaluation possible, simply by walking the expression and evaluating all operations. It does not work for the functions in #10071, because the .operator()
method doesn't work on them; I believe this is a separate issue for another ticket though.
Patchbot apply trac_10034.patch
Changed 7 years ago by
comment:4 Changed 7 years ago by
Glance looks good. Before I think more about this, a question  is eval
the right name for this? I know I'm the one who suggested it... but what do other eval methods do? Also, I think there are a lot of examples which use simplify
to evaluate these currently  maybe we could switch them to this (or add this, perhaps). Yes, I agree that #10071 is fine not to try to handle here  that's why I opened #10071.
comment:5 Changed 7 years ago by
The _eval_
method for symbolic functions defines what to do when the function is evaluated, and the _eval_self
method for expressions tries to do numerical evaluation. Maybe a name like unhold
would be better?
Ah right, I'll switch the examples to this. There's no reason why these expressions should be transferred to Maxima simply for evaluating an operation.
comment:6 Changed 7 years ago by
Ok.
As another remark (and you might hate me for this one), I could imagine someone wanting to evaluate some but not all of the held operations. I think this is possible with your patch and judicious use of op
and the tree, but at least adding an example of that would be helpful. Particularly in the x * x + x * x
example, though, I wonder if it wouldn't be pretty annoying to simplify this to 2 * x * x
using this. What do you think about such cases?
comment:7 Changed 7 years ago by
I've thought about this. One option is to use pattern matching to specify the parts to evaluate, but I don't how the expression could be reconstructed afterwards.
Another option is to have an argument for providing a list of operators not to evaluate (I think it's better to have an argument to exclude rather than include, because it is difficult to find all the operators in Sage, while finding ones to exclude just involves searching the expression). Then for the 2 * x * x
example you could just add operator.mul
to the excluded operators and it would work.
comment:8 Changed 7 years ago by
Okay, the new patch renames eval
to unhold
, moves the examples to use the new method, and adds an exclude
option. Excluding arithmetic operators doesn't yet work because of #14850.
Patchbot apply trac_10034_2.patch
Changed 7 years ago by
comment:9 Changed 7 years ago by
 Status changed from needs_review to needs_work
Actually, the way I implemented it is not correct, since if the length of the operands is over two it reduces the rest of the operands using the operator. This is the desired behaviour for the arithmetic operators, but not generally.
comment:10 Changed 7 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:11 Changed 7 years ago by
Maybe this should also fix other places the hold stuff is shown, e.g. functions/trig.py.
comment:12 Changed 7 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:13 Changed 6 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:14 Changed 6 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:15 followup: ↓ 16 Changed 6 years ago by
 Summary changed from Make evaluation possible for Pynac 'hold' objects to simplify_trig of f(a/b*pi) without Maxima
I don't think an eval
member is right here. The end user would expect .simplify_trig()
to work, and it does actually. The only problem the original submitter had was the Maxima overhead, so it boils down to a native implementation called from simplify_trig()
.
comment:16 in reply to: ↑ 15 Changed 5 years ago by
What I wrote:
I don't think an
eval
member is right here. The end user would expect.simplify_trig()
to work, and it does actually. The only problem the original submitter had was the Maxima overhead, so it boils down to a native implementation called fromsimplify_trig()
.
is of course nonsense. Every function that sends the held expression through Maxima unchanged would work because the hold status gets lost. The expansion happens in Pynac's (function)::eval
so is already implemented outside Maxima.
comment:17 Changed 5 years ago by
 Summary changed from simplify_trig of f(a/b*pi) without Maxima to Make evaluation possible for Pynac 'hold' objects
Previous title restored.
comment:18 Changed 5 years ago by
 Branch set to u/rws/make_evaluation_possible_for_pynac__hold__objects
comment:19 Changed 5 years ago by
 Commit set to 026ab3d85d69ccfb756302593d566f31f013e8c6
 Milestone changed from sage6.4 to sage6.10
 Status changed from needs_work to needs_review
 Summary changed from Make evaluation possible for Pynac 'hold' objects to Make evaluation possible for 'hold' objects
I used the convenient ExpressionTreeWalker
that takes care of the caveats mentioned above.
New commits:
026ab3d  10034: implement Expression.unhold()

comment:20 Changed 4 years ago by
 Branch changed from u/rws/make_evaluation_possible_for_pynac__hold__objects to u/rws/100341
comment:21 Changed 4 years ago by
 Commit changed from 026ab3d85d69ccfb756302593d566f31f013e8c6 to d414b5de538f2a05d561d428702ae7ab88ca42ff
Branch pushed to git repo; I updated commit sha1. New commits:
d414b5d  10034: increase coverage

comment:22 Changed 4 years ago by
comment:23 Changed 4 years ago by
 Cc paulmasson added
comment:24 Changed 4 years ago by
 Commit changed from d414b5de538f2a05d561d428702ae7ab88ca42ff to 6e4c71610ff7914ccdbeb6ea23825bbd223fce91
comment:25 Changed 4 years ago by
Right. Thanks for the review. Please add your name to Reviewers: too.
comment:26 Changed 4 years ago by
 Reviewers set to Paul Masson
 Status changed from needs_review to positive_review
comment:27 Changed 4 years ago by
 Branch changed from u/rws/100341 to 6e4c71610ff7914ccdbeb6ea23825bbd223fce91
 Resolution set to fixed
 Status changed from positive_review to closed
This is related to #10071, which is about functions which can't even be evaluated using Maxima or
n()
. This ticket is saying that one should be able to evaluate all held functions without using Maxima orn()
, whether or not a function currently can be evaluated in that way or not.