# Mma10 mystery: Failure of pure function substitution with Interpretation?

Bug introduced in 10.0.0 and fixed in 10.0.1

I had code to display with subscripts from Displaying index as subscript on output: e.g. C[i] -> C_i with Notation[...] or Interpretation[..]? which is now breaking an innocuous pure function substitution as in Looking for an elegant way to solve a (system of) ODEs/functional equations with undetermined coefficients The substitution itself has nothing to do with any actual display of subscripts.

I am having a little trouble creating a minimal example, but here goes. First, in Mma10 try the pre-side effect code:

ODE = F'[z] == g F[z]
Fguess = {F-> (Exp[a #]&)}
ODE /. Fguess //FullSimplify

=> e^(a z)(a - g)== 0, the proper output


Now, add in the following code, stripped down from that previous example. This isn't intended to actually have anything to do with the substitution, but is causing side effects.

NotScriptedVarQ[z_] := ! MemberQ[$scriptedfunctionsvars, z, Infinity]; makeDef[pat_, body_] := (MakeBoxes[a : pat, fmt_] := ToBoxes[Interpretation[body, a], fmt] /; MemberQ[Union[$scriptedconstants, $scriptedfunctions], Unevaluated@h]; ) makeDef[h_Symbol[argssub__?NotScriptedVarQ], h[argssub]];$scriptedconstants = {};
$scriptedfunctions = {};$scriptedfunctionsvars = {};


Now, try the substitution and a few permutations:

(*The ODE and guess are*)
ODE = F'[z] == g F[z]
Fguess = {F -> (Exp[a #] &)}
(*Substituting NOW DOESN'T work*)
ODE /. Fguess // FullSimplify
(*But if the guess is NOT displayed before the substitution(i.e., no ;) WORKS!*)
Fguess = {F -> (Exp[a #] &)};
ODE /. Fguess // FullSimplify
(*And if the guess is substituted directly, IT WORKS!*)
F'[z] == g F[z] /. {F -> (Exp[a #] &)} // FullSimplify


As this used to work fine in Mma9, I imagine this is a bug. If so, any idea of a workaround?

One last thing I learned: If you change the definition so that NotScriptedVarQ[z_] := True, or change it to always be False, the bug is no longer there!

-
What are the Print expressions suppose to accomplish? Are they supposed to function as comments? Should that be the case, then use Mathematica's comment syntax, e.g., (* a comment *). – m_goldberg Jul 16 '14 at 4:21
Sorry, you are right, I just had them in there to keep track of the output. They don't effect the bug – jlperla Jul 16 '14 at 4:23
Prints converted to comments. Thanks. – jlperla Jul 16 '14 at 17:29
It seems this bug has been fixed in 10.0.1; I added a header accordingly. If you find this to not be true please remove that header (and let me know). – Mr.Wizard Sep 17 '14 at 16:04
Confirmed, fixed. – jlperla Sep 19 '14 at 17:17

I can't yet explain the behavior but I can greatly reduce your minimum example:

MakeBoxes[a_ /; FreeQ["foo", a], fmt_] := "bar" /; False

ODE = F'[z] == g F[z];
Fguess = {F -> (Exp[a #] &)}

ODE /. {F -> (Exp[a #] &)}
ODE /. Fguess

{F -> (Exp[a #1] &)}

a E^(a z) == E^(a z) g

Derivative[1][F][z] == g F[z]


Critically:

• If I suppress the output of Fguess = {F -> (Exp[a #] &)} by appending a ; the problem exhibited in the final line of code goes away.

• If I replace FreeQ["foo", a] with FreeQ["foo", HoldPattern @ a] the problem goes away.
(Kernel restart required.)

Apparently the evaluation of a within FreeQ (or MemberQ) when MakeBoxes is performed on the output of the line Fguess = {F -> (Exp[a #] &)} breaks something but at this point I have no idea what.

-
That did it! Changing to MemberQ[$scriptedfunctionsvars, HoldPattern@ z, Infinity] seems to have fixed everything. This sure looks like a bug to me, how does Wolfram like these things to be submitted? – jlperla Jul 22 '14 at 19:21 @jlperla Under the Help menu there should be a Give Feedback item you can use for that. I'm glad this solves your problem. I too believe it is a bug as I can't think of any other explanation for the behavior. I'll add that tag to the question. If later I am proven wrong so be it. – Mr.Wizard Jul 22 '14 at 19:26 @jlperla Oh, and thanks for the Bounty! – Mr.Wizard Jul 22 '14 at 19:27 Sent to them. Thank you so much for looking at this and finding a workaround. – jlperla Jul 22 '14 at 20:56 @jlperla By the way is there a reason you are using ! MemberQ[$scriptedfunctionsvars, HoldPattern @ z, Infinity]; rather than FreeQ[\$scriptedfunctionsvars, HoldPattern @ z]? – Mr.Wizard Jul 25 '14 at 7:00