This year’s Wolfram Summer School will be held at Bentley University in Waltham, Massachusetts, from June 18 to July 7, 2017.

Maybe you’re a researcher who wants to study the dynamics of galaxies with cellular automata. Perhaps you’re an innovator who wants to create a way to read time from pictures of analog clocks or build a new startup with products that use RFID (radio-frequency identification) to track objects. You might be an educator who wants to build an algebra feedback system or write a textbook that teaches designers how to disinvent the need for air conditioning. These projects show the diversity and creativity of some of our recent Summer School students. Does this sound like you? If so, we want you to join us this summer!

We offer three tracks: Science, Technology & Innovation and Educational Innovation. As a student, you will design and execute a challenging, practical project and acquire an incredible amount of knowledge along the way. At the Summer School, you will gain skills that are useful universally and network with a community of smart, creative people from all over the world. Many of our students go on to work for us in some capacity, whether that be as an employee, intern, ambassador, etc.

If you’re accepted to the Summer School, you will be mentored by top-notch staff who have made powerful and important contributions to the Wolfram Language, Mathematica, Wolfram|Alpha and more—including the inventor of the Wolfram Language, Stephen Wolfram.

The Wolfram Language has a vast depth of built-in algorithms and knowledge. Recent feature additions include a dynamic and ever-growing set of machine learning capabilities (including neural networks), as well as advancements in the areas of image processing, visualization, 3D printing, geographic information systems, natural language processing and computational linguistics and database and web frameworks, among many others.

Whatever your background, profession or future plans, the Wolfram Summer School can equip you with the computational tools you need to bring any idea to reality.

For more information, visit our website.

]]>I’m pleased to announce the release today of Version 11.1 of the Wolfram Language (and Mathematica). As of now, Version 11.1 is what’s running in the Wolfram Cloud—and desktop versions are available for immediate download for Mac, Windows and Linux.

What’s new in Version 11.1? Well, actually a remarkable amount. Here’s a summary:

There’s a lot here. One might think that a .1 release, nearly 29 years after Version 1.0, wouldn’t have much new any more. But that’s not how things work with the Wolfram Language, or with our company. Instead, as we’ve built our technology stack and our procedures, rather than progressively slowing down, we’ve been continually accelerating. And now even something as notionally small as the Version 11.1 release packs an amazing amount of R&D, and new functionality.

There’s one very obvious change in 11.1: the documentation looks different. We’ve spiffed up the design, and on the web we’ve made everything responsive to window width—so it looks good even when it’s in a narrow sidebar in the cloud, or on a phone.

We’ve also introduced some new design elements—like the mini-view of the Details section. Most people like to see examples as soon as they get to a function page. But it’s important not to forget the Details—and the mini-view provides what amounts to a little “ad” for them.

Here’s a word cloud of new functions in Version 11.1:

Altogether there are an impressive 132 new functions—together with another 98 that have been significantly enhanced. These functions represent the finished output of our R&D pipeline in just the few months that have elapsed since Version 11.0 was released.

When we bring out a major “integer” release—like Version 11—we’re typically introducing a bunch of complete, new frameworks. In (supposedly) minor .1 releases like Version 11.1, we’re not aiming for complete new frameworks. Instead, there’s typically new functionality that’s adding to existing frameworks—together with a few (sometimes “experimental”) hints of major new frameworks to come. Oh, and if a complete, new framework does happen to be finished in time for a .1 release, it’ll be there too.

One very hot area in which Version 11.1 makes some big steps forward is neural nets. It’s been exciting over the past few years to see this area advance so quickly in the world at large, and it’s been great to see the Wolfram Language at the very leading edge of what’s being done.

Our goal is to define a very high-level interface to neural nets, that’s completely integrated into the Wolfram Language. Version 11.1 adds some new recently developed building blocks—in particular 30 new types of neural net layers (more than double what was there in 11.0), together with automated support for recurrent nets. The concept is always to let the neural net be specified symbolically in the Wolfram Language, then let the language automatically fill in the details, interface with low-level libraries, etc. It’s something that’s very convenient for ordinary feed-forward networks (tensor sizes are all knitted together automatically, etc.)—but for recurrent nets (with variable-length sequences, etc.) it’s something that’s basically essential if one’s going to avoid lots of low-level programming.

Another crucial feature of neural nets in the Wolfram Language is that it’s set up to be automatic to encode images, text or whatever in an appropriate way. In Version 11.1, `NetEncoder` and `NetDecoder` cover a lot of new cases—extending what’s integrated into the Wolfram Language.

It’s worth saying that underneath the whole integrated symbolic interface, the Wolfram Language is using a very efficient low-level library—currently MXNet—which takes care of optimizing ultimate performance for the latest CPU and GPU configurations. By the way, another feature enhanced in 11.1 is the ability to store complete neural net specifications, complete with encoders, etc. in a portable and reusable .wlnet file.

There’s a lot of power in treating neural nets as symbolic objects. In 11.1 there are now functions like `NetMapOperator` and `NetFoldOperator` that symbolically build up new neural nets. And because the neural nets are symbolic, it’s easy to manipulate them, for example breaking them apart to monitor what they’re doing inside, or systematically comparing the performance of different structures of net.

In some sense, neural net layers are like the machine code of a neural net programming system. In 11.1 there’s a convenient function—`NetModel`—that provides pre-built trained or untrained neural net models. As of today, there are a modest number of famous neural nets included, but we plan to add more every week—surfing the leading edge of what’s being developed in the neural net research community, as well as adding some ideas of our own.

Here’s a simple example of `NetModel` at work:

Now apply the network to some actual data—and see it gets the right answer:

But because the net is specified symbolically, it’s easy to “go inside” and “see what it’s thinking”. Here’s a tiny (but neat) piece of functional programming that visualizes what happens at every layer in the net—and, yes, in the end the first square lights up red to show that the output is 0:

Neural nets are an important method for machine learning. But one of the core principles of the Wolfram Language is to provide highly automated functionality, independent of underlying methods. And in 11.1 there’s a bunch more of this in the area of machine learning. (As it happens, much of it uses the latest deep learning neural net methods, but for users what’s important is what it does, not how it does it.)

My personal favorite new machine learning function in 11.1 is `FeatureSpacePlot`. Give it any collection of objects, and it’ll try to lay them out in an appropriate “feature space”. Like here are the flags of countries in Europe:

What’s particularly neat about `FeatureSpacePlot` is that it’ll immediately use sophisticated pre-trained feature extractors for specific classes of input—like photographs, texts, etc. And there’s also now a `FeatureNearest` function that’s the analog of `Nearest`, but operates in feature space. Oh, and all the stuff with `NetModel` and pre-trained net models immediately flows into these functions, so it becomes trivial, say, to experiment with “meaning spaces”:

Particularly with `NetModel`, there are all sorts of very useful few-line neural net programs that one can construct. But in 11.1 there are also some major new, more infrastructural, machine learning capabilities. Notable examples are `ActiveClassification` and `ActivePrediction`—which build classifiers and predictors by actively sampling a space, learning how to do this as efficiently as possible. There will be lots of end-user applications for `ActiveClassification` and `ActivePrediction`, but for us internally the most immediately interesting thing is that we can use these functions to optimize all sorts of meta-algorithms that are built into the Wolfram Language.

Version 11.0 began the process of making audio—like images—something completely integrated into the Wolfram Language. Version 11.1 continues that process. For example, for desktop systems, it adds `AudioCapture` to immediately capture audio from a microphone on your computer. (Yes, it’s nontrivial to automatically handle out-of-core storage and processing of large audio samples, etc.) Here’s an example of me saying “hello”:

Play Audio

You can immediately take this, and, say, make a cepstrogram (yes, that’s another new audio function in 11.1):

Version 11.1 has quite an assortment of new features for images and visualization. `CurrentImage` got faster and better. `ImageEffect` has lots of new effects added. There are new functions and options to support the latest in computational photography and computational microscopy. And images got even more integrated as first-class objects—that one can for example now immediately do arithmetic with:

Something else with images—that I’ve long wanted—is the ability to take a bitmap image, and find an approximate vector graphics representation of it:

