# ParallelMap doesn't work with an Association. Is this a bug?

No longer a problem in Mathematica 11.0.1 on macOS.

I receive a ParallelCombine::nopar1 error when executing

ParallelMap[Identity, <|1 -> 1, 2 -> 2|>]


Is this an expected behaviour or a bug? I'm using Mathematica 10.0.2 for Mac.

(I've already worked around this by ParallelMap[Identity, Values@<|1 -> 1, 2 -> 2|>] by the way.)

• I hesitate to put this into an answer but if I understood this answer by Leonid correctly, one probably can't operate on associations in parallel. You would have to break them into entries, operate on each one in parallel, and reassemble an association. It doesn't sound like they were intended for that, but maybe one day it will be possible (one can always overload an exception). Putting my description into code leads to something like Association@ParallelMap[Identity, Normal@<|1 -> 1, 2 -> 2|>]. Mar 11, 2015 at 17:45
• @MichaelE2 I think your comment is right on target. OTOH, this can be viewed as a current limitation of the parallel functionality. The ParallelMap implements its own version of Map, which schedules the computations to individual kernels and then assembles the result. Your implementation can be viewed as one such possible implementation, although in general the code should be a little different, since mapping on Associations maps on values, while in your code mapping will be on rules key -> value. Mar 11, 2015 at 19:40
• @LeonidShifrin Yes, my code is more like AssociationMap, but in part that's why I said "something like" (and because of comment limitations and not really being concerned about a valid workaround). I suppose I should have written AssociationThread[Keys@assoc, ParallelMap[f, Values@assoc]]. Mar 11, 2015 at 22:31
• @MichaelE2 Yes, that's right, your second version is what I meant - your code is probably the best way to do this currently. If f is expensive, this may actually be quite a sensible thing to do. Mar 11, 2015 at 23:15
• Within Mathematica 11.0.1 on macos, this problem seems to have been settled, now. Jul 16, 2017 at 21:06

Edited to reflect later comments below :

These examples will work:

ParallelMap[Identity, {<|1 -> 1|>, <|2 -> 2|>}]
(* {<|1 -> 1|>, <|2 -> 2|>}  *)

ParallelMap[Identity, {<|1 -> 1, 3 -> 3|>, <|2 -> 2, 3 -> 3|>}]
(*  {<|1 -> 1, 3 -> 3|>, <|2 -> 2, 3 -> 3|>}  *)


Its worth noting that if you wrap the association in list brackets you can suppress the error, although I suspect that may effectively force a serial process.

I think its because it doesn't have anything to ParallelMap for in your example because it attempts to process the entire association as 1 "thing"

I think this kinda makes sense if you think how Associations (and Datasets) can be used for row based processing. You'd tend to want to fling the whole row at a parallel process.

• Aaaaaah, right! Thank you. Now I understand Associations more. By the way, ParallelMap[Identity, {<|1 -> $KernelID, 2 ->$KernelID|>}] shows that it is only evaluated serially in the main kernel as you suspected. Mar 11, 2015 at 14:21
• I don't think this explanation is quite right. Map has a certain specific semantics on Associations, namely it maps a function on the values of an Association, and the fact that parallel functionality does not yet work in the same way is a current limitation of the parallel functionality. By the logic of your answer, Map also shouldn't work on Associations, but it does. Why Map has this semantics for an Association, is a separate question, but given this design decision, ParallelMap should in principle do the same. Mar 11, 2015 at 19:44
• Right. Please let me retract the answer for now. I got your point, Leonid. The behaviours of ParallelMap of Map should've been in line with each other. Gordon's explanation contradicts this. Mar 12, 2015 at 1:13
• Edited my answer - but have left the "working" examples in incase they are useful. Mar 12, 2015 at 10:50