方程线程:为什么是默认行为?

发布于 2024-11-02 10:44:58 字数 701 浏览 1 评论 0原文

我最近重新发现了 Roman Maeder 的一个小包,它告诉 Mathematica 自动对 x == y 等表达式进行算术和类似函数的线程处理。 Maeder 包的链接。

首先,为了演示,下面是 Maeder 给出的一个示例:

In[1]:= Needs["EqualThread`"]

现在继续使用线程行为“手动”求解 x 的以下方程:

In[7]:= a == b Log[2 x]
In[8]:= %/b
Out[8]:= a/b == Log[2 x]

现在求幂:

In[9]:= Exp[%]
Out[9]= E^(a/b) == 2 x

并除以 2:

In[10]:= %/2
Out[10]= (E^(a/b))/2 == x

Q:从设计角度来看,有人可以解释为什么 Mathematica 设置为这种方式吗默认? 自动线程似乎是 Mathematica 初学者所期望的行为类型(至少对我来说),也许有人可以提供一两个示例,这些示例会导致整个系统出现问题。 (并随时指出任何数学无知......)

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...)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

他不在意 2024-11-09 10:44:58

考虑算术运算时似乎很自然。但情况并非总是如此。

当我写作时

Boole[a==b]  

,我不想

Boole[a] == Boole[b]  

这就是 Maeder 包的作用。

编辑

在下面回答您的评论:

我注意到 Boole[] 是在 v.5.2 中添加的,而 Maeder 的包是为 v.3 编写的。我想我的问题的核心仍然围绕着“设计”问题。我的意思是,如何解决您指出的问题?对我来说,最清晰的途径是声明一些关于您正在使用的变量的信息,不是吗? -- 让我困惑的是你通常只能通过假设来做到这一点(全局或作为简化的选项等)。还有人认为拥有全套数字属性会更自然吗? (在这方面,Constant Attribute 就是个逗逼)

我的回答绝不是对 Maeder 的包的批评,这很好,而是声明它不应该是对待 Equal[ ] 在MMA。

Equal[ ] 是一个函数,一开始不太容易掌握:

  • 如果 lhs 和 rhs 相同,则返回 True
  • ,如果通过数字或其他原始数据(例如字符串)之间的比较确定 lhs 和 rhs 不相等,则返回 False。
  • 当 lhs 或 rhs 包含诸如“不确定”和“溢出”之类的对象时,保持未计算状态。
  • 用于表示符号方程,可以使用 Solve 等函数进行操作。

Maeder 包的目的(我理解与您的非常一致)是为表达式 lhs == rhs 赋予人类在做数学时使用的相同含义和操作规则。

在数学中,等式是一种等价关系,在集合中强加偏序,而方程是一种断言,即表达式通过这种特定关系相关。

将这些差异与其他 Mma“功能”进行比较。 Sin[x] 在 Mma 中,在通常的数学中是同样的东西(嗯,几乎),并且对于大多数 Mma 野兽来说也是如此。然而,有一些 Mma 结构并不具有与数学概念完全相同的同构性:Equal、SameQ、Equivalent 等。它们是从数学世界到编程世界的桥梁。它们不是严格的数学概念,而是经过修改的编程概念来容纳它们。

抱歉,如果我有一点哲学方面的知识。

哈!

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!

我想部分原因是这种行为不能扩展到不平等。还因为当评估平等时,这种行为应该有意义:

会很好:

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

但是:

In[87]:= Thread[Power[a == b, c == d] /. {c -> 2, d -> 2}, Equal]

Out[87]= a^True == b^True

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
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文