Astronomical Graphics and Their Axes
天文图形及其轴线

It’s complicated to define where things are in the sky. There are four main coordinate systems that get used in doing this: horizon (relative to local horizon), equatorial (relative to the Earth’s equator), ecliptic (relative to the orbit of the Earth around the Sun) and galactic (relative to the plane of the galaxy). And when we draw a diagram of the sky (here on white for clarity) it’s typical to show the “axes” for all these coordinate systems:
要确定事物在天空中的位置非常复杂。主要有四个坐标系：地平线（相对于本地地平线）、赤道（相对于地球赤道）、黄道（相对于地球绕太阳的轨道）和银河系（相对于银河系平面）。当我们绘制天空示意图时（为了清晰起见，这里用白色），通常会显示所有这些坐标系的 "轴线"：

But here’s a tricky thing: how should those axes be labeled? Each one is different: horizon is most naturally labeled by things like cardinal directions (N, E, S, W, etc.), equatorial by hours in the day (in sidereal time), ecliptic by months in the year, and galactic by angle from the center of the galaxy.
但这里有一个棘手的问题：这些坐标轴应该如何标注？每条轴线都不一样：地平线最自然的标注方式是以红绿方位（北、东、南、西等）标注，赤道轴以一天中的小时数（恒星时）标注，黄道轴以一年中的月份标注，银河轴以与银河系中心的角度标注。

In ordinary plots axes are usually straight, and labeled uniformly (or perhaps, say, logarithmically). But in astronomy things are much more complicated: the axes are intrinsically circular, and then get rendered through whatever projection we’re using.
在普通绘图中，坐标轴通常是直的，并统一标注（或者说，按对数标注）。但在天文学中，情况要复杂得多：坐标轴本质上是圆形的，然后通过我们使用的投影进行渲染。

And we might have thought that such axes would require some kind of custom structure. But not in the Wolfram Language. Because in the Wolfram Language we try to make things general. And axes are no exception:
我们可能会认为，这种轴需要某种自定义结构。但在 Wolfram 语言中并非如此。因为在沃尔夫拉姆语言中，我们努力使事物具有通用性。轴也不例外：

So in AstroGraphics all our various axes are just AxisObject constructs—that can be computed with. And so, for example, here’s a Mollweide projection of the sky:
因此，在 AstroGraphics 中，我们所有的轴都只是 AxisObject 结构，可以用它来计算。例如，这里是天空的 Mollweide 投影：

If we insist on “seeing the whole sky”, the bottom half is just the Earth (and, yes, the Sun isn’t shown because I’m writing this after it’s set for the day…):
如果我们坚持要 "看到整个天空"，那么下半部分就是地球（是的，没有显示太阳，因为我是在太阳落山后写这篇文章的......）：

Things get a bit wild if we start adding grid lines, here for galactic coordinates:
如果我们开始添加网格线，情况就会变得有点疯狂，这里是银河系坐标：

And, yes, the galactic coordinate axis is indeed aligned with the plane of the Milky Way (i.e. our galaxy):
是的，银河坐标轴确实与银河系（即我们的银河系）的平面对齐：

When Is Earthrise on Mars? New Level of Astronomical Computation
火星何时日出？天文计算的新水平

When will the Earth next rise above the horizon from where the Perseverance rover is on Mars? In Version 14.1 we can now compute this (and, yes, this is an “Earth time” converted from Mars time using the standard barycentric celestial reference system (BCRS) solar-system-wide spacetime coordinate system):
从 "坚毅 "号漫游车所在的火星上看，地球下一次升出地平线的时间是什么时候？在 14.1 版中，我们现在可以计算出这个时间（是的，这是使用标准重心天体参考系（BCRS）太阳系全时空坐标系从火星时间转换而来的 "地球时间"）：

This is a fairly complicated computation that takes into account not only the motion and rotation of the bodies involved, but also various other physical effects. A more “down to Earth” example that one might readily check by looking out of one’s window is to compute the rise and set times of the Moon from a particular point on the Earth:
这是一项相当复杂的计算，不仅要考虑相关天体的运动和旋转，还要考虑其他各种物理效应。一个更 "接地气 "的例子是，从地球上的某一点计算月球的升起和落下时间：

There’s a slight variation in the times between moonrises:
两次月升之间的时间略有不同：

Over the course of a year we see systematic variations associated with the periods of different kinds of lunar months:
在一年中，我们可以看到与不同种类的农历月份的周期有关的系统性变化：

There are all sorts of subtleties here. For example, when exactly does one define something (like the Sun) to have “risen”? Is it when the top of the Sun first peeks out? When the center appears? Or when the “whole Sun” is visible? In Version 14.1 you can ask about any of these:
这里有各种各样的微妙之处。例如，究竟什么时候才算 "太阳升起"？是太阳的顶部第一次露出来的时候？当中心出现时？还是当 "整个太阳 "出现时？在 14.1 版中，您可以询问其中任何一个问题：

Oh, and you could compute the same thing for the rise of Venus, but now to see the differences, you’ve got to go to millisecond granularity (and, by the way, granularities of milliseconds down to picoseconds are new in Version 14.1):
哦，你也可以计算金星上升的时间，但现在要看到差异，你必须使用毫秒粒度（顺便说一下，14.1 版新增了从毫秒到皮秒的粒度）：

By the way, particularly for the Sun, the concept of ReferenceAltitude is useful in specifying the various kinds of sunrise and sunset: for example, “civil twilight” corresponds to a reference altitude of –6°.
顺便提一下，特别是对于太阳来说， ReferenceAltitude 的概念在指定各种日出日落时非常有用：例如，"民用黄昏 "对应于-6°的参考高度。

Geometry Goes Color, and Polar
几何、色彩和极地

Last year we introduced the function ARPublish to provide a streamlined way to take 3D geometry and publish it for viewing in augmented reality. In Version 14.1 we’ve now extended this pipeline to deal with color:
去年，我们引入了函数 ARPublish 以提供一种简化的方法来获取 3D 几何图形并将其发布到增强现实中查看。现在，我们在 14.1 版中扩展了这一管道，以处理颜色问题：