`TextRecognize` has also become significantly stronger—in particular being able to pick out structure in text, like paragraphs and columns and the like.

Oh, and in visualization, there are things like `GeoBubbleChart`, here showing the populations of the largest cities in the US:

There’s lots of little (but nice) stuff too. Like support for arbitrary callouts in pie charts, optimized labeling of discrete histograms and full support of scaling functions for `Plot3D`, etc.

There’s always new data flowing into the Wolfram Knowledgebase, and there’ve also been plenty of completely new things added since 11.0: 130,000+ new types of foods, 250,000+ atomic spectral lines, 12,000+ new mountains, 10,000+ new notable buildings, 300+ types of neurons, 650+ new waterfalls, 200+ new exoplanets (because they’ve recently been discovered), and lots else (not to mention 7,000+ new spelling words). There’s also, for example, much higher resolution geo elevation data—so now a 3D-printable Mount Everest can have much more detail:

Something new in Version 11.1 are integrated external services—that allow built-in functions that work by calling external APIs. Two examples are `WebSearch` and `WebImageSearch`. Here are thumbnail images found by searching the web for “colorful birds”:

For the heck of it, let’s see what `ImageIdentify` thinks they are (oh, and in 11.1. `ImageIdentify` is much more accurate, and you can even play with the network inside it by using `NetModel`):

Since `WebSearch` and `WebImageSearch` use external APIs, users need to pay for them separately. But we’ve set up what we call Service Credits to make this seamless. (Everything’s in the language, of course, so there’s for example `$ServiceCreditsAvailable`.)

There will be quite a few more examples of integrated services in future versions, but in 11.1, beyond web searching, there’s also `TextTranslation`. `WordTranslation` (new in 11.0) handles individual word translation for hundreds of languages; now in 11.1 `TextTranslation` uses external services to also translate complete pieces of text between several tens of languages:

A significant part of our R&D organization is devoted to continuing our three-decade effort to push the frontiers of mathematical and algorithmic computation. So it should come as no surprise that Version 11.1 has all sorts of advances in these areas. There’s space-filling curves, fractal meshes, ways to equidistribute points on a sphere:

There are new kinds of spatial, robust and multivariate statistics. There are Hankel transforms, built-in modular inverses, and more. Even in differentiation, there’s something new: *n*^{th} order derivatives, for symbolic *n*:

Here’s something else about differentiation: there are now functions `RealAbs` and `RealSign` that are versions of `Abs` and `Sign` that are defined only by the real axis, and so can freely be differentiated, without having to give any assumptions about variables.

In Version 10.1, we introduced the function `AnglePath`, that computes a path from successive segments with specified lengths and angles. At some level, `AnglePath` is like an industrial-scale version of Logo (or Scratch) “turtle geometry”. But `AnglePath` has turned out to be surprisingly broadly useful, so for Version 11.1, we’ve generalized it to `AnglePath3D` (and, yes, there are all sorts of subtleties about frames and Euler angles and so on).

When we say “June 23, 1988”, what do we mean? The beginning of that day? The whole 24-hour period from midnight to midnight? Or what? In Version 11.1 we’ve introduced the notion of granularity for dates—so you can say whether a date is supposed to represent a day, a year, a second, a week starting Sunday—or for that matter just an instant in time.

It’s a nice application of the symbolic character of the Wolfram Language—and it solves all sorts of problems in dealing with dates and times. In a way, it’s a little like precision for numbers, but it’s really its own thing. Here for example is how we now represent “the current week”:

Here’s the current decade:

This is the next month from now:

This says we want to start from next month, then add 7 weeks—getting another month:

And here’s the result to the granularity of a month:

Talking of dates, by the way, one of the things that’s coming across the system is the use of `Dated` as a qualifier, for example for properties of entities of the knowledgebase (so this asks for the population of New York City in 1970):

I’m very proud of how smooth the Wolfram Language is to use—and part of how that’s been achieved is that for 30 years we’ve been continually polishing it. We’re always making sure everything fits perfectly together—and we’re always adding little conveniences.

One of our principles is that if there’s a lump of computational work that people repeatedly do, then so long as there’s a good name for it (that people will readily remember, and readily recognize when they see it in a piece of code), it should be inserted as a built-in function. A very simple example in Version 11.1 is `ReverseSort`:

(One might think: what’s the point of this—it’s just `Reverse[Sort[...]]`. But it’s very common to want to map what’s now `ReverseSort` over a bunch of objects, and it’s smoother to be able to say `ReverseSort /@ ...` rather than `Reverse[Sort[#]]& /@ ...` or `Reverse@*Sort /@ ...`).

Another little convenience: `Nearest` now has special ways to specify useful things to return. For example, this gives the distances from 2.7 to the 5 nearest values:

`CellularAutomaton` is a very broad function. Version 11.1 makes it easier to use for common cases by allowing rules to be specified by associations with labeled elements:

We’re always trying to make sure that patterns we’ve established get used as broadly as possible. Like in 11.1, you can use `UpTo` in lots of new places, like in `ImageSize` specifications.

We also always trying to make sure that things are as general as possible. Like `IntegerString` now works not only with the standard representation of integers, but also with traditional ones used for different purposes around the world:

And `IntegerName` can also now handle different types and languages of names:

And there are lots more examples—each making the experience of using the Wolfram Language just a little bit smoother.

If you make a definition list ` x=7`, or

`PersistentValue` lets you specify a name (like `"foo"`), and a `"persistence location"`. (It also allows options like `PersistenceTime` and `ExpirationDate`.) The persistence location can just be `"KernelSession"`—which means that the value lasts only for a single kernel session. But it can also be `"FrontEndSession"`, or `"Local"` (meaning that it should be the same whenever you use the same computer), or `"Cloud"` (meaning that it’s globally synchronized across the cloud).

`PersistentValue` is pretty general. It lets you have values in different places (like different private clouds, for example); then there’s a `$PersistencePath` that defines the order to look at them in, and a `MergingFunction` that specifies how (if at all) the values should be merged.

One of the goals of the Wolfram Language is to be able to interact as broadly as possible with all computational ecosystems. Version 11.1 adds support for the M4A audio format, the .ubj binary JSON format, as well as .ini files and Java .properties files. There’s also a new function, `BinarySerialize`, that converts any Wolfram Language expression into a new binary (“WXF”) form, optimized for speed or size:

`BinaryDeserialize` gets it back:

Version 11.0 introduced `WolframScript`—a command-line interface to the Wolfram Language, running either locally or in the cloud. With `WolframScript` you can create standalone Wolfram Language programs that run from the shell. There are several enhancements to `WolframScript` itself in 11.1, but there’s also now a new `New` > `Script` menu item that gives you a notebook interface for creating .wls (=“Wolfram Language Script”) files to be run by `WolframScript`:

One of the major ways the Wolfram Language has advanced in recent times has been in its deployability. We’ve put a huge amount of work into making sure that the Wolfram Language can be robustly deployed at scale (and there are now lots of examples of successes out in the world).

We make updates to the Wolfram Cloud very frequently (and invisibly), steadily enhancing server performance and user interface capabilities. Along with Version 11.1 we’ve made some major updates. There are a few signs of this in the language.

Like there’s now an option `AutoCopy` that can be set for any cloud object—and that means that every time the object is accessed, one should get a fresh copy of it. This is very useful if, for example, you want to have a notebook that lots of people can separately modify. (“Explore these ideas; here’s a notebook to start from…”, etc.)

`CloudDeploy[APIFunction[...]]` makes it extremely easy to deploy web APIs. In Version 11.1 there are some options to automate aspects of how those APIs behave. For example, there’s `AllowedCloudExtraParameters`, which lets you say that APIs can have parameters like `"_timeout"` or `"_geolocation"` automated. There’s also `AllowedCloudParameterExtensions` (no, it’s not the longest name in the system; that honor currently goes to `MultivariateHypergeometricDistribution`). What `AllowedCloudParameterExtensions` does is to let you say not just ` x=value`, but

