🙂 ✌🏻 🥈 第12版今天发布！（这对Wolfram语言和Mathematica来说是一个巨大的飞跃） 🛡️ 👋🏼 🖊️

快速连结

- 版本12之路
- 首先，一些数学
- 不确定性的演算
- 经典数学，基础和高级
- 更多关于多边形的信息
- 使用多面体进行计算
- 欧几里得风格的几何可计算
- 用公理理论走向超级符号化
-n身体问题
- 语言扩展和便利
- 更多机器学习功能
- 最新的神经网络
- 使用图像进行计算
- 语音识别及更多音频
- 自然语言处理
- 计算化学
- 地理计算扩展
- 许多小的可视化增强
- 加强知识库集成
- 整合来自外部数据库的大数据
-RDF，SPARQL等
- 数值优化
- 非线性有限元分析
- 全新的复杂编译器
- 调用Python和其他语言
-Wolfram“ Super Shell”的更多内容
- 伪造Web浏览器
- 独立微控制器
- 从Python和其他地方调用Wolfram语言
- 链接到Unity Universe
- 机器学习的模拟环境
- 区块链（和CryptoKitty）计算
- 还有普通加密
- 连接到财务数据源
- 软件工程和平台更新
- 还有很多...

2019年4月16日-Stephen Wolfram

通往版本12之路

今天，我们将在桌面平台和Wolfram云中发布Wolfram语言（和Mathematica ）的第12版。我们于2016年8月发布了版本11.0 ，于2017年3月发布了11.1，于2017 年9 月发布了 11.2，于2018年3 月发布了 11.3 。从版本11.3到版本12.0有了很大的跳跃。在大约103个区域中，共有278个全新功能，以及整个系统上的数千种不同更新：

在12这样的“ 整数版本 ”中，我们的目标是提供功能齐全的新区域。但是在每个版本中，我们也希望提供我们研发工作的最新成果。在12.0中，也许我们的一半新功能可以看作是在以前的“ .1”版本中开始的整理区域，而另一半则是在新区域中开始的整理区域。在本文中，我将讨论两种类型的功能，但我将特别强调从11.3到12.0的新功能的细节。

我必须说，既然12.0已经完成，我为其中的多少以及自11.3起我们增加了多少而感到惊讶。在去年10月举行的Wolfram技术会议上的主题演讲中，我总结了到目前为止的工作-甚至花费了将近4个小时。现在还有更多。

我们能够做的事情既证明了我们的研发力量，也证明了Wolfram语言作为开发环境的有效性。这两件事当然已经建立了三十年。但是12.0的新功能是，我们一直在让人们观看我们的幕后设计流程- 直播我300多个小时的内部设计会议。因此，除了其他所有内容之外，我怀疑这使12.0版成为有史以来以这种方式打开的第一个主要软件版本。

好的，那么12.0中有什么新功能？有一些大而令人惊讶的事情-特别是在化学，几何，数值不确定性和数据库集成方面。但是总的来说，很多领域都有很多东西-实际上，甚至文献中心的这些内容的基本摘要也已经长达19页：

首先，一些数学

尽管当今Wolfram语言（和Mathematica）的绝大部分功能不是通常认为的数学，但我们仍将巨大的研发努力推向了数学领域的前沿。作为我们在12.0中添加的内容的第一个示例，这是一个非常丰富多彩的ComplexPlot3D ：

始终可以编写Wolfram语言代码以在复杂平面上进行绘图。但是直到现在，我们才解决了在复杂平面上自动绘制甚至强大的病理函数的过程所需的数学和算法问题。

几年前，我还记得刻苦地绘制对数函数及其实部和虚部。现在， ReImPlot可以做到：

复杂功能的可视化是一个（复杂的）故事，细节在人们对某个功能的注意方面有很大的不同。因此，在12.0中我们要做的一件事情就是引入精心选择的标准化方式（例如命名的颜色函数）以突出显示不同的功能：

不确定性演算

现实世界中的测量通常具有不确定性，不确定性可以表示为具有±误差的值。我们提供了附加软件包，用于处理年龄段的“有错误的数字”。但是在12.0版中，我们正在建立具有不确定性的计算，而且我们做得对。

关键是[ x，δ ] 周围的符号对象，它表示值“ x周围”，不确定度δ ：

您可以使用Around进行算术运算，并且存在不确定性如何组合的整体计算方法：

如果您绘制数字，它们将显示为误差线：

有很多选择-例如，这是显示x和y的不确定性的一种方法：

您可以拥有数量：

而且，您还可以使用符号环绕对象：

