I ran into a bug in my code today based on an errant assumption. Namely, I thought that:
Thread[Equal[{aa, bb, cc}, {dd, ee, ff}]]
Thread[SameQ[{aa, bb, cc}, {dd, ee, ff}]]
Would
{aa == dd, bb == ee, cc == ff}
{False,False,False}
Respectively (variables are undefined). What I get instead is
{aa == dd, bb == ee, cc == ff}
False
Which I can argue makes sense, since the lists aren't equivalent. But why doesn't Thread work? What's the precedence argument here? How can I get the answer I want ({False,False,False}) from a similar construct?
Answer
Thread doesn't hold its arguments. You can check its attributes.
So, before doing any threading, it evaluates its arguments.
Now, understanding the behaviour you describe requires understanding the difference between Equal and SameQ. Equal is meant for math reasoning. For expressing an equality, which might involve a variable that at the time you don't yet know it's value. So, for example, x==8 returns unevaluated if x isn't defined.
SameQ however is a predicate. It will always return either True or False if the constructs are exactly the same (after evaluation).
So, Thread[SameQ[{aa, bb, cc}, {dd, ee, ff}]] -> Thread[False]-> False
One can see this by running (thanks @rcollyer)
Trace[Thread[SameQ[{aa, bb, cc}, {dd, ee, ff}]],
TraceInternal -> True]
Out[1] = {{{aa, bb, cc} === {dd, ee, ff}, False}, Thread[False], False}
If you want to thread SameQ without evaluation, just use Unevaluated
Thread[Unevaluated@SameQ[{aa, bb, cc}, {dd, ee, ff}]]
{False, False, False}
Another construction that gives the result you want is the one suggested by @kguler in his comment and supported by @rcoller and his upvoters: MapThread. I'd suggest you search the docs if you don't know it
MapThread[SameQ, {{aa, bb, cc}, {dd, ee, ff}}]
Comments
Post a Comment