Another thing about Version 11.1 is that it’s got various features added to support private instances of the Wolfram Cloud—and our major new Wolfram Enterprise Private Cloud product (with a first version released late last year). For example, in addition to `$WolframID` for the Wolfram Cloud, there’s also `$CloudUserID` that’s generalized to allow authentication on private clouds. And inside the system, there are all sorts of new capabilities associated with “multicloud authentication” and so on. (Yes, it’s a complicated area—but the symbolic character of the Wolfram Language lets one handle it rather beautifully.)

OK, so I’ve summarized some of what’s in 11.1. There’s a lot more I could say. New functions, and new capabilities—each of which is going to be exciting to somebody. But to me it’s actually pretty amazing that I can write this long a post about a .1 release! It’s a great testament to the strength of the R&D pipeline—and to how much can be done with the framework we’ve built in the Wolfram Language over the past 30 years.

We always work on a portfolio of projects—from small ones that get delivered very quickly, to ones that may take a decade or more to mature. Version 11.1 has the results of several multi-year projects (e.g. in machine learning, computational geometry, etc.), and a great many shorter projects. It’s exciting for us to be able to deliver the fruits of our efforts, and I look forward to hearing what people do with Version 11.1—and to seeing successive versions continue to be developed and delivered.

]]>In Mathematica 10, we introduced support for anatomical structures in `EntityValue`, which included, among many other things, a “Graphics3D” property that returns a 3D model of the anatomical structure in question. We also styled the models and aligned them with the concepts in the Unified Medical Language System (UMLS).

The output is a standard `Graphics3D` expression, but it contains metadata in the form of an `Annotation` that allows for additional exploration.

This means each model knows what lower-level structures it’s made of.

I should note that the models being used are not just eye candy. If that were the intent, we might explore low polygon count models and use textures for a more realistic appearance. But these models are not just good for looking at—you can also use them for computation. For meaningful results, you need accurate models, which may be large, so you may need to be patient when downloading and/or rendering them. Keep in mind that some entities, like the brain, have lots of internal structures. So the model may be larger than you expect, although you may not see this internal structure from the outside.

One example of using these models for computation would be calculating the eigenfrequencies of an air-filled transverse colon (let the jokes fly). Finite element mesh (FEM) calculations are common in medical research today. By retrieving the mesh from `AnatomyData`, we can perform computations on the model.

Now we can obtain the resonant frequencies of the transverse colon.

You can use `Sound` to listen to the resonant frequencies of the transverse colon.

Play Audio

We can find the surface area of the model by directly operating on the `MeshRegion`. Units are in square millimeters.

To compute the volume, we need to convert the `MeshRegion` into a `BoundaryMeshRegion` first. Units are in cubic millimeters.

You can even compute the distance between the transverse colon and the region centroid of the large intestine. Units are in millimeters.

Lower-resolution models will give lower-quality results.

To make it easy to render anatomical structures, we introduced `AnatomyPlot3D`.

`AnatomyPlot3D` allows directives to modify its “primitives,” similar in syntax to `Graphics3D`.

The output of `AnatomyPlot3D` doesn’t contain the original `Entity` objects. They get resolved at evaluation time to 3D graphics primitives, and the normal rules of the graphics language apply to them. The output of `AnatomyPlot3D` is a `Graphics3D` object.

Because `AnatomyPlot3D` can be thought of as an extension to the `Graphics3D` language, you can mix anatomical structures with normal `Graphics3D` primitives.

In `AnatomyPlot3D`, the `Graphics3D` language has been extended at multiple levels to make use of anatomical structures. Within `AnatomyPlot3D`, anatomical entities work just like graphics primitives do in `Graphics3D`. But they can also be used in place of coordinates in `Graphics3D` primitives like `Point` and `Line`. In that context, the entity represents the region centroid of the structure. This allows you, for example, to draw a line from one entity to another.

This concept can be applied to annotate a 3D model using arrows and labels.

You can refer to the subparts of structures and apply styles to them using `AnatomyForm`. It applies only to anatomical structures (not `Graphics3D` primitives) and supports a couple of different forms. The following example behaves similar to a standalone directive, except that it applies only to the anatomical structure, not the `Cuboid`.

A more useful form can be used to style subparts.

`AnatomyForm` works by allowing you to associate specified directives with specified entities that may or may not exist in the structure you are visualizing. Any `Directive` supported by Graphics3D is supported, including `Lighting`, `Opacity`, `EdgeForm`, `FaceForm`, `ClipPlanes` and any combination thereof. In addition to supporting styles for specific entities, `AnatomyForm` also supports a default case via the use of an underscore. The following example shows the left humerus in red and everything else transparent and backlit, giving an X-ray-like appearance.

`PlotRange` can make use of entities to constrain what would otherwise include all of the referenced entities. The following example includes several bones of the left lower limb, but the `PlotRange` is centered on the left patella and padded out from there by a fixed amount.

`SkinStyle` is a convenient way to include any enclosing skin that can be found around the specified entities.

The default styling can be overridden.

You can use `ClipPlanes` to peel away layers of skin.

Use multiple clip planes to peel away successive anatomical layers.

Apply geometric transformations to anatomical structures to rotate them. The following example includes many bones in the skull, but applies a rotation to just the elements of the lower jaw around the temporomandibular joint.

A mix of styles can be useful for highlighting different tissue types in the head.

A similar approach can be used in the torso for different organs.

Here is an advanced example showing the use of `ClipPlanes` to remove muscles below a specific cutting plane.

Inner structures can be differentiated using styles, in this case within the brain.

Here are links to some animations rendered using `AnatomyPlot3D`:

Scaling Transform Applied to the Bones of the Skull

As time goes on, we will continue to add additional models and tools allowing you to explore human anatomy more deeply.

To download this post as a CDF, click here. New to CDF? Get your copy for free with this one-time download.

]]>Until now, it has been difficult for the average engineer to perform simple vibration analysis. The initial cost for simple equipment, including software, may be several thousand dollars—and it is not unusual for advanced equipment and software to cost ten times as much. Normally, a vibration specialist starts an investigation with a hammer impact test. An accelerometer is mounted on a structure, and a special impact hammer is used to excite the structure at several locations in the simplest and most common form of hammer impact testing. The accelerometer and hammer-force signals are recorded. Modal analysis is then used to get a preliminary understanding of the behavior of the system. The minimum equipment requirements for such a test are an accelerometer, an impact hammer, amplifiers, a signal recorder and analysis software.

I’ve figured out how to use the Wolfram Language on my smartphone to sample and analyze machine vibration and noise,Â and to perform surprisingly good vibration analysis. I’ll show you how, and give you some simple Wolfram Language code to get you started.

Throughout the history of the development of machines, vibration and sound measurements have been important issues. There are two reasons for this:

- Vibrations are a source of noise, can decrease operating performance and can also cause workplace injuries such as “vibration white fingers,” also known as hand-arm vibration syndrome (HAVS), resulting from continuous use of handheld machinery vibrating at certain key frequencies.
- Vibrations can indicate wear or defects of the bearings and gears, and so analysis of vibrations is a useful and commonly used tool for fault detection.

The many applications of vibration analysis have led to a huge number engineers studying this subject in universities all over the world. The research area of “machine vibrations” has its own conferences and publications. Companies specialize in developing different kinds of equipment and services. Most large machine-building industries have departments specializing in vibrations.

So here we go: recording the sound of a vibrating machine with an iPhone is simple. I used the iPhone’s built-in digital voice recorder, Voice Memo. The recording can be converted to an MP3 file just by saving it in the MP3 format in iTunes. The default Apple M4A format cannot be used directly in the Wolfram Language. If iTunes is not available, there are a lot of free converters on the internet that will change your M4A files to MP3 files.

Play Audio

I’ll use an industrial gearbox as an example. The example itself is not that important, but it does suggest possible areas where the method can be used. Some data and dimensions have been modified from the original application.

A gearbox is making a lot of noise. What is the problem?

In the figure below, a motor drives the input shaft. The shaft speed is reduced by the gearbox. The power is used by the output shaft. Typically, the motor is a diesel or electrical engine; in this example, it is a diesel engine. The number of teeth are z1 = 23, z2 = 65, z3 = 27 and z4 = 43, respectively. The largest wheels are about one meter in diameter.