(Yes, the color is a little different on the phone because the phone tries to make it look “more natural”.)
(是的，手机上的颜色有点不同，因为手机试图让它看起来 "更自然"）。

And now it’s easy to view this not just on a phone, but also, for example, on the Apple Vision Pro:
现在，不仅可以在手机上轻松查看，还可以在 Apple Vision Pro 上查看：

Graphics have always had color. But now in Version 14.1 symbolic geometric regions can have color too:
图形一直都有颜色。但现在在 14.1 版中，符号几何区域也可以有颜色：

And constructive geometric operations on regions preserve color:

Two other new functions in Version 14.1 are PolarCurve and FilledPolarCurve:

And while at this level this may look simple, what’s going on underneath is actually seriously complicated, with all sorts of symbolic analysis needed in order to determine what the “inside” of the parametric curve should be.

Talking about geometry and color brings up another enhancement in Version 14.1: plot themes for diagrams in synthetic geometry. Back in Version 12.0 we introduced symbolic synthetic geometry—in effect finally providing a streamlined computable way to do the kind of geometry that Euclid did two millennia ago. In the past few versions we’ve been steadily expanding our synthetic geometry capabilities, and now in Version 14.1 one notable thing we’ve added is the ability to use plot themes—and explicit graphics options—to style geometric diagrams. Here’s the default version of a geometric diagram:

Now we can “theme” this for the web:

New Computation Flow in Notebooks: Introducing Cell-Linked %

In building up computations in notebooks, one very often finds oneself wanting to take a result one just got and then do something with it. And ever since Version 1.0 one’s been able to do this by referring to the result one just got as %. It’s very convenient. But there are some subtle and sometimes frustrating issues with it, the most important of which has to do with what happens when one reevaluates an input that contains %.

Let’s say you’ve done this:

But now you decide that actually you wanted Median[ % ^ 2 ] instead. So you edit that input and reevaluate it:

Oops! Even though what’s right above your input in the notebook is a list, the value of % is the latest result that was computed, which you can’t now see, but which was 3.

OK, so what can one do about this? We’ve thought about it for a long time (and by “long” I mean decades). And finally now in Version 14.1 we have a solution—that I think is very nice and very convenient. The core of it is a new notebook-oriented analog of %, that lets one refer not just to things like “the last result that was computed” but instead to things like “the result computed in a particular cell in the notebook”.

So let’s look at our sequence from above again. Let’s start typing another cell—say to “try to get it right”. In Version 14.1 as soon as we type % we see an autosuggest menu:

The menu is giving us a choice of (output) cells that we might want to refer to. Let’s pick the last one listed:

The object is a reference to the output from the cell that’s currently labeled In[1]—and using now gives us what we wanted.

But let’s say we go back and change the first (input) cell in the notebook—and reevaluate it:

The cell now gets labeled In[5]—and the (in In[4]) that refers to that cell will immediately change to :

And if we now evaluate this cell, it’ll pick up the value of the output associated with In[5], and give us a new answer:

So what’s really going on here? The key idea is that signifies a new type of notebook element that’s a kind of cell-linked analog of %. It represents the latest result from evaluating a particular cell, wherever the cell may be, and whatever the cell may be labeled. (The object always shows the current label of the cell it’s linked to.) In effect is “notebook front end oriented”, while ordinary % is kernel oriented. is linked to the contents of a particular cell in a notebook; % refers to the state of the Wolfram Language kernel at a certain time.

gets updated whenever the cell it’s referring to is reevaluated. So its value can change either through the cell being explicitly edited (as in the example above) or because reevaluation gives a different value, say because it involves generating a random number:

OK, so always refers to “a particular cell”. But what makes a cell a particular cell? It’s defined by a unique ID that’s assigned to every cell. When a new cell is created it’s given a universally unique ID, and it carries that same ID wherever it’s placed and whatever its contents may be (and even across different sessions). If the cell is copied, then the copy gets a new ID. And although you won’t explicitly see cell IDs, works by linking to a cell with a particular ID.

One can think of as providing a “more stable” way to refer to outputs in a notebook. And actually, that’s true not just within a single session, but also across sessions. Say one saves the notebook above and opens it in a new session. Here’s what you’ll see:

The is now grayed out. So what happens if we try to reevaluate it? Well, we get this:

If we press Reconstruct from output cell the system will take the contents of the first output cell that was saved in the notebook, and use this to get input for the cell we’re evaluating:

In almost all cases the contents of the output cell will be sufficient to allow the expression “behind it” to be reconstructed. But in some cases—like when the original output was too big, and so was elided—there won’t be enough in the output cell to do the reconstruction. And in such cases it’s time to take the Go to input cell branch, which in this case will just take us back to the first cell in the notebook, and let us reevaluate it to recompute the output expression it gives.

By the way, whenever you see a “positional %” you can hover over it to highlight the cell it’s referring to:

Having talked a bit about “cell-linked %” it’s worth pointing out that there are still cases when you’ll want to use “ordinary %”. A typical example is if you have an input line that you’re using a bit like a function (say for post-processing) and that you want to repeatedly reevaluate to see what it produces when applied to your latest output.

In a sense, ordinary % is the “most volatile” in what it refers to. Cell-linked % is “less volatile”. But sometimes you want no volatility at all in what you’re referring to; you basically just want to burn a particular expression into your notebook. And in fact the % autosuggest menu gives you a way to do just that.

Notice the that appears in whatever row of the menu you’re selecting:

Press this and you’ll insert (in iconized form) the whole expression that’s being referred to:

Now—for better or worse—whatever changes you make in the notebook won’t affect the expression, because it’s right there, in literal form, “inside” the icon. And yes, you can explicitly “uniconize” to get back the original expression:

Once you have a cell-linked % it always has a contextual menu with various actions:
一旦有了单元格链接 % ，它总是有一个包含各种操作的上下文菜单：

One of those actions is to do what we just mentioned, and replace the positional by an iconized version of the expression it’s currently referring to. You can also highlight the output and input cells that the is “linked to”. (Incidentally, another way to replace a by the expression it’s referring to is simply to “evaluate in place” , which you can do by selecting it and pressing CMDReturn or ShiftControlEnter.)
其中一项操作就是执行我们刚才提到的操作，将位置 替换为当前引用表达式的图标化版本。您还可以高亮显示 所 "链接 "的输出和输入单元格。(顺便提一下，用表达式替换 的另一种方法是简单地 "就地求值" ，您可以通过选择 CMD Return 或 Shift Control Enter 来实现）。

Another item in the menu is Replace With Rolled-Up Inputs. What this does is—as it says—to “roll up” a sequence of “ references” and create a single expression from them:
菜单中的另一个项目是 Replace With Rolled-Up Inputs 。如其所述，它的作用是 "卷起 "一系列" 引用"，并从中创建一个表达式：

What we’ve talked about so far one can think of as being “normal and customary” uses of . But there are all sorts of corner cases that can show up. For example, what happens if you have a that refers to a cell you delete? Well, within a single (kernel) session that’s OK, because the expression “behind” the cell is still available in the kernel (unless you reset your $HistoryLength etc.). Still, the will show up with a “red broken link” to indicate that “there could be trouble”:

And indeed if you go to a different (kernel) session there will be trouble—because the information you need to get the expression to which the refers is simply no longer available, so it has no choice but to show up in a kind of everything-has-fallen-apart “surrender state” as:
事实上，如果您转到另一个（内核）会话，就会遇到麻烦--因为您要获取 所指的表达式所需的信息已不再可用，所以它只能以一种万事俱备、只欠东风的 "投降状态 "出现：

is primarily useful when it refers to cells in the notebook you’re currently using (and indeed the autosuggest menu will contain only cells from your current notebook). But what if it ends up referring to a cell in a different notebook, say because you copied the cell from one notebook to another? It’s a precarious situation. But if all relevant notebooks are open, can still work, though it’s displayed in purple with an action-at-a-distance “wi-fi icon” to indicate its precariousness:
主要用于指当前使用的笔记本中的单元格（事实上，自动建议菜单将只包含当前笔记本中的单元格）。但是，如果它最终指向的是另一个笔记本中的单元格，例如，由于您将单元格从一个笔记本复制到了另一个笔记本，那该怎么办呢？这种情况很危险。但是，如果所有相关笔记本都已打开， 仍然可以工作，尽管它会显示为紫色，并带有一个远距离操作的 "wi-fi 图标"，以显示其不稳定性：

And if, for example, you start a new session, and the notebook containing the “source” of the isn’t open, then you’ll get the “surrender state”. (If you open the necessary notebook it’ll “unsurrender” again.)
例如，如果您开始一个新会话，而包含 的 "源代码 "的笔记本没有打开，那么您就会进入 "投降状态"。(如果你打开了必要的笔记本，它就会再次 "取消投降"）。

Yes, there are lots of tricky cases to cover (in fact, many more than we’ve explicitly discussed here). And indeed seeing all these cases makes us not feel bad about how long it’s taken for us to conceptualize and implement .
是的，有很多棘手的情况需要处理（事实上，比我们在此明确讨论的情况要多得多）。事实上，看到所有这些情况，我们就不会为我们花了如此长的时间来构思和实现 而感到遗憾。

The most common way to access is to use the % autosuggest menu. But if you know you want a , you can always get it by “pure typing”, using for example ESC%ESC. (And, yes, ESC%%ESC or ESC%5ESC etc. also work, so long as the necessary cells are present in your notebook.)
访问 的最常用方法是使用 % 自动建议菜单。但是，如果您知道自己想要 ，您可以通过 "纯键入 "来获得，例如使用 ESC % ESC 。(当然，只要笔记本中存在必要的单元格， ESC %% ESC 或 ESC %5 ESC 等也可以使用）。

The UX Journey Continues: New Typing Affordances, and More
用户体验之旅仍在继续：新的打字功能及其他

We invented Wolfram Notebooks more than 36 years ago, and we’ve been improving and polishing them ever since. And in Version 14.1 we’re implementing several new ideas, particularly around making it even easier to type Wolfram Language code.
我们在 36 年前发明了 Wolfram 笔记本，从那时起我们就一直在改进和完善它。在 14.1 版中，我们将实现一些新的想法，尤其是让 Wolfram 语言代码的输入变得更加容易。

It’s worth saying at the outset that good UX ideas quickly become essentially invisible. They just give you hints about how to interpret something or what to do with it. And if they’re doing their job well, you’ll barely notice them, and everything will just seem “obvious”.

So what’s new in UX for Version 14.1? First, there’s a story around brackets. We first introduced syntax coloring for unmatched brackets back in the late 1990s, and gradually polished it over the following two decades. Then in 2021 we started “automatching” brackets (and other delimiters), so that as soon as you type “f[” you immediately get f[ ].
那么 14.1 版的用户体验有哪些新变化呢？首先是关于括号的故事。早在 20 世纪 90 年代末，我们就首次为不匹配的括号引入了语法着色，并在随后的 20 年中逐步完善。之后在 2021 年，我们开始 "自动匹配 "括号（和其他分隔符），因此只要您输入 "f["，就会立即得到 f[ ] 。

But how do you keep on typing? You could use an to “move through” the ]. But we’ve set it up so you can just “type through” ] by typing ]. In one of those typical pieces of UX subtlety, however, “type through” doesn’t always make sense. For example, let’s say you typed f[x]. Now you click right after [ and you type g[, so you’ve got f[g[x]. You might think there should be an autotyped ] to go along with the [ after g. But where should it go? Maybe you want to get f[g[x]], or maybe you’re really trying to type f[g[],x]. We definitely don’t want to autotype ] in the wrong place. So the best we can do is not autotype anything at all, and just let you type the ] yourself, where you want it. But remember that with f[x] on its own, the ] is autotyped, and so if you type ] yourself in this case, it’ll just type through the autotyped ] and you won’t explicitly see it.
但如何继续键入呢？您可以使用 来 "穿过" ] 。但是我们已经设置好，您只需键入 ] 即可 "键入" ] 。然而，在用户体验的典型微妙之处中，"键入通过 "并不总是有意义的。例如，假设您键入了 f[x] 。现在，您点击 [ 之后的右键，然后键入 g[ ，这样您就得到了 f[g[x] 。您可能会认为，在 g 之后，应该有一个自动生成的 ] 与 [ 搭配使用。但是它应该放在哪里呢？也许您想输入 f[g[x]] ，也许您真的想输入 f[g[],x] 。我们肯定不想在错误的地方自动键入 ] 。因此，我们能做的最好的办法就是不自动键入任何内容，而是让您自己键入 ] 到您想要的位置。但是请记住，在 f[x] 独立存在的情况下， ] 是自动键入的，因此在这种情况下，如果您自己键入 ] ，它只会通过自动键入的 ] 键入，您不会明确看到它。

