问题
I recently rediscovered a small package by Roman Maeder that tells Mathematica to automatically thread arithmetic and similar functions over expressions such as x == y. Link to Maeder's package.
First, to demonstrate, here's an example given by Maeder:
In[1]:= Needs["EqualThread`"]
Now proceed to use the threading behavior to solve the following equation for x 'by hand':
In[7]:= a == b Log[2 x]
In[8]:= %/b
Out[8]:= a/b == Log[2 x]
Now exponentiate:
In[9]:= Exp[%]
Out[9]= E^(a/b) == 2 x
And divide through by 2:
In[10]:= %/2
Out[10]= (E^(a/b))/2 == x
Q: From a design perspective, can someone explain why Mathematica is set to behave this way by default? Automatically threading seems like the type of behavior a Mathematica beginner would expect---to me, at least---perhaps someone can offer an example or two that would cause problems with the system as a whole. (And feel free to point out any mathematica ignorance...)
回答1:
Seems natural when thinking of arithmetic operations. But that is not always the case.
When I write
Boole[a==b]
I don't want
Boole[a] == Boole[b]
And that is what Maeder's package does.
Edit
Answering your comment below:
I noticed that Boole[] was added in v.5.2, whereas Maeder's package was authored for v.3. I guess the core of my question still revolves around the 'design' issue. I mean, how would one get around the issue you pointed out? To me, the clearest path would be declaring something about variables you're working with, no? -- What puzzles me is the way you can generally only do this with Assumptions (globally or as an option to Simplify, etc). Anyone else think it would be more natural to have a full set of numerical Attributes? (in this regard, the Constant Attribute is a tease)
My answer is by no means a critic to Maeder's package, which is nice, but a statement that it should not be the mainstream way to treat Equal[ ] in Mma.
Equal[ ] is a function, and not particularly easy to grasp at first:
- returns True if lhs and rhs are identical
- returns False if lhs and rhs are determined to be unequal by comparisons between numbers or other raw data, such as strings.
- remains unevaluated when lhs or rhs contains objects such as Indeterminate and Overflow.
- is used to represent a symbolic equation, to be manipulated using functions like Solve.
The intent of Maeder's package, which I understand is well aligned with yours, is to give to the expression lhs == rhs the same meaning and manipulation rules humans use when doing math.
In math, equality is an equivalence relation, imposing a partial order in a set, and an equation is an assertion that the expressions are related by this particular relation.
Compare these differences with other Mma "functions". Sin[x] is in Mma, and in usual math the same thing (well, almost), and the same can be said of most Mma beasts. There are a few Mma constructs, however, that do not hold that exact isomorphism to math concepts: Equal, SameQ, Equivalent, etc. They are the bridge from the math world to the programming world. They are not strict math concepts, but modified programming concepts to hold them.
Sorry if I got a little on the philosophical side.
HTH!
回答2:
I guess it is partly because the behavior can not be extended over to inequalities. And also because the behavior should make sense both when equalities become evaluated:
Would be nice:
In[85]:= Thread[Power[a == b, 2], Equal]
Out[85]= a^2 == b^2
In[86]:= Thread[Power[a == b, c == d], Equal]
Out[86]= a^c == b^d
but:
In[87]:= Thread[Power[a == b, c == d] /. {c -> 2, d -> 2}, Equal]
Out[87]= a^True == b^True
来源：https://stackoverflow.com/questions/5701159/equation-threading-why-the-default-behavior