但是，真正的“ 环绕对象”是什么？在某些情况下，存在基于不确定的正态分布来组合不确定性的某些规则。但是，没有人说过[ x，δ ]表示实际上详细遵循正态分布的任何事物，而[[ x，δ ]则表示在间隔 [{ x-δ， x +δ }]。只是对象周围会根据一致的通用规则传播错误或不确定性，从而成功地捕获了实验科学中通常要做的事情。

好的，假设您进行了一些有价值的测量。您可以使用MeanAround获得值的估计值及其不确定性（是的，如果度量本身具有不确定性，则在加权其贡献时将考虑这些不确定性）：

系统中的所有功能（尤其是机器学习中的功能）开始具有选项ComputeUncertainty- > True ，这使它们给出了Around对象而不是纯数字。

到处看似一个简单的概念，但它充满了微妙之处-这是直到现在它才进入系统的主要原因。许多微妙之处围绕不确定性之间的相关性。基本思想是，每个“ 周围”物体的不确定性均假定为独立的。但有时会有一些具有相关不确定性的值-因此，除了Around之外，还有VectorAround ，它表示具有指定协方差矩阵的潜在相关值的向量。

当处理代数公式之类的东西时，甚至还有更多的微妙之处。如果将此处的x替换为Around ，则按照Around的规则，假定每个实例都是不相关的：

但是，可能有人想在这里假设，即使x的值可能不确定，但对于每个实例它都是相同的，并且可以使用功能AroundReplace来做到这一点（注意结果是不同的）：

如何显示不确定数字有很多微妙之处。就像您应该输入多少个尾随的0：

或者您应该包括多少精度的不确定性（尾数为35时会有一个常规的断点）：

在少数情况下，许多数字是已知的（例如，一些物理常数），人们希望采用另一种方式来指定不确定性：

而且它还在继续。但是逐步地， Around将开始在整个系统中显示。顺便说一句，还有许多其他方法可以指定数字。这是一个相对误差为10％的数字：

这是Around可以代表间隔的最佳方法：

对于分布， Around计算方差：

通过提供不对称的不确定性，它也可以考虑不对称性：

经典数学，基础和高级

在进行数学计算时，既要“使一切正确”，又要不使基本用户感到困惑或恐吓始终是一个挑战。 12.0版引入了一些帮助。首先，尝试求解不可约的五次方程：

在过去，这会显示很多显式的Root对象。但是现在，根对象被格式化为显示其近似数值的框。计算的工作原理完全相同，但是显示并不会立即使人们不得不了解代数。

当我们说Integrate时，在反导数的意义上是指“找到一个积分”。但是在基本演算中，人们希望看到积分的显式常数（就像在Wolfram | Alpha中一样），因此我们为此添加了一个选项（C [ n ]也有一个不错的新输出形式）：

当我们对符号集成功能进行基准测试时，我们做得很好。但是总会有更多的事情要做，特别是在找到最简单形式的积分方面（从理论上讲，这是符号表达等价性无法确定的必然结果）。在12.0版中，我们继续在前沿进行介绍，并添加了以下示例：

在版本11.3中，我们引入了渐近分析，能够找到积分的渐近值，等等。 12.0版为方程式添加了渐近和，渐近递归和渐近解：

数学运算的一大优点就是它为我们提供了解释数学本身的新方法。我们一直在做的事情是增强我们的文档，以便它解释数学以及函数。例如，这是有关极限的文档的开始-带有图表和核心数学思想的示例：

多边形的更多内容

从版本1开始，多边形就已经成为Wolfram语言的一部分。但是在版本12.0中，它们已经得到了概括：现在有一种系统的方法可以在其中指定孔。一个典型的地理用例是南非的多边形-带有莱索托国家/地区的孔。

在12.0版中，就像Root一样， Polygon获得了一种方便的新显示形式：

您可以像以前一样使用它进行计算：

RandomPolygon也是新的。您可以以3D的形式询问5个随机凸多边形，每个多边形有10个顶点：

多边形上有许多新操作。类似于PolygonDecomposition ，它可以例如将多边形分解为凸形部分：

带孔的多边形也引入了对其他类型操作的需求，例如OuterPolygon ， SimplePolygonQ和CanonicalizePolygon 。

用多面体计算

多边形很容易指定：您只需按顺序给出其顶点（如果它们有孔，则还应给出这些孔的顶点）。多面体稍微复杂一点：除了给出顶点外，您还必须说出这些顶点如何形成面。但是在12.0版中， Polyhedron使您可以相当普遍地执行此操作，包括空隙（孔的3D模拟）等。

但是首先，认识到它们已有2000多年的历史，版本12.0引入了五种柏拉图固体的功能：

有了柏拉图固体，就可以立即开始使用它们进行计算：

这是对着顶点1的立体角（因为它是柏拉图式的，所以所有顶点都具有相同的角度）：

这是在多面体上完成的操作：

除了柏拉图固体之外，第12版还构建了所有“ 统一多面体 ”（在每个顶点上有n个边和m个面相交）—并且您还可以从PolyhedronData获得名为多面体的符号多面体版本：

您可以制作任何多面体（包括带有RandomPolyhedron的“随机”面体），然后在其上进行所需的任何计算：

欧几里得风格的几何可计算

Mathematica和Wolfram语言在执行显式计算几何和以代数表示的几何方面都非常强大。但是几何如何在Euclid的《元素》中完成呢？在几何中，人们提出了几何断言，然后看到它们的后果是什么？

好吧，在第12版中，借助我们构建的整个技术塔，我们终于能够提供一种新型的数学计算-实际上使Euclid 2000年前所做的工作实现了自动化。一个关键思想是引入具有表示诸如点之类的构造的符号的符号“几何场景”，然后根据它们定义几何对象和关系。

例如，这是一个几何场景，表示一个三角形a，b，c和一个通过a，b和c的圆，中心为o ，约束条件为o处于从a到c的直线的中点：

就其本身而言，这只是一个象征性的事情。但是我们可以对其进行操作。例如，我们可以要求它的随机实例，其中a，b，c和o是特定的：

您可以根据需要生成任意数量的随机实例。我们尝试使实例尽可能通用，而不会因约束而导致巧合：

好的，但是现在让我们“玩欧几里得”，找到与我们的设置一致的几何猜想：

对于给定的几何场景，可能会有许多可能的猜想。我们尝试挑选出有趣的东西。在这种情况下，我们提出了两个-第一个是图示：线ba与线cb垂直。碰巧的是，这个结果实际上出现在Euclid中（作为建议31的一部分出现在第三本书中）-尽管通常被称为Thales定理。

在12.0中，我们现在有了一种完整的符号语言，用于表示以Euclid风格几何图形出现的典型事物。这是一个更复杂的情况-与所谓的拿破仑定理相对应：

在12.0中，有许多新的有用的几何函数可用于显式坐标：

对于三角形，支持12种类型的“中心”，是的，可以有符号坐标：

为了支持设置几何语句，我们还需要“ 几何断言 ”。在12.0中，有29种不同的类型，例如“并行” ， “同余” ， “正切” ， “凸”等。以下是三个断言成对切线的圆：

用公理理论走向超级符号化

版本11.3引入了FindEquationalProof，用于生成证明的符号表示。但是这些证明应使用什么公理？ 12.0版引入了AxiomaticTheory ，它为各种常见的公理理论提供了公理。

这是我个人最喜欢的公理系统：

这是什么意思？从某种意义上说，它是一种比我们以前更具有象征意义的符号表达。在类似1 + x的情况下，我们没有说x的值是多少，但我们认为x可以有一个值。在上面的表达式中，a，b和c是纯粹的“形式符号”，在本质上起到结构性作用，永远不能被认为具有具体的价值。

·（中心点）呢？在1 + x中，我们知道+的含义。但是·旨在成为纯抽象运算符。公理的点实际上是在定义可表示的内容上的约束。在这种特殊情况下，事实证明，公理是布尔代数的公理，因此可以表示Nand和Nor 。但是我们可以完全正式地得出公理的结果，例如使用FindEquationalProof ：

所有这些都有很多微妙之处。在上面的示例中，使用·作为运算符非常有用，尤其是因为它显示得很好。但是它没有内在的含义，并且AxiomaticTheory允许您提供其他内容（在此处f ）作为运算符：

那边的“ Nand”在做什么？这是运算符的名称（但不应将其解释为与运算符的值有关）。例如，在群论公理中，出现了几个运算符：

这给出了各种运算符的默认表示形式：

AxiomaticTheory知道有关特定公理系统的著名定理：

在版本7中引入了形式符号的基本概念，用于在生成的结构中表示虚拟变量，例如：

您可以使用\ [FormalA]或Esc，a，Esc等输入正式符号。但是回到版本7，
\ [FormalA]呈现为。这意味着上面的表达式看起来像：

我一直认为这看起来异常复杂。对于版本12，我们想简化它。我们尝试了多种可能性，但最终都选择了单个灰色底纹-我认为它看起来要好得多。

在AxiomaticTheory中，变量和运算符都是“纯符号”的。但是确定的一件事是每个运算符的友善程度，可以问AxiomaticTheory ：

方便的是，可以将运算符和arities的表示形式立即输入Groupings中，以获得涉及特定变量的可能表达式：

n身体问题

公理理论代表了数学的经典历史领域。 n体问题是另一个经典的历史领域，更多的是在应用方面。 12.0版引入了NBodySimulation ，它可以模拟n体问题。这是一个具有某些初始条件（以及平方反比定律）的三体问题（例如Earth-Moon-Sun ）：

您可以询问解决方案的各个方面。这将位置作为时间的函数进行绘制：

在下面，这只是求解微分方程式，但是-有点像SystemModel - NBodySimulation提供了一种方便的方法来建立方程式并处理其解。而且，是的，内置了标准力法则，但是您可以定义自己的法则。

语言扩展和便利

三十多年来，我们一直在完善Wolfram语言的核心，在每个后续版本中，我们最终都会引入一些新的扩展和便利。

从1.0版开始，我们就具有信息功能，但是在12.0版中，我们对其进行了很大的扩展。它曾经只是提供有关符号的信息（尽管它也已经现代化）：

但是现在它也提供了有关许多对象的信息。以下是有关分类器的信息：

以下是有关云对象的信息：

将鼠标悬停在“信息框”中的标签上，即可找到相应属性的名称：

对于实体，信息提供了已知属性值的摘要：

在过去的几个版本中，我们引入了许多新的摘要显示表单。在版本11.3中，我们引入了Iconize ，它本质上是一种为任何内容创建摘要显示表单的方式。实践证明，Iconize比我们最初预期的要有用。这对于隐藏笔记本和Wolfram语言代码中不必要的复杂性非常有用。在12.0中，我们重新设计了Iconize的显示方式，特别是使其在表达式和代码中“很好地阅读”。

您可以显式图标化某些内容：

按+，您将看到一些详细信息：

按下

然后您将再次获得原始表达式：

如果您要在计算中引用大量数据，则始终可以将其存储在文件中或云中（甚至存储在数据存储库中）。但是，通常将它放在笔记本中会更方便，因此您可以将所有内容都放在同一位置。避免数据“接管您的笔记本”的一种方法是将其放在封闭的单元格中。但是Iconize提供了一种更灵活，更优雅的方式来执行此操作。

在编写代码时，“就地图标化”通常很方便。现在，右键单击菜单可让您执行以下操作：

说到显示，这是我们在12.0中添加的一些小而方便的东西：

这是我们添加的其他两个“数字便利”：

函数式编程一直是Wolfram语言的核心部分。但是，我们一直在寻求扩展它，并引入新的，通常有用的原语。 SubsetMap是版本12.0中的一个示例：

函数通常是可以接受多个输入但总会给出单个输出的事物。但是，在诸如量子计算之类的领域，人们反而对拥有n个输入和n个输出感兴趣。 SubsetMap有效地实现n-> n个函数，从列表中n个指定位置提取输入，对其进行一些操作，然后将结果放回相同的n个位置。

大约一年前，我开始制定现在的SubsetMap 。我很快意识到，实际上，多年来我确实可以在各种地方使用此功能。但是，这种特殊的“计算工作量”应该称为什么？我最初的工作名称是ArrayReplaceFunction （在我的笔记中简称为ARF ）。在一系列（直播）会议中，我们来回走了。有一些想法，例如ApplyAt （但不是真正的Apply ）和MutateAt （但是在左值意义上并没有做突变），还有RewriteAt ， ReplaceAt ， MultipartApply和ConstructInPlace 。有一些关于咖喱式“函数装饰器”形式的想法，例如PartAppliedFunction ， PartwiseFunction ， AppliedOnto ， AppliedAcross和MultipartCurry 。

但是以某种方式解释功能时，我们会继续讨论该功能在列表的子集上的运行方式，以及它实际上与Map的关系，只是一次要在多个元素上运行。所以最后我们确定了名称SubsetMap 。并且-进一步增强了语言设计的重要性-令人惊讶的是，一旦有人为这样的名称命名，如何立即发现自己能够对此进行推理，并查看可以在何处使用它。

用图像计算

从版本10.1 开始，我们引入了ImageIdentify ，用于识别图像的含义。在版本12.0中，我们设法对此进行了概括，不仅要弄清楚图像的含义，而且要弄清楚图像中的内容。因此，例如， ImageCases将向我们展示图像中已知种类的对象的情况：

有关更多详细信息， ImageContents给出了有关图像内容的数据集：

您可以告诉ImageCases寻找特定种类的东西：

而且，您还可以测试图像是否包含特定种类的东西：

从某种意义上讲， ImageCases类似于FindFaces的通用版本，用于查找图像中的人脸。 12.0版中的新功能是FindFaces和FacialFeatures变得更加高效和强大 -如今， FindFaces基于神经网络而不是传统的图像处理，并且FacialFeatures的网络现在为10 MB，而不是500 MB：

像ImageCases之类的功能代表“新型”图像处理，这种类型的处理似乎在几年前才想到。但是，尽管这样的功能可以让人们做各种各样的新事情，但是在更经典的技术中仍然有很多价值。很长时间以来，我们已经用Wolfram语言完成了相当完整的经典图像处理，但是我们仍在不断进行改进。

版本12.0中的一个示例是ImagePyramid框架，用于执行多尺度图像处理：

12.0版中有几个与颜色计算有关的新功能。一个关键的想法是ColorsNear ，它代表感知颜色空间中的一个邻居，这里围绕着粉红色：

例如，可以在新的ImageRecolor函数中使用颜色邻域的概念：

语音识别及更多音频

当我坐在计算机上写这篇文章时，我将对计算机说些话，然后将其捕获：

这是我捕获的音频的频谱图：

到目前为止，我们可以在11.3版中执行此操作（尽管频谱图在12.0版中的速度提高了10倍）。但是现在有一些新东西：

我们正在做语音转文字！我们正在使用最先进的神经网络技术，但我对它的运行效果感到惊讶。它非常精简，而且我们能够很好地处理甚至很长的音频，例如存储在文件中的音频。在典型的计算机上，转录将以实际的实时速度进行，因此一个小时的语音翻译将需要大约一个小时。

目前，我们认为语音识别是实验性的，我们将继续对其进行改进。但是有趣的是，另一个主要的计算任务只是成为Wolfram语言中的一个函数。

在12.0版中，还有其他增强功能。 SpeechSynthesize支持新的语言和新的声音（如VoiceStyleData []所列）。

现在有类似于WebImageSearch的WebAudioSearch，它使您可以在网络上搜索音频：

您可以检索实际的音频对象：

然后，您可以进行频谱图或其他测量：

然后-版本12.0中的新增功能-您可以使用AudioIdentify尝试识别声音的类别（是说话的公鸡吗？）：

我们仍然认为AudioIdentify是实验性的。这是一个有趣的开始，但是例如ImageIdentify确实不能正常工作。

一个更成功的音频功能是PitchRecognize ，它试图识别音频信号中的主导频率（它同时使用“经典”方法和神经网络方法）。它尚不能处理“和弦”，但对于“单个音符”而言，它的效果非常好。

当处理音频时，人们通常不仅希望识别音频中的内容，而且还要对其进行注释。 12.0版引入了大规模音频框架的开始。现在， AudioAnnotate可以标记沉默的地方或大声的地方。将来，我们将添加说话人识别和单词边界以及许多其他功能。除此之外，我们还具有AudioAnnotationLookup之类的功能，用于挑选音频对象中以特定方式进行了注释的部分。

在所有这些高级音频功能的下方，都有一个完整的低级音频处理基础架构。 12.0版大大增强了AudioBlockMap （用于将滤波器应用于音频信号），并引入了诸如ShortTimeFourier之类的功能。

频谱图可以有点像乐谱的连续模拟，其中音高是时间的函数。在12.0版中，现在有了InverseSpectrogram，它从一系列频谱图数据转换为音频。从1991年的Version 2开始，我们就开始使用Play从一个函数（如Sin [100 t]）生成声音。现在，借助逆频谱图，我们有了从“频率-时间位图”转换为声音的方法。（而且，是的，当一个相位只有量级信息时，存在关于相位的最佳猜测的棘手问题。）

自然语言处理

从Wolfram | Alpha开始，我们已经拥有了非常强大的自然语言理解（NLU）功能。这意味着，给定一种自然语言，我们就可以很好地将其理解为Wolfram语言-然后我们可以从中进行计算：

但是自然语言处理（NLP）怎么样？在这种情况下，我们正在花很长的时间来使用自然语言，而不是试图完全理解它们，而只是查找或处理它们的特定功能？诸如TextSentences ， TextStructure ， TextCases和WordCounts之类的功能在一段时间内为我们提供了该领域的基本功能。但是在12.0版中-通过利用最新的机器学习以及我们长期的NLU和知识库功能-我们现在已经跃升为具有非常强大的NLP功能。

核心是TextCases的显着增强版本。 TextCases的基本目标是在一段文本中查找不同类型的内容的案例。这方面的一个例子是经典的NLP任务“实体识别”， TextCases可以在Wikipedia文章中找到有关 ocelots的国家名称：

我们还可以询问提到了哪些岛屿，但是现在我们不要求使用Wolfram语言解释：

TextCases并不是完美的，但效果很好：

它也支持很多不同的内容类型：

您可以要求它查找代词，简化的从句，数量，电子邮件地址或150种实体（例如公司，工厂或电影）中的任何一种。您还可以要求它挑选出特定于人类或计算机语言的文本，或者与特定主题（例如旅行或健康）相关的文本，或者具有正面或负面情绪的文本。而且，您可以使用诸如Containing之类的构造来要求这些东西的组合（例如包含河流名称的名词短语）：

例如， TextContents可让您查看在特定文本中检测到的所有实体的详细信息：

而且，是的，原则上可以通过FindTextualAnswer使用这些功能来尝试回答文本中的问题-但是在这种情况下，结果可能很古怪：

当然，您可以从我们实际的内置精选知识库中获得真正的答案：

顺便说一下，在版本12.0中，我们添加了各种小的“自然语言便捷功能”，例如同义词和反义词：

计算化学

12.0版中的“惊奇”新领域之一是计算化学。很长时间以来，我们就已经在已知的已知化学物质中获得了数据。但是在12.0版中，我们可以使用简单指定为纯符号对象的分子进行计算。这是我们可以指定什么是水分子的方法：

这是我们制作3D渲染的方法：

我们可以处理“已知化学物质”：

我们可以使用任意IUPAC名称：

或者我们“组成”化学物质，例如通过其SMILES字符串指定它们：

但是我们不只是在这里生成图片。我们还可以从结构中计算出事物，例如对称性：

给定一个分子，我们可以做一些事情，例如加亮碳-氧键：

或突出显示结构，例如由SMARTS字符串指定的结构（此处为任何5元环）：

您也可以搜索“分子模式”。结果以原子数表示：

我们在12.0版中添加的计算化学功能非常通用且非常强大（需要注意的是，到目前为止，它们仅处理有机分子）。在最低级别上，他们将分子视为带有与键相对应的边缘的标记图。但是他们也了解物理学，并且正确地解释了原子价和键构型。不用说，有很多细节（关于立体化学，对称性，芳香性，同位素等）。但是最终结果是，分子结构和分子计算现已成功添加到Wolfram语言所集成的区域列表中。

地理计算扩展

Wolfram语言已经具有强大的地理计算功能，但是12.0版增加了更多功能，并增强了其中一些功能。

例如，现在有RandomGeoPosition ，它会生成一个随机的经纬度位置。有人可能会认为这是微不足道的，但当然必须担心坐标转换–使得它变得更加微不足道的是，人们可以告诉它仅在特定区域内（这里是法国）来选择点：

12.0版中新的地理功能的主题不仅是处理地理点和区域，而且还处理地理矢量。这是当前的风向矢量，例如，在埃菲尔铁塔的位置，以GeoVector表示，具有速度和方向（还有GeoVectorENU ，它提供东，北和上分量，以及GeoGridVector和GeoVectorXYZ ）：

诸如GeoGraphics之类的功能可让您可视化离散的地理矢量。 GeoStreamPlot是StreamPlot （或ListStreamPlot ）的地理模拟-并显示由地理矢量（此处为WindDirectionData ）形成的流线：

大地测量学是一个数学复杂的领域，我们为自己在Wolfram语言中的出色表现而感到自豪。在12.0版中，我们添加了一些新功能来填充一些细节。例如，我们现在具有诸如GeoGridUnitDistance和GeoGridUnitArea之类的函数，这些函数给出与地球上每个位置（或月球，火星等）上不同的地理投影相关的失真（基本上是雅可比矩阵的特征值）。

许多可视化方面的增强

我们一直在稳步发展的可视化方向之一就是所谓的“元图形”：图形事物的标记和注释。我们在11.0版中引入了标注；在12.0版中，它已扩展到3D图形之类的东西：

弄清楚在哪里标记事物非常好，即使它们变得有点复杂：

要使图形看起来真的很漂亮，有很多细节很重要。 12.0版中已增强的功能是确保图形的列在其框架上对齐，而与刻度标签的长度无关。我们还添加了LabelVisibility ，它使您可以指定应该使不同标签可见的相对优先级。

版本12.0的另一个新功能是多面板图版式，其中不同的数据集显示在不同的面板中，但是只要有可能，面板就共享轴：

加强知识库集成

我们精心挑选的知识库（例如为Wolfram | Alpha提供支持的知识库）是庞大且不断增长的。在每个版本的Wolfram语言中，我们都在逐步加强其与语言核心的集成。

在12.0版中，我们要做的一件事就是直接用该语言公开数百种实体：

在12.0版之前，“ Wolfram | Alpha示例”页面用作记录多种类型实体的代理。但是现在有针对所有这些语言的Wolfram语言文档：

仍然有诸如SatelliteData ， WeatherData和FinancialData之类的功能来处理通常需要复杂选择或计算的实体类型。但是在版本12.0中，可以使用自然语言（“ control + =”）输入以及“黄色框”实体和属性以相同的方式访问每种实体类型：

顺便说一句，也可以隐式使用实体，例如在这里要求具有已知最高熔点的5个元素：

并且可以使用Dated来获取时间序列值：

从外部数据库集成大数据

使用Wolfram Knowledgebase内置的数据，我们已经非常方便。您有实体，并且很容易询问属性等等：

但是，如果您有自己的数据怎么办？您可以设置它以便如此轻松地使用它吗？版本11的一项主要新功能是增加了EntityStore ，它可以定义自己的实体类型，然后指定实体，属性和值。

Wolfram数据存储库包含大量实体存储示例。这是一个：

它描述了单个实体类型： “ SWLibraryBook” 。为了能够像内置实体一样使用这种类型的实体，我们“注册”实体存储：

现在，我们可以做一些事情，例如请求10个类型为“ SWLibraryBook”的随机实体：

实体存储中的每个实体都有各种属性。这是一个特定实体的属性值的数据集：

好的，但是通过这种设置，我们基本上是将实体存储的全部内容读取到内存中。这使得执行所需的Wolfram语言操作非常高效。但是对于大量数据（例如，太大而无法容纳在内存中的数据）来说，这不是一个很好的可伸缩解决方案。

但是大数据的典型来源是什么？通常，它是一个数据库，通常是一个可以使用SQL访问的关系数据库。十多年来，我们已经拥有DatabaseLink软件包，用于对SQL数据库的低级别读写访问。但是在12.0版中，我们添加了一些主要的内置功能，这些功能允许使用Wolfram语言处理外部关系数据库，就像实体存储或Wolfram知识库的内置部分一样。

让我们从一个玩具示例开始。这是恰好存储在文件中的小型关系数据库的符号表示：

马上我们得到一个框，它总结了数据库中的内容，并告诉我们该数据库有8个表。如果打开框，我们可以开始检查这些表的结构：

然后，我们可以将该关系数据库设置为Wolfram语言中的实体存储。它看起来与上面的图书馆书本实体非常相似，但是现在实际的数据没有被拉到内存中了。相反，它仍然在外部关系数据库中，而我们只是在Wolfram语言中定义了（类似于ORM的）实体映射：

现在我们可以注册该实体存储，这将设置一堆实体类型（至少默认情况下），这些实体类型以数据库中表的名称命名：

现在，我们可以像在Wolfram知识库中的内置实体上那样对它们进行“实体计算”。这里的每个实体对应于数据库中“员工”表中的一行：

对于给定的实体类型，我们可以询问其具有哪些属性。这些“属性”对应于基础数据库中表中的列：

现在我们可以要求特定实体的特定属性的值：

我们还可以通过给出标准来挑选实体；在这里，我们要求“付款”实体的“金额”属性的值最大为4：

我们同样可以要求以下最大金额的值：

好的，但是这里变得更加有趣：到目前为止，我们一直在研究一个小的文件支持的数据库。但是，对于外部服务器上托管的巨型数据库，我们可以做完全相同的事情。

例如，让我们连接到TB级的OpenStreetMap PostgreSQL数据库，该数据库基本上包含世界的街道地图：

和以前一样，让我们在此数据库中将表注册为实体类型。像大多数野生数据库一样，结构中的故障很少，可以解决，但会生成警告：

但是现在我们可以问有关数据库的问题，例如世界上所有街道上有多少个地理点或“节点”（是的，这是一个很大的数字，这就是数据库很大的原因）：

在这里，我们要询问（101 GB）planet_osm_polygon表中具有10个最大（投影）区域的对象的名称（是的，它需要一秒钟的时间）：

那么这一切如何运作？基本上发生的是，我们的Wolfram语言表示形式已被编译成低级SQL查询，然后将其发送以直接在数据库服务器上执行。

有时，您会要求获得的结果只是最终值（例如，上面的“金额”）。但是在其他情况下，您会需要一些中间的东西-例如以特定方式选择的实体集合。当然，这个收藏可能会有十亿个条目。因此，我们在版本12.0中引入的一个非常重要的功能是，我们可以纯粹地象征性地表示和操作这些事物，直到最后才将它们解析为特定的事物。

回到我们的玩具数据库，下面是一个示例，该示例如何指定通过汇总具有给定国家/地区值的所有客户的总creditLimit获得的实体类别：

起初，这只是象征性的东西。但是，如果我们要求特定的值，那么实际的数据库查询就完成了，并且我们获得了特定的结果：

有一系列新功能可用于设置不同种类的查询。这些功能实际上不仅适用于关系数据库，而且适用于实体商店和内置的Wolfram知识库。因此，例如，我们可以要求元素周期表中给定时间段的平均原子质量：

一个重要的新构造是EntityFunction 。 EntityFunction类似于Function ，不同之处在于EntityFunction的变量表示实体（或实体的类），并且它描述可以直接在外部数据库上执行的操作。这是一个带有内置数据的示例，其中我们定义了一个“已过滤”实体类，其中过滤条件是测试总体值的函数。 FilteredEntityClass本身只是象征性地表示，但是EntityList实际上执行查询，并解析（此处为未排序的）实体的显式列表：

除了EntityFunction ， AggregatedEntityClass和SortedEntityClass之外，版本12.0还包括SampledEntityClass （从类中获取一些实体）， ExtendedEntityClass （以添加计算属性）和CombinedEntityClass （以组合来自不同类的属性）。有了这些原语，就可以建立“ 关系代数 ”的所有标准运算。

在标准数据库编程中，通常以“连接”和“外键”等的整个丛林结束。我们的Wolfram语言表示形式使您可以在更高层次上进行操作-基本上，联接成为函数组合，而外键只是不同的实体类型。（但是，如果要进行显式连接，则可以使用例如CombinedEntityClass 。）

实际情况是，所有那些Wolfram语言构造都已被编译成SQL，或更准确地说，是适合您所使用的特定数据库的SQL的特定方言（我们目前支持SQLite ， MySQL ， PostgreSQL和MS -SQL ，即将支持OracleSQL 。进行编译时，我们会自动检查类型，以确保您得到有意义的查询。即使是相当简单的Wolfram语言规范也可能最终变成许多行SQL。例如

会产生以下中间SQL（此处用于查询SQLite数据库）：

我们在12.0版中拥有的数据库集成系统非常复杂-我们已经在该系统上工作了很多年。这是向前迈出的重要一步，它使Wolfram语言可以直接处理大数据的新“大”水平，并让Wolfram语言直接对TB级的数据集进行数据科学。就像发现世界上哪些街道式实体的名称中带有“ Wolfram”一样：

RDF，SPARQL等

代表有关世界的知识的最佳方法是什么？自古以来，这个问题就一直被哲学家（和其他人）争论。有时人们说逻辑是关键。有时是数学。有时是关系数据库。但是现在我们至少知道一个坚实的基础（或者至少，我很确定我们知道）：一切都可以用计算来表示。这是一个强大的想法-从某种意义上讲，这就是使我们使用Wolfram语言所做的一切成为可能。

但是，是否存在通用计算的子集可用于表示至少某些种类的知识？我们在Wolfram知识库中广泛使用的一种概念是实体（“纽约市”），财产（“人口”）及其价值（“ 860万人”）的概念。当然，这样的三元组并不能代表世界上所有的知识（“火星明天的位置将是什么？”）。但是，当涉及到有关不同事物的某些“静态”知识时，它们是一个不错的起点。

那么如何才能形式化这种知识表示呢？一个答案是通过图形数据库。在12.0版中（与许多“语义Web”项目保持一致），我们支持使用RDF的图形数据库，并使用SPARQL对其进行查询。在RDF中，中心对象是IRI （“国际化资源标识符”），它可以表示实体或属性。然后，“ 三元组 ”由三元组（“主题”，“谓词”，“对象”）组成，每个三元组中的每个元素都是IRI（或文字，例如数字）。然后可以将整个对象视为图形数据库或图形存储，或者在数学上称为超图。（这是一个超图，因为谓词“边缘”也可以是其他位置的顶点。）

您可以像构建EntityStore一样构建自己的RDFStore －实际上，您可以像查询RDFStore一样使用SPARQL查询任何Wolfram语言EntityStore 。而且由于Wolfram知识库的实体属性部分可以视为实体存储，因此您也可以查询此实体。因此，这里最后是一个示例。国家/城市列表实体 [“ Country ”]，实体 [“ City ”]}实际上代表RDF商店。那么SPARQLSelect是对该存储执行操作的运算符。它的作用是尝试找到一个与您的要求匹配的三元组，并为“ SPARQL变量” x赋予特定值：

