Fix the bug in evaluation of expressions with elements of the form Unevaluated[elem]

[mmatera]

This PR is a proposal to fix #122. The idea is to temporarily replace elements of the form Expression(SymbolUnevaluated, elem) by an instance of a wrapped object UnevaluatedWrapper(elem).
A larger and improved set of pytest was incorporated to test_evaluation.

[rocky]

This PR is a proposal to fix #122. The idea is to temporarily replace elements of the form Expression(SymbolUnevaluated, elem) by an instance of a wrapped object UnevaluatedWrapper(elem). A larger and improved set of pytest was incorporated to test_evaluation.

I haven't looked at this in detail, but from this high-level description I don't think this is going in the right direction.

Instead of inventing solutions, I think we should be following common practice of separating the idea of a symbol (and unbound symbol) versus a bound symbol which is a symbol along with a binding to a value.

[mmatera]

This PR is a proposal to fix #122. The idea is to temporarily replace elements of the form Expression(SymbolUnevaluated, elem) by an instance of a wrapped object UnevaluatedWrapper(elem). A larger and improved set of pytest was incorporated to test_evaluation.

I haven't looked at this in detail, but from this high-level description I don't think this is going in the right direction.

Instead of inventing solutions, I think we should be following common practice of separating the idea of a symbol (and unbound symbol) versus a bound symbol which is a symbol along with a binding to a value.

I do not see how it fits with the evaluation loop described in WR, but OK. In any case, what I tried to do here is to look for a solution that is localized in the routine that must be fixed, and again, to provide a fix to the behavior, and a set of tests that must be passed for a better, clear and canonical proposal of fixing.

[rocky]

This PR is a proposal to fix #122. The idea is to temporarily replace elements of the form Expression(SymbolUnevaluated, elem) by an instance of a wrapped object UnevaluatedWrapper(elem). A larger and improved set of pytest was incorporated to test_evaluation.

I haven't looked at this in detail, but from this high-level description I don't think this is going in the right direction.
Instead of inventing solutions, I think we should be following common practice of separating the idea of a symbol (and unbound symbol) versus a bound symbol which is a symbol along with a binding to a value.

I do not see how it fits with the evaluation loop described in WR, but OK. In any case, what I tried to do here is to look for a solution that is localized in the routine that must be fixed, and again, to provide a fix to the behavior, and a set of tests that must be passed for a better, clear and canonical proposal of fixing.

It is about how variables get values. The evaluation loop gets values from variables/symbols.

Yes, I get that the way this is working is from specific bug to specific hand-crafted solution to that bug. I tried with my Rubik's cube analogy to describe how that sometimes can lead one to astray.

Here is another: in sailing there is "line of sight navigation" where you find a landmark sail to it and then find another landmark. If all you need to do is move a short distance, this can be done okay. The polynesians worked that way for their local islands. However if you want to move great distances, you need to take a more global view.

Or if you want this explained in theory: going to the local maxima of a curve doesn't always find the maximum.

[rocky]

Are we having isort/black wars? isort should be followed by black. isort will respect black's formatting of isort'ed code. However running black and then isort, may cause isort to change the formatting when isort wants to reorder things.