So how can you tell whether a ] you type will explicitly show up, or will just be “absorbed” as type-through? In Version 14.1 there’s now different syntax coloring for these cases: yellow if it’ll be “absorbed”, and pink if it’ll explicitly show up.
那么，如何判断您键入的 ]是会明确显示出来，还是会被 "吸收 "为穿透型呢？在 14.1 版中，针对这些情况有了不同的语法着色：如果会被 "吸收"，则为黄色；如果会明确显示，则为粉色。

This is an example of non-type-through, so Range is colored yellow and the ] you type is “absorbed”:
这是一个非穿透类型的示例，因此 Range 被染成黄色，而您键入的 ] 则被 "吸收"：

And this is an example of non-type-through, so Round is colored pink and the ] you type is explicitly inserted:
这是一个非穿透类型的示例，因此 Round 会被染成粉红色，而您键入的 ] 会被明确插入：

This may all sound very fiddly and detailed—and for us in developing it, it is. But the point is that you don’t explicitly have to think about it. You quickly learn to just “take the hint” from the syntax coloring about when your closing delimiters will be “absorbed” and when they won’t. And the result is that you’ll have an even smoother and faster typing experience, with even less chance of unmatched (or incorrectly matched) delimiters.
这一切听起来可能非常繁琐和细致，而对于我们开发人员来说，确实如此。但问题是，你不需要明确地考虑这一点。你很快就能从语法着色中学会 "接受暗示"，知道什么时候你的结尾分隔符会被 "吸收"，什么时候不会被 "吸收"。结果就是，你将获得更流畅、更快速的键入体验，更少出现分隔符不匹配（或错误匹配）的情况。

The new syntax coloring we just discussed helps in typing code. In Version 14.1 there’s also something new that helps in reading code. It’s an enhanced version of something that’s actually common in IDEs: when you click (or select) a variable, every instance of that variable immediately gets highlighted:
我们刚刚讨论过的新语法着色有助于键入代码。在 14.1 版中，还有一些新功能有助于阅读代码。它是集成开发环境中常见功能的增强版：当您单击（或选择）一个变量时，该变量的每个实例都会立即高亮显示：

What’s subtle in our case is that we take account of the scoping of localized variables—putting a more colorful highlight on instances of a variable that are in scope:
在我们的例子中，最微妙的是我们考虑到了本地化变量的作用域--为处于作用域内的变量实例添加了更多色彩：

One place this tends to be particularly useful is in understanding nested pure functions that use #. By clicking a # you can see which other instances of # are in the same pure function, and which are in different ones (the highlight is bluer inside the same function, and grayer outside):
在理解使用 # 的嵌套纯函数时，这一点往往特别有用。通过点击 # 可以查看 # 的其他实例中哪些在同一个纯函数中，哪些在不同的纯函数中（同一函数内部的高亮度更蓝，外部的高亮度更灰）：

On the subject of finding variables, another change in Version 14.1 is that fuzzy name autocompletion now also works for contexts. So if you have a symbol whose full name is context1`subx`var2 you can type c1x and you’ll get a completion for the context; then accept this and you get a completion for the symbol.
关于查找变量，14.1 版的另一个变化是模糊名称自动完成功能现在也适用于上下文。因此，如果一个符号的全名是 context1`subx`var2 ，你可以输入 c1x ，就会得到上下文的补全；然后接受它，就会得到符号的补全。

There are also several other notable UX “tune-ups” in Version 14.1. For many years, there’s been an “information box” that comes up whenever you hover over a symbol. Now that’s been extended to entities—so (alongside their explicit form) you can immediately get to information about them and their properties:
14.1 版还对用户体验进行了其他一些显著的 "调整"。多年来，只要将鼠标悬停在符号上，就会出现一个 "信息框"。现在，该功能已扩展到实体，因此（除了实体的显式形式外），您还可以立即获取有关实体及其属性的信息：

Next there’s something that, yes, I personally have found frustrating in the past. Say you’ve a file, or an image, or something else somewhere on your computer’s desktop. Normally if you want it in a Wolfram Notebook you can just drag it there, and it will very beautifully appear. But what if the thing you’re dragging is very big, or has some other kind of issue? In the past, the drag just failed. Now what happens is that you get the explicit Import that the dragging would have done, so that you can run it yourself (getting progress information, etc.), or you can modify it, say adding relevant options.
接下来还有一件事，是的，我个人在过去也曾感到沮丧。比方说，你在电脑桌面上有一个文件、一张图片或其他东西。通常情况下，如果你想把它放到 Wolfram 笔记本中，只需将它拖到那里，它就会非常漂亮地显示出来。但如果您拖动的东西非常大或有其他问题怎么办？过去，拖动会失败。现在，您将获得拖动本应完成的显式 Import ，这样您就可以自己运行它（获得进度信息等），或者对它进行修改，例如添加相关选项。