We ran the engine at 1200 rpm, recording five seconds of sound with my iPhone. Converted to MP3, the sound file was named “measurement.mp3”. Then all I needed to do was import it into the Wolfram Language to plot the frequency spectrum.

The excitation frequency in Hertz of the gear contact on the input shaft is z1*rpm/60, and

(z1/z2)*z3 *rpm/60 on the output shaft. Marking the histogram for the input and output shafts’ gear mesh excitation frequencies—red and green, respectively—makes it clear that these frequencies are correlated with the spectrogram.

Let’s make the spectrogram interactive: often we don’t want to use the whole sound file, so we add an option to select a start and end time within the file. Let’s also make it possible to change the rpm.

The analysis toolkit is ready. The options `PlotRange`, `MaxValue` and `Manipulate` in the plot above are set manually. Of course, this can be developed further. But we stop here to keep it simple.

So what happened with the real application investigation? Well, the same analysis as above was performed over the whole rpm region. The maxima of the peaks at each rpm are plotted below.

The input shaft’s highest value is 747.7 rpm, and the output shaft’s is 1,800 rpm. Both become excited at about 287 Hz, the gearbox fundamental resonance frequency. Note that

747.7/60*23 = 286.6 Hz and 1800*23/65*27/60 = 286.6 Hz

We concluded that the gear mesh was not optimized for smooth running and the gearbox had a bad resonance frequency. We opened the gearbox and were able to confirm wear on the teeth, which suggested possibilities for improving the contact pattern. We improved contact by selecting an optimum helical angle, as well as tip relief and correct crowning. Tip reliefÂ is a surface modification of a tooth profile; a small amount of material is removed near the tip of the gear tooth. Crowning is a surface modification in the lengthwise direction to prevent contact at the teeth ends, where a small amount of material is removed near the end of the gear tooth.

I have used this method, utilizing my smartphone and the Wolfram Language, several times for real-world and often complex investigations and applications. Often, measurement specialists have already gotten involved before I arrive. But they may have missed the basics because they are using comprehensive measurement programs.

The method I describe here may sometimes yield a similar—or even better—understanding of the problem in just a few minutes at no cost. Well worth trying.

]]>

I will touch on two aspects of her scientific work that were mentioned in the film: orbit calculations and reentry calculations. For the orbit calculation, I will first exactly follow what Johnson did and then compare with a more modern, direct approach utilizing an array of tools made available with the Wolfram Language. Where the movie mentions the solving of differential equations using Euler’s method, I will compare this method with more modern ones in an important problem of rocketry: computing a reentry trajectory from the rocket equation and drag terms (derived using atmospheric model data obtained directly from within the Wolfram Language).

The movie doesn’t focus much on the math details of the types of problems Johnson and her team dealt with, but for the purposes of this blog, I hope to provide at least a flavor of the approaches one might have used in Johnson’s day compared to the present.

One of the earliest papers that Johnson coauthored, “Determination of Azimuth Angle at Burnout for Placing a Satellite over a Selected Earth Position,” deals with the problem of making sure that a satellite can be placed over a specific Earth location after a specified number of orbits, given a certain starting position (e.g. Cape Canaveral, Florida) and orbital trajectory. The approach that Johnson’s team used was to determine the azimuthal angle (the angle formed by the spacecraft’s velocity vector at the time of engine shutoff with a fixed reference direction, say north) to fire the rocket in, based on other orbital parameters. This is an important step in making sure that an astronaut is in the correct location for reentry to Earth.

In the paper, Johnson defines a number of constants and input parameters needed to solve the problem at hand. One detail to explain is the term “burnout,” which refers to the shutoff of the rocket engine. After burnout, orbital parameters are essentially “frozen,” and the spacecraft moves solely under the Earth’s gravity (as determined, of course, through Newton’s laws). In this section, I follow the paper’s unit conventions as closely as possible.

For convenience, some functions are defined to deal with angles in degrees instead of radians. This allows for smoothly handling time in angle calculations:

Johnson goes on to describe several other derived parameters, though it’s interesting to note that she sometimes adopted values for these rather than using the values returned by her formulas. Her adopted values were often close to the values obtained by the formulas. For simplicity, the values from the formulas are used here.

Semilatus rectum of the orbit ellipse:

Angle in orbit plane between perigee and burnout point:

Orbit eccentricity:

Orbit period:

Eccentric anomaly:

To describe the next parameter, it’s easiest to quote the original paper: “The requirement that a satellite with burnout position *φ*1, *λ*1 pass over a selected position *φ*2, *λ*2 after the completion of *n* orbits is equivalent to the requirement that, during the first orbit, the satellite pass over an equivalent position with latitude *φ*2 the same as that of the selected position but with longitude *λ*2e displaced eastward from *λ*2 by an amount sufficient to compensate for the rotation of the Earth during the *n* complete orbits, that is, by the polar hour angle *n ω _{E} T*. The longitude of this equivalent position is thus given by the relation”:

Time from perigee for angle *θ*:

Part of the final solution is to determine values for intermediate parameters *δλ*_{1-2e} and *θ*_{2e}. This can be done in a couple of ways. First, I can use `ContourPlot` to obtain a graphical solution via equations 19 and 20 from the paper:

`FindRoot` can be used to find the solutions numerically:

Of course, Johnson didn’t have access to `ContourPlot` or `FindRoot`, so her paper describes an iterative technique. I translated the technique described in the paper into the Wolfram Language, and also solved for a number of other parameters via her iterative method. Because the base computations are for a spherical Earth, corrections for oblateness are included in her method:

Graphing the value of *θ*2e for the various iterations shows a quick convergence:

I can convert the method in a `FindRoot` command as follows (this takes the oblateness effects into account in a fully self-consistent manner and calculates values for all nine variables involved in the equations):

Interestingly, even the iterative root-finding steps of this more complicated system converge quite quickly:

With the orbital parameters determined, it is desirable to visualize the solution. First, some critical parameters from the previous solutions need to be extracted:

Next, the latitude and longitude of the satellite as a function of azimuth angle need to be derived:

*φ*s and *λ*s are the latitudes and longitudes as a function of *θ*s:

The satellite ground track can be constructed by creating a table of points:

Johnson’s paper presents a sketch of the orbital solution including markers showing the burnout, selected and equivalent positions. It’s easy to reproduce a similar plain diagram here:

For comparison, here is her original diagram:

A more visually useful version can be constructed using `GeoGraphics`, taking care to convert the geocentric coordinates into geodetic coordinates:

Today, virtually every one of us has, within immediate reach, access to computational resources far more powerful than those available to the entirety of NASA in the 1960s. Now, using only a desktop computer and the Wolfram Language, you can easily find direct numerical solutions to problems of orbital mechanics such as those posed to Katherine Johnson and her team. While perhaps less taxing of our ingenuity than older methods, the results one can get from these explorations are no less interesting or useful.

To solve for the azimuthal angle *ψ* using more modern methods, let’s set up parameters for a simple circular orbit beginning after burnout over Florida, assuming a spherically symmetric Earth (I’ll not bother trying to match the orbit of the Johnson paper precisely, and I’ll redefine certain quantities from above using the modern SI system of units). Starting from the same low-Earth orbit altitude used by Johnson, and using a little spherical trigonometry, it is straightforward to derive the initial conditions for our orbit:

The relevant physical parameters can be obtained directly from within the Wolfram Language:

Next, I obtain a differential equation for the motion of our spacecraft, given the gravitational field of the Earth. There are several ways you can model the gravitational potential near the Earth. Assuming a spherically symmetric planet and utilizing a Cartesian coordinate system throughout, the potential is merely:

Alternatively, you can use a more realistic model of Earth’s gravity, where the planet’s shape is taken to be an oblate ellipsoid of revolution. The exact form of the potential from such an ellipsoid (assuming constant mass-density over ellipsoidal shells), though complicated (containing multiple elliptic integrals), is available through `EntityValue`:

