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

Post a Comment

Popular posts from this blog

front end - keyboard shortcut to invoke Insert new matrix

I frequently need to type in some matrices, and the menu command Insert > Table/Matrix > New... allows matrices with lines drawn between columns and rows, which is very helpful. I would like to make a keyboard shortcut for it, but cannot find the relevant frontend token command (4209405) for it. Since the FullForm[] and InputForm[] of matrices with lines drawn between rows and columns is the same as those without lines, it's hard to do this via 3rd party system-wide text expanders (e.g. autohotkey or atext on mac). How does one assign a keyboard shortcut for the menu item Insert > Table/Matrix > New... , preferably using only mathematica? Thanks! Answer In the MenuSetup.tr (for linux located in the $InstallationDirectory/SystemFiles/FrontEnd/TextResources/X/ directory), I changed the line MenuItem["&New...", "CreateGridBoxDialog"] to read MenuItem["&New...", "CreateGridBoxDialog", MenuKey["m", Modifiers-...
Post a Comment
Read more

How to thread a list

I have data in format data = {{a1, a2}, {b1, b2}, {c1, c2}, {d1, d2}} Tableform: I want to thread it to : tdata = {{{a1, b1}, {a2, b2}}, {{a1, c1}, {a2, c2}}, {{a1, d1}, {a2, d2}}} Tableform: And I would like to do better then pseudofunction[n_] := Transpose[{data2[[1]], data2[[n]]}]; SetAttributes[pseudofunction, Listable]; Range[2, 4] // pseudofunction Here is my benchmark data, where data3 is normal sample of real data. data3 = Drop[ExcelWorkBook[[Column1 ;; Column4]], None, 1]; data2 = {a #, b #, c #, d #} & /@ Range[1, 10^5]; data = RandomReal[{0, 1}, {10^6, 4}]; Here is my benchmark code kptnw[list_] := Transpose[{Table[First@#, {Length@# - 1}], Rest@#}, {3, 1, 2}] &@list kptnw2[list_] := Transpose[{ConstantArray[First@#, Length@# - 1], Rest@#}, {3, 1, 2}] &@list OleksandrR[list_] := Flatten[Outer[List, List@First[list], Rest[list], 1], {{2}, {1, 4}}] paradox2[list_] := Partition[Riffle[list[[1]], #], 2] & /@ Drop[list, 1] RM[list_] := FoldList[Transpose[{First@li...
Post a Comment
Read more

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...
Post a Comment
Read more