当然，在Wolfram语言中，还有一种更简单的方法可以做到这一点：

但是，借助SPARQL，您可以做更多奇特的事情-例如询问与美国和墨西哥相关的房地产：

或者是否存在从葡萄牙到德国的基于邻国关系的道路：

原则上，您可以仅将SPARQL查询作为字符串编写（有点像可以编写SQL字符串）。但是我们在版本12.0中所做的是引入了SPARQL的符号表示形式，该符号表示形式允许对表示形式本身进行计算，例如，可以轻松地自动生成复杂的SPARQL查询。（并且这样做特别重要，因为单独的实际SPARQL查询习惯变得非常冗长和费力。）

可以，但是在野外有RDF存储吗？一个长期的希望是，Web的很大一部分将以某种方式进行足够的标记以“成为语义”，并实际上是一个巨大的RDF存储。如果发生这种情况会很好，但是到目前为止绝对没有。仍然有一些公共RDF商店，以及组织内的一些RDF商店，借助我们在12.0版中的新功能，我们处于与他们一起做有趣事情的独特位置。

数值优化

在数学的工业应用中，一种非常普遍的问题形式是：“如果必须满足某些约束条件，哪种配置可以使成本最小化（或使收益最大化）？” 半个多世纪以前，发明了所谓的单纯形算法来解决此类问题的线性形式，其中目标函数（成本，收益）和约束条件都是问题中变量的线性函数。到1980年代，已经发明了效率更高的（“内部点”）方法，并且很长时间以来，我们就一直使用这些方法来进行Wolfram语言中的“ 线性编程 ”。