For a general homogeneous triaxial ellipsoid, the potential contains piecewise functions:

Here, *κ* is the largest root of *x*^{2}/(*a*^{2}+*κ*)+*y*^{2}/(*b*^{2}+*κ*)+*z*^{2}/(*c*^{2}+*κ*)=1. In the case of an oblate ellipsoid, the previous formula can be simplified to contain only elementary functions…

… where *κ*=((2 *z*^{2} (*a*^{2}-*c*^{2}+*x*^{2}+*y*^{2})+(-*a*^{2}+*c*^{2}+*x*^{2}+*y*^{2})^{2}+*z*^{4})^{1/2}-*a*^{2}-*c*^{2}+*x^{2}+y^{2}+z^{2})*/2.

A simpler form that is widely used in the geographic and space science community, and that I will use here, is given by the so-called International Gravity Formula (IGF). The IGF takes into account differences from a spherically symmetric potential up to second order in spherical harmonics, and gives numerically indistinguishable results from the exact potential referenced previously. In terms of four measured geodetic parameters, the IGF potential can be defined as follows:

I could easily use even better values for the gravitational force through `GeogravityModelData`. For the starting position, the IGF potential deviates only 0.06% from a high-order approximation:

With these functional forms for the potential, finding the orbital path amounts to taking a gradient of the potential to get the gravitational field vector and then applying Newton’s third law. Doing so, I obtain the orbital equations of motion for the two gravity models:

I am now ready to use the power of `NDSolve` to compute orbital trajectories. Before doing this, however, it will be nice to display the orbital path as a curve in three-dimensional space. To give these curves context, I will plot them over a texture map of the Earth’s surface, projected onto a sphere. Here I construct the desired graphics objects:

While the orbital path computed in an inertial frame forms a periodic closed curve, when you account for the rotation of the Earth, it will cause the spacecraft to pass over different points on the Earth’s surface during each subsequent revolution. I can visualize this effect by adding an additional rotation term to the solutions I obtain from `NDSolve`. Taking the number of orbital periods to be three (similar to John Glenn’s flight) for visualization purposes, I construct the following `Manipulate` to see how the orbital path is affected by the azimuthal launch angle *ψ*, similar to the study in Johnson’s paper. I’ll plot both a path assuming a spherical Earth (in white) and another path using the IGF (in green) to get a sense of the size of the oblateness effect (note that the divergence of the two paths increases with each orbit):

In the notebook attached to this blog, you can see this `Manipulate` in action, and note the speed at which each new solution is obtained. You would hope that Katherine Johnson and her colleagues at NASA would be impressed!

Now, varying the angle *ψ* at burnout time, it is straightforward to calculate the position of the spacecraft after, say, three revolutions:

The movie also mentions Euler’s method in connection with the reentry phase. After the initial problem of finding the azimuthal angle has been solved, as done in the previous sections, it’s time to come back to Earth. Rockets are fired to slow down the orbiting body, and a complex set of events happens as the craft transitions from the vacuum of space to an atmospheric environment. Changing atmospheric density, rapid deceleration and frictional heating all become important factors that must be taken into account in order to safely return the astronaut to Earth. Height, speed and acceleration as a function of time are all problems that need to be solved. This set of problems can be solved with Euler’s method, as done by Katherine Johnson, or by using the differential equation-solving functionality in the Wolfram Language.

For simple differential equations, one can get a detailed step-by-step solution with a specified quadrature method. An equivalent of Newton’s famous *F* = *m a* for a time-dependent mass *m*(*t*) is the so-called ideal rocket equation (in one dimension)…

