Browse by Topic

# Mathematica News

Current Events & History

## ChatGPT Gets Its “Wolfram Superpowers”!

Early in January I wrote about the possibility of connecting ChatGPT to Wolfram|Alpha. And today—just two and a half months later—I’m excited to announce that it’s happened! Thanks to some heroic software engineering by our team and by OpenAI, ChatGPT can now call on Wolfram|Alpha—and Wolfram Language as well—to give it what we might think […]

Best of Blog

## The Latest from Our R&D Pipeline: Version 13.2 of Wolfram Language & Mathematica

In 2020 it was Versions 12.1 and 12.2; in 2021 Versions 12.3 and 13.0. In late June this year it was Version 13.1. And now we’re releasing Version 13.2. We continue to have a huge pipeline of R&D, some short term, some medium term, some long term (like decade-plus). Our goal is to deliver timely […]

Announcements & Events

## Trees Continue to Grow 🌱🌳

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:

 ✕

All tree functions now include support for associations:

 ✕

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

 ✕

and here’s the unlabeled analog:

 ✕

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:

 ✕

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

 ✕

(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:

 ✕

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

 ✕

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:

 ✕

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

 ✕

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:

 ✕

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:

 ✕

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

 ✕

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:

 ✕

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:

 ✕

This uses both data and position information for each node:

 ✕

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:

 ✕
Announcements & Events

## New in 13.1: Visual Effects and Beautification

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:
 ✕
Drop shadowing turns out to be a nice way to “bring graphics to life”
 ✕
or to emphasize one element over others:
 ✕
It works well in geo graphics as well:
 ✕
DropShadowing allows detailed control over the shadows: what direction they’re in, how blurred they are and what color they are:
 ✕
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):
 ✕
Here’s the most basic form of shading: flat shading of each facet (and the specularity in this case doesn’t “catch” any facets):
 ✕
Here now is Gouraud shading, with a somewhat-faceted glint:
 ✕
And then there’s Phong shading, looking somewhat more natural for a sphere:
 ✕
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:
 ✕
And, yes, things can get a bit surreal (or “treky”)—here dollying in and then zooming out:
Announcements & Events

## New in 13.1: Beyond Listability: Introducing Threaded

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.

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:
 ✕
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:
 ✕
This uses ordinary listability, effectively computing:
 ✕
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:
 ✕
On its own, Threaded is just a symbolic wrapper:
 ✕
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:
 ✕
How should we then multiply each element by {1,–1}? We could do this with:
 ✕
But now we’ve got Threaded, and so instead we can just say:
 ✕
You can give Threaded as an argument to any listable function, not just Plus and Times:
 ✕
You can use Threaded and ordinary listability together:
 ✕
You can have several Threadeds together as well:
 ✕
Threaded, by the way, gets its name from the function Thread, which explicitly does “threading”, as in:
 ✕
By default, Threaded will always thread into the lowest level of a list:
 ✕
 ✕
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:
 ✕
This multiplies every RGB triple by {0,1,2}:
 ✕
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:
 ✕
Here’s level 1, which is just like ordinary listability:
 ✕
And here’s threading into level 2:
 ✕
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:
 ✕
Here now is “ordinary listability” behavior:
 ✕
For the arrays we’re looking at here, the default behavior is equivalent to:
 ✕
Sometimes it’s clearer to write this out in a form like
 ✕
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.
Announcements & Events

## New in 13.1: College and Fractional Calculus

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

### College Calculus

Transforming college calculus was one of the early achievements of Mathematica. But even now we’re continuing to add functionality to make college calculus ever easier and smoother to do—and more immediately connectable to applications. We’ve always had the function D for taking derivatives at a point. Now in Version 13.1 we’re adding ImplicitD for finding implicit derivatives.

So, for example, it can find the derivative of xy with respect to x, with y determined implicit by the constraint x2 + y2 = 1:

 ✕

Leave out the first argument and you’ll get the standard college calculus “find the slope of the tangent line to a curve”:

 ✕

So far all of this is a fairly straightforward repackaging of our longstanding calculus functionality. And indeed these kinds of implicit derivatives have been available for a long time in Wolfram|Alpha. But for Mathematica and the Wolfram Language we want everything to be as general as possible—and to support the kinds of things that show up in differential geometry, and in things like asymptotics and validation of implicit solutions to differential equations. So in addition to ordinary college-level calculus, ImplicitD can do things like finding a second implicit derivative on a curve defined by the intersection of two surfaces:

 ✕

In Mathematica and the Wolfram Language Integrate is a function that just gets you answers. (In Wolfram|Alpha you can ask for a step-by-step solution too.) But particularly for educational purposes—and sometimes also when pushing boundaries of what’s possible—it can be useful to do integrals in steps. And so in Version 13.1 we’ve added the function IntegrateChangeVariables for changing variables in integrals.