但是非线性问题呢？好吧，在一般情况下，可以使用NMinimize之类的功能。他们所做的是最先进的工作。但这是一个难题。但是，几年前，很明显，即使在非线性优化问题中，也存在一类所谓的凸优化问题，实际上可以像线性问题一样有效地解决。（“凸”表示目标和约束都只包含凸函数-因此，当一个函数逼近极值时，没有任何东西可以“摆动”，并且不会存在不是全局最小值的任何局部最小值。）

在12.0版中，我们现在对凸优化的所有各种标准类都有了强大的实现。这是一个简单的情况，涉及最小化具有两个线性约束的二次形式：

NMinimize可以在版本11.3中解决此特定问题：

但是，如果有更多变量，旧的NMinimize将很快陷入困境。但是，在12.0版中，二次优化将继续正常运行，最多可以处理100,000个以上的变量，且约束超过100,000个（只要它们相当稀疏）。

在12.0版中，我们获得了“原始凸优化”功能，例如SemidefiniteOptimization （处理线性矩阵不等式）和ConicOptimization （处理线性向量不等式）。但是，像NMinimize和FindMinimum这样的函数也可以自动识别何时可以通过转换为凸优化形式来有效解决问题。

一个如何设置凸优化问题？较大的变量涉及对整个向量或变量矩阵的约束。在12.0版中，我们现在有了VectorGreaterEqual之类的功能（输入为≥），可以立即表示这些功能。

