Solve with v9 (issues with Subscript, Overscript, Superscript etc)

Question

The way Solve works has changed in v9 ... in essence, to get the answers that one obtained under v8, one now often has to specify a lot more information about all the variables and parameters, in order to get the desired neat solution.

In providing this extra detail on Input, across the board, so to speak, I have discovered that, rather unfortunately, the Solve function has a poor understanding of notational forms such as Subscript, Superscript, OverBar, OverHat, OverDot, OverTilde etc etc ... causing Solve[] to fail on even the simplest examples when such notation is used.

As a quick illustration:

... when, of course, Mathematica can trivially solve such examples.

Two clarifications on the above:

1. The solution here is certainly not to use the Notation package ... I must confess that the point of the latter has mostly escaped me, because the very beauty of using Subscript etc notation in Mathematica is to be able Thread or Map over the index etc ... essentially getting the best of both worlds: a wonderfully flexible symbolic structure, even if not strictly a Symbol. The Notation package, by contrast, does the opposite ... by symbolising the structure, all flexibility is lost.

2. Some years ago, back in the days of Mathematica 3 or 4, a very similar issue occurred with Integrate when using Subscript notation ... causing it to fail horribly when certain Subscript variables were used on Input. And there were problems with Plot when using Subscript notation too. I recall raising these issue at the time, and if I recall correctly, these issues ... which effect the way thousands of people use Mathematica on a daily basis, were rectified in subsequent revisions of mma. It would be very helpful if a similar fix was adopted for the Solve case, so that Solve was aware that Subscript[y,1] is not the same as say Sin[y] ... That Subscript[y,1] notation does not denote a mathematical function of y ... but rather just denotes a typesetting function of y.

Do others have thoughts as to whether this behaviour in Solve is inconsistent? Or as they expect it to be? Or different to the way other Mma functions treat Subscript notation?

Answer 1

The reason why Solve fails here is that it does not understand that Subscript[y,1] and y are independent and unrelated. You can avoid this problem by making sure that you won't use the symbol from inside Subscript on its own. If you use Subscript[y,1], you can still use Subscript[y,2], but not y. The same applies for using y[1] instead of Subscript[y,1].

To understand the limitation better, compare

Solve[Subscript[y, 1] == y, y]

to

Solve[fun[y, 1] == y, y]

where fun can be an arbitrary function.

Answer 2

Solve is looking for symbols. If you symbolize your subscripts then it works fine:

Needs["Notation`"]

Symbolize[ParsedBoxWrapper[SubscriptBox["y", "1"]]]
Head[Subscript[y, 1]]
(* Symbol *)

Answer 3

The pitfalls of Subscript and similarly Overscript etc. have been pointed out in the various comments, but this doesn't mean it's impossible to work with these constructs the way you want to. As long as you remain aware the issues, you can for example do the following:

SetAttributes[Subscript, HoldFirst]

Subscript[y, i_] := Subscript["y", i]

Solve[{Subscript[y, 1] == y/k, Subscript[y, 1] > 0, k > 0}, y]

{{y->ConditionalExpression[k Subscript[y, 1],Subscript[y, 1]>0&&k>0]}}

For the special name y the Subscript function now substitutes a string. It is able to do that because I've given it the attribute HoldFirst. This makes the y in the subscript $y_i$ different from the variable named y in the equation.

Answer 4

Here is one approach to teaching Solve about inert notational constructs:

$Notations = (
    Subscript | Superscript | Subsuperscript | SubPlus | SubMinus | 
    SubStar | SuperPlus | SuperMinus | SuperStar | SuperDagger |
    Overscript | Underscript | Underoverscript | OverBar | OverVector |
    OverTilde | OverHat | OverDot | UnderBar
);

Unprotect[Solve];
Solve[a__] /; !FreeQ[{a}, $Notations[__]] := Block[{CompressedData},
    With[
        {z = Unevaluated[Solve[a]] /. s:$Notations[__] :> CompressedData[Compress[s]]},
        z /; !MatchQ[z, _Solve]
    ]
]
Protect[Solve];

A couple comments:

1. Compressing the notational object (e.g., Subscript[..]) prevents Solve from thinking that the argument of the notation object (e.g., the y in Subscript[y, 1]) is something to be solved for. Now, CompressedData[Compress[expr]] normally evaluates to expr, but by blocking CompressedData this evaluation only happens after the block is exited. Basically, the block temporarily modifies the notational object so that Solve can work as expected.

2. The !MatchQ condition avoids recursion errors when Solve returns unevaluated (i.e., when Solve doesn't understand the input).

Your first example:

Solve[{Subscript[y, 1]==y/k, Subscript[y, 1]>0, y>0, k>0}, y]

{{y -> ConditionalExpression[k Subscript[y, 1], Subscript[y, 1] > 0 && k > 0]}}