Make evaluation possible for 'hold' objects

[kcrisman]

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.

CC: @eviatarbach @paulmasson

Component: symbolics

Author: Eviatar Bach, Ralf Stephan

Branch/Commit: 6e4c716

Reviewer: Paul Masson

Issue created by migration from https://trac.sagemath.org/ticket/10034

[kcrisman]

comment:1

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 or n(), whether or not a function currently can be evaluated in that way or not.

[eviatarbach]

comment:3

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

[eviatarbach]

Attachment: trac_10034.patch.gz

[kcrisman]

comment:4

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.

[eviatarbach]

comment:5

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.

[kcrisman]

comment:6

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?

[eviatarbach]

comment:7

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.

[eviatarbach]

comment:8

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

[eviatarbach]

Attachment: trac_10034_2.patch.gz