# Seems like OptimizeExpression is getting worse over time

I've been using the OptimizeExpression function again recently, and cleaning up the results by hand. Its results have been unbelievably sub-optimal in my recent usage, as opposed to the past. So much so that it doesn't even require manipulation of the results to see.

Have any of you run into this recently? Can you test this on older versions?

For context I'm in Mathematica Online, so I'm using version 12.0.0 for Linux x86 (64-bit) (March 31, 2019). I don't use the desktop version.

f[u1@P]+c f[u2@P]/.f@u_->3/2/u(1/2/u-1/Tan[2u])//FullSimplify
{%,%/D[%,P]}/.{u1->(j1 Sqrt@#&),u2->(j2 Sqrt@#&)}//FullSimplify
ExperimentalOptimizeExpression[%,OptimizationSymbol->a]


• I really wonder if this function is maintained at all ... – Szabolcs May 8 at 21:24
• @Szabolcs Well, if they quit maintaining it, I'd like them to expose whatever function they're currently using for compiling functions for plotting, etc... Unless they're actually still using this function without maintaining it... – Chris Chiasson May 8 at 21:27
• @Szabolcs It seems to me if the function is not maintained (= ignored?), then no change in behavior should be observed. -- BTW, the third underlined expression contains Power[j1, -2] and is not the same as a18 = Power[j1, 2]. I have observed similar behavior to OptimizeExpression not using Power[a18, -1] in place of Power[j1, -2] in earlier versions. If you think about it, it is not more optimal; at least on the face of it, both require evaluating Power. – Michael E2 May 9 at 12:50
• @MichaelE2 One of them requires either dividing or exponentiating one more time than the other (per substitution) after compilation, so I disagree. Besides, it is plain to see that it has missed plenty of other substitutions (for example in my answer below, but also in regular usage of the function). My guess is that it is bitrotting due to a lack of QA or automated regression testing on that function. – Chris Chiasson May 9 at 13:10
• There is no dividing: there's multiplying by Power[expr, -n]. It's been noted before that Divide[a, b] evaluates (on nonnumeric input) to Times[a, Power[b, -1]], which is less efficient. You're saying, I take it, that in earlier versions, these expressions were optimized -- is that right? Have you tried OptimizationLevel -> 2? I'm unclear whether you're saying level 1 is not as optimal as possible or as optimal as it was in some previous version. – Michael E2 May 9 at 13:47

Here is a workaround while we wait for support to answer... It uses a18=j1^2 and a20=j2^2 as I underlined above, and also uses a29=2*j2*a25 and a36=a28+a35.

f[u1@P]+c f[u2@P]/.f@u_->3/2/u(1/2/u-1/Tan[2u])//FullSimplify;
{%,%/D[%,P]}/.{u1->(j1 Sqrt@#&),u2->(j2 Sqrt@#&)}//FullSimplify;
ExperimentalOptimizeExpression[%,OptimizationSymbol->a]
Out@3/.{Set->Rule,ExperimentalOptimizedExpression|Block|
CompoundExpression->List};
%[[1,2]];
Reverse@Fold[Flatten[{#//.Reverse@#2//.Reverse[1/#&/@#2],#2}]&,
Reverse@%]


• What is Out@3`? The line number depends on the session. – Michael E2 May 9 at 13:41
• @MichaelE2 Look at the screen shot... or start a new kernel – Chris Chiasson May 9 at 14:18