Last year we released Version 13.0 of the Wolfram Language. Here are the updates in trees since then, including the latest features in 13.1.

 

Trees Continue to Grow

In Version 12.3 we introduced Tree as a new fundamental construct in the Wolfram Language. In Version 13.0 we added a variety of styling options for trees, and in Version 13.1 we’re adding more styling as well as a variety of new fundamental features.

An important update to the fundamental Tree construct in Version 13.1 is the ability to name branches at each node, by giving them in an association:

&#10005

All tree functions now include support for associations:

&#10005

In many uses of trees the labels of nodes are crucial. But particularly in more abstract applications one often wants to deal with unlabeled trees. In Version 13.1 the function UnlabeledTree (roughly analogously to UndirectedGraph) takes a labeled tree, and basically removes all visible labels. Here is a standard labeled tree

&#10005

and here’s the unlabeled analog:

&#10005

In Version 12.3 we introduced ExpressionTree for deriving trees from general symbolic expressions. Our plan is to have a wide range of “special trees” appropriate for representing different specific kinds of symbolic expressions. We’re beginning this process in Version 13.1 by, for example, having the concept of “Dataset trees”. Here’s ExpressionTree converting a dataset to a tree:

&#10005

And now here’s TreeExpression “inverting” that, and producing a dataset:

&#10005

(Remember the convention that *Tree functions return a tree; while Tree* functions take a tree and return something else.)

Here’s a “graph rendering” of a more complicated dataset tree:

&#10005

The new function TreeLeafCount lets you count the total number of leaf nodes on a tree (basically the analog of LeafCount for a general symbolic expression):

&#10005

Another new function in Version 13.1 that’s often useful in getting a sense of the structure of a tree without inspecting every node is RootTree. Here’s a random tree:

&#10005

RootTree can get a subtree that’s “close to the root”:

&#10005

It can also get a subtree that’s “far from the leaves”, in this case going down to elements that are at level –2 in the tree:

&#10005

In some ways the styling of trees is like the styling of graphs—though there are some significant differences as a result of the hierarchical nature of trees. By default, options inserted into a particular tree element affect only that tree element:

&#10005

But you can give rules that specify how elements in the subtree below that element are affected:

&#10005

In Version 13.1 there is now detailed control available for styling both nodes and edges in the tree. Here’s an example that gives styling for parent edges of nodes:

&#10005

Options like TreeElementStyle determine styling from the positions of elements. TreeElementStyleFunction, on the other hand, determines styling by applying a function to the data at each node:

&#10005

This uses both data and position information for each node:

&#10005

In analogy with VertexShapeFunction for graphs, TreeElementShapeFunction provides a general mechanism to specify how nodes of a tree should be rendered. This named setting for TreeElementShapeFunction makes every node be displayed as a circle:

&#10005

Last year we released Version 13.0 of the Wolfram Language. Here are the updates in visual effects and beautification since then, including the latest features in 13.1.

 

Visual Effects & Beautification

At first it seemed like a minor feature. But once we’d implemented it, we realized it was much more useful than we’d expected. Just as you can style a graphics object with its color (and, as of Version 13.0, its filling pattern), now in Version 13.1 you can style it with its drop shadowing:

&#10005

Drop shadowing turns out to be a nice way to “bring graphics to life”

&#10005

or to emphasize one element over others:

&#10005

It works well in geo graphics as well:

&#10005

DropShadowing allows detailed control over the shadows: what direction they’re in, how blurred they are and what color they are:

&#10005

Drop shadowing is more complicated “under the hood” than one might imagine. And when possible it actually works using hardware GPU pixel shaders—the same technology that we’ve used since Version 12.3 to implement material-based surface textures for 3D graphics. In Version 13.1 we’ve explicitly exposed some well-known underlying types of 3D shading. Here’s a geodesic polyhedron (yes, that’s another new function in Version 13.1), with its surface normals added (using the again new function EstimatedPointNormals):

&#10005

Here’s the most basic form of shading: flat shading of each facet (and the specularity in this case doesn’t “catch” any facets):

&#10005

Here now is Gouraud shading, with a somewhat-faceted glint:

&#10005

And then there’s Phong shading, looking somewhat more natural for a sphere:

&#10005

Ever since Version 1.0, we’ve had an interactive way to rotate—and zoom into—3D graphics. (Yes, the mechanism was a bit primitive 34 years ago, but it rapidly got to more or less its modern form.) But in Version 13.1 we’re adding something new: the ability to “dolly” into a 3D graphic, imitating what would happen if you actually walked into a physical version of the graphic, as opposed to just zooming your camera:

&#10005

And, yes, things can get a bit surreal (or “treky”)—here dollying in and then zooming out:

Last year we released Version 13.0 of the Wolfram Language. Here are the updates in listability since then, including the latest features in 13.1.

 

Beyond Listability: Introducing Threaded

From the very beginning of Mathematica and the Wolfram Language we’ve had the concept of listability: if you add two lists, for example, their corresponding elements will be added:

&#10005

It’s a very convenient mechanism, that typically does exactly what you’d want. And for 35 years we haven’t really considered extending it. But if we look at code that gets written, it often happens that there are parts that basically implement something very much like listability, but slightly more general. And in Version 13.1 we have a new symbolic construct, Threaded, that effectively allows you to easily generalize listability. Consider:

&#10005

This uses ordinary listability, effectively computing:

&#10005

But what if you want instead to “go down a level” and thread {x,y} into the lowest parts of the first list? Well, now you can use Threaded to do that:

&#10005

On its own, Threaded is just a symbolic wrapper:

&#10005

But as soon as it appears in a function—like Plus—that has attribute Listable, it specifies that the listability should be applied after what’s specified inside Threaded is “threaded” at the lowest level. Here’s another example. Create a list:

&#10005

How should we then multiply each element by {1,–1}? We could do this with:

&#10005

But now we’ve got Threaded, and so instead we can just say:

&#10005

You can give Threaded as an argument to any listable function, not just Plus and Times:

&#10005

You can use Threaded and ordinary listability together:

&#10005

You can have several Threadeds together as well:

&#10005

Threaded, by the way, gets its name from the function Thread, which explicitly does “threading”, as in:

&#10005

By default, Threaded will always thread into the lowest level of a list:

&#10005

&#10005

Here’s a “real-life” example of using Threaded like this. The data in a 3D color image consists of a rank-3 array of triples of RGB values:

&#10005

This multiplies every RGB triple by {0,1,2}:

&#10005

Most of the time you either want to use ordinary listability that operates at the top level of a list, or you want to use the default form of Threaded, that operates at the lowest level of a list. But Threaded has a more general form, in which you can explicitly say what level you want it to operate at. Here’s the default case:

&#10005

Here’s level 1, which is just like ordinary listability:

&#10005

And here’s threading into level 2:

&#10005

Threaded provides a very convenient way to do all sorts of array-combining operations. There’s additional complexity when the object being “threaded in” itself has multiple levels. The default in this case is to align the lowest level in the thing being threaded in with the lowest level of the thing into which it’s being threaded:

&#10005

Here now is “ordinary listability” behavior:

&#10005

For the arrays we’re looking at here, the default behavior is equivalent to:

&#10005

Sometimes it’s clearer to write this out in a form like

&#10005

which says that the first level of the array inside the Threaded is to be aligned with the second level of the outside array. In general, the default case is equivalent to –1 → –1, specifying that the bottom level of the array inside the Threaded should be aligned with the bottom level of the array outside.