非线性有限元分析

偏微分方程很难，而且我们已经致力于处理它们的越来越复杂的通用方法已有30年了。 1991年，我们首次在版本2中引入了NDSolve （用于ODE）。到1990年代中期，我们有了第一个（1 +1维）数值PDE。在2003年，我们引入了强大的模块化框架来处理数值微分方程。但是就PDE而言，我们基本上仍然只处理简单的矩形区域。为了超出构建第10版中引入的整个计算几何系统的要求，并以此发布了第一个有限元PDE求解器。然后，在版本11中，我们归纳为特征问题。

现在，在版本12中，我们将介绍另一个主要的概括：非线性有限元分析。有限元分析涉及将区域分解为小的离散三角形，四面体等，在这些三角形上，原始PDE可以通过大量耦合方程式近似。当原始PDE是线性的时，这些方程式也将是线性的—这就是人们在谈论“有限元分析”时所考虑的典型情况。

但是，有许多具有实际重要性的PDE并不是线性的-要解决这些问题，需要进行非线性有限元分析，这是我们现在在版本12.0中所拥有的。

例如，以下是解决非线性非线性PDE的方法，该非线性PDE描述了2D最小表面（例如理想化的肥皂膜）的高度，此处在环形区域上具有（狄利克雷）边界条件，使其在正弦上摆动。边缘（好像肥皂膜从电线上悬挂了）：

