# Match a variable name pattern [duplicate]

I have a list of variables:

{RBI,RCD,ASD,FGH}


I want to select only those whose name starts with R. Using the pattern Rx_ does not work because it takes the Rx all together, so all variables in the list get selected.

• You have to convert to string, ToString, then use string matching functions. In general, try not to encode information meant to be read programmatically into variable names. It's error prone and considered bad style. It will also be very slow if you proceed to build something big with it ... – Szabolcs Jul 24 '15 at 16:57
• see SymbolName – george2079 Jul 24 '15 at 16:57
• But I need it! In order to apply a rule, I need to match a pattern. In my question it is just an example - which I can directly apply to my problem. – space_voyager Jul 24 '15 at 17:05
• I second the advice of @Szabolcs. I haven't yet seen a single case where such approach would bring any benefits, but have seen plenty where it was a source of varius troubles. Symbols are intended to either store something (i.e. play a role of variables in the programming sense), or just remain symbolic, not storing any value. In either case, their string content should be irrelevant. If you need to know string content, use strings. Symbols and strings are very different things, and conversion from one to the other is something to be avoided, in a symbolic environment, as much as possible. – Leonid Shifrin Jul 24 '15 at 17:14
• Related: (6998), (75907), (88859) – Mr.Wizard Jul 25 '15 at 12:38

If it's absolutely necessary to use the symbols as you've defined them, here's one option. (I've added FRH to the list to show that it doesn't get matched.)

Cases[{RBI, RCD, ASD, FGH, FRH}, a_ /; StringMatchQ[ToString @ a, "R" ~~ ___]]


results in

{RBI, RCD}


which is a list of Symbols (not a list of Strings).

Now, there's a problem if you have already assigned values to these symbols. For instance, if RBI = 1, then the command above returns

{RCD}


because Cases evaluates its first argument before matching the pattern in the second argument. I don't know how to fix this problem, which is why I suggest:

### Suggestions

I agree with the comments: try to name your variables differently. Perhaps something like R[BI] or R[C][D]. Then the selection is simple:

Cases[{R[BI], R[CD], A[SD], F[GH], F[RH]}, R[_]]


results in

{R[BI], R[CD]}


Now, if you have already associated values with R, then things won't work, because Cases will evaluate its first argument before matching. For instance, if you have set R[BI] = 1, then the above code results in

{R[CD]}


You would need to modify the code to be

Cases[HoldForm[{R[BI], R[CD], A[SD], F[GH], F[RH]}], R[_], 2]


resulting in

{1, R[CD]}


or

Cases[HoldForm[{R[BI], R[CD], A[SD], F[GH], F[RH]}], R[a_] :> Hold[R[a]], 2]


resulting in

{Hold[R[BI]], Hold[R[CD]]}


You can then ReleaseHold, resulting in

{1, R[CD]}

• R[BI] did the trick. Does Mathematica see R[BI] and R[CD] as two different variables though? I checked and the output is different for each (good), but are they really "independent"? – space_voyager Jul 24 '15 at 17:38
• @space_voyager. It depends on how you define them, of course. If you do R[BI] = <stuff> and R[CD] = <things>, then both <stuff> and <things> get associated with the symbol R (look up DownValues and do DownValues[R]), but you can still call them separately. There is also a way to associate <stuff> with BI and <things> with CD rather than R (look up 'UpValues and UpSet). – march Jul 24 '15 at 17:43
• @space_voyager. See the updated answer. It makes the argument for using things like R[CD] even stronger. – march Jul 24 '15 at 18:02