An immediate issue is that when you specify an integral with Integrate[...], Integrate will just go ahead and do the integral:

 ✕

But for IntegrateChangeVariables you need an “undone” integral. And you can get this using Inactive, as in:

 ✕

And given this inactive form, we can use IntegrateChangeVariables to do a “trig substitution”:

 ✕

The result is again an inactive form, now stating the integral differently. Activate goes ahead and actually does the integral:

 ✕

IntegrateChangeVariables can deal with multiple integrals as well—and with named coordinate systems. Here it’s transforming a double integral to polar coordinates:

 ✕

Although the basic “structural” transformation of variables in integrals is quite straightforward, the whole story of IntegrateChangeVariables is considerably more complicated. “College-level” changes of variables are usually carefully arranged to come out easily. But in the more general case, IntegrateChangeVariables ends up having to do nontrivial transformations of geometric regions, difficult simplifications of integrands subject to certain constraints, and so on.

In addition to changing variables in integrals, Version 13.1 also introduces DSolveChangeVariables for changing variables in differential equations. Here it’s transforming the Laplace equation to polar coordinates:

 ✕

Sometimes a change of variables can just be a convenience. But sometimes (think General Relativity) it can lead one to a whole different view of a system. Here, for example, an exponential transformation converts the usual Cauchy–Euler equation to a form with constant coefficients:

 ✕

### Fractional Calculus

The first derivative of x2 is 2x; the second derivative is 2. But what is the derivative? It’s a question that was asked (for example by Leibniz) even in the first years of calculus. And by the 1800s Riemann and Liouville had given an answer—which in Version 13.1 can now be computed by the new FractionalD:

 ✕

And, yes, do another derivative and you get back the 1st derivative:

 ✕

In the more general case we have:

 ✕

And this works even for negative derivatives, so that, for example, the (–1)st derivative is an ordinary integral:

 ✕

It can be at least as difficult to compute a fractional derivative as an integral. But FractionalD can still often do it

 ✕

though the result can quickly become quite complicated:

 ✕

Why is FractionalD a separate function, rather than just being part of a generalization of D? We discussed this for quite a while. And the reason we introduced the explicit FractionalD is that there isn’t a unique definition of fractional derivatives. In fact, in Version 13.1 we also support the Caputo fractional derivative (or differintegral) CaputoD.

For the derivative of x2, the answer is still the same:

 ✕

But as soon as a function isn’t zero at x = 0 the answer can be different:

 ✕

CaputoD is a particularly convenient definition of fractional differentiation when one’s dealing with Laplace transforms and differential equations. And in Version 13.1 we can now only compute CaputoD but also do integral transforms and solve equations that involve it.

Here’s a -order differential equation

 ✕

and a -order one

 ✕

as well as a πth-order one:

 ✕

Note the appearance of MittagLefflerE. This function (which we introduced in Version 9.0) plays the same kind of role for fractional derivatives that Exp plays for ordinary derivatives.

Announcements & Events

## New in 13.1: Chemical Representations and Pattern Reactions

Last year we released Version 13.0 of the Wolfram Language. Here are the updates in chemical representations and symbolic pattern reactions since then, including the latest features in 13.1.

### Representing Amounts of Chemicals

Molecule lets one symbolically represent a molecule. Quantity lets one symbolically represent a quantity with units. In Version 13.1 we now have the new construct ChemicalInstance that’s in effect a merger of these, allowing one to represent a certain quantity of a certain chemical.

## Fractional Calculus in Wolfram Language 13.1

What is the half-derivative of x?

Fractional calculus studies the extension of derivatives and integrals to such fractional orders, along with methods of solving differential equations involving these fractional-order derivatives and integrals. This branch is becoming more and more popular in fluid dynamics, control theory, signal processing and other areas. Realizing the importance and potential of this topic, we have added support for fractional derivatives and integrals in the recent release of Version 13.1 of the Wolfram Language.
Best of Blog

## The Epic Continues…

Last week it was 34 years since the original launch of Mathematica and what’s now the Wolfram Language. And through all those years we’ve energetically continued building further and further, adding ever more capabilities, and steadily extending the domain of the computational paradigm.

In recent years we’ve established something of a rhythm, delivering the fruits of our development efforts roughly twice a year. We released Version 13.0 on December 13, 2021. And now, roughly six months later, we’re releasing Version 13.1. As usual, even though it’s a “.1” release, it’s got a lot of new (and updated) functionality, some of which we’ve worked on for many years but finally now brought to fruition.