在我的计算机上，仅需四分之一秒即可求解此方程式，并获得插值函数。这是代表解的插值函数图：

新的，复杂的编译器

多年来，我们已经投入大量工程来优化Wolfram语言程序的执行。早在1989年，我们就开始自动将简单的机器精度数值计算编译为有效的虚拟机的指令（并且碰巧，我为此编写了原始代码）。多年来，我们已经扩展了此编译器的功能，但始终仅限于相当简单的程序。

在12.0版中，我们迈出了重要的一步，并且我们发布了一个新的，功能更强大的编译器的第一个版本，该版本已经开发了好几年。该编译器既可以处理更广泛的程序（包括复杂的功能构造和复杂的控制流程），也可以不编译为虚拟机，而是直接编译为优化的本机代码。

在12.0版中，我们仍然考虑使用新的编译器。但是它正在迅速发展，它将对Wolfram语言中许多事物的效率产生巨大影响。在12.0版中，我们只是公开具有特定编译功能的新编译器的“工具包形式”。但是，我们将逐步使编译器越来越多地自动运行-在值得花时间进行什么级别的编译时，通过机器学习和其他方法来解决。

在技术层面上，新的Version 12.0编译器基于LLVM，并通过生成LLVM代码来工作-链接到Wolfram语言内核本身使用的同一低级运行时库，并回调完整的Wolfram语言内核以获取功能不在运行时库中。

这是在新版本的当前编译器中编译纯函数的基本方法：

生成的编译代码函数的工作原理与原始函数相同，但速度更快：

使FunctionCompile生成更快的函数的很大一部分是，您要告诉它对要获取的参数类型进行假设。我们支持许多基本类型（例如“ Integer32 ”和“ Real64 ”）。但是，当使用FunctionCompile时，您将提交特定的参数类型，因此可以生成更多简化的代码。

新编译器的许多复杂之处与推断在程序执行中将生成什么类型的数据有关。（涉及许多图论和其他算法，不用说，编译器的所有元编程都是使用Wolfram语言完成的。）

这是一个涉及类型推断的示例（ fib的类型推导为“ Integer64”->“ Integer64” ：返回整数的整数函数）：

在我的计算机上， cf [25]运行的速度比未编译的功能快300倍。（当然，当编译版本的输出不再是“ Integer64 ”类型时，编译版本就会失败，但是标准Wolfram语言版本仍然可以正常工作。）

编译器已经可以处理数百种Wolfram语言编程原语，可以适当地跟踪产生的类型，并生成直接实现这些原语的代码。但是，有时候，人们可能想在Wolfram语言中使用复杂的函数，而对于这些函数而言，生成自己的编译代码没有任何意义-而真正想做的只是调用Wolfram语言内核中的这些函数。在12.0版中， KernelFunction可以做到这一点：

好的，但是，假设有一个已编译的代码函数。它可以做什么？好吧，首先可以在Wolfram语言中运行它。一个人也可以存储它，然后再运行它。对于特定的处理器体系结构（例如64位x86），可以完成任何特定的编译。但是，如果需要， CompiledCodeFunction会自动保留足够的信息以对其他体系结构进行其他编译。

但是，有了CompiledCodeFunction ，有趣的新可能性之一就是可以直接生成甚至可以在Wolfram语言环境之外运行的代码。（我们的旧编译器具有CCodeGenerate软件包，该软件包在简单的情况下提供了稍微相似的功能-尽管即使这样仍依赖于精心编写的C编译器的工具链等。）

这是导出原始LLVM代码的方式（请注意，尾递归优化之类的操作会自动完成-并且还要注意符号函数和编译器选项的末尾）：

如果使用FunctionCompileExportLibrary ，则将获取一个库文件-Mac上的.dylib，Windows上的.dll以及Linux上的.so。可以通过执行LibraryFunctionLoad在Wolfram语言中使用它。但是也可以在外部程序中使用它。

决定新编译器通用性的主要因素之一是其类型系统的丰富性。现在，编译器支持14种原子类型（例如“ Boolean ”，“ Integer8 ”，“ Complex64 ”等）。它还支持“ PackedArray ”之类的类型构造函数，例如， TypeSpecifier [“ PackedArray ”] [ “ Real64”，2 ]对应于64位实数的等级2压缩数组。

在Wolfram语言的内部实现中（顺便说一下，它本身主要是在Wolfram语言中），我们有一种优化的方法可以长时间存储数组。在12.0版中，我们将其公开为NumericArray 。与普通的Wolfram语言构造不同，您必须详细告诉NumericArray应该如何存储数据。但是随后它以一种很好的优化方式工作：

调用Python和其他语言

在版本11.2中，我们引入了ExternalEvaluate ，它使您可以从Wolfram语言中使用Python和JavaScript之类的语言进行计算（在Python中，“ ^”表示BitXor ）：

在版本11.3中，我们引入了外部语言单元，以简化在笔记本中直接输入外部语言程序或其他输入的操作：

在12.0版中，我们正在加强集成。例如，在外部语言字符串中，可以使用<* ... *>给出Wolfram语言代码以进行评估：

这也适用于外部语言单元：

当然，Python不是Wolfram语言，所以很多事情不起作用：

但是ExternalEvaluate至少可以从Python返回许多类型的数据，包括列表（如List ），字典（如Association ），图像（如Image ），日期（如DateObject ）， NumPy数组（如NumericArray ）和熊猫数据集（如TimeSeries）， DataSet等）。（ ExternalEvaluate也可以返回ExternalObject ，该对象基本上是可以发送回Python的对象的句柄。）

您也可以直接使用外部函数（稍微奇怪的ord基本上是ToCharacterCode的Python类似物）：

这是一个Python纯函数，用Wolfram语言象征性地表示：

从Python和其他地方调用Wolfram语言

一个人应该如何使用Wolfram语言？有很多方法。一个人可以直接在笔记本上使用它。可以调用在云中执行它的API 。或者可以在命令行shell中使用WolframScript 。 WolframScript可以针对本地Wolfram引擎运行，也可以针对云中的Wolfram引擎运行。它使您可以直接给出要执行的代码：

它使您可以执行诸如定义函数之类的事情，例如使用文件中的代码：

随着版本12.0的发布，我们还发布了第一个针对Python的新Wolfram语言客户端库。该库的基本思想是使Python程序易于调用Wolfram语言。（值得指出的是，通过有效的WSTP ，我们已经有效地拥有了至少30年的C语言客户端库。）

语言客户端库的工作方式因不同的语言而异。对于Python（作为一种解释语言（实际上是早期Wolfram语言所提供的信息））来说，它特别简单。之后您建立特写库，并启动会话（本地或云），你可以当时只是由钨评价语言下面的代码和得到的结果早在Python的：

您可以通过沃尔弗拉姆还可以直接访问语言功能的（与一种以逆ExternalFunction）：

您可以直接与pandas结构，NumPy数组等交互。实际上，您实际上可以将整个Wolfram语言视为可以从Python访问的巨型库。或者，当然，您可以直接使用精美的集成Wolfram语言，如果需要，可以创建外部API。

Wolfram“ Super Shell”的更多内容

使用Wolfram语言的一项功能是，它使您不必考虑计算机系统的详细信息以及文件和进程之类的内容。但是有时人们想要在系统级别上工作。对于相当简单的操作，您可以只使用操作系统GUI。但是对于更复杂的事情呢？过去，我通常会使用Unix shell。但是很长一段时间以来，我改用Wolfram语言。

将所有内容都放在笔记本中当然非常方便，并且能够以编程方式使用诸如FileNames（ls），FindList（grep），SystemProcessData（ps），RemoteRunProcess（ssh）和FileSystemScan。但是在12.0版中，我们添加了许多附加功能来支持将Wolfram语言用作“超级外壳”。