… where *m*(*t*) is the rocket mass, *v*_{e} the engine exhaust velocity and *m ^{‘}_{p}*(

With initial and final conditions for the mass, I get the celebrated rocket equation (Tsiolkovsky 1903):

The details of solving this equation with concrete parameter values and e.g. with the classical Euler method I can get from Wolfram|Alpha. Here are those details together with a detailed comparison with the exact solution, as well as with other numerical integration methods:

Following the movie plot, I will now implement a minimalistic ODE model of the reentry process. I start by defining parameters that mimic Glenn’s flight:

I assume that the braking process uses 1% of the thrust of the stage-one engine and runs, say, for 60 seconds. The equation of motion is:

Here, **F**_{grav} is the gravitational force, **F**_{exhaust}(*t*) the explicitly time-dependent engine force and **F**_{friction}(* x*(

For the height-dependent air density, I can conveniently use the `StandardAtmosphereData` function. I also account for a height-dependent area because of the parachute that opened about 8.5 km above ground:

This gives the following set of coupled nonlinear differential equations to be solved. The last `WhenEvent``[...]` specifies to end the integration when the capsule reaches the surface of the Earth. I use vector-valued position and velocity variables X and V:

With these definitions for the weight, exhaust and air friction force terms…

… total force can be found via:

In this simple model, I neglected the Earth’s rotation, intrinsic rotations of the capsule, active flight angle changes, supersonic effects on the friction force and more. The explicit form of the differential equations in coordinate components is the following. The equations that Katherine Johnson solved would have been quite similar to these:

Supplemented by the initial position and velocity, it is straightforward to solve this system of equations numerically. Today, this is just a simple call to `NDSolve`. I don’t have to worry about the method to use, step size control, error control and more because the Wolfram Language automatically chooses values that guarantee meaningful results:

Here is a plot of the height, speed and acceleration as a function of time:

Plotting as a function of height instead of time shows that the exponential increase of air density is responsible for the high deceleration. This is not due to the parachute, which happens at a relatively low altitude. The peak deceleration happens at a very high altitude as the capsule goes from a vacuum to an atmospheric environment very quickly:

And here is a plot of the vertical and tangential speed of the capsule in the reentry process:

Now I repeat the numerical solution with a fixed-step Euler method:

Qualitatively, the solution looks the same as the previous one:

For the used step size of the time integration, the accumulated error is on the order of a few percent. Smaller step sizes would reduce the error (see the previous Wolfram|Alpha output):

Note that the landing time predicted by the Euler method deviates only 0.11% from the previous time. (For comparison, if I were to solve the equation with two modern methods, say `"BDF"` vs. `"Adams"`, the error would be smaller by a few orders of magnitude.)

Now, the reentry process generates a lot of heat. This is where the heat shield is needed. At which height is the most heat per area *q* generated? Without a detailed derivation, I can, from purely dimensional grounds, conjecture :

Many more interesting things could be calculated (Hicks 2009), but just like the movie had to fit everything into two hours and seven minutes, I will now end my blog for the sake of time. I hope I can be pardoned for the statement that, with the Wolfram Language, the sky’s the limit.

To download this post as a Computable Document Format (CDF) file, click here. New to CDF? Get your copy for free with this one-time download.

]]>In my recent Wolfram Community post, “How many animals can one find in a random image?,” I looked into the pareidolia phenomenon from the viewpoints of pixel clusters in random (2D) black-and-white images. Here are some of the shapes I found, extracted, rotated, smoothed and colored from the connected black pixel clusters of a single 800×800 image of randomly chosen, uncorrelated black-and-white pixels.

For an animation of such shapes arising, changing and disappearing in a random gray-level image with slowly time-dependent pixel values, see here. By looking carefully at a selected region of the image, at the slowly changing, appearing and disappearing shapes, one frequently can “see” animals and faces.

The human mind quickly sees faces, animals, animal heads and ghosts in these shapes. Human evolution has optimized our vision system to recognize predators and identify food. Our recognition of an eye (or a pair of eyes) in the above shapes is striking. For the neuropsychological basis of seeing faces in a variety of situations where actual faces are absent, see Martinez-Conde2016.

A natural question: is this feature of our vision specific to 2D silhouette shapes, or does the same thing happen for 3D shapes? So here, I will look at random shapes in 3D images and the 2D projections of these 3D shapes. Various of the region-related functions that were added in the last versions of the Wolfram Language make this task possible, straightforward and fun.

I should explain the word Arp-imals from the title. With the term “Arp-imals” I refer to objects in the style of the sculptures by Jean Arp, meaning smooth, round, randomly curved biomorphic forms. Here are some examples.

Forms such as these hide frequently in 3D images made from random black-and-white voxels. Here is a quick preview of shapes we will extract from random images.

We will also encounter what I call Moore-iens, in the sense of the sculptures by the slightly later artist Henry Moore.

With some imagination, one can also see forms of possible aliens in some of the following 2D shapes. (See Domagal-Goldman2016 for a discussion of possible features of alien life forms.)

As in the 2D case, we start with a random image: this time, a 3D image of voxels of values 0 and 1. For reproducibility, we will seed the random number generator. The Arp-imals are so common that virtually any seed produces them. And we start with a relatively small image. Larger images will contain many more Arp-imals.

Hard to believe at first, but the blueprints of the above-shown 3D shapes are in the last 3D cube. In the following, we will extract them and make them more visible.

As in the 2D case, we again use `ImageMesh` to extract connected regions of white cells. The regions still look like a random set of connected polyhedra. After smoothing the boundaries, nicer shapes will arise.

Here are the regions, separated into non-touching ones, using the function `ConnectedMeshComponents`. The function `makeShapes3D` combines the image creation, the finding of connected voxel regions, and the region separation.

For demonstration purposes, in the next example, we use a relatively low density of white voxels to avoid the buildup of a single large connected region that spans the whole cube.

Here are the found regions individually colored in their original positions in the 3D image.

To smooth the outer boundaries, thereby making the shapes more animal-, Arp-imal- and alien-like, the function `smooth3D` (defined in the accompanying notebook) is a quick-and-dirty implementation of the Loop subdivision algorithm. (As the 3D shapes might have a higher genus, we cannot use `BSplineSurface` directly, which would have been the direct equivalent to the 2D case.) Here are successive smoothings of the third of the above-extracted regions.

Using the region plot theme `"SmoothShading"` of the function `BoundaryMeshRegion`, we can add normals to get the feeling of a genuinely smooth boundary.

And for less than $320 one can obtain this Arp-inspired piece in brass. A perfect, unique, stunning post-Valentine’s gift. For hundreds of alternative shapes to print, see below. We use `ShellRegion` to reduce the price and save some internal material by building a hollow region.

Here is the smoothing procedure shown for another of the above regions.

And for three more.

Many 3D shapes can now be extracted from random and nonrandom 3D images. The next input calculates the region corresponding to lattice points with coprime coordinates.

In the above example, we start with a coarse 3D region, which feels polyhedral due to the obvious triangular boundary faces. It is only after the smoothing procedure that we obtain “interesting-looking” 3D shapes. The details of the applied smoothing procedure do not matter, as long as sharp edges and corners are softened.

Human perception is optimized for smooth shapes, and most plants and animals have smooth boundaries. This is why we don’t see anything interesting in the collection of regions returned from `ImageMesh` applied to a 3D image. This is quite similar to the 2D case. In the following visualization of the 2D case, we start with a set of randomly selected points. Then we connect these points through a curve. Filling the curve yields a deformed checkerboard-like pattern that does not remind us of a living being. Rasterizing the filled curve in a coarse-grained manner still does not remind us of organic shapes. The connected region, and especially the smoothed region, do remind most humans of living beings.

The following `Manipulate` (available in the notebook) allows us to explore the steps and parameters involved in an interactive session.

And here is a corresponding 3D example.

In her reply to my community post, Marina Shchitova showed some examples of faces and animals in shadows of hands and fingers. Some classic examples from the Cassel1896 book are shown here.

So, what do projections/shadows of the above two 3D shapes look like? (For a good overview of the use of shadows in art at the time and place of the young Arp, see Forgione1999.)

The projections of these 3D shapes are exactly the types of shapes I encountered in the connected smoothed components of 2D images. The function `projectTo2D` takes a 3D graphic complex and projects it into a thin slice parallel to the three coordinate planes. The result is still a `Graphics3D` object.

These are the 2×3 projections of the above two 2D shapes. Most people recognize animal shapes in the projections.

We get exactly these projections if we just look at the 3D shape from a larger distance with a viewpoint and direction parallel to the coordinate axes.

For comparison, here are three views of the first object from very far away, effectively showing the projections.

By rotating the 3D shapes, we can generate a large variety of different shapes in the 2D projections. The following `Manipulate` allows us to explore the space of projections’ shapes interactively. Because we need the actual rotated coordinates, we define a function `rotate`, rather than using the built-in function `Rotate`.

Here is an array of 16 projections into the x-z plane for random orientations of the 3D shape.

The initial 3D image does not have to be completely random. In the next example, we randomly place circles in 3D and color a voxel white if the circle intersects the voxel. As a result, the 3D shapes corresponding to the connected voxel regions have a more network-like shape.

2D projection shapes of 3D animals typically have no symmetry. Even if an animal has a symmetry, the visible shape from a given viewpoint and a given animal posture does not have a symmetry. But most animals have a bilateral symmetry. I will now use random images that have a bilateral symmetry. As a result, many of the resulting shapes will also have a bilateral symmetry. Not all of the shapes, because some regions do not intersect the symmetry plane. Bilateral symmetry is important for the classic Rorschach inkblot test: “The mid-line appears to attract the patient’s attention with a sort of magical power,” noted Rorschach (Schott2013). The function `makeSymmetricShapes3D` will generate regions with bilateral symmetry.

Here are some examples.

And here are smoothed and colored versions of these regions. The viewpoint is selected in such a way as to make the bilateral symmetry most obvious.

To get a better feeling for the connection between the pixel values of the 3D image and the resulting smoothed shape, the next `Manipulate` allows us to specify each pixel value for a small-sized 3D image. The grids/matrices of checkboxes represent the voxel values of one-half of a 3D image with bilateral symmetry.

Randomly and independently selecting the voxel value of a 3D image makes it improbable that very large connected components without many holes form. Using instead random functions and deriving voxel values from these random continuous functions yields different-looking types of 3D shapes that have a larger uniformity over the voxel range. Effectively, the voxel values are no longer totally uncorrelated.

Here are some examples of the resulting regions, as well as their smoothed versions.

Our notebook contains in the initialization section more than 400 selected regions of “interesting” shapes classified into five types (mostly arbitrarily, but based on human feedback).

Let’s look at some examples of these regions. Here is a list of some selected ones. Many of these shapes found in random 3D images could be candidates for Generation 8 PokÃ©mon or even some new creatures, tentatively dubbed Mathtubbies.

Many of the shapes are reminiscent of animals, even if the number of legs and heads is not always the expected number.

To see all of the 400+ shapes from the initialization cells, one could carry out the following.

`Do[Print[Framed[Style[t, Bold, Gray], FrameStyle -> Gray]];
Do[Print[Rasterize @ makeRegion @ r], {r, types[t]}], {t,Keys[types]}]`

The shapes in the list above were manually selected. One could now go ahead and partially automate the finding of interesting animal-looking shapes and “natural” orientations using machine learning techniques. In the simplest case, we could just use `ImageIdentify`.

This seems to be a stegosaurus-poodle crossbreed. But we will not pursue this direction here and now, but rather return to the 2D projections. (For using software to find faces in architecture and general equipment, see Hong2014.)

Before returning to the 2D projections, we will play for a moment with the 3D shapes generated and modify them for a different visual appearance.

For instance, we could tetrahedralize the regions and fill the tetrahedra with spheres.

Or with smaller tetrahedra.

Or add some spikes.

Or fill the shapes with cubes.

Or thicken or thin the shapes.

Or thicken and add thin bands.

Or just add a few stripes as camouflage.

Or model the inside through a wireframe of cylinders.

Or build a stick figure.

Or fill the surface with a tube.

Or a Kelvin inversion.

If we look at the 2D projections of some of these 3D shapes, we can see again (with some imagination) a fair number of faces, witches, kobolds, birds and other animals. Here are some selected examples. We show the 3D shape in the original orientation, a randomly oriented version of the 3D shape, and the three coordinate-plane projections of the randomly rotated 3D shape.

Unsurprisingly, some are recognizable 3D shapes, like these projections that look like bird heads.

Others are much more surprising, like the two heads in the projections of the two-legged-two-finned frog-dolphin.

Different orientations of the 3D shape can yield quite different projections.

For the reader’s amusement, here are some more projections.

Now that we have looked at 2D projections of 3D shapes, the next natural step would be to look at 3D projections of 4D shapes. And while there is currently no built-in function `Image4D`, it is not too difficult to implement for finding the connected components of white 4D voxels. We implement this through the graph theory function `ConnectedComponents` and consider two 4D voxels as being connected by an edge if they share a common 3D cube face. As an example, we use a 10*10*10*10 voxel 4D image. `makeVoxels4D` makes the 4D image data and `whitePositionQ` marks the position of the white voxels for quick lookup.

The 4D image contains quite a few connected components.

Here are the four canonical projections of the 4D complex.

We package the finding of the connected components into a function `getConnected4DVoxels`.

We also define a function `rotationMatrix4D` for conveniently carrying rotations in the six 2D planes of the 4D space.

Once we have the 3D projections, we can again use the above function to smooth the corresponding 3D shapes.

In the absence of Tralfamadorian vision, we can visualize a 4D connected voxel complex, rotate this complex in 4D, then project into 3D, smooth the shapes and then project into 2D. For a single 4D shape, this yields a large variety of possible 2D projections. The function `projectionGrid3DAnd2D` projects the four 3D projections canonically into 2D. This means we get 12 projections. Depending on the shape of the body, some might be identical.

We show the 3D shape in a separate graphic so as not to cover up the projections. Again, many of the 2D projections, and also some of the 3D projections, remind us of animal shapes.

The following `Manipulate` allows us to rotate the 4D shape. The human mind sees many animal shapes and faces.

Here is another example, with some more scary animal heads.

We could now go to 5D images, but this will very probably bring no new insights. To summarize some of the findings: After rotation and smoothing, a few percent of the connected regions of black voxels in random 3D images have an animal-like shape, or an artistic rendering of an animal-like shape. A large fraction (~10%) of the projections of these 3D shapes into 2D pronouncedly show the pareidolia phenomenon, in the sense that we believe we can recognize animals and faces in these projections. 4D images, due to the voxel count that increases exponentially with dimension, yield an even larger number of possible animal and face shapes.

To download this post as a CDF, click here. New to CDF? Get your copy for free with this one-time download.

]]>If aliens actually visited Earth, world leaders would bring in a scientist to develop a process for understanding their language. So when director Denis Villeneuve began working on the science fiction movie *Arrival*, he and his team turned to real-life computer scientists Stephen and Christopher Wolfram to bring authentic science to the big screen. Christopher specifically was tasked with analyzing and writing code for a fictional nonlinear visual language. On January 31, he demonstrated the development process he went through in a livecoding event broadcast on LiveEdu.tv.

