# Strange behavior of Pick when named constants appear in its arguments

### Basic problem

This is the briefest working example I have found of the problem.

Pick[{2 E, 2 E }, {0, 2 E}, 0]


{2 E, 1}

I expected the result to be

{2 E}

### Further discussion

Multipliers are necessary in the arguments, but they can symbolic and different. I read this that Times is somehow involved.

Pick[{2 E, 2 E }, {0, E}, 0]


{2 E}

Pick[{2 E, E }, {0, 2 E}, 0]


{2 E}

Pick[{2 E, n E }, {0, k E}, 0]


{2 E, 1}

The named constants can apparently occur in any mixture.

Pick[{2 E, 2 Degree }, {0, 2 Glaisher}, 0]


{2 E, 1}

### Questions

• There is no 1 in any of the 1st arguments given to Pick in this question, and the 2nd item in the 2nd arguments never matches zero, so where is the 1 in the result coming from?

• Should this question be tagged with ?

• Pick[{2 x, 3 }, {y^ z, 0}, 0] suggests the issue is more pervasive than named constants.
– kglr
Mar 16, 2018 at 4:58

No, a support response like

I could reproduce the issue and it does appear that Pick[] is behaving strangely in certain cases. I have forwarded a report to the appropriate members of our development team.

should not be taken as confirmation of an actual bug.

Why should

Pick[{2 E, 2 E }, {0, 2 E}, 0]


return {2 E, 1}?

Well, 2 E is clearly there because of the first part of the selector, which matches the test 0.

What is more interesting is the second, non-atomic part of the selector. The head Times does not really matter, only the structure does, so it is treated effectively as List. The result is the same as from

Pick[{2 E, 2 E}, {0, {2, E}}, 0]

In other words, the nested second part will now act similarly to Pick[f[x, y], g[a, b], False] or

Pick[f[x, y], {a, b}, False]

(* f[] *)


where the selector parts did not match the test, so x and y weren't picked and we were left with nothing, or Sequence[] inside f, analogously to a {} result.

Of course, in our example, x and y happen to be 2 and E, while Times[] is by definition 1.

• I'm very glad to get this answer. It's a very clear explanation. It's too bad the support tech who handled my query didn't have thechops to give an equivalent answer. Poor chap. I presume he will get informed and will presently send me an email with a similar explanation. Mar 16, 2018 at 7:38
• So pick effectively ignores heads in the expression and the selector and applying a replacement rule like /.h_[args__]:>{args__} shouldn't change the outcome? (big +1 ofc) Mar 16, 2018 at 12:24
• @m_goldberg In fairness, sometimes people with a lot more experience have had doubts about Pick. It was even more common before the documentation page was significantly improved (for 10.4, I think). Mar 16, 2018 at 17:09
• @LLlAMnYP I think that is true for the selector argument Mar 16, 2018 at 17:11
• Stole my answer! I will just add that the last Possible Issues example on the ref page was written a couple of years ago to try to clarify this point, and gives an even more extreme, though in some sense more obvious, failure mode. We have had chats about how to extend pick to make is less suprising, but it's not easy and--as always--there are many competing priorities. Mar 16, 2018 at 18:28

I'm posting this is in support of a "yes" answer to the 2nd question asked above.

I reported this to Wolfram tech support and received the following reply (edited to omit boilerplate and other non-relevant material).

I could reproduce the issue and it does appear that Pick[] is behaving strangely in certain cases. I have forwarded a report to the appropriate members of our development team.