Another small piece of polish that’s been added in Version 14.1 has to do with Preferences. There are a lot of things you can set in the notebook front end. And they’re explained, at least briefly, in the many Preferences panels. But in Version 14.1 there are now (i) buttons that give direct links to the relevant workflow documentation:
14.1 版中添加的另一小部分改进与 Preferences 有关。您可以在笔记本前端设置很多内容。在许多 Preferences 面板中都有简要说明。但在 14.1 版中， (i) 按钮提供了相关工作流文档的直接链接：

Syntax for Natural Language Input
自然语言输入语法

Ever since shortly after Wolfram|Alpha was released in 2009, there’ve been ways to access its natural language understanding capabilities in the Wolfram Language. Foremost among these has been CTRL=—which lets you type free-form natural language and immediately get a Wolfram Language version, often in terms of entities, etc.:
自 2009 年Wolfram|Alpha发布后不久，就有很多方法可以访问 Wolfram 语言中的自然语言理解功能。其中最重要的是 CTRL = - 您可以输入自由格式的自然语言，并立即获得 Wolfram 语言的版本，通常是实体等方面的版本：

Generally this is a very convenient and elegant capability. But sometimes one may want to just use plain text to specify natural language input, for example so that one doesn’t interrupt one’s textual typing of input.
一般来说，这是一种非常方便和优雅的功能。但有时，人们可能只想使用纯文本来指定自然语言输入，例如，这样就不会中断文本输入。

In Version 14.1 there’s a new mechanism for this: syntax for directly entering free-form natural language input. The syntax is a kind of a “textified” version of CTRL=: =[…]. When you type =[...] as input nothing immediately happens. It’s only when you evaluate your input that the natural language gets interpreted—and then whatever it specifies is computed.
14.1 版为此提供了一种新机制：直接输入自由格式自然语言输入的语法。该语法是 CTRL = 的 "文本化 "版本： =[…] 。当您输入 =[...] 时，什么也不会立即发生。只有当您对输入进行评估时，自然语言才会被解释，然后它指定的任何内容才会被计算。

Here’s a very simple example, where each =[…] just turns into an entity:
下面是一个非常简单的例子，每个 =[…] 都会变成一个实体：

But when the result of interpreting the natural language is an expression that can be further evaluated, what will come out is the result of that evaluation:
但是，当解释自然语言的结果是一个可以进一步评估的表达式时，出来的就是评估的结果：

One feature of using =[…] instead of CTRL= is that =[…] is something anyone can immediately see how to type:
使用 =[…] 而不是 CTRL = 的一个特点是， =[…] 任何人都能一眼看出如何键入：

But what actually is =[…]? Well, it’s just input syntax for the new function FreeformEvaluate:
但 =[…] 究竟是什么呢？它只是新函数 FreeformEvaluate 的输入语法：

You can use FreeformEvaluate inside a program—here, rather whimsically, to see what interpretations are chosen by default for “a” followed by each letter of the alphabet:
您可以在程序中使用 FreeformEvaluate --在这里，您可以异想天开地查看默认情况下，字母表中每个字母后面的 "a "会选择什么解释：

By default, FreeformEvaluate interprets your input, then evaluates it. But you can also specify that you want to hold the result of the interpretation:
默认情况下， FreeformEvaluate 会解释输入内容，然后对其进行求值。但您也可以指定保留解释的结果：

Diff[ ] … for Notebooks and More!
Diff[ ] ...用于笔记本及其他产品！

It’s been a very long-requested capability: give me a way to tell what changed, particularly in a notebook. It’s fairly easy to do “diffs” for plain text. But for notebooks—as structured symbolic documents—it’s a much more complicated story. But in Version 14.1 it’s here! We’ve got a function Diff for doing diffs in notebooks, and actually also in many other kinds of things.
这是一项长期以来一直被要求的功能：让我有办法知道哪些内容发生了变化，尤其是在笔记本中。对纯文本进行 "差异 "处理相当容易。但对于作为结构化符号文档的笔记本来说，情况就要复杂得多。不过，在 14.1 版中就有了！我们已经有了一个函数 Diff 用于在笔记本中进行差异处理，实际上也可以在许多其他类型的东西中进行差异处理。

Here’s an example, where we’re requesting a “side-by-side view” of the diff between two notebooks:
下面是一个例子，我们要求 "并排查看 "两个笔记本之间的差异：

And here’s an “alignment chart view” of the diff:
这是差分的 "排列图视图"：

Like everything else in the Wolfram Language, a “diff” is a symbolic expression. Here’s an example:
与 Wolfram 语言中的其他内容一样，"diff "也是一种符号表达式。下面是一个例子：

There are lots of different ways to display a diff object; many of them one can select interactively with the menu:
有许多不同的方法来显示不同的对象；其中许多方法可以通过菜单进行交互式选择：

But the most important thing about diff objects is that they can be used programmatically. And in particular DiffApply applies the diffs from a diff object to an existing object, say a notebook.
不过，diff 对象最重要的一点是，它们可以编程使用。尤其是 DiffApply 可以将 diff 对象中的差异应用到现有对象（例如笔记本）中。

What’s the point of this? Well, let’s imagine you’ve made a notebook, and given a copy of it to someone else. Then both you and the person to whom you’ve given the copy make changes. You can create a diff object of the diffs between the original version of the notebook, and the version with your changes. And if the changes the other person made don’t overlap with yours, you can just take your diffs and use DiffApply to apply your diffs to their version, thereby getting a “merged notebook” with both sets of changes made.
这有什么意义呢？假设你做了一本笔记本，并把它的副本给了别人。然后，你和被你复制的人都做了修改。你可以创建一个 diff 对象，显示笔记本的原始版本和你修改后的版本之间的差异。如果其他人所做的改动与你的改动不重叠，你可以直接使用你的差异对象，并使用 DiffApply 将你的差异对象应用到他们的版本中，从而得到一个包含两组改动的 "合并笔记本"。