有一个RemoteFile用来象征性地表示一个远程文件（如果需要的话，带有身份验证）-您可以立即在CopyFile之类的函数中使用它。有FileConvert可直接在不同格式之间转换文件。

并且，如果您真的想深入研究，请按照以下方法在来自wolfram.com的读取中跟踪端口80和443上的所有数据包：

伪造网络浏览器

在Wolfram语言中，使用URLExecute和HTTPRequest之类的功能以及$ Cookies等，很长时间以来一直很容易与Web服务器进行交互。但是在12.0版中，我们添加了一些新功能：Wolfram语言可以控制Web浏览器，并以编程方式使其能够完成我们想要的功能。我们能做的最直接的事情就是将网站的外观图像显示在网络浏览器上：

结果是我们可以使用以下图像进行计算：

要进行更详细的操作，我们必须启动浏览器会话（我们目前支持Firefox和Chrome）：

随即，一个空白的浏览器窗口出现在我们的屏幕上。现在，我们可以使用WebExecute打开网页：

现在我们打开了页面，可以运行许多命令。这将单击第一个包含文本“ Programming Lab”的超链接：

这将返回我们已经到达的页面的标题：

您可以键入字段，运行JavaScript，并基本上以编程方式执行您可以使用网络浏览器进行的任何操作。不用说，多年来我们一直在公司内部使用该技术的版本来测试我们所有的各种网站和Web服务。但是现在，在版本12.0中，我们将提供一个简化的版本，该版本普遍可用。

独立微控制器

对于当今世界上的每台通用计算机，运行微控制器而无需任何通用操作系统的微控制器的数量大概是其的十倍。微控制器的价格可能在几美分到几美元之间，而在中档汽车之类的产品中，可能会有30美分。

在12.0版中，我们引入了Wolfram语言的微控制器套件，该套件使您可以提供符号规范，并从中自动生成和部署代码以在微控制器中自主运行。在典型设置中，微控制器会不断对来自传感器的数据进行计算，并实时向执行器输出信号。在控制理论和信号处理中，最常见的计算类型是有效的计算类型。

长期以来，我们一直支持直接使用Wolfram语言进行控制理论和信号处理。但是现在，微控制器工具包可以采用语言中指定的内容，并将其作为嵌入式代码下载到独立的微控制器中，该微控制器可以部署在任何地方（在设备，IoT，设备等中）。

例如，以下是如何生成模拟信号处理滤波器的符号表示的方法：

我们可以直接在Wolfram语言中使用此过滤器-假设使用RecurrenceFilter将其应用于音频信号。我们还可以做一些事情，例如绘制其频率响应：

要将滤波器部署在微控制器中，我们首先必须从这种连续时间表示中得出离散时间近似值，该近似值可以在微控制器中以紧密循环（此处为每0.1秒）运行：

现在，我们准备使用微控制器套件将其实际部署到微控制器中。该套件支持一百多种不同类型的微控制器。这是将过滤器部署到已连接到计算机串行端口的Arduino Uno的方法：

微控制器EmbedCode的工作原理是生成适当的类似于C的源代码，将其编译为所需的微控制器体系结构，然后通过所谓的编程器将其实际部署到微控制器中。这是在这种特殊情况下生成的实际源代码：

所以现在我们有了这样的东西，它可以运行Butterworth过滤器，我们可以在任何地方使用它：

如果我们想检查它在做什么，我们总是可以使用DeviceOpen将其重新连接到Wolfram语言，以打开其串行端口，并从中进行读写。

链接到Unity Universe

Wolfram语言和视频游戏之间有什么关系？多年来，Wolfram语言已在游戏开发的许多方面（模拟策略，创建几何图形，分析结果等）在后台使用。但是一段时间以来，我们一直在研究Wolfram语言和Unity游戏环境之间的更紧密链接，并且在12.0版中，我们发布了该链接的第一个版本。

基本方案是让Unity与Wolfram语言一起运行，然后建立双向通信，从而可以交换对象和命令。引擎盖下的管道非常复杂，但是结果是Wolfram Language和Unity的优势完美融合。

这将设置链接，然后在Unity中启动一个新项目：

现在创建一些复杂的形状：

然后，只需一个命令即可将其作为一个名为“ thingoid ”的对象放入Unity游戏：

在Wolfram语言中，该对象具有符号表示形式，并且UnityLink现在提供了数百种用于操纵此类对象的功能，并且始终在Unity和Wolfram语言中维护版本。

可以将Wolfram语言中的内容立即带入Unity，这非常强大，无论它们是几何，图像，音频，地理地形，分子结构， 3D解剖结构还是其他任何东西。然后可以通过Unity游戏中的诸如游戏物理性或用户动作之类的东西来操纵这些东西，这也非常强大。（最终，人们可以期望拥有类似Manipulate的功能，其中控件不仅是滑块和其他东西，而是复杂的游戏玩法。）

自1990年代初以来，我们就进行了将Wolfram语言–生成的内容应用于虚拟现实的实验。但是在现代，Unity已成为设置VR / AR环境的事实上的标准-现在使用UnityLink可以将来自Wolfram语言的内容日常地放入任何现代XR环境中，变得非常简单。

人们可以使用Wolfram语言为Unity游戏做准备，但是在Unity游戏中，UnityLink基本上还可以让人们插入可以在游戏期间在本地计算机上或通过Wolfram Cloud中的API执行的Wolfram语言代码。并且，除其他外，这使得将钩子插入游戏变得很简单，因此游戏可以发送“遥测”（例如Wolfram Data Drop ）以Wolfram语言进行分析。（也可以编写游戏脚本，例如，这对游戏测试非常有用。）

编写游戏是一件复杂的事情。但是UnityLink提供了一种有趣的新方法，可以简化各种游戏的原型制作以及学习游戏开发的思路。原因之一是它通过使用Wolfram语言中的符号构造有效地让一个脚本更高级别地玩游戏。但是另一个原因是，它允许在笔记本中逐步完成开发过程，并解释和记录其每一步。例如，以下是描述“ 钢琴游戏 ”的发展的计算文章：

UnityLink不是一件简单的事情：它包含600多个函数。但是有了这些功能，就有可能访问Unity的几乎所有功能，并建立几乎任何可以想象的游戏。

机器学习的模拟环境

对于诸如强化学习之类的东西，在进行机器学习时，必须在循环中拥有可操纵的外部环境。好吧， ServiceExecute允许您启动实际设备（向左转动机器人）并从传感器获取数据（机器人是否跌倒了？）， DeviceExecute允许您调用API（发布该tweet或进行该交易的效果如何？）。

但是出于许多目的，人们想要的是拥有一个模拟的外部环境。从某种意义上说，纯Wolfram语言已经在某种程度上做到了这一点，例如，提供了访问丰富的“计算宇宙”的途径，其中充满了可修改的程序和方程式（元胞自动机，微分方程式 ……）。而且，是的，可以通过现实世界来了解该计算宇宙中的事物，例如具有海洋，化学物质或山脉的真实属性。

但是，什么样的环境更像我们现代人通常在其中学习的环境-充满了已构建的工程结构等等？足够方便的是， SystemModel可以访问许多实际的工程系统。通过UnityLink，我们可以期望获得丰富的基于游戏的世界模拟。

但首先，在版本12.0中，我们将建立与一些简单游戏的连接-特别是来自OpenAI“ gym”的连接。该界面与用于与现实世界进行交互的界面非常相似，可以像访问“设备”一样访问游戏（在适当的时候进行了“开源痛苦”的安装）：

我们可以阅读游戏状态：

我们可以将其显示为图像：

稍加努力，我们就可以在游戏中采取100个随机动作（始终检查我们没有“死”），然后显示观察到的游戏状态的特征空间图：

区块链（和CryptoKitty）计算

在版本11.3中，我们开始了与区块链的首次连接。 12.0版增加了许多新特性和功能，也许最值得注意的是具有写入公共区块链以及从中读取的功能。（我们还为Wolfram云用户提供了自己的Wolfram区块链。）我们目前正在支持比特币，以太坊和ARK 区块链，包括其主网和测试网（是的，我们有自己的节点直接连接到这些区块链）。