Scientists and general viewers alike were interested in the story of the Wolframs’ behind-the-scenes contributions to the movie, from Space.com to OuterPlaces.com and others. SlashFilm.com went further, pointing readers to the Science vs. Cinema *Arrival* episode featuring interviews with the Wolframs, other scientists, Jeremy Renner, Amy Adams and Villeneuve. *Wired* magazine also interviewed Christopher Wolfram on the subject of the Wolfram Language code he created to lend validity to the computer screens shown in the film. Watch Christopher Wolfram walk you through his development process.

Wolfram Research has a track record of contributing to film and TV. From the puzzles in the television show *NUMB3RS* to the wormhole experience in *Interstellar*, Wolfram technology and expertise have enriched some beloved popular art and entertainment. With *Arrival*, however, Stephen and Christopher consulted more extensively on what Stephen calls “the science texture” of the film.

Science and technology shape our world now more than ever. Science fiction movies are finding a wider audience, and we find these stories are crafted into films by some of the most skilled filmmakers around. If filmmakers such as Villeneuve continue to recognize the importance of getting the science right, science fiction will continue to live up to Arthur C. Clarke’s claim that “science fiction is escape into reality…. [It] concern[s] itself with real issues: the origin of man; our future.”

For more information on the Wolframs’ involvement in *Arrival*, read Stephen Wolfram’s blog post, “Quick, How Might the Alien Spacecraft Work?”

**Jeremy Sykes:** To celebrate the release of *Hands-on Start to Wolfram Mathematica and Programming with the Wolfram Language* (*HOS2*), now in its second edition, I sat down with the authors. Working with Cliff, Kelvin and Michael as the book’s production manager has been an easy and engaging process. I’m thrilled to see the second edition in print, particularly now in its smaller, more conveniently sized format.

**Q:** Let’s start with Version 11. What’s new for Version 11 in HOS2 that you’d like to talk about?

**Michael:** As with any major Mathematica release, there are more new things to talk about than can be discussed in the time we have available. But I’m getting a lot of use out of the new graphics capabilities—the new labeling system, the ability to have callouts on a graph, word clouds, enhanced geographical visualizations and even things you don’t think about, such as the removal of discontinuities when plotting things like tan(*x*). The second edition of the book also includes updates for working with data, like the ability to process audio information, working with linguistic data, new features for date computation and preparing output for 3D printing. (Also new is an index, to make it easier to find specific topics.)

**Q:** Getting back to basics, I know that HOS existed in some form long before the book came out. Maybe you could fill out some of the history for us.

**Cliff:** Twenty years ago, I started at Wolfram on the MathMobile, traveling from city to city, visiting organizations (mostly universities—some companies and government labs as well). The MathMobile was a 30-foot trailer (connected to a truck) with three laptop stations where people would come into the trailer to see Mathematica in action in this mobile computer lab. My job was to walk people through how to get started with Mathematica, sometimes answering technical questions for existing users, and sometimes going through a first overview for non-users. Afterward, I worked in technical support and then in sales, and through these experiences, I had the opportunity to see many types of first-time interactions with Mathematica. Thus, my passion for helping people get started with Mathematica was initiated. Several years ago, I came up with the idea for a free video series showing people how to get started. That was extremely popular. From that, many requests for a book version of the video series came. Then we translated the video series into a book.

**Q:** Tell me a bit about the partnership behind CKM Media and how you came together for the project.

**Cliff:** In the late 1990s, Kelvin and I began working closely together on many Wolfram projects relating to academia. We found a lot of shared ideas and approaches to problems, bringing very different strengths to those projects. I tended to look at things from a liberal-arts-college perspective and that of a math student who had strong math skills but not a lot of programming experience. Kelvin often came at things more from the mindset of an engineer at a research university. We found that these different mindsets helped ensure that more members of academia were well represented in those projects. Michael started at Wolfram in the mid-2000s. The three of us worked closely together after his hire. Michael brought a computer science mindset with a focus on data analytics and programmatic solutions to real-world problems. So while we have been good friends for about fifteen years, we also bring such different skill sets to projects and feel we make for a great collaborative team for this book.

**Q:** What makes HOS a good Mathematica teaching tool?

**Kelvin:** I think it’s a good teaching tool from two perspectives—one, it’s extremely useful for teaching anyone how to get started with Mathematica. We’ve had lots of great feedback from students, teachers, professors and lots of different types of people in the government and commercial sectors. But also, it’s been a great tool for the classroom. Over the years, we’ve learned a lot from the free Hands-on Start video series. The comments and feedback from educators using the videos for their classes helped shape the philosophy of the book. What we wanted was a slow buildup of material that works well for non-users, and specifically for non-users without any coding experience. As the chapters progress, the examples get more intricate and more interesting, using multiple Mathematica functions. At the same time, we wanted the first few chapters to also show a complete sample project in Mathematica. Then, when syntax conventions are covered, they are framed with a discussion about why that convention is useful for a project. The second thing we wanted to do was show the scope of Mathematica and the Wolfram Language.

There are many good books and tutorials for learning Mathematica, but they often focus on one field or class. Our team wanted to provide a good foundation for how to use Mathematica and the Wolfram Language for a broad range of applications. Even Mathematica users who have focused on a select few functions could learn how to use Mathematica in new types of applications or projects. And it’s been fun to see the results so far.

