Skip to main content

programming - How is LHS = RHS; ... ; LHS (nontrivially) different from ... ; RHS


I'm trying to understand how Mathematica thinks about the results of Set. Suppose we perform LHS = RHS. I'm focusing on when Mathematica considers LHS to be fully evaluated and when it decides to evaluate LHS again later.


Discussion and Examples


Suppose I do the following:


(* First example *)

ClearAll[ LHS, f, F ];
LHS = f[x]; (* f[x] *)
f[x_] := F[x]
LHS
(* F[x] *)

This is what I would have expected to happen -- LHS is re-evaluated at the end.


Now, the following works a bit differently:


(* Second example *)
ClearAll[LHS, f, F, changeQ];


changeQ[x_] := False
f[x_?changeQ] := F[x]

LHS = f[x];
changeQ[x] := True
LHS
(* f[x] *)

Apparently Mathematica decided not to re-evaluate LHS at the end, otherwise it would evaluate to F[x]. This is a case where LHS and f[x] evaluate to different quantities.



Interestingly enough, swapping the order of two lines in the above changes the outcome:


(* Third example *)
ClearAll[LHS, f, F, changeQ];

changeQ[x_] := False
LHS = f[x];

f[x_?changeQ] := F[x]
changeQ[x] := True
LHS

(* F[x] *)

Swapping the order made LHS re-evaluate at the end, just like in the first example.


This leads me to more formally pose and tentatively answer the question:


Question


Suppose, for some choice of initialCode and additionalCode, we perform


initialCode
LHS = f[x]; (* f[x] *)
additionalCode
LHS


Assuming that LHS originally evaluated to f[x],




  1. For what types of additionalCode (and possibly initialCode) does the final evaluation of LHS yield something different from evaluating f[x]?




  2. If LHS and f[x] evaluate to different values (as is the case at the end of the second example above), is it possible to somehow "force" LHS to evaluate in the same way as f[x]?





Tentative Answer to Question 1


(Based on evidence from above examples)



  • LHS will re-evaluate when additionalCode gives a down value to f (See 1st and 3rd examples above)

  • LHS will not re-evaluate in general. (See 2nd example above, where a down value was given to a different function, changedQ.)


Follow Up


Assuming the tentative answer is along the right track, I'm looking for two things:



  • How does Mathematica 'know' when to re-evaluate LHS? I'm particularly interested in the vocabulary used to describe the process.


  • Are there any other conditions under which LHS re-evaluates?

  • Is there a generic way to force LHS to re-evaluate? (This is similar to the second question above.)


Of course, I'd welcome any suggestions for good references on this.



Answer



Behavior you're describing is briefly mentioned in last paragraph of "Controlling Infinite Evaluation" tutorial and very similar example is shown in documentation of Update function.


It's related to how Mathematica optimizes evaluation, how it decides that expression has not changed since last evaluation and whether it needs to be re-evaluated.



For what types of additionalCode (and possibly initialCode) does the final evaluation of LHS yield something different from evaluating f[x]?




If evaluation of f[x], before evaluating additionalCode, depends on Condition or PatternTest and evaluation of additionalCode changes some symbols in such a way that results of said Condition or PatternTest changes. Then evaluation of LHS will give different result than evaluation of f[x] after additionalCode was evaluated.


I don't know details of internal optimizations and above answer is based on what I recall from my experience, it's not backed up by any definite reference nor by conclusive experiments with Mathematica.



If LHS and f[x] evaluate to different values (as is the case at the end of the second example above), is it possible to somehow "force" LHS to evaluate in the same way as f[x]?



Yes, evalute Update[f] after evaluation of additionalCode:


(* Second example *)
ClearAll[LHS, f, F, changeQ];

changeQ[x_] := False

f[x_?changeQ] := F[x]

LHS = f[x];
changeQ[x] := True

Update[f]

LHS
(* F[x] *)



How does Mathematica 'know' when to re-evaluate LHS? I'm particularly interested in the vocabulary used to describe the process.


Are there any other conditions under which LHS re-evaluates?



Daniel Lichtblau shed some light on this in answer to "Mathematica execution-time bug: symbol names" post.



Is there a generic way to force LHS to re-evaluate? (This is similar to the second question above.)



Yes, use Update function. If you know which symbols where affected, pass them to Update, otherwise call Update[] without arguments.





Comments

Popular posts from this blog

functions - Get leading series expansion term?

Given a function f[x] , I would like to have a function leadingSeries that returns just the leading term in the series around x=0 . For example: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x)] x and leadingSeries[(1/x + 2 + (1 - 1/x^3)/4)/(4 + x)] -(1/(16 x^3)) Is there such a function in Mathematica? Or maybe one can implement it efficiently? EDIT I finally went with the following implementation, based on Carl Woll 's answer: lds[ex_,x_]:=( (ex/.x->(x+O[x]^2))/.SeriesData[U_,Z_,L_List,Mi_,Ma_,De_]:>SeriesData[U,Z,{L[[1]]},Mi,Mi+1,De]//Quiet//Normal) The advantage is, that this one also properly works with functions whose leading term is a constant: lds[Exp[x],x] 1 Answer Update 1 Updated to eliminate SeriesData and to not return additional terms Perhaps you could use: leadingSeries[expr_, x_] := Normal[expr /. x->(x+O[x]^2) /. a_List :> Take[a, 1]] Then for your examples: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x), x] leadingSeries[Exp[x], x] leadingSeries[(1/x + 2 + (1 - 1/x...

mathematical optimization - Minimizing using indices, error: Part::pkspec1: The expression cannot be used as a part specification

I want to use Minimize where the variables to minimize are indices pointing into an array. Here a MWE that hopefully shows what my problem is. vars = u@# & /@ Range[3]; cons = Flatten@ { Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; Minimize[{Total@((vec1[[#]] - vec2[[u[#]]])^2 & /@ Range[1, 3]), cons}, vars, Integers] The error I get: Part::pkspec1: The expression u[1] cannot be used as a part specification. >> Answer Ok, it seems that one can get around Mathematica trying to evaluate vec2[[u[1]]] too early by using the function Indexed[vec2,u[1]] . The working MWE would then look like the following: vars = u@# & /@ Range[3]; cons = Flatten@{ Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; NMinimize[ {Total@((vec1[[#]] - Indexed[vec2, u[#]])^2 & /@ R...

What is and isn't a valid variable specification for Manipulate?

I have an expression whose terms have arguments (representing subscripts), like this: myExpr = A[0] + V[1,T] I would like to put it inside a Manipulate to see its value as I move around the parameters. (The goal is eventually to plot it wrt one of the variables inside.) However, Mathematica complains when I set V[1,T] as a manipulated variable: Manipulate[Evaluate[myExpr], {A[0], 0, 1}, {V[1, T], 0, 1}] (*Manipulate::vsform: Manipulate argument {V[1,T],0,1} does not have the correct form for a variable specification. >> *) As a workaround, if I get rid of the symbol T inside the argument, it works fine: Manipulate[ Evaluate[myExpr /. T -> 15], {A[0], 0, 1}, {V[1, 15], 0, 1}] Why this behavior? Can anyone point me to the documentation that says what counts as a valid variable? And is there a way to get Manpiulate to accept an expression with a symbolic argument as a variable? Investigations I've done so far: I tried using variableQ from this answer , but it says V[1...