在版本11.3中，我们允许原始读取来自区块链的交易。在版本12.0中，我们添加了一层分析，例如，您可以要求以太坊区块链上的“ CK”令牌（AKA CryptoKitties ）摘要：

快速查看历史记录中的所有令牌交易，并对不同令牌的活跃程度做出一词云：

但是如何进行我们自己的交易呢？假设我们要使用比特币ATM （就像在我附近的百吉饼商店中存在的那个那样）将现金转移到比特币地址。好吧，首先我们创建我们的加密密钥（并且我们需要确保我们记得我们的私有密钥！）：

接下来，我们必须使用我们的公钥并从中生成一个比特币地址：

从中制作一个QR码，您就可以开始使用ATM了：

但是，如果我们想自己写区块链怎么办？在这里，我们将使用比特币测试网（因此，我们不会花费真钱）。这显示了我们之前进行的交易的输出-包括0.0002比特币（即20,000聪）：

现在，我们可以建立一个使用此输出的事务，例如，向两个地址（我们为ATM事务定义的地址）分别发送8000个聪：

好的，所以现在我们有了一个区块链交易对象，该对象将向矿工愿意支付所有剩余的加密货币（此处为4000 satoshi）的费用（用红色显示，因为这是您要花费的“实际钱”）。区块链中的交易。但是，在我们可以提交此交易（并“花钱”）之前，我们必须使用私钥对其进行签名：

最后，我们只应用BlockchainTransactionSubmit ，我们已经提交了要放在区块链上的交易：

这是它的交易ID：

如果我们立即询问该交易，我们将收到一条消息，指出该交易不在区块链中：

但是等了几分钟之后，就到了，它很快就会传播到比特币测试网区块链的每个副本中：

如果您准备花真钱，则可以使用完全相同的功能在主网上进行交易。您也可以做类似购买CryptoKitties的事情。诸如BlockchainContractValue之类的功能可以用于任何（目前仅以太坊）智能合约，并且可以立即了解诸如ERC-20和ERC-721令牌之类的内容。

还有普通的加密货币

处理区块链涉及很多加密，其中一些是12.0版中的新功能（特别是处理椭圆曲线）。但是在版本12.0中，我们还扩展了非区块链密码功能。例如，我们现在有了直接处理数字签名的功能。这将从上方使用私钥创建数字签名：

现在，任何人都可以使用相应的公共密钥来验证消息：

在12.0版中，我们为Hash函数添加了几种新类型的哈希，尤其是为了支持各种加密货币。我们还添加了生成和验证派生密钥的方法。从任何密码开始， GenerateDerivedKey将把它“塞入”更长的时间（为了更安全，您应该添加“ salt ”）：

这是派生密钥的一个版本，适用于各种身份验证方案：

连接到财务数据源

Wolfram知识库包含各种财务数据。通常，有一个金融实体（如股票），然后有一个财产（如价格）。这是苹果公司股票价格的完整每日历史（以对数刻度看起来最好，这令人印象深刻）：

但是，虽然Wolfram知识库中的财务数据（通常以Wolfram语言提供）一直在不断更新，但是它不是实时的（通常会延迟15分钟），并且没有许多金融交易员使用的所有细节。但是，对于严重的财务使用，我们开发了Wolfram Finance Platform 。现在，在12.0版中，可以直接访问Bloomberg和Reuters的财务数据提要。

我们构建Wolfram语言的方式，与彭博社和路透社的连接框架始终以该语言提供，但只有在具有Wolfram金融平台以及适当的Bloomberg或Reuters订阅的情况下，才会激活该语言。但是，如果您拥有这些，则连接彭博终端服务的外观如下所示：

彭博终端机处理的所有金融工具现在都可以以Wolfram语言的实体形式获得：

现在我们可以请求该实体的属性：

彭博航站楼共有超过60,000个属性可供访问：

这是5个随机示例（是的，它们非常详细；这些是彭博名称，而不是我们的名称）：

我们支持彭博终端服务，彭博数据许可服务和路透社电子服务。现在可以做的一件复杂的事情是设置一个连续任务以异步接收数据，并在每次收到新数据时调用“ 处理程序函数 ”：

软件工程和平台更新

我已经讨论了Wolfram语言中的许多新功能和新功能。但是Wolfram语言的基础架构又如何呢？好吧，我们也一直在努力。例如，在版本11.3和版本12.0之间，我们设法修复了将近8000个报告的错误。我们还使许多事情变得更快，更强大。通常，我们一直在加强系统的软件工程，例如将初始下载大小减少近10％（尽管已添加了所有功能）。（我们还进行了诸如从云中改进知识库元素的预测性预取之类的工作，因此，当您需要类似的数据时，很有可能已经将其缓存在计算机上了。）

操作系统不断更新是计算环境的一项长期功能-要利用其最新功能，应用程序也必须进行更新。我们已经进行了数年的Mac笔记本界面重大更新工作，该更新终于在12.0版中准备好了。作为更新的一部分，我们重写和重组了20多年开发和完善的大量代码，但是结果是，在版本12.0中，Mac上我们系统的所有内容都是完全64位的，并利用了最新的Cocoa API 。这意味着笔记本电脑的前端显着提高了速度，并且还可以超过以前的2 GB内存限制。

Linux上还有一个平台更新，现在笔记本界面完全支持Qt 5 ，它允许所有渲染操作“无头”进行，而无需任何X服务器，从而大大简化了Wolfram Engine在云中的部署。（版本12.0尚不支持Windows的高dpi，但即将推出。）

Wolfram Cloud的开发在某些方面与Wolfram语言和Wolfram Desktop应用程序的开发不同（尽管出于内部兼容性的考虑，我们在两种环境中同时发布了12.0版）。但是自从版本11.3发布以来的过去一年中，Wolfram Cloud取得了巨大进步。

特别值得注意的是云笔记本的进步-支持更多的界面元素（包括嵌入式网站和视频中的某些元素，而台式笔记本甚至还没有提供这些元素）以及极大地提高了鲁棒性和速度。（使我们整个笔记本界面都可以在网络浏览器中工作并不是软件工程的壮举，并且在12.0版中，有一些非常复杂的策略可以用于维护一致的快速加载缓存以及完整的符号DOM表示。）

在12.0版中，现在只有一个简单的菜单项（“文件”>“发布到云...”），可以将任何笔记本发布到云中。笔记本发布后，世界上任何人都可以与它进行交互-并制作自己的副本，以便他们可以对其进行编辑。

有趣的是，云已经进入了Wolfram语言可以完成的工作。除了云知识库的所有无缝集成，以及能够接触诸如区块链之类的功能之外，如果没有直接的电子邮件服务器连接，还可以使用诸如使用云通过云发送，发送任何笔记本等便利功能。

还有很多...

尽管这是一个漫长的过程，但它还不能完全讲述12.0版中的新增功能的全部故事。与我们团队的其他成员一起，我已经为版本12.0进行了很长时间的努力-但是仍然很高兴看到其中实际上有多少。

但是至关重要的（还有很多工作要做！）是我们添加的所有内容都经过精心设计，以与现有内容保持一致。从30年前的第一个版本开始，到现在的Wolfram语言，我们一直遵循相同的核心原则-这是使我们能够在保持长期兼容性的同时大幅扩展系统的一部分。

始终很难确切地确定为每个新版本优先开发的内容，但是我对我们为版本12.0所做的选择感到非常满意。在过去的一年中，我进行了许多演讲，而对于能够经常谈论发生的事情我感到非常震惊：“嗯，碰巧这将成为12.0版的一部分！ ”

我个人使用版本12.0的内部初步版本已经将近一年了，我已经把它的许多新功能视为理所当然-并且经常使用和享受它们。因此，今天我们拥有最终的12.0版非常高兴，它正式包含了所有这些新功能，随时可供任何人使用...

第12版今天发布！ （这对Wolfram语言和Mathematica来说是一个巨大的飞跃）