Opened 12 years ago
Closed 6 years ago
#10034 closed enhancement (fixed)
Make evaluation possible for 'hold' objects
Reported by:  KarlDieter Crisman  Owned by:  Burcin Erocal 

Priority:  major  Milestone:  sage6.10 
Component:  symbolics  Keywords:  
Cc:  Eviatar Bach, Paul Masson  Merged in:  
Authors:  Eviatar Bach, Ralf Stephan  Reviewers:  Paul Masson 
Report Upstream:  N/A  Work issues:  
Branch:  6e4c716 (Commits, GitHub, GitLab)  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 12 years ago by
comment:2 Changed 9 years ago by
Cc:  Eviatar Bach added 

comment:3 Changed 9 years ago by
Status:  new → 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 9 years ago by
Attachment:  trac_10034.patch added 

comment:4 Changed 9 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 9 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 9 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 9 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 9 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 9 years ago by
Attachment:  trac_10034_2.patch added 

comment:9 Changed 9 years ago by
Status:  needs_review → 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 9 years ago by
Milestone:  sage5.11 → sage5.12 

comment:11 Changed 9 years ago by
Maybe this should also fix other places the hold stuff is shown, e.g. functions/trig.py.
comment:12 Changed 9 years ago by
Milestone:  sage6.1 → sage6.2 

comment:13 Changed 8 years ago by
Milestone:  sage6.2 → sage6.3 

comment:14 Changed 8 years ago by
Milestone:  sage6.3 → sage6.4 

comment:15 followup: 16 Changed 8 years ago by
Summary:  Make evaluation possible for Pynac 'hold' objects → 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 Changed 7 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 7 years ago by
Summary:  simplify_trig of f(a/b*pi) without Maxima → Make evaluation possible for Pynac 'hold' objects 

Previous title restored.
comment:18 Changed 7 years ago by
Branch:  → u/rws/make_evaluation_possible_for_pynac__hold__objects 

comment:19 Changed 7 years ago by
Authors:  → Eviatar Bach, Ralf Stephan 

Commit:  → 026ab3d85d69ccfb756302593d566f31f013e8c6 
Milestone:  sage6.4 → sage6.10 
Status:  needs_work → needs_review 
Summary:  Make evaluation possible for Pynac 'hold' objects → 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 6 years ago by
Branch:  u/rws/make_evaluation_possible_for_pynac__hold__objects → u/rws/100341 

comment:21 Changed 6 years ago by
Commit:  026ab3d85d69ccfb756302593d566f31f013e8c6 → d414b5de538f2a05d561d428702ae7ab88ca42ff 

Branch pushed to git repo; I updated commit sha1. New commits:
d414b5d  10034: increase coverage

comment:22 Changed 6 years ago by
comment:23 Changed 6 years ago by
Cc:  Paul Masson added 

comment:24 Changed 6 years ago by
Commit:  d414b5de538f2a05d561d428702ae7ab88ca42ff → 6e4c71610ff7914ccdbeb6ea23825bbd223fce91 

comment:25 Changed 6 years ago by
Right. Thanks for the review. Please add your name to Reviewers: too.
comment:26 Changed 6 years ago by
Reviewers:  → Paul Masson 

Status:  needs_review → positive_review 
comment:27 Changed 6 years ago by
Branch:  u/rws/100341 → 6e4c71610ff7914ccdbeb6ea23825bbd223fce91 

Resolution:  → fixed 
Status:  positive_review → 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.