The first edition has been a recommended or required text in classes like chemistry, economics, physics and mathematics, and in classes specific to teaching Mathematica or the Wolfram Language itself.

**Jeremy:** *HOS2* is available from our webstore. It’s also available on Amazon. It’s available in the beautiful, perfect-bound 7×10 paperback copy, and also as a fully updated Kindle version. For those who buy the printed book, we have enrolled the book in Kindle’s MatchBook program, which allows you to buy the EPUB at a reduced cost. We also have plans to release on iTunes. For our international users, we plan to release translated versions of *HOS2* in Japanese, Chinese and other languages.

*Be sure to check out our upcoming series of Hands-on Start to Wolfram Mathematica Training Tutorials. Learn directly from the authors of the book and ask questions during the interactive Q&A. Visit Wolfram Research’s Facebook event page to learn more about upcoming events. *

I used the Wolfram Language to create several visualizations to celebrate his work and gain some new insights into his life. Last June, I wrote a Wolfram Community post about Ali’s career. On what would have been The Greatest’s 75th birthday, I wanted to take a minute to explore the larger context of Ali’s career, from late-career boxing stats to poetry.

First, I created a `PieChart` showing Ali’s record:

Ali was dangerous outside the ring as well as inside it, at least for the white establishment in the US. He converted to Islam and changed his name from Cassius Clay, which he called his “slave name,” to Muhammad Ali. Later he refused military service during the Vietnam War, citing his religious beliefs. For this, he was arrested on charges of evading the draft, and he was pulled out of the ring for four years. All this made Ali an icon of racial pride for African Americans and the counterculture generation during the 1960s Civil Rights Movement.

Perhaps a lesser-known fact about Ali is that he played an important role in the emergence of rap, and he was an influential figure in the world of hip-hop music. He earned two Grammy nominations and he wrote several poems, among which is the shortest poem in the English language:

“Me?

Whee!”

So let’s create a `WordCloud` of his most popular poems. First, I need to import his poems from a database site like Poetry Soup and do some string processing from the HTML file in order to get the poems as plain strings:

Here are the first three poems:

Then I get a list of the important words with `TextWords` and delete the stopwords with `DeleteStopwords`. Next, I style the word cloud with a boxing glove shape:

With just a glimpse, I can see that he mainly wrote about his opponents, himself and boxing.

In my Community post from last June, I showed how to create the following `DateListPlot` that shows his victories over time. Note that his suspension period happened just as his performance was rising steeply:

I imported the other data from his Wikipedia page, which allowed me to visualize where these fights took place with `GeoGraphics` and who his opponents were:

Now as a continuation of that previous post, I would like to further analyze Ali’s opponents. For this, I’m going to take the data from the BoxRec.com site, where one can find a record of all of Ali’s opponents. I’m going to skip the parsing process of the relevant data imported from the HTMLs and will directly use a dataset that I created for this purpose (see the attached file at the end of this post).

First, let’s create a `CommunityGraphPlot` with all of Ali’s opponents. I want the vertexes of the graph to represent the boxers and the edges to indicate if two boxers encountered each other in the ring. Each community here will represent a group of boxers that are more connected to each other than the rest of boxers, and they will each be represented in a different color. For this, I need the list of opponents of each of Ali’s opponents:

In addition, I can indicate the number of bouts fought by each boxer by plotting the diameter of the vertexes proportionally and also indicate the losses that Ali had during his career with red edges using `VertexSize` and `VertexLabels`, respectively (see the complete code in the attached notebook):

We can observe that Moore had the largest number of bouts. But was he better than Ali in terms victories over losses?

One way to compare the boxers is by calculating the following ratio for each one:

I can then use a machine learning function such as `FindClusters` to classify the opponents into different categories, visualized here with a `Histogram`:

Another way to compare the opponents’ records is by plotting a `BubbleChart`:

Under such a classification method, Ali is one of the greatest (as I expected), but Moore is just a “good” boxer, even if he holds the record number of wins. Although this is a nice way to compare boxers, one should be cautious—for example, I noticed that Spinks is classified as a “bad” boxer even though he beat Ali once.

Before concluding the opponents analysis, I will plot Ali’s weight over his career and compare it with the one of his rivals with `DateListPlot`:

As one should expect, Ali gained weight over the course of his career. And he had one really heavy opponent, Buster Mathis, who weighed over 250 pounds at the end of his career.

Finally, I would like to point out a fun fact that I discovered thanks to the amazing amount of knowledge built into the Wolfram Language. After winning his first world heavyweight title in 1964, there was a little boom of babies named Cassius, who are now around 52 years old. There would probably be even more people called Cassius now if he hadn’t changed his name to Muhammad Ali:

The Wolfram Language offers so many possibilities to keep exploring Ali’s life. But I will stop here and encourage you to create your own visualizations and share your ideas on Wolfram Community’s Ali thread.

*Download this post as a Computable Document Format (CDF) file along with the accompanying dataset. (Note that you should save the dataset file in the same folder as the notebook in order to load the data needed for the visualizations.) New to CDF? Get your copy for free here.*

For the past couple of years, I’ve been playing with, collecting and analyzing data from used car auctions in my free time with an automotive journalist named Steve Lang to try and get an idea of what the used car market looks like in terms of long-term vehicle reliability. I figured it was about time that I showed off some of the ways that the Wolfram Language has allowed us to parse through information on over one million vehicles (and counting).

I’ll start off by saying that there isn’t anything terribly elaborate about the process we’re using to collect and analyze the information on these vehicles; it’s mostly a process of reading in reports from our data provider (and cleaning up the data), and then cross-referencing that data with various automotive APIs to get additional information. This data then gets dumped into a database that we use for our analysis, but having all of the tools we need built into the Wolfram Language makes the entire operation something that can be scripted—which greatly streamlines the process. I’ll have to skip over some of the details or this will be a *very* long post, but I’ll try to cover most of the key elements.

The data we get comes in from a third-party provider that manages used car auctions around the country (unfortunately, our licensing agreement doesn’t allow me to share the data right now), but it’s not very computable at first (the data comes in as a text file report once a week):

Fortunately, parsing this sort of log-like data into individual records is easy in the Wolfram Language using basic string patterns:

Then it’s mostly a matter of cleaning up the individual records into something more standardized (I’ll spare you some of the hacky details due to artifacts in the data feed). You’ll end up with something like the following:

From there, we use the handy Edmunds vehicle API to get more information on an individual vehicle using their VIN decoder:

We then insert the records into an HSQL database (conveniently included with Mathematica), resulting in an easy way to search for the records we want:

From there, we can take a quick look at metrics using larger datasets, such as the number of transmission issues for a given set of vehicles for different model years:

Or a histogram of those issues broken down by vehicle mileage:

It also lets us look at industry-wide trends, so we can develop a baseline for what the expected rate of defects for an average vehicle (or vehicle of a certain class) should be:

We can then compare a given vehicle to that model:

We then use that model, as well as other information, to generate a statistical index. We use that index to give vehicles an overall quality rating based on their historical reliability, which ranges from a score of 0 (chronic reliability issues) to 100 (exceptional reliability), with the industry average hovering right around 50:

We also use various gauges to put together informative visualizations of defect rates and the overall quality:

There is a lot more we do to pull all of this together (like the Wolfram Language templating we use to generate the HTML pages and reports), and honestly, there is a whole lot more we could do (my background in statistics is pretty limited, so most of this is pretty rudimentary, and I’m sure others here may already have ideas for improvements in presentation for some of this data). If you’d like to take a look at the site, it’s freely available (Steve has a nice introduction to the site here, and he also writes articles for the page related to practical uses for our findings).

Our original site was called the Long-Term Quality Index, which is still live but showed off my lack of experience in HTML development, so we recently rolled out our newer, WordPress-based venture Dashboard Light, which also includes insights from our auto journalist on his experiences running an independent, used car dealership.

This is essentially a two-man project that Steve and I handle in our (limited) free time, and we’re still getting a handle on presenting the data in a useful way, so if anyone has any suggestions or questions about our methodology, feel free to reach out to us.

Cheers!

*Continue the conversation at Wolfram Community.*