But what if your changes might conflict? Well, then you need to use the function Diff3. Diff3 takes your original notebook and two modified versions, and does a “three-way diff” to give you a diff object in which any conflicts are explicitly identified. (And, yes, three-way diffs are familiar from source control systems in which they provide the back end for making the merging of files as automated as possible.)
但如果您的更改可能会发生冲突怎么办？那么，你需要使用函数 Diff3 。 Diff3 使用你的原始笔记本和两个修改过的版本，并进行 "三向差分"，给你一个差分对象，其中任何冲突都会被明确识别出来。(没错，三向差异在源代码控制系统中并不陌生，它为尽可能自动化地合并文件提供了后端）。

Notebooks are an important use case for Diff and related functions. But they’re not the only one. Diff can perfectly well be applied, for example, just to lists:
笔记本是 Diff 和相关功能的一个重要用例。但它们并不是唯一的用例。例如， Diff 完全可以只用于列表：

There are many ways to display this diff object; here’s a side-by-side view:
有很多方法可以显示这个差异对象；下面是一个并排视图：

And here’s a “unified view” reminiscent of how one might display diffs for lines of text in a file:
这是一个 "统一视图"，让人想起如何显示文件中文本行的差异：

And, speaking of files, Diff, etc. can immediately be applied to files:
说到文件， Diff 等可以立即应用于文件：

Diff, etc. can also be applied to cells, where they can analyze changes in both content and styles or metadata. Here we’re creating two cells and then diffing them—showing the result in a side by side:
Diff 等也可以应用于单元格，它们可以分析内容、样式或元数据的变化。在这里，我们创建了两个单元格，然后对它们进行了差分--以并列方式显示结果：

In “Combined” view the “pure insertions” are highlighted in green, the “pure deletions” in red, and the “edits” are shown as deletion/insertion stacks:
在 "组合 "视图中，"纯插入 "显示为绿色，"纯删除 "显示为红色，"编辑 "显示为删除/插入堆叠：

Many uses of diff technology revolve around content development—editing, software engineering, etc. But in the Wolfram Language Diff, etc. are set up also to be convenient for information visualization and for various kinds of algorithmic operations. For example, to see what letters differ between the Spanish and Polish alphabets, we can just use Diff:
差分技术的许多用途都围绕着内容开发--编辑、软件工程等。但在 Wolfram 语言中， Diff 等的设置也便于信息可视化和各种算法操作。例如，要查看西班牙语字母表和波兰语字母表中哪些字母不同，我们只需使用 Diff ：

Here’s the “pure visualization”:
这里是 "纯可视化"：

And here’s an alternate “unified summary” form:
下面是另一种 "统一摘要 "形式：

Another use case for Diff is bioinformatics. We retrieve two genome sequences—as strings—then use Diff:
Diff 的另一个用例是生物信息学。我们以字符串的形式检索两个基因组序列，然后使用 Diff ：

We can take the resulting diff object and show it in a different form—here character alignment:
我们可以将得到的差异对象以不同的形式显示出来--这里是字符对齐：

Under the hood, by the way, Diff is finding the differences using SequenceAlignment. But while Diff is giving a “high-level symbolic diff object”, SequenceAlignment is giving a direct low-level representation of the sequence alignment:
顺便说一下，在引擎盖下， Diff 正在使用 SequenceAlignment 查找差异。但是， Diff 给出的是 "高级符号差异对象"，而 SequenceAlignment 给出的是序列比对的直接低级表示：

Information visualization isn’t restricted to two-way diffs; here’s an example with a three-way diff:
信息可视化并不局限于双向差异，下面是一个三向差异的例子：

And here it is as a “unified summary”:
这里是 "统一摘要"：

There are all sorts of options for diffs. One that is sometimes important is DiffGranularity. By default the granularity for diffs of strings is "Characters":
有各种各样的差异选项。其中一个有时很重要的选项是 DiffGranularity 。默认情况下，字符串差异的粒度是 "Characters" ：

But it’s also possible to set it to be "Words":
但也可以将其设置为 "Words" ：

Coming back to notebooks, the most “interactive” form of diff is a “report”:
回到笔记本，最 "互动 "的 diff 形式是 "报告"：

In such a report, you can open cells to see the details of a specific change, and you can also click to jump to where the change occurred in the underlying notebooks.
在这样的报告中，你可以打开单元格查看特定更改的详细信息，还可以单击跳转到底层笔记本中发生更改的位置。

When it comes to analyzing notebooks, there’s another new feature in Version 14.1: NotebookCellData. NotebookCellData gives you direct programmatic access to lots of properties of notebooks. By default it generates a dataset of some of them, here for the notebook in which I’m currently authoring this:
说到分析笔记本，14.1 版中还有一项新功能： NotebookCellData 。 NotebookCellData 可以让你以编程方式直接访问笔记本的大量属性。默认情况下，它会生成其中一些属性的数据集，这里是我正在撰写的笔记本的数据集：

There are properties like the word count in each cell, the style of each cell, the memory footprint of each cell, and a thumbnail image of each cell.
这些属性包括每个单元格的字数、每个单元格的样式、每个单元格的内存占用以及每个单元格的缩略图。

Ever since Version 6 in 2007 we’ve had the CellChangeTimes option which records when cells in notebooks are created or modified. And now in Version 14.1 NotebookCellData provides direct programmatic access to this data. So, for example, here’s a date histogram of when the cells in the current notebook were last changed:
自 2007 年 Version 6 以来，我们一直使用 CellChangeTimes 选项来记录创建或修改笔记本单元格的时间。现在，在 14.1 版中， NotebookCellData 提供了对这些数据的直接编程访问。因此，举例来说，这里有一个日期柱状图，显示了当前笔记本中单元格的最后修改时间：

Lots of Little Language Tune-Ups
大量的语言小调整

It’s part of a journey of almost four decades. Steadily discovering—and inventing—new “lumps of computational work” that make sense to implement as functions or features in the Wolfram Language. The Wolfram Language is of course very much strong enough that one can build essentially any functionality from the primitives that already exist in it. But part of the point of the language is to define the best “elements of computational thought”. And particularly as the language progresses, there’s a continual stream of new opportunities for convenient elements that get exposed. And in Version 14.1 we’ve implemented quite a diverse collection of them.
这是我近四十年历程的一部分。我们不断发现和发明新的 "计算工作"，并将其作为 Wolfram 语言的函数或功能加以实现。当然，Wolfram 语言已经足够强大，人们基本上可以利用其中已有的基元构建任何功能。但沃尔夫拉姆语言的部分意义在于定义最佳的 "计算思维元素"。尤其是随着语言的发展，会不断有新的便捷元素出现。在 14.1 版本中，我们已经实现了相当多样化的元素集合。

Let’s say you want to nestedly compose a function. Ever since Version 1.0 there’s been Nest for that:
比方说，您想嵌套地组成一个函数。自1.0版开始，就有了 Nest ：

But what if you want the abstract nested function, not yet applied to anything? Well, in Version 14.1 there’s now an operator form of Nest (and NestList) that represents an abstract nested function that can, for example, be composed with other functions, as in
但是，如果您想要尚未应用于任何对象的抽象嵌套函数，该怎么办呢？那么，在 14.1 版中，现在有了 Nest （和 NestList ）的运算符形式，可以表示抽象嵌套函数，例如，可以与其他函数组成，如

or equivalently: 或等同于

A decade ago we introduced functions like AllTrue and AnyTrue that effectively “in one gulp” do a whole collection of separate tests. If one wanted to test whether there are any primes in a list, one can always do:
十年前，我们引入了 AllTrue 和 AnyTrue 等函数，这些函数可以 "一气呵成 "地完成一系列单独的测试。如果要测试一个列表中是否存在素数，我们可以这样做：

But it’s better to “package” this “lump of computational work” into the single function AnyTrue:
不过，最好还是把这 "一大堆计算工作""打包 "到单个函数 AnyTrue 中：

In Version 14.1 we’re extending this idea by introducing AllMatch, AnyMatch and NoneMatch:
在 14.1 版中，我们通过引入 AllMatch 、 AnyMatch 和 NoneMatch 扩展了这一想法：

Another somewhat related new function is AllSameBy. SameQ tests whether a collection of expressions are immediately the same. AllSameBy tests whether expressions are the same by the criterion that the value of some function applied to them is the same:
另一个有点相关的新函数是 AllSameBy 。 SameQ 测试表达式集合是否立即相同。 AllSameBy 测试表达式是否相同的标准是，应用于表达式的某个函数的值是否相同：

Talking of tests, another new feature in Version 14.1 is a second argument to QuantityQ (and KnownUnitQ), which lets you test not only whether something is a quantity, but also whether it’s a specific type of physical quantity:
说到测试，14.1 版的另一个新功能是为 QuantityQ （和 KnownUnitQ ）添加了第二个参数，这样您不仅可以测试某物是否是量，还可以测试它是否是特定类型的物理量：

And now talking about “rounding things out”, Version 14.1 does that in a very literal way by enhancing the RoundingRadius option. For a start, you can now specify a different rounding radius for particular corners:
说到 "四舍五入"，14.1 版通过增强 RoundingRadius 选项，以非常直观的方式做到了这一点。首先，您现在可以为特定的边角指定不同的圆角半径：

And, yes, that’s useful if you’re trying to fit button-like constructs together:
是的，如果你想把类似纽扣的结构组合在一起，这很有用：

By the way, RoundingRadius now also works for rectangles inside Graphics:
顺便提一下， RoundingRadius 现在也适用于 Graphics 内的矩形：

Let’s say you have a string, like “hello”. There are many functions that operate directly on strings. But sometimes you really just want to use a function that operates on lists—and apply it to the characters in a string. Now in Version 14.1 you can do this using StringApply:
比方说，你有一个字符串，比如 "hello"。有很多函数可以直接对字符串进行操作。但有时您真的只想使用一个对列表进行操作的函数，并将其应用于字符串中的字符。现在，在 14.1 版中，您可以使用 StringApply 实现这一功能：

Another little convenience in Version 14.1 is the function BitFlip, which, yes, flips a bit in the binary representation of a number:
14.1 版的另一个小便利是函数 BitFlip ，没错，它可以在数字的二进制表示中翻转一位：

When it comes to Boolean functions, a detail that’s been improved in Version 14.1 is the conversion to NAND representation. By default, functions like BooleanConvert have allowed Nand[p] (which is equivalent to Not[p]). But in Version 14.1 there’s now "BinaryNAND" which yields for example Nand[p, p] instead of just Nand[p] (i.e. Not[p]). So here’s a representation of Or in terms of Nand:
说到布尔函数，14.1 版中改进的一个细节是转换为 NAND 表示法。默认情况下，像 BooleanConvert 这样的函数允许 Nand [p] （相当于 Not [p] ）。但在 14.1 版中，现在有了 "BinaryNAND" ，这就产生了例如 Nand [p, p] 而不仅仅是 Nand [p] （即 Not [p] ）。因此，这里用 Nand 表示 Or ：

Making the Wolfram Compiler Easier to Use
让 Wolfram 编译器更易于使用

Let’s say you have a piece of Wolfram Language code that you know you’re going to run a zillion times—so you want it to run absolutely as fast as possible. Well, you’ll want to make sure you’re doing the best algorithmic things you can (and making the best possible use of Wolfram Language superfunctions, etc.). And perhaps you’ll find it helpful to use things like DataStructure constructs. But ultimately if you really want your code to run absolutely as fast as your computer can make it, you’ll probably want to set it up so that it can be compiled using the Wolfram Compiler, directly to LLVM code and then machine code.
假设您有一段 Wolfram 语言代码，您知道要运行无数次，因此希望它运行得越快越好。那么，您就需要确保自己在算法上做到最好（并尽可能充分利用 Wolfram 语言的超级函数等）。也许您还会发现使用 DataStructure 结构之类的东西很有帮助。但最终，如果您真的希望您的代码以计算机能达到的最快速度运行，您可能会希望对代码进行设置，以便使用Wolfram编译器直接编译为LLVM代码，然后再编译为机器代码。

We’ve been developing the Wolfram Compiler for many years, and it’s becoming steadily more capable (and efficient). And for example it’s become increasingly important in our own internal development efforts. In the past, when we wrote critical inner-loop internal code for the Wolfram Language, we did it in C. But in the past few years we’ve almost completely transitioned instead to writing pure Wolfram Language code that we then compile with the Wolfram Compiler. And the result of this has been a dramatically faster and more reliable development pipeline for writing inner-loop code.
多年来，我们一直在开发 Wolfram 编译器，它的功能和效率正在稳步提高。例如，它在我们自己的内部开发工作中变得越来越重要。过去，当我们为 Wolfram 语言编写关键的内循环内部代码时，我们使用的是 C 语言。但在过去几年中，我们几乎完全过渡到编写纯 Wolfram 语言代码，然后使用 Wolfram 编译器进行编译。这样做的结果是，在编写内循环代码时，开发管道的速度大大加快，而且更加可靠。

Ultimately what the Wolfram Compiler needs to do is to take the code you write and align it with the low-level capabilities of your computer, figuring out what low-level data types can be used for what, etc. Some of this can be done automatically (using all sorts of fancy symbolic and theorem-proving-like techniques). But some needs to be based on collaboration between the programmer and the compiler. And in Version 14.1 we’re adding several important ways to enhance that collaboration.
最终，Wolfram 编译器需要做的是将您编写的代码与计算机的底层功能相匹配，找出哪些底层数据类型可用于哪些用途，等等。其中有些工作可以自动完成（使用各种花哨的符号和类似定理推导的技术）。但也有一部分需要程序员和编译器共同协作完成。在 14.1 版中，我们增加了几种重要的方法来加强这种协作。

The first thing is that it’s now easy to get access to information the compiler has. For example, here’s the type declaration the compiler has for the built-in function Dimensions:
首先，现在可以轻松获取编译器掌握的信息。例如，下面是编译器掌握的内置函数 Dimensions 的类型声明：

And here’s the source code of the actual implementation the compiler is using for Dimensions, calling its intrinsic low-level internal functions like CopyTo:
下面是编译器为 Dimensions 调用其固有的低级内部函数（如 CopyTo ）的实际实现的源代码：

A function like Map has a vastly more complex set of type declarations:
像 Map 这样的函数，其类型声明要复杂得多：

For types themselves, CompilerInformation lets you see their type hierarchy:
对于类型本身， CompilerInformation 可以让你看到它们的类型层次结构：

And for data structure types, you can do things like see the fields they contain, and the operations they support:
对于数据结构类型，你可以查看它们包含的字段以及支持的操作：

And, by the way, something new in Version 14.1 is the function OperationDeclaration which lets you declare operations to add to a data structure type you’ve defined.
顺便提一下，14.1 版还新增了 OperationDeclaration 函数，通过该函数，您可以声明要添加到已定义的数据结构类型中的操作。

Once you actually start running the compiler, a convenient new feature in Version 14.1 is a detailed progress monitor that lets you see what the compiler is doing at each step:
一旦开始实际运行编译器，14.1 版的一个便捷新功能是详细的进度监控器，可让您查看编译器在每一步的运行情况：

As we said, the key to compilation is figuring out how to align your code with the low-level capabilities of your computer. The Wolfram Language can do arbitrary symbolic operations. But many of those don’t align with low-level capabilities of your computer, and can’t meaningfully be compiled. Sometimes those failures to align are the result of sophistication that’s possible only with symbolic operations. But sometimes the failures can be avoided if you “unpack” things a bit. And sometimes the failures are just the result of programming mistakes. And now in Version 14.1 the Wolfram Compiler is starting to be able to annotate your code to show where the misalignments are happening, so you can go through and figure out what to do with them. (It’s something that’s uniquely possible because of the symbolic structure of the Wolfram Language and even more so of Wolfram Notebooks.)
正如我们所说，编译的关键在于如何使代码与计算机的底层功能保持一致。Wolfram 语言可以进行任意的符号运算。但其中许多操作并不符合计算机的底层能力，因此无法进行有意义的编译。有时，这些不一致是由于只有符号运算才能实现的复杂性造成的。但有时，如果你稍微 "解包 "一下，就能避免这些故障。有时，失败只是编程错误的结果。现在，在 14.1 版中，Wolfram 编译器开始能够注释您的代码，以显示发生错位的位置，这样您就可以查看并找出如何处理它们。(由于 Wolfram 语言的符号结构，以及 Wolfram 笔记本的独特功能，这一切都成为可能）。

Here’s a very simple example:
这里有一个非常简单的例子：

In compiled code, Sin expects a numerical argument, so a Boolean argument won’t work. Clicking the Source button lets you see where specifically something went wrong:
在编译后的代码中， Sin 希望使用数字参数，因此布尔参数将不起作用。单击 Source 按钮，您就可以看到具体是哪里出错了：

If you have several levels of definitions, the Source button will show you the whole chain:
如果您有多个级别的定义， Source 按钮将显示整个链：

Here’s a slightly more complicated piece of code, in which the specific place where there’s a problem is highlighted:
下面是一段稍微复杂的代码，其中突出显示了出现问题的具体位置：

In a typical workflow you might start from pure Wolfram Language code, without Typed and other compilation information. Then you start adding such information, repeatedly trying the compilation, seeing what issues arise, and fixing them. And, by the way, because it’s completely efficient to call small pieces of compiled code within ordinary Wolfram Language code, it’s common to start by annotating and compiling the “innermost inner loops” in your code, and gradually “working outwards”.
在一个典型的工作流程中，您可能会从纯粹的 Wolfram 语言代码开始，没有 Typed 和其他编译信息。然后，您开始添加此类信息，反复尝试编译，查看出现了哪些问题，并加以解决。顺便提一下，由于在普通 Wolfram 语言代码中调用小段编译后的代码是完全高效的，因此通常会从注释和编译代码中的 "最内层内部循环 "开始，然后逐步 "向外扩展"。

But, OK, let’s say you’ve successfully compiled a piece of code. Most of the time it’ll handle certain cases, but not others (for example, it might work fine with machine-precision numbers, but not be capable of handling arbitrary precision). By default, compiled code that’s running is set up to generate a message and revert to ordinary Wolfram Language evaluation if it can’t handle something:
但是，好吧，假设你已经成功编译了一段代码。大多数情况下，它能处理某些情况，但不能处理其他情况（例如，它可能能很好地处理机器精度数字，但不能处理任意精度数字）。默认情况下，运行中的编译代码会生成一条信息，并在无法处理某些问题时恢复到普通的 Wolfram 语言评估：

But in Version 14.1 there a new option CompilerRuntimeErrorAction that lets you specify an action to take (or, in general, a function to apply) whenever a runtime error occurs. A setting of None aborts the whole computation if there’s a runtime error:
但在 14.1 版中，有一个新选项 CompilerRuntimeErrorAction 可以让您指定在运行时出错时要采取的行动（或一般情况下要应用的函数）。如果出现运行时错误， None 的设置会中止整个计算：

Even Smoother Integration with External Languages
与外部语言更顺畅的集成

Let’s say there’s some functionality you want to use, but the only implementation you have is in a package in some external language, like Python. Well, it’s now basically seamless to work with such functionality directly in the Wolfram Language—plugging into the whole symbolic framework and functionality of the Wolfram Language.
比方说，您想使用某些功能，但唯一的实现方式是在某种外部语言（如 Python）的软件包中。那么，现在基本上可以直接在 Wolfram 语言中无缝地使用这些功能--直接插入 Wolfram 语言的整个符号框架和功能。

As a simple example, here’s a function that uses the Python package faker to produce a random sentence (which of course would also be straightforward to do directly in Wolfram Language):
举个简单的例子，下面是一个使用 Python 软件包 faker 生成随机句子的函数（当然也可以直接在 Wolfram 语言中实现）：

The first time you run RandomSentence, the progress monitor will show you all sorts of messy things happening under the hood, as Python versions get loaded, dependencies get set up, and so on. But the point is that it’s all automatic, and so you don’t have to worry about it. And in the end, out pops the answer:
第一次运行 RandomSentence 时，进度监视器会显示在引擎盖下发生的各种乱七八糟的事情，如 Python 版本加载、依赖关系设置等等。但重点是，这些都是自动进行的，所以你不必担心。最后，答案就出来了：

And if you run the function again, all the setup will already have been done, and the answer will pop out immediately:
如果您再次运行该函数，所有设置都已完成，答案会立即弹出：

An important piece of automation here is the conversion of data types. One of the great things about the Wolfram Language is that it has fully integrated symbolic representations for a very wide range of things—from videos to molecules to IP addresses. And when there are standard representations for these things in a language like Python, we’ll automatically convert to and from them.
数据类型的转换是自动化的重要一环。Wolfram 语言的一大优点是，它完全集成了各种事物的符号表示法，从视频到分子，再到 IP 地址。当像 Python 这样的语言中存在这些事物的标准表示法时，我们就会自动进行转换。

But particularly with more sophisticated packages, there’ll be a need to let the package deal with its own “external objects” that are basically opaque to the Wolfram Language, but can be handled as atomic symbolic constructs there.
但是，特别是对于更复杂的软件包，有必要让软件包处理自己的 "外部对象"，这些对象对于 Wolfram 语言来说基本上是不透明的，但在 Wolfram 语言中可以作为原子符号构造来处理。

For example, let’s say we’ve started a Python external package chess (and, yes, there’s a paclet in the Wolfram Paclet Repository that has considerably more chess functionality):
例如，假设我们启动了一个 Python 外部软件包 chess （没错，Wolfram Paclet Repository 中有一个 paclet 具有更多的国际象棋功能）：

Now the state of a chessboard can be represented by an external object:
现在，棋盘的状态可以用外部对象来表示：

We can define a function to plot the board:
我们可以定义一个函数来绘制电路板：

And now in Version 14.1 you can just pass your external object to the external function:
现在，在 14.1 版中，您只需将外部对象传递给外部函数即可：

You can also directly extract attributes of the external object:
您还可以直接提取外部对象的属性：

And you can call methods (here to make a chess move), changing the state of the external object:
你还可以调用方法（这里是下棋），改变外部对象的状态：

Here’s a plot of a new board configuration:
下面是新电路板的配置图：

This computes all legal moves from the current position, representing them as external objects:
它会计算从当前位置开始的所有合法移动，并将其表示为外部对象：

Here are UCI string representations of these:
以下是 UCI 字符串表示法：

In what we’re doing here we’re immediately performing each external operation. But Version 14.1 introduces the construct ExternalOperation which lets you symbolically represent an external operation, and for example build up collections of such operations that can all be performed together in a single external evaluation. ExternalObject supports various built-in operations for each environment. So, for example, in Python we can use Call and GetAttribute to get the symbolic representation:
在这里，我们将立即执行每个外部操作。但是，14.1 版引入了 ExternalOperation 结构，它可以让您用符号表示外部操作，例如，可以建立此类操作的集合，在一次外部评估中一并执行。 ExternalObject 支持每个环境的各种内置操作。因此，例如在 Python 中，我们可以使用 Call 和 GetAttribute 获得符号表示：

If we evaluate this, all these operations will get done together in the external environment:
如果我们对此进行评估，所有这些操作都将在外部环境中一并完成：

Standalone Wolfram Language Applications!
独立的 Wolfram 语言应用程序！

Let’s say you’re writing an application in pretty much any programming language—and inside it you want to call Wolfram Language functionality. Well, you could always do that by using a web API served from the Wolfram Cloud. And you could also do it locally by running the Wolfram Engine. But in Version 14.1 there’s something new: a way of integrating a standalone Wolfram Language runtime right into your application. The Wolfram Language runtime is a dynamic library that you link into your program, and then call using a C-based API. How big is the runtime? Well, it depends on what you want to use in the Wolfram Language. Because we now have the technology to prune a runtime to include only capabilities needed for particular Wolfram Language code. And the result is that adding the Wolfram Language will often increase the disk requirements of your application only by a remarkably small amount—like just a few hundred megabytes or even less. And, by the way, you can distribute the Wolfram runtime as an integrated part of an application, with its users not needing their own licenses to run it.
假设您正在使用几乎所有编程语言编写应用程序，并希望在其中调用 Wolfram 语言的功能。您可以使用 Wolfram Cloud 提供的网络 API 来实现这一目的。您也可以在本地运行 Wolfram 引擎。但在 14.1 版中有一些新功能：将独立的 Wolfram 语言运行时直接集成到您的应用程序中。Wolfram 语言运行时是一个动态库，您可以将其链接到程序中，然后使用基于 C 语言的应用程序接口调用。运行时有多大？这取决于您想在 Wolfram 语言中使用什么。因为我们现在拥有的技术可以对运行时进行剪裁，使其只包含特定 Wolfram 语言代码所需的功能。因此，添加 Wolfram 语言通常只会增加应用程序的磁盘需求，而且增加的数量非常少，只有几百兆甚至更少。此外，您还可以将 Wolfram 运行时作为应用程序的一个集成部分进行发布，用户无需获得自己的许可证即可运行 Wolfram 运行时。

OK, so how does creating a standalone Wolfram-enabled application actually work? There’s a lot of software engineering (associated with the Wolfram Language runtime, how it’s called, etc.) under the hood. But at the level of the application programmer you only have to deal with our Standalone Applications SDK—whose interface is rather simple.
那么，创建一个支持 Wolfram 的独立应用程序究竟是如何实现的呢？这需要大量的软件工程（与 Wolfram 语言运行时、如何调用等相关）。但在应用程序编程人员层面，您只需使用我们的独立应用程序 SDK，其界面非常简单。

As an example, here’s the C code part of a standalone application that uses the Wolfram Language to identify what (human) language a piece of text is in. The program here takes a string of text on its command line, then runs the Wolfram Language LanguageIdentify function on it, and then prints a string giving the result:
举例来说，下面是一个独立应用程序的 C 代码部分，它使用 Wolfram 语言来识别一段文本所使用的（人类）语言。该程序在命令行中接收一串文本，然后运行 Wolfram 语言的 LanguageIdentify 函数，最后打印出一个字符串，给出结果：

If we ignore issues of pruning, etc. we can compile this program just with (and, yes, the file paths are necessarily a bit long):
如果不考虑剪枝等问题，我们只需编译这个程序即可（当然，文件路径必然有点长）：

Now we can run the resulting executable directly from the command line—and it’ll act just like any other executable, even though inside it’s got all the power of a Wolfram Language runtime:
现在，我们可以直接从命令行运行生成的可执行文件--它的运行方式与其他可执行文件无异，尽管其内部拥有 Wolfram 语言运行时的所有功能：

If we look at the C program above, it basically begins just by starting the Wolfram Language runtime (using WLR_SDK_START_RUNTIME()). But then it takes the string (argv[1]) from the command line, embeds it in a Wolfram Language expression LanguageIdentify[string], evaluates this expression, and extracts a raw string from the result.
如果我们看一下上面的 C 程序，它基本上只是从启动 Wolfram 语言运行时开始（使用 WLR_SDK_START_RUNTIME() ）。但随后它会从命令行中获取字符串 (argv[1]) ，将其嵌入 Wolfram 语言表达式 LanguageIdentify [ string ] ，对该表达式进行求值，并从结果中提取原始字符串。

The functions, etc. that are involved here are part of the new Expression API supported by the Wolfram Language runtime dynamic library. The Expression API provides very clean capabilities for building up and taking apart Wolfram Language expressions from C. There are functions like wlr_Symbol("string") that form symbols, as well as macros like wlr_List(elem_$1, elem_$2, …) and wlr_E(head, arg_$1, arg_$2, …) that build up lists and general expressions. Then there’s the function wlr_Eval(expr) that calls the Wolfram Language evaluator. With functions like wlr_StringData(expr, &result, …) you can then extract content from expressions (here the characters in a string) and put it into C data structures.
这里涉及的函数等是 Wolfram 语言运行时动态库支持的新表达式 API 的一部分。Expression API 为从 C 语言构建和拆分 Wolfram 语言表达式提供了非常简洁的功能。有一些函数，如 wlr_ Symbol (" string ") 可以形成符号、以及像 wlr_ List (elem_$1, elem_$2, …) 和 wlr_ E ( head , arg_$1, arg_$2, …) 这样的宏，用于建立列表和一般表达式。然后是调用 Wolfram 语言评估器的函数 wlr_Eval(expr) 。通过 wlr_StringData(expr, &result, …) 等函数，您可以从表达式中提取内容（此处为字符串中的字符），并将其放入 C 数据结构中。

How does the Expression API relate to WSTP? WSTP (“Wolfram Symbolic Transfer Protocol”) is our protocol for transferring symbolic expressions between processes. The Expression API, on the other hand, operates within a single process, providing the “glue” that connects C code to expressions in the Wolfram Language runtime.
Expression API 与 WSTP 有什么关系？WSTP（"Wolfram 符号传输协议"）是我们用于在进程间传输符号表达式的协议。另一方面，Expression API 在单个进程内运行，提供连接 C 代码与 Wolfram 语言运行时中表达式的 "粘合剂"。

One example of a real-world use of our new Standalone Applications technology is the LSPServer application that will soon be in full distribution. LSPServer started from a pure (though somewhat lengthy) Wolfram Language paclet that provides Language Server Protocol services for annotating Wolfram Language code in programs like Visual Studio Code. To build the LSPServer standalone application we just wrote a tiny C program that calls the paclet, then compiled this and linked it against our Standalone Applications SDK. Along the way (using tools that we’re planning to soon make available)—and based on the fact that only a small part of the full functionality of the Wolfram Language is needed to support LSPServer—we pruned the Wolfram Language runtime, in the end getting a complete LSPServer application that’s only about 170 MB in size, and that shows no outside signs of having Wolfram Language functionality inside.
我们新的独立应用程序技术在现实世界中的一个应用实例是即将全面发布的 LSPServer 应用程序。LSPServer 源自一个纯粹的 Wolfram 语言小程序（虽然有些冗长），它为在 Visual Studio Code 等程序中注释 Wolfram 语言代码提供语言服务器协议服务。为了构建 LSPServer 独立应用程序，我们只需编写一个调用 paclet 的小 C 程序，然后将其编译并与我们的独立应用程序 SDK 相链接。在此过程中（使用我们计划很快推出的工具），基于支持 LSPServer 只需要 Wolfram 语言全部功能中的一小部分这一事实，我们对 Wolfram 语言运行时进行了删减，最终得到了一个完整的 LSPServer 应用程序，其大小仅为 170 MB 左右，而且没有任何外部迹象表明其内部包含 Wolfram 语言功能。

And Yet More… 还有更多...

Is that all? Well, no. There’s more. Like new formatting of Root objects (yes, I was frustrated with the old one). Or like a new drag-and-drop-to-answer option for QuestionObject quizzes. Or like all the documentation we’ve added for new types of entities and interpreters.
就这些？嗯，没有。还有更多。比如 Root 对象的新格式（是的，我对旧格式很不满意）。或者像 QuestionObject 测验的新拖放到答案选项。或者像我们为新型实体和解释器添加的所有文档。

In addition, there’s also the continual stream of new data that we’ve curated, or that’s flowed in real time into the Wolfram Knowledgebase. And beyond the core Wolfram Language itself, there’ve also been lots of functions added to the Wolfram Function Repository, lots of paclets added to the Wolfram Language Paclet Repository, not to mention new entries in the Wolfram Neural Net Repository, Wolfram Data Repository, etc.
此外，我们还不断整理新数据，或将其实时导入Wolfram知识库。除了核心 Wolfram 语言本身，Wolfram 函数库中还添加了大量函数、Wolfram 语言 Paclet 资源库中添加了大量 paclet，更不用说 Wolfram 神经网络资源库、Wolfram 数据资源库中的新条目等等。

Yes, as always it’s been a lot of work. But today it’s here, and we’re proud of it: Version 14.1!
是的，一如既往，我们做了大量的工作。但今天，它来了，我们为此感到自豪：14.1 版！

Related Writings 相关著作

The Story Continues: Announcing Version 14 of Wolfram Language and Mathematica
故事仍在继续发布第 14 版 Wolfram 语言和 Mathematica

January 9, 2024 2024 年 1 月 9 日

How to Think Computationally about AI, the Universe and Everything
如何用计算思维看待人工智能、宇宙和万物

October 27, 2023 2023 年 10 月 27 日

Expression Evaluation and Fundamental Physics
表达评估和基础物理学

September 29, 2023 2023 年 9 月 29 日

Generative AI Space and the Mental Imagery of Alien Minds
生成式人工智能空间与外星人的心理想象

July 17, 2023 2023 年 7 月 17 日