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?

  • 3
    $\begingroup$ Please note that this site is meant for clear, answerable question. You did not actually ask anything. In my answer I assumed that you were looking for an explanation of why this happens so you will be able to avoid the problem. $\endgroup$
    – Szabolcs
    Feb 25, 2013 at 17:57
  • 1
    $\begingroup$ Subscripts are not being interpreted the way you think they are here. The first solution is correct. I wouldn't use subscripts unless you are very aware of how they are going to be interpreted. $\endgroup$
    – Searke
    Feb 25, 2013 at 18:43
  • 7
    $\begingroup$ Don't worry. You're most certainly not the first or last person who has run into this. Really the best way to use subscripts is to not use them. $\endgroup$
    – Searke
    Feb 25, 2013 at 18:55
  • $\begingroup$ I just want to add that, this isn't a v9 issue, it exists in my v8 too, and I think it can also be reproduced in earlier version. $\endgroup$
    – xzczd
    Apr 15, 2013 at 6:25

4 Answers 4


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]


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

where fun can be an arbitrary function.

  • $\begingroup$ In a sense, yes ... that is the issue: that Solve fails to understand that Subscript[y,1] and y are independent. But I think it is more pervasive than that. Consider Solve[{Subscript[y, 1] == x/k, Subscript[y, 1] > 0, y > 0}, x] Here, the inclusion of the 'irrelevant' term y>0 causes the Solve to fail again. By contrast, something like: Integrate[Subscript[y, 1], {Subscript[y, 1], 0, 1}, Assumptions -> y > 0] does not interfere with the evaluation of the integral. $\endgroup$
    – wolfies
    Feb 25, 2013 at 18:44
  • 2
    $\begingroup$ @wolfies Yes, I agree that this is a bit inconsistent, and that it would be nice to be able to use subscript without ever having to worry (this is not the only issue with subscripts). I was simply trying to show what it is most likely cause of failure, to make it easier to avoid it. (Also for other people reading this, not only for you.) Personally I never use subscripts, it seems to much trouble. If I want to transform variables into each other, I use x[1], x[2], but that's not free of this problem either ... it's better not to use x when these are present. $\endgroup$
    – Szabolcs
    Feb 25, 2013 at 18:47

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


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

enter image description here

  • 3
    $\begingroup$ To add to this, this is one of the primary purposes of the Notation` package. $\endgroup$
    – rcollyer
    Feb 25, 2013 at 23:44

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.


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

Solve[a__] /; !FreeQ[{a}, $Notations[__]] := Block[{CompressedData},
        {z = Unevaluated[Solve[a]] /. s:$Notations[__] :> CompressedData[Compress[s]]},
        z /; !MatchQ[z, _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]}}

  • $\begingroup$ Er… what's the purpose of Block[{CompressedData}, and /; ! MatchQ[z, _Solve]? $\endgroup$
    – xzczd
    May 28, 2021 at 8:09
  • $\begingroup$ @xzczd See update $\endgroup$
    – Carl Woll
    May 28, 2021 at 20:11
  • $\begingroup$ Oh, I didn't know func[a_] := Block[{b}, a /; True] won't overwrite func[a_] := Block[{}, a /; True]! $\endgroup$
    – xzczd
    May 29, 2021 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.