Follow Stephen Wolfram Blog on Feedspot

Continue with Google
Continue with Facebook


The Release Pipeline

Last September we released Version 11.2 of the Wolfram Language and Mathematica—with all sorts of new functionality, including 100+ completely new functions. Version 11.2 was a big release. But today we’ve got a still bigger release: Version 11.3 that, among other things, includes nearly 120 completely new functions.

This June 23rd it’ll be 30 years since we released Version 1.0, and I’m very proud of the fact that we’ve now been able to maintain an accelerating rate of innovation and development for no less than three decades. Critical to this, of course, has been the fact that we use the Wolfram Language to develop the Wolfram Language—and indeed most of the things that we can now add in Version 11.3 are only possible because we’re making use of the huge stack of technology that we’ve been systematically building for more than 30 years.

We’ve always got a large pipeline of R&D underway, and our strategy for .1 versions is to use them to release everything that’s ready at a particular moment in time. Sometimes what’s in a .1 version may not completely fill out a new area, and some of the functions may be tagged as “experimental”. But our goal with .1 versions is to be able to deliver the latest fruits of our R&D efforts on as timely a basis as possible. Integer (.0) versions aim to be more systematic, and to provide full coverage of new areas, rounding out what has been delivered incrementally in .1 versions.

In addition to all the new functionality in 11.3, there’s a new element to our process. Starting a couple of months ago, we began livestreaming internal design review meetings that I held as we brought Version 11.3 to completion. So for those interested in “how the sausage is made”, there are now almost 122 hours of recorded meetings, from which you can find out exactly how some of the things you can now see released in Version 11.3 were originally invented. And in this post, I’m going to be linking to specific recorded livestreams relevant to features I’m discussing.

What’s New?

OK, so what’s new in Version 11.3? Well, a lot of things. And, by the way, Version 11.3 is available today on both desktop (Mac, Windows, Linux) and the Wolfram Cloud. (And yes, it takes extremely nontrivial software engineering, management and quality assurance to achieve simultaneous releases of this kind.)

In general terms, Version 11.3 not only adds some completely new directions, but also extends and strengthens what’s already there. There’s lots of strengthening of core functionality: still more automated machine learning, more robust data import, knowledgebase predictive prefetching, more visualization options, etc. There are all sorts of new conveniences: easier access to external languages, immediate input iconization, direct currying, etc. And we’ve also continued to aggressively push the envelope in all sorts of areas where we’ve had particularly active development in recent years: machine learning, neural nets, audio, asymptotic calculus, external language computation, etc.

Here’s a word cloud of new functions that got added in Version 11.3:


There are so many things to say about 11.3, it’s hard to know where to start. But let’s start with something topical: blockchain. As I’ll be explaining at much greater length in future posts, the Wolfram Language—with its built-in ability to talk about the real world—turns out to be uniquely suited to defining and executing computational smart contracts. The actual Wolfram Language computation for these contracts will (for now) happen off the blockchain, but it’s important for the language to be able to connect to blockchains—and that’s what’s being added in Version 11.3. [Livestreamed design discussion.]

The first thing we can do is just ask about blockchains that are out there in the world. Like here’s the most recent block added to the main Ethereum blockchain:

BlockchainBlockData[-1, BlockchainBase -> "Ethereum"]

Now we can pick up one of the transactions in that block, and start looking at it:

 BlockchainBase -> "Ethereum"]

And we can then start doing data science—or whatever analysis—we want about the structure and content of the blockchain. For the initial release of Version 11.3, we’re supporting Bitcoin and Ethereum, though other public blockchains will be added soon.

But already in Version 11.3, we’re supporting a private (Bitcoin-core) Wolfram Blockchain that’s hosted in our Wolfram Cloud infrastructure. We’ll be periodically publishing hashes from this blockchain out in the world (probably in things like physical newspapers). And it’ll also be possible to run versions of it in private Wolfram Clouds.

It’s extremely easy to write something to the Wolfram Blockchain (and, yes, it charges a small number of Cloud Credits):


The result is a transaction hash, which one can then look up on the blockchain:


Here’s the circle back again from the blockchain:

By the way, the Hash function in the Wolfram Language has been extended in 11.3 to immediately support the kinds of hashes (like “RIPEMD160SHA256”) that are used in cryptocurrency blockchains. And by using Encrypt and related functions, it’s possible to start setting up some fairly sophisticated things on the blockchain—with more coming soon.

System Modeling

Alright, so now let’s talk about something really big that’s new—at least in experimental form—in Version 11.3. One of our long-term goals in the Wolfram Language is to be able to compute about anything in the world. And in Version 11.3 we’re adding a major new class of things that we can compute about: complex engineering (and other) systems. [Livestreamed design discussions 1 and 2.]

Back in 2012 we introduced Wolfram SystemModeler: an industrial-strength system modeling environment that’s been used to model things like jet engines with tens of thousands of components. SystemModeler lets you both run simulations of models, and actually develop models using a sophisticated graphical interface.

What we’re adding (experimentally) in Version 11.3 is the built-in capability for the Wolfram Language to run models from SystemModeler—or in fact basically any model described in the Modelica language.

Let’s start with a simple example. This retrieves a particular model from our built-in repository of models:


If you press the [+] you see more detail:

But the place where it gets really interesting is that you can actually run this model. SystemModelPlot makes a plot of a “standard simulation” of the model:


What actually is the model underneath? Well, it’s a set of equations that describe the dynamics of how the components of the system behave. And for a very simple system like this, these equations are already pretty complicated:


It comes with the territory in modeling real-world systems that there tend to be lots of components, with lots of complicated interactions. SystemModeler is set up to let people design arbitrarily complicated systems graphically, hierarchically connecting together components representing physical or other objects. But the big new thing is that once you have the model, then with Version 11.3 you can immediately work with it in the Wolfram Language.

Every model has lots of properties:

[SystemModel["Modelica.Electrical.Analog.Examples.IdealTriacCircuit"] \

One of these properties gives the variables that characterize the system. And, yes, even in a very simple system like this, there are already lots of those:

[SystemModel["Modelica.Electrical.Analog.Examples.IdealTriacCircuit"] \

Here’s a plot of how one of those variables behaves in the simulation:


A typical thing one wants to do is to investigate how the system behaves when parameters are changed. This simulates the system with one of its parameters changed, then makes a plot:

SystemModelSimulate[[SystemModel["Modelica.Electrical.Analog.Examples.IdealTriacCircuit"]],  {"V.freqHz" -> 2.5}|>]

SystemModelPlot[%, "idealTriac.capacitor.p.i"]

We could go on from here to sample lots of different possible inputs or parameter values, and do things like studying the robustness of the system to changes. Version 11.3 provides a very rich environment for doing all these things as an integrated part of the Wolfram Language.

In 11.3 there are already over 1000 ready-to-run models included—of electrical, mechanical, thermal, hydraulic, biological and other systems. Here’s a slightly more complicated example—the core part of a car:


If you expand the icon, you can mouse over the parts to find out what they are:

This gives a quick summary of the model, showing that it involves 1110 variables:


In addition to complete ready-to-run models, there are also over 6000 components included in 11.3, from which models can be constructed. SystemModeler provides a full graphical environment for assembling these components. But one can also do it purely with Wolfram Language code, using functions like ConnectSystemModelComponents (which essentially defines the graph of how the connectors of different components are connected):

components = {"R" \[Element] 
   "L" \[Element] "Modelica.Electrical.Analog.Basic.Inductor", 
   "AC" \[Element] "Modelica.Electrical.Analog.Sources.SineVoltage", 
   "G" \[Element] "Modelica.Electrical.Analog.Basic.Ground"};

connections = {"G.p" -> "AC.n", "AC.p" -> "L.n", "L.p" -> "R.n", 
   "R.p" -> "AC.n"};

model = ConnectSystemModelComponents[components, connections]

You can also create models directly from their underlying equations, as well as making “black-box models” purely from data or empirical functions (say from machine learning).

It’s taken a long time to build all the system modeling capabilities that we’re introducing in 11.3. And they rely on a lot of sophisticated features of the Wolfram Language—including large-scale symbolic manipulation, the ability to robustly solve systems of differential-algebraic equations, handling of quantities and units, and much more. But now that system modeling is integrated into the Wolfram Language, it opens all sorts of important new opportunities—not only in engineering, but in all fields that benefit from being able to readily simulate multi-component real-world systems.

New in Notebooks

We first introduced notebooks in Version 1.0 back in 1988—so by now we’ve been polishing how they work for no less than 30 years. Version 11.3 introduces a number of new features. A simple one is that closed cell groups now by default have an “opener button”, as well as being openable using their cell brackets:

I find this helpful, because otherwise I sometimes don’t notice closed groups, with extra cells inside. (And, yes, if you don’t like it, you can always switch it off in the stylesheet.)

Another small but useful change is the introduction of “indefinite In/Out labels”. In a notebook that’s connected to an active kernel, successive cells are labeled In[1], Out[1], etc. But if one’s no longer connected to the same kernel (say, because one saved and reopened the notebook), the In/Out numbering no longer makes sense. So in the past, there were just no In, Out labels shown. But as of Version 11.3, there are still labels, but they’re grayed down, and they don’t have any explicit numbers in them:

Another new feature in Version 11.3 is Iconize. Here’s the basic problem it solves. Let’s say you’ve got some big piece of data or other input that you want to store in the notebook, but you don’t want it to visually fill up the notebook. Well, one thing you can do is to put it in closed cells. But then to use the data you have to do something like creating a variable and so on. Iconize provides a simple, inline way to save data in a notebook.

Here’s how you make an iconized version of an expression:


Now you can use this iconized form in place of giving the whole expression; it just immediately evaluates to the full expression:

Reverse[{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}]

Another convenient use of Iconize is to make code easier to read, while still being complete. For example, consider something like this:

Plot[Sin[Tan[x]], {x, 0, 10}, Filling -> Axis, 
 PlotTheme -> "Scientific"]

You can select the options here, then go to the right-click menu and say to Iconize them:

The result is an easier-to-read piece of code—that still evaluates just as it did before:

Plot[Sin[Tan[x]], {x, 0, 10}, Sequence[
 Filling -> Axis, PlotTheme -> "Scientific"]]

In Version 11.2 we introduced ExternalEvaluate, for evaluating code in external languages (initially Python and JavaScript) directly from the Wolfram Language. (This is supported on the desktop and in private clouds; for security and provisioning reasons, the public Wolfram Cloud only runs pure Wolfram Language code.)

In Version 11.3 we’re now making it even easier to enter external code in notebooks. Just start an input cell with a > and you’ll get an external code cell (you can stickily select the language you want):

ExternalEvaluate["Python", "import platform; platform.platform()"]

And, yes, what comes back is a Wolfram Language expression that you can compute with:

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
The Nature of the Problem

Let’s say we had a way to distribute beacons around our solar system (or beyond) that could survive for billions of years, recording what our civilization has achieved. What should they be like?

It’s easy to come up with what I consider to be sophomoric answers. But in reality I think this is a deep—and in some ways unsolvable—philosophical problem, that’s connected to fundamental issues about knowledge, communication and meaning.

Still, a friend of mine recently started a serious effort to build little quartz disks, etc., and have them hitch rides on spacecraft, to be deposited around the solar system. At first I argued that it was all a bit futile, but eventually I agreed to be an advisor to the project, and at least try to figure out what to do to the extent we can.

But, OK, so what’s the problem? Basically it’s about communicating meaning or knowledge outside of our current cultural and intellectual context. We just have to think about archaeology to know this is hard. What exactly was some arrangement of stones from a few thousand years ago for? Sometimes we can pretty much tell, because it’s close to something in our current culture. But a lot of the time it’s really hard to tell.

OK, but what are the potential use cases for our beacons? One might be to back up human knowledge so things could be restarted even if something goes awfully wrong with our current terrestrial civilization. And of course historically it was very fortunate that we had all those texts from antiquity when things in Europe restarted during the Renaissance. But part of what made this possible was that there had been a continuous tradition of languages like Latin and Greek—not to mention that it was humans that were both the creators and consumers of the material.

But what if the consumers of the beacons we plan to spread around the solar system are aliens, with no historical connection to us? Well, then it’s a much harder problem.

In the past, when people have thought about this, there’s been a tendency to say “just show them math: it’s universal, and it’ll impress them!” But actually, I think neither claim about math is really true.

To understand this, we have to dive a little into some basic science that I happen to have spent many years working on. The reason people think math is a candidate for universal communication is that its constructs seem precise, and that at least here on Earth there’s only one (extant) version of it, so it seems definable without cultural references. But if one actually starts trying to work out how to communicate about current math without any assumptions (as, for example, I did as part of consulting on the Arrival movie), one quickly discovers that one really has to go “below math” to get computational processes with simpler rules.

And (as seems to happen with great regularity, at least to me) one obvious place one lands is with cellular automata. It’s easy to show an elaborate pattern that’s created according to simple well-defined rules:

But here’s the problem: there are plenty of physical systems that basically operate according to rules like these, and produce similarly elaborate patterns. So if this is supposed to show the impressive achievement of our civilization, it fails.

OK, but surely there must be something we can show that makes it clear that we’ve got some special spark of intelligence. I certainly always assumed there was. But one of the things that’s come out of the basic science I’ve done is what I called the Principle of Computational Equivalence, that basically says that once one’s gotten beyond a very basic level, every system will show behavior that’s equivalent in the sophistication of the computation it exhibits.

So although we’re very proud of our brains, and our computers, and our mathematics, they’re ultimately not going to be able to produce anything that’s beyond what simple programs like cellular automata—or, for that matter, “naturally occurring” physical systems—can produce. So when we make an offhand comment like “the weather has a mind of its own”, it’s not so silly: the fluid dynamic processes that lead to the weather are computationally equivalent to the processes that, for example, go on in our brains.

It’s a natural human tendency at this point to protest that surely there must be something special about us, and everything we’ve achieved with our civilization. People may say, for example, that there’s no meaning and no purpose to what the weather does. Of course, we can certainly attribute such things to it (“it’s trying to equalize temperatures between here and there”, etc.), and without some larger cultural story there’s no meaningful way to say if they’re “really there” or not.

OK, so if showing a sophisticated computation isn’t going to communicate what’s special about us and our civilization, what is? The answer is in the end details. Sophisticated computation is ubiquitous in our universe. But what’s inevitably special about us is the details of our history and what we care about.

We’re learning the same thing as we watch the progress of artificial intelligence. Increasingly, we can automate the things we humans can do—even ones that involve reasoning, or judgement, or creativity. But what we (essentially by definition) can’t automate is defining what we want to do, and what our goals are. For these are intimately connected to the details of our biological existence, and the history of our civilization—which is exactly what’s special about us.

But, OK, how can we communicate these things? Well, it’s hard. Because—needless to say—they’re tied into aspects of us that are special, and that won’t necessarily be shared with whatever we’re trying to communicate with.

At the end of the day, though, we’ve got a project that’s going to launch beacons on spacecraft. So what’s the best thing to put on them? I’ve spent a significant part of my life building what’s now the Wolfram Language, whose core purpose is to provide a precise language for communicating knowledge that our civilization has accumulated in a way that both us humans, and computers, can understand. So perhaps this—and my experience with it—can help. But first, we should talk about history to get an idea of what has and hasn’t worked in the past.

Lessons from the Past

A few years ago I was visiting a museum and looking at little wooden models of life in ancient Egypt that had been buried with some king several millennia ago. “How sad,” I thought. “They imagined this would help them in the afterlife. But it didn’t work; instead it just ended up in a museum.” But then it struck me: “No, it did work! This is their ‘afterlife’!” And they successfully transmitted some essence of their life to a world far beyond their own.

Of course, when we look at these models, it helps that a lot of what’s in them is familiar from modern times. Cows. A boat with oars. Scrolls. But some isn’t that familiar. What are those weird things at the ends of the boat, for example? What’s the purpose of those? What are they for? And here begins the challenge—of trying to understand without shared context.

I happened last summer to visit an archaeological site in Peru named Caral, that has all sorts of stone structures built more than 4000 years ago. It was pretty obvious what some of the structures were for. But others I couldn’t figure out. So I kept on asking our guide. And almost always the answer was the same: “it was for ceremonial purposes”.

Immediately I started thinking about modern structures. Yes, there are monuments and public artworks. But there are also skyscrapers, stadiums, cathedrals, canals, freeway interchanges and much more. And people have certain almost-ritual practices in interacting with these structures. But in the context of modern society, we would hardly call them “ceremonial”: we think of each type of structure as having a definite purpose which we can describe. But that description inevitably involves a considerable depth of cultural context.

When I was growing up in England, I went wandering around in woods near where I lived—and came across all sorts of pits and berms and other earthworks. I asked people what they were. Some said they were ancient fortifications; some said at least the pits were from bombs dropped in World War II. And who knows: maybe instead they were created by some process of erosion having nothing to do with people.

Almost exactly 50 years ago, as a young child vacationing in Sicily, I picked up this object on a beach:

Being very curious what it was, I took it to my local archaeology museum. “You’ve come to the wrong place, young man,” they said, “it’s obviously a natural object.” So off I went to a natural history museum, only to be greeted with “Sorry, it’s not for us; it’s an artifact”. And from then until now the mystery has remained (though with modern materials analysis techniques it could perhaps be resolved—and I obviously should do it!)

There are so many cases where it’s hard to tell if something is an artifact or not. Consider all the structures we’ve built on Earth. Back when I was writing A New Kind of Science, I asked some astronauts what the most obvious manmade structure they noticed from space was. It wasn’t anything like the Great Wall of China (which is actually hard to see). Instead, they said it was a line across the Great Salt Lake in Utah (actually a 30-mile-long railroad causeway built in 1959, with algae that happen to have varying colors on the two sides):

Right image courtesy of Ravell Call and Deseret News.

Then there was the 12-mile-diameter circle in New Zealand, the 30-mile one in Mauritania, and the 40-mile one in Quebec (with a certain Arrival heptapod calligraphy look):

Which were artifacts? This was before the web, so we had to contact people to find out. A New Zealand government researcher told us not to make the mistake of thinking their circle followed the shape of the cone volcano at its center. “The truth is, alas, much more prosaic,” he said: it’s the border of a national park, with trees cut outside only, i.e. an artifact. The other circles, however, had nothing to do with humans.

(It’s fun to look for evidence of humans visible from space. Like the grids of lights at night in Kansas, or lines of lights across Kazakhstan. And in recent years, there’s the 7-mile-long palm tree rendering in Dubai.  And, on the flip side, people have also tried to look for what might be “archaeological structures” in high-resolution satellite images of the Moon.)

But, OK, let’s come back to the question of what things mean. In a cave painting from 7000 years ago, we can recognize shapes of animals, and hand stencils that we can see were made with hands. But what do the configurations of these things mean? Realistically at this point we have no serious idea.

Maybe it’s easier if we look at things that are more “mathematical”-like. In the 1990s I did a worldwide hunt for early examples of complex but structured patterns. I found all sorts of interesting things (such as mosaics supposedly made by Gilgamesh, from 3000 BC—and the earliest fractals, from 1210 AD). Most of the time I could tell what rules were used to make the patterns—though I could not tell what “meaning” the patterns were supposed to convey, or whether, instead, they were “merely ornamental”.

The last pattern above, though, had me very puzzled for a while. Is it a cellular automaton being constructed back in the 1300s? Or something from number theory? Well, no, in the end it turns out it’s a rendering of a list of 62 attributes of Allah from the Koran, in a special square form of Arabic calligraphy constructed like this:

About a decade ago, I learned about a pattern from 11,000 years ago, on a wall in Aleppo, Syria (one hopes it’s still intact there). What is this? Math? Music? Map? Decoration? Digitally encoded data? We pretty much have no idea.

I could go on giving examples. Lots of times people have said “if one sees such-and-such, then it must have been made for a purpose”. The philosopher Immanuel Kant offered the opinion that if one saw a regular hexagon drawn in the sand, one could only imagine a “rational cause” for it. I used to think of this whenever I saw hexagonal patterns formed in rocks. And a few years ago I heard about hexagons in sand, produced purely by the action of wind. But the biggest hexagon I know is the storm pattern around the north pole of Saturn—that presumably wasn’t in any usual sense “put there for a purpose”:

In 1899 Nikola Tesla picked up all sorts of elaborate and strange-sounding radio emissions, often a little reminiscent of Morse code. He knew they weren’t of human origin, so his immediate conclusion was that they must be radio messages from the inhabitants of Mars. Needless to say, they’re not. And instead, they’re just the result of physical processes in the Earth’s ionosphere and magnetosphere.

But here’s the ironic thing: they often sound bizarrely similar to whale songs! And, yes, whale songs have all sorts of elaborate rhyme-like and other features that remind us of languages. But we still don’t really know if they’re actually for “communication”, or just for “decoration” or “play”.

One might imagine that with modern machine learning and with enough data one should be able to train a translator for “talking to animals”. And no doubt that’d be easy enough for “are you happy?” or “are you hungry?”. But what about more sophisticated things? Say the kind of things we want to communicate to aliens?

I think it’d be very challenging. Because even if animals live in the same environment as us, it’s very unclear how they think about things. And it doesn’t help that even their experience of the world may be quite different—emphasizing for example smell rather than sight, and so on.

Animals can of course make “artifacts” too. Like this arrangement of sand produced over the course of a week or so by a little puffer fish:

But what is this? What does it mean? Should we think of this “piscifact” as some great achievement of puffer fish civilization, that should be celebrated throughout the solar system?

Surely not, one might say. Because even though it looks complex—and even “artistic” (a bit like bird songs have features of music)—we can imagine that one day we’d be able to decode the neural pathways in the brain of the puffer fish that lead it to make this. But so what? We’ll also one day be able to know the neural pathways in humans that lead them to build cathedrals—or try to plant beacons around the solar system.

Aliens and the Philosophy of Purpose

There’s a thought experiment I’ve long found useful. Imagine a very advanced civilization, that’s able to move things like stars and planets around at will. What arrangement would they put them in?

Maybe they’d want to make a “beacon of purpose”. And maybe—like Kant—one could think that would be achievable by setting up some “recognizable” geometric pattern. Like how about an equilateral triangle? But no, that won’t do. Because for example the Trojan asteroids actually form an equilateral triangle with Jupiter and the Sun already, just as a result of physics.

And pretty soon one realizes that there’s actually nothing the aliens could do to “prove their purpose”. The configuration of stars in the sky may look kind of random to us (except, of course, that we still see constellations in it). But there’s nothing to say that looked at in the right way it doesn’t actually represent some grand purpose.

And here’s the confusing part: there’s a sense in which it does! Because, after all, just as a matter of physics, the configuration that occurs can be characterized as achieving the purpose of extremizing some quantity defined by the equations for matter and gravity and so on. Of course, one might say “that doesn’t count; it’s just physics”. But our whole universe (including ourselves) operates according to physics. And so now we’re back to discussing whether the extremization is “meaningful” or not.

We humans have definite ways to judge what’s meaningful or not to us. And what it comes down to is whether we can “tell a story” that explains, in culturally meaningful terms, why we’re doing something. Of course, the notion of purpose has evolved over the course of human history. Imagine trying to explain walking on a treadmill, or buying goods in a virtual world, or, for that matter, sending beacons out into the solar system—to the people thousands of years ago who created the structures from Peru that I showed above.

We’re not familiar (except in mythology) with telling “culturally meaningful stories” about the world of stars and planets. And in the past we might have imagined that somehow whatever stories we could tell would inevitably be far less rich than the ones we can tell about our civilization. But this is where basic science I’ve done comes in. The Principle of Computational Equivalence says that this isn’t true—and that in the end what goes on with stars and planets is just as rich as what goes on in our brains or our civilization.

In an effort to “show something interesting” to the universe, we might have thought that the best thing to do would be to present sophisticated abstract computational things. But that..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Catch a current livestream, or watch recorded livestreams at twitch.tv/stephen_wolfram »

Thinking in Public

I’ve been CEOing Wolfram Research for more than 30 years now. But what does that actually entail? What do I end up doing on a typical day? I certainly work hard. But I think I’m not particularly typical of CEOs of tech companies our size. Because for me a large part of my time is spent on the front lines of figuring out how our products should be designed and architected, and what they should do.

Thirty years ago I mostly did this by myself. But nowadays I’m almost always working with groups of people from our 800 or so employees. I like to do things very interactively. And in fact, for the past 15 years or so I’ve spent much of my time doing what I often call “thinking in public”: solving problems and making decisions live in meetings with other people.

I’m often asked how this works, and what actually goes on in our meetings. And recently I realized: what better way to show (and perhaps educate) people than just to livestream lots of our actual meetings? So over the past couple of months, I’ve livestreamed over 40 hours of my internal meetings—in effect taking everyone behind the scenes in what I do and how our products are created. (Yes, the livestreams are also archived.)

This essay is also posted in WIRED »

Seeing Decisions Be Made

In the world at large, people often complain that “nothing happens in meetings”. Well, that’s not true of my meetings. In fact, I think it’s fair to say that in every single product-design meeting I do, significant things are figured out, and at least some significant decisions are made. So far this year, for example, we’ve added over 250 completely new functions to the Wolfram Language. Each one of those went through a meeting of mine. And quite often the design, the name, or even the very idea of the function was figured out live in the meeting.

There’s always a certain intellectual intensity to our meetings. We’ll have an hour or whatever, and we’ll have to work through what are often complex issues, that require a deep understanding of some area or another—and in the end come up with ideas and decisions that will often have very long-term consequences.

I’ve worked very hard over the past 30+ years to maintain the unity and coherence of the Wolfram Language. But every day I’m doing meetings where we decide about new things to be added to the language—and it’s always a big challenge and a big responsibility to maintain the standards we’ve set, and to make sure that the decisions we make today will serve us well in the years to come.

It could be about our symbolic framework for neural nets. Or about integrating with databases. Or how to represent complex engineering systems. Or new primitives for functional programming. Or new forms of geo visualization. Or quantum computing. Or programmatic interactions with mail servers. Or the symbolic representation of molecules. Or a zillion other topics that the Wolfram Language covers now, or will cover in the future.

What are the important functions in a particular area? How do they relate to other functions? Do they have the correct names? How can we deal with seemingly incompatible design constraints? Are people going to understand these functions? Oh, and are related graphics or icons as good and clear and elegant as they can be?

By now I basically have four decades of experience in figuring things like this out—and many of the people I work with are also very experienced. Usually a meeting will start with some proposal that’s been developed for how something should work. And sometimes it’ll just be a question of understanding what’s proposed, thinking it through, and then confirming it. But often—in order to maintain the standards we’ve set—there are real problems that still have to be solved. And a meeting will go back and forth, grappling with some issue or another.

Ideas will come up, often to be shot down. Sometimes it’ll feel like we’re completely stuck. But everyone in the meeting knows this isn’t an exercise; we’ve got to come up with an actual answer. Sometimes I’ll be trying to make analogies—to find somewhere else where we’ve solved a similar problem before. Or I’ll be insisting we go back to first principles—to kind of the center of the problem—to understand everything from the beginning. People will bring up lots of detailed academic or technical knowledge—and I’ll usually be trying to extract the essence of what it should be telling us.

It’d certainly be a lot easier if our standards were lower. But we don’t want a committee compromise result. We want actual, correct answers that will stand the test of time. And these often require actual new ideas. But in the end it’s typically tremendously satisfying. We put in lots of work and thinking—and eventually we get a solution, and it’s a really good solution, that’s a real intellectual achievement.

Usually all of this goes on in private, inside our company. But with the livestream, anyone can see it happening—and can see the moment when some function is named, or some problem is solved.

What Are the Meetings Like?

What will actually be going on if you tune into a livestream? It’s pretty diverse. You might see some new Wolfram Language function being tried out (often based on code that’s only days or even hours old). You might see a discussion about software engineering, or trends in machine learning, or the philosophy of science, or how to handle some issue of popular culture, or what it’s going to take to fix some conceptual bug. You might see some new area get started, you might some specific piece of Wolfram Language documentation get finished, or you might see a piece of final visual design get done.

There’s quite a range of people in our meetings, with a whole diversity of accents and backgrounds and specialties. And it’s pretty common for us to need to call in some extra person with specific expertise we hadn’t thought was needed. (I find it a little charming that our company culture is such that nobody ever seems surprised to be called into a meeting and asked about a detail of some unusual topic they had no idea was relevant to us before.)

We’re a very geographically distributed company (I’ve been a remote CEO since 1991). So basically all our meetings are through webconferencing. (We use audio and screensharing, but we never find video helpful, except perhaps for looking at a mobile device or a book or a drawing on a piece of paper.)

Most often we’re looking at my screen, but sometimes it’ll be someone else’s screen. (The most common reason to look at someone else’s screen is to see something that’s only working on their machine so far.) Most often I’ll be working in a Wolfram Notebook. Usually there’ll be an initial agenda in a notebook, together with executable Wolfram Language code. We’ll start from that, but then I’ll be modifying the notebook, or creating a new one. Often I’ll be trying out design ideas. Sometimes people will be sending code fragments for me to run, or I’ll be writing them myself. Sometimes I’ll be live-editing our main documentation. Sometimes we’ll be watching graphic design being done in real time.

As much as possible, the goal in our meetings is to finish things. To consult in real time with all the people who have input we need, and to get all the ideas and issues about something resolved. Yes, sometimes, afterwards, someone (sometimes me) will realize that something we thought we figured out isn’t correct, or won’t work. But the good news is that that’s pretty rare, probably because the way we run our meetings, things get well aired in real time.

People in our meetings tend to be very direct. If they don’t agree with something, they’ll say so. I’m very keen that everyone in a meeting actually understands anything that’s relevant to them—so we get the benefit of their thinking and judgement about it. (That probably leads to an over-representation from me of phrases like “does that make sense?” or “do you get what I’m saying?”.)

It really helps, of course, that we have very talented people, who are quick at understanding things. And by now everyone knows that even if the main topic of a meeting is one thing, it’s quite likely that we’ll have to dip into something completely different in order to make progress. It requires a certain intellectual agility to keep up with this—but if nothing else, I think that’s on its own a great thing to practice and cultivate.

For me it’s very invigorating to work on so many different topics—often wildly different even between successive hours in a day. It’s hard work, but it’s also fun. And, yes, there is often humor, particularly in the specifics of the examples we’ll end up discussing (lots of elephants and turtles, and strange usage scenarios).

The meetings vary in size from 2 or 3 people to perhaps 20 people. Sometimes people will be added and dropped through the course of the meeting, as the details of what we’re discussing change. Particularly in larger meetings—that tend to be about projects that cut across multiple groups—we’ll typically have one or more project managers (we call them “PMs”) present. The PMs are responsible for the overall flow of the project—and particularly for coordinating between different groups that need to contribute.

If you listen to the livestream, you’ll hear a certain amount of jargon. Some of it is pretty typical in the software industry (UX = user experience, SQA = software quality assurance). Some of it is more specific to our company—like acronyms for departments (DQA = Document Quality Assurance, WPE = Web Product Engineering) or names of internal things (XKernel = prototype Wolfram Language build, pods = elements of Wolfram|Alpha output, pinkboxing = indicating undisplayable output, knitting = crosslinking elements of documentation). And occasionally, of course, there’s a new piece of jargon, or a new name for something, invented right in the meeting.

Usually our meetings are pretty fast paced. An idea will come up—and immediately people are responding to it. And as soon as something’s been decided, people will start building on the decision, and figuring out more. It’s remarkably productive, and I think it’s a pretty interesting process to watch. Even though without the experience base that the people in the meeting have, there may be some points at which it seems as if ideas are flying around too fast to keep track of what’s going on.

The Process of Livestreaming

The idea of livestreaming our internal meetings is new. But over the years I’ve done a fair amount of livestreaming for other purposes.

Back in 2009, when we launched Wolfram|Alpha, we actually livestreamed the process of making the site live. (I figured that if things went wrong, we might as well just show everyone what actually went wrong, rather than just putting up a “site unavailable” message.)

I’ve livestreamed demos and explorations of new software we’ve released. I’ve livestreamed work I happen to be doing in writing code or producing “computational essays”. (My son Christopher is arguably a faster Wolfram Language programmer than me, and he’s livestreamed some livecoding he’s done too.) I’ve also livestreamed live experiments, particularly from our Wolfram Summer School and Wolfram Summer Camp.

But until recently, all my livestreaming had basically been solo: it hadn’t involved having other people in the livestream. But I’ve always thought our internal design review meetings are pretty interesting, so I thought “why not let other people listen in on them too?”. I have to admit I was a little nervous about this at first. After all, these meetings are pretty central to what our company does, and we can’t afford to have them be dragged down by anything.

And so I’ve insisted that a meeting has to be just the same whether it’s livestreamed or not. My only immediate concession to livestreaming is that I give a few sentences of introduction to explain roughly what the meeting is going to be about. And the good news has been that as soon as a meeting gets going, the people in it (including myself) seem to rapidly forget that it’s being livestreamed—and just concentrate on the (typically quite intense) things that are going on in the meeting.

But something interesting that happens when we’re livestreaming a meeting is that there’s real-time text chat with viewers. Often it’s questions and general discussion. But sometimes it’s interesting comments or suggestions about what we’re doing or saying. It’s like having instant advisors, or an instant focus group, giving us real-time input or feedback about our decisions.

As a practical matter, the primary people in the meeting are too focused on the meeting itself to be handling text chat. So we have separate people doing that—surfacing a small number of the most relevant comments and suggestions. And this has worked great—and in fact in most meetings at least one or two good ideas come from our viewers, that we’re instantly able to incorporate into our thinking.

One can think of livestreaming as something a bit like reality TV—except that it’s live and real time. We’re planning to have some systematic “broadcast times” for recorded material. But the live component has the constraint that it has to happen when the meetings are actually happening. I tend to have a very full and complex schedule, packing in all the various things I do. And exactly when a particular design review meeting can happen will often depend on when a particular piece of code or design work is ready.

It will also depend on the availability of the various other people in the meetings—who have their own constraints, and often live in a wide range of time zones. I’ve tried other approaches, but the most common thing now is that design review meetings are scheduled soon before they actually happen, and typically not more than a day or two in advance. And even though I personally work at night as well as during the day, most design reviews tend to get scheduled during US (East Coast) working hours, because that’s when it’s easiest to arrange for all the people who have to be in the meeting—as well as people who might be called in if their expertise is needed.

From the point of view of livestreaming, it would be nice to have a more predictable schedule of relevant meetings, but the meetings are being set up to achieve maximum productivity in their own right—and livestreaming is just an add-on.

We’re trying to use Twitter to give some advance notice of livestreaming. But in the end the best indication of when a livestream is starting is just the notification that comes from the Twitch livestreaming platform we’re using. (Yes, Twitch is mainly used for e-sports right now, but we [and they] hope it can be used for other things too—and with their e-sports focus, their technology for screensharing has become very good. Curiously, I’ve been aware of Twitch for a long time. I met its founders at the very first Y Combinator Demo Day in 2005, and we used its precursor, justin.tv, to livestream the Wolfram|Alpha launch.)

Styles of Work

Not all the work I do is suitable for livestreaming. In addition to “thinking in public” in meetings, I also spend time “thinking in private”, doing things like just writing. (I actually spent more than 10 years almost exclusively “thinking in private” when I worked on my book A New Kind of Science.)

If I look at my calendar for a given week, I’ll see a mixture of things. Every day there are typically at least one or two design reviews of the kind I’ve been livestreaming. There are also a fair number of project reviews, where I’m trying to help move all kinds of projects along. And there are some strategy and management discussions too, along with the very occasional external meeting.

Our company is weighted very heavily towards R&D—and trying to build the best possible products. And that’s certainly reflected in the way I spend my time—and in my emphasis on intellectual rather than commercial value. Some people might think that after all these years I couldn’t possibly still be involved in the level of detail that’s in evidence in the design reviews we’ve been livestreaming.

But here’s the thing: I’m trying hard to design the Wolfram Language in the very best possible way for the long term. And after 40 years of doing software design, I’m pretty experienced at it. So I’m both fairly fast at doing it, and fairly good at not making mistakes. By now, of course, there are many other excellent software designers at our company. But I’m still the person who has the most experience with Wolfram Language design—as well as the most global view of the system (which is part of why in design review meetings, I end up spending some fraction of my time just connecting different related design efforts).

And, yes, I get involved in details. What exactly should the name of that option be? What color should that icon be? What should this function do in a particular corner case? And, yes, every one of these things could be solved in some way without me. But in a fairly short time, I can help make sure that what we have is really something that we can build on—and be proud of—in the years to come. And I consider it a good and worthy way for me to spend my time.

And it’s fun to be able to open up this process for people, by livestreaming the meetings we have. I’m hoping it’ll be useful for people to understand a bit about what goes into creating the Wolfram Language (and yes, software design often tends to be a bit unsung, and mainly noticed only if it’s got wrong—so it’s nice to be able to show what’s actually involved).

In a sense, doing the design of the Wolfram Language is a very concentrated and high-end example of computational thinking. And I hope that by experiencing it in watching our meetings, people will be learn more about how they can do computational thinking themselves.

The meetings that we’re livestreaming now are about features of the Wolfram Language etc. that we currently have under development. But with our aggressive schedule of releasing software, it shouldn’t be long before the things we’re talking about are actually released in working products. And when that happens, there’ll be something quite unique about it. Because for the first time ever, people will not only be able to see what got done, but they’ll also be able to go back to a recorded livestream and see how it came to be figured out.

It’s an interesting and unique record of a powerful form of intellectual activity. But for me it’s already nice just to be able to share some of the fascinating conversations I end up being part of every day. And to feel like the time I’m spending as a very hands-on CEO not only advances the Wolfram Language and the other things we’re building, but can also directly help educate—and perhaps entertain—a few more people out in the world.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
A Powerful Way to Express Ideas

People are used to producing prose—and sometimes pictures—to express themselves. But in the modern age of computation, something new has become possible that I’d like to call the computational essay.

I’ve been working on building the technology to support computational essays for several decades, but it’s only very recently that I’ve realized just how central computational essays can be to both the way people learn, and the way they communicate facts and ideas. Professionals of the future will routinely deliver results and reports as computational essays. Educators will routinely explain concepts using computational essays. Students will routinely produce computational essays as homework for their classes.

Here’s a very simple example of a computational essay:

There are basically three kinds of things here. First, ordinary text (here in English). Second, computer input. And third, computer output. And the crucial point is that these three kinds of these all work together to express what’s being communicated.

The ordinary text gives context and motivation. The computer input gives a precise specification of what’s being talked about. And then the computer output delivers facts and results, often in graphical form. It’s a powerful form of exposition that combines computational thinking on the part of the human author with computational knowledge and computational processing from the computer.

But what really makes this work is the Wolfram Language—and the succinct representation of high-level ideas that it provides, defining a unique bridge between human computational thinking and actual computation and knowledge delivered by a computer.

In a typical computational essay, each piece of Wolfram Language input will usually be quite short (often not more than a line or two). But the point is that such input can communicate a high-level computational thought, in a form that can readily be understood both by the computer and by a human reading the essay.

It’s essential to all this that the Wolfram Language has so much built-in knowledge—both about the world and about how to compute things in it. Because that’s what allows it to immediately talk not just about abstract computations, but also about real things that exist and happen in the world—and ultimately to provide a true computational communication language that bridges the capabilities of humans and computers.

An Example

Let’s use a computational essay to explain computational essays.

Let’s say we want to talk about the structure of a human language, like English. English is basically made up of words. Let’s get a list of the common ones.

Generate a list of common words in English:

How long is a typical word? Well, we can take the list of common words, and make a histogram that shows their distribution of lengths.

Make a histogram of word lengths:

Do the same for French:

Notice that the word lengths tend to be longer in French. We could investigate whether this is why documents tend to be longer in French than in English, or how this relates to quantities like entropy for text. (Of course, because this is a computational essay, the reader can rerun the computations in it themselves, say by trying Russian instead of French.)

But as something different, let’s compare languages by comparing their translations for, say, the word “computer”.

Find the translations for “computer” in the 10 most common languages:

Find the first translation in each case:

Arrange common languages in “feature space” based on their translations for “computer”:

From this plot, we can start to investigate all sorts of structural and historical relationships between languages. But from the point of view of a computational essay, what’s important here is that we’re sharing the exposition between ordinary text, computer input, and output.

The text is saying what the basic point is. Then the input is giving a precise definition of what we want. And the output is showing what’s true about it. But take a look at the input. Even just by looking at the names of the Wolfram Language functions in it, one can get a pretty good idea what it’s talking about. And while the function names are based on English, one can use “code captions” to understand it in another language, say Japanese:

But let’s say one doesn’t know about FeatureSpacePlot. What is it? If it was just a word or phrase in English, we might be able to look in a dictionary, but there wouldn’t be a precise answer. But a function in the Wolfram Language is always precisely defined. And to know what it does we can start by just looking at its documentation. But much more than that, we can just run it ourselves to explicitly see what it does.

And that’s a crucial part of what’s great about computational essays. If you read an ordinary essay, and you don’t understand something, then in the end you really just have to ask the author to find out what they meant. In a computational essay, though, there’s Wolfram Language input that precisely and unambiguously specifies everything—and if you want to know what it means, you can just run it and explore any detail of it on your computer, automatically and without recourse to anything like a discussion with the author.


How does one actually create a computational essay? With the technology stack we have, it’s very easy—mainly thanks to the concept of notebooks that we introduced with the first version of Mathematica all the way back in 1988. A notebook is a structured document that mixes cells of text together with cells of Wolfram Language input and output, including graphics, images, sounds, and interactive content:

In modern times one great (and very hard to achieve!) thing is that full Wolfram Notebooks run seamlessly across desktop, cloud and mobile. You can author a notebook in the native Wolfram Desktop application (Mac, Windows, Linux)—or on the web through any web browser, or on mobile through the Wolfram Cloud app. Then you can share or publish it through the Wolfram Cloud, and get access to it on the web or on mobile, or download it to desktop or, now, iOS devices.

Sometimes you want the reader of a notebook just to look at it, perhaps opening and closing groups of cells. Sometimes you also want them to be able to operate the interactive elements. And sometimes you want them to be able to edit and run the code, or maybe modify the whole notebook. And the crucial point is that all these things are easy to do with the cloud-desktop-mobile system we’ve built.

A New Form of Student Work

Computational essays are great for students to read, but they’re also great for students to write. Most of the current modalities for student work are remarkably old. Write an essay. Give a math derivation. These have been around for millennia. Not that there’s anything wrong with them. But now there’s something new: write a computational essay. And it’s wonderfully educational.

A computational essay is in effect an intellectual story told through a collaboration between a human author and a computer. The computer acts like a kind of intellectual exoskeleton, letting you immediately marshall vast computational power and knowledge. But it’s also an enforcer of understanding. Because to guide the computer through the story you’re trying to tell, you have to understand it yourself.

When students write ordinary essays, they’re typically writing about content that in some sense “already exists” (“discuss this passage”; “explain this piece of history”; …). But in doing computation (at least with the Wolfram Language) it’s so easy to discover new things that computational essays will end up with an essentially inexhaustible supply of new content, that’s never been seen before. Students will be exploring and discovering as well as understanding and explaining.

When you write a computational essay, the code in your computational essay has to produce results that fit with the story you’re telling. It’s not like you’re doing a mathematical derivation, and then some teacher tells you you’ve got the wrong answer. You can immediately see what your code does, and whether it fits with the story you’re telling. If it doesn’t, well then maybe your code is wrong—or maybe your story is wrong.

What should the actual procedure be for students producing computational essays? At this year’s Wolfram Summer School we did the experiment of asking all our students to write a computational essay about anything they knew about. We ended up with 72 interesting essays—exploring a very wide range of topics.

In a more typical educational setting, the “prompt” for a computational essay could be something like “What is the typical length of a word in English” or “Explore word lengths in English”.

There’s also another workflow I’ve tried. As the “classroom” component of a class, do livecoding (or a live experiment). Create or discover something, with each student following along by doing their own computations. At the end of the class, each student will have a notebook they made. Then have their “homework” be to turn that notebook into a computational essay that explains what was done.

And in my experience, this ends up being a very good exercise—that really tests and cements the understanding students have. But there’s also something else: when students have created a computational essay, they have something they can keep—and directly use—forever.

And this is one of the great general features of computational essays. When students write them, they’re in effect creating a custom library of computational tools for themselves—that they’ll be in a position to immediately use at any time in the future. It’s far too common for students to write notes in a class, then never refer to them again. Yes, they might run across some situation where the notes would be helpful. But it’s often hard to motivate going back and reading the notes—not least because that’s only the beginning; there’s still the matter of implementing whatever’s in the notes.

But the point is that with a computational essay, once you’ve found what you want, the code to implement it is right there—immediately ready to be applied to whatever has come up.

Any Subject You Want

What can computational essays be about? Almost anything! I’ve often said that for any field of study X (from archaeology to zoology), there either is now, or soon will be, a “computational X”. And any “computational X” can immediately be explored and explained using computational essays.

But even when there isn’t a clear “computational X” yet,  computational essays can still be a powerful way to organize and present material. In some sense, the very fact that a sequence of computations are typically needed to “tell the story” in an essay helps define a clear backbone for the whole essay. In effect, the structured nature of the computational presentation helps suggest structure for the narrative—making it easier for students (and others) to write essays that are easy to read and understand.

But what about actual subject matter? Well, imagine you’re studying history—say the history of the English Civil War. Well, conveniently, the Wolfram Language has a lot of knowledge about history (as about so many other things) built in. So you can present the English Civil War through a kind of dialog with it. For example, you can ask it for the geography of battles:

You could ask for a timeline of the beginning of the war (you don’t need to say “first 15 battles”, because if one cares, one can just read that from the Wolfram Language code):

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Is there a global theory for the shapes of fishes? It’s the kind of thing I might feel encouraged to ask by my explorations of simple programs and the forms they produce. But for most of the history of biology, it’s not the kind of thing anyone would ever have asked. With one notable exception: D’Arcy Wentworth Thompson.

And it’s now 100 years since D’Arcy Thompson published the first edition of his magnum opus On Growth and Form—and tried to use ideas from mathematics and physics to discuss global questions of biological growth and form. Probably the most famous pages of his book are the ones about fish shapes:

Stretch one kind of fish, and it looks like another. Yes, without constraints on how you stretch, it’s not quite clear what this is telling one, and I don’t think it’s much. But just to ask the question is interesting, and On Growth and Form is full of interesting questions—together with all manner of curious and interesting answers.

D’Arcy Thompson was in many ways a quintessential British Victorian academic, steeped in the classics, and writing books with titles like A Glossary of Greek Fishes (i.e. how were fish described in classical Greek texts). But he was also a diligent natural scientist, and he became a serious enthusiast of mathematics and physics. And where Aristotle (whom D’Arcy Thompson had translated) used plain language, with perhaps a dash of logic, to try to describe the natural world, D’Arcy Thompson tried to use the language of mathematics and physics.

At Christmas time, according to his daughter, he used to entertain children by drawing pictures of dogs on rubber sheets and stretching them from poodles to dachshunds. But it was not until the age of 57 that he turned such pursuits into the piece of scholarship that is On Growth and Form.

The first edition of the book was published in 1917. In many ways it’s like a catalog of biological forms—a kind of geometrical analog of Aristotle’s books on natural history. It’s particularly big on aquatic life—from plankton to fish. Land animals do make a showing, though mostly as skeletons. And ordinary plants make only specific appearances. But throughout the book the emphasis is on “why does such-and-such a thing have the form or shape it does?”. And over and over again the answer that’s given is: “because it’s following such-and-such a physical phenomenon, or mathematical structure”.

Much of the story of the book is told in its pictures. There are growth curves—of haddock, trees, regenerated tadpole tails, etc. There’s a long discussion of the shapes of cells—and especially their connection with phenomena (like splashes, bubbles and foams) where surface tension is important. There are spirals—described mathematically, and appearing in shells and horns and leaf arrangements. And finally there’s a long discussion of the “theory of transformations”—about how different forms (like the shapes of fishes or primate skulls) might be related by various (mathematically rather undefined) “transformations”.

In D’Arcy Thompson’s time—as still to a large extent today—the dominant form of explanation in biology is Darwinism: essentially the idea that things are the way they are because they’ve somehow evolved to be that way, in order to maximize some kind of fitness. D’Arcy Thompson didn’t think that was the whole story, or even necessarily the most important part of the story. He thought instead that many natural forms are the way they are because it’s an inevitable feature of the physics of biological tissue, or the mathematics of geometrical forms.

Sometimes his explanations fall a little flat. Leaves aren’t really shaped much like polar plots of trigonometric functions. Jellyfish aren’t convincingly shaped like drops of ink in water. But what he says often rings true. Hexagonal arrangements of cells are like closest geometrical packings of disks. Sheep horns and nautilus shells form logarithmic (equiangular) spirals.

He uses basic geometry and algebra quite a bit—and even sometimes a little combinatorics or topology. But he never goes as far as calculus (and, as it happens, he never learned it), and he never considers ideas like recursive rules or nested structures. But for me—as for quite a few others over the years—D’Arcy Thompson’s book is an important inspiration for the concept that even though biological forms may at first look complicated, there can still be theories and explanations for them.

In modern times, though, there’s a crucial new idea, that D’Arcy Thompson did not have: the idea of using not traditional mathematics and physics, but instead computation and simple programs as a way to describe the rules by which things grow. And—as I discovered in writing my book A New Kind of Science—it’s remarkable to what extent that idea lets us understand the mechanisms by which complex biological forms are produced, and lets us finish the bold initiative that D’Arcy Thompson began a century ago in On Growth and Form.

Who Was D’Arcy Thompson?

D’Arcy Wentworth Thompson was born in Edinburgh on May 5, 1860. His father, who was also named D’Arcy Wentworth Thompson, had been born in 1829, aboard a ship captained by his father, that was transporting convicts to Tasmania. D’Arcy Senior was soon sent to boarding school in England, and eventually studied classics at Cambridge. Though academically distinguished, he was apparently passed over for a fellowship because of perceived eccentricity—and wound up as a (modernizing, if opinionated) schoolteacher in Edinburgh. Once there, he soon met the lively young Fanny Gamgee, daughter of Joseph Gamgee, an early and distinguished veterinary surgeon—and in 1859 they were married.

D’Arcy (junior) was born the next year—but unfortunately his mother contracted an infection during childbirth, and died within the week. The result was that D’Arcy (junior) ended up living with his mother’s parents, taken care of by one of his mother’s sisters. When D’Arcy (junior) was three years old, his father then got a university professorship (of ancient Greek) in Ireland, and moved there. Still, D’Arcy (junior) stayed in close touch with his father through letters, and, later, visits. And indeed his father seems to have doted on him, for example publishing two children’s books dedicated to him:

In a foreshadowing of his later interests, D’Arcy (junior) learned Latin from his father almost as soon as he was able to speak, and was continually exposed to animals of all sorts in the Gamgee household. There was also a certain math/physics theme. D’Arcy Thompson (senior)’s best friend in Edinburgh was Peter Guthrie Tait—a distinguished mathematical physicist (mechanics, thermodynamics, knot theory, …) and friend of Maxwell, Hamilton and Kelvin—and D’Arcy (junior) often hung out at his house. Joseph Gamgee was also engaged in various scientific pursuits, for example publishing the book On Horseshoeing and Lameness based in part on a statistical study he’d done with the then 10-year-old D’Arcy (junior). Meanwhile, D’Arcy Thompson (senior) began to travel, as D’Arcy (junior) would later do, for example visiting Harvard in 1867 to give the Lowell Lectures—which D’Arcy (junior) would also give, in 1936, 69 years later.

At the age of 11, D’Arcy went to the school where his father had previously taught. He did well in academic studies, but also organized a natural history (“Eureka”) club, where he and his friends collected all sorts of specimens. And by the end of his time at school, he published his first paper: the 11-page (with photographs) “Note on Ulendron and Halonia”, describing the regular pattern of growth scars on two kinds of fossil plants.”

At 18, D’Arcy started at Edinburgh University as a medical student. His grandfather—while distinguished—was not wealthy, with the result that D’Arcy had to support himself by tutoring Greek and writing articles for the Edinburgh-published Encyclopedia Britannica (the 9th edition, from 1889, contains an extensive article by D’Arcy on John Ray, a British naturalist of the 1600s). But D’Arcy’s real passion at the time was the then-hot field of paleontology, and after two years he abandoned his medical studies—and left to instead study Natural Science at the place his father had been years earlier: Trinity College, Cambridge.

D’Arcy did well at Cambridge, had an interesting circle of friends (including the future co-author of Principia Mathematica, Alfred North Whitehead), and quickly became something of a fixture in the local natural history scene. This led Macmillan & Co. to commission D’Arcy (still an undergraduate) to produce his first book: a translation from German of Hermann Muller’s The Fertilisation of Flowers. The publisher thought that the book—which was a fairly traditional work of descriptive natural history, based in part on observing about 14,000 visits of insects to flowers—would be of popular interest, and (in one of his last published appearances) got no less than Charles Darwin to write a preface for it:

At Cambridge, D’Arcy hung out a lot at the new Museum of Zoology, and was particularly influenced by a young professor named Frank Balfour who studied comparative embryology, and for whom a new Department of Animal Morphology was being created—but who died trying to climb Mont Blanc right when D’Arcy was finishing Cambridge.

D’Arcy began to pursue all sorts of projects, giving lectures on topics such as “Aristotle on Cephalopods”, and making detailed studies of “hydroid zoophyte” specimens (aquatic animals like sea anemones that look like plants) brought back from expeditions to the Arctic and Antarctic. He applied for a fellowship in Cambridge, but—like his father before him—didn’t get it.

In 1884, though, the newly created and new-thinking (non-religious, co-ed, young professors, …) University College in Dundee, Scotland, advertised for a professor of biology (yes, combining zoology and botany!). D’Arcy applied, and got the job—with the result that at age 24 he became a professor, a role in which he would remain for nearly 64 years.

D’Arcy the Professor

D’Arcy was immediately popular as a teacher, and continued to do a certain amount of rather dry academic work (in 1885 he published A Bibliography of Protozoa, Sponges, Coelenterata, and Worms, which was, as advertised, a list of about 6000 publications on those subjects between 1861 and 1883). But his real passion was the creation of his own Museum of Zoology, and the accumulation of specimens for it.

He was soon excitedly writing that “within the last week, I have had a porpoise, two mongooses, a small shark, an eel 8ft long… a young ostrich and two bagfuls of monkeys: all dead of course.” His archive (among its 30,000 items) contains extensive evidence of all sorts of trading of specimens from around the world:

But in Dundee he found a particularly good local source of specimens. Dundee had long been a center of international textile trade, and had also developed a small whaling industry. And when it was discovered that by mixing jute with whale oil it could be turned into fabric, whaling in Dundee grew dramatically.

Some of the hunting they did was local. But whaling ships from Dundee went as far as Canada and Greenland (and once even to Antarctica). And befriending their captains, D’Arcy persuaded them to bring him back specimens (as skeletons, in jars, etc.) from their expeditions—with the result, for example, that his museum rapidly accumulated the best arctic collection around.

The museum always operated on a shoestring budget, and it was typical in 1886 when D’Arcy wrote that he’d personally been “working all day on a baby Ornithorhynchus” (platypus). In his early years as a professor, D’Arcy published only a few papers, mostly on very detailed matters—like the strangely shaped stomach of a type of possum, or the structure of the porpoise larynx, or the correct taxonomic placement of a duck-like dinosaur. And he always followed the prevailing Darwinian paradigm of trying to explain things either by their evolutionary connections, or by their fitness for a particular function.

The Matter of the Alaskan Seals

In Dundee, D’Arcy joined various local clubs, like the Dundee Naturalists’ Society, the Dundee Working Men’s Field Club, the Homeric Club, and, later, also the Freemasons. He became quite active in university and community affairs, notably campaigning for a medical school (and giving all sorts of statistical evidence for its utility), as well as for education for the local poor. But mostly D’Arcy lived the life of an academic, centered around his teaching and his museum.

Still, as a responsible member of the community, he was called on in various ways, and in 1892, he joined his first government commission—formed to investigate a plague of voles in Scotland (conclusions included: “don’t shoot hawks and owls that eat voles”, and “it’s probably not a good idea to set loose a ‘virus’ to infect the voles”). Then in 1896—at the age of 36—D’Arcy was tapped for a piece of international scientific diplomacy.

It all had to do with seals, and the fur trade based on them. When Russia sold Alaska to the US in 1867 it also sold the rights to the seals which bred on some of the islands in the Bering Sea. But by the 1890s Canadian ships (under British protection) were claiming the right to catch seals in the open ocean—and too many seals were being killed for the population to be maintained. In 1893 a treaty was made to clarify the situation. But in 1896 there was a need to analyze more carefully what was going on (and, yes, to claim what ended up being $10M in damages for Canadian/British sealers).

Lord Salisbury, the British Prime Minister at the time, who happened to be an amateur botanist, knew of D’Arcy and asked him to travel to the Bering Sea to investigate. D’Arcy had by that point traveled a bit around Europe, but this was a complex trip. At first he went to Washington, DC, dropping in at the White House. Then across Canada, and then by Coast Guard ship (and dog sled) to the seals.

D’Arcy did well at making friends with his American counterparts (who included the president of the then-a-decade-old Stanford University), and found that at least on the American-controlled islands (the Russian-controlled ones were a different story) seals were being herded a bit like sheep in Scotland, and that though there was “abundant need for care and prudent measures of conservation”, things were basically OK. In Washington, DC, D’Arcy gave a long speech, and helped broker a kind of “seal peace treaty”—that the British government was pleased enough with to give D’Arcy a (medieval-inspired) “Companion of the Bath” honor.

Statesman of Science

Being a professor in Dundee wasn’t a particularly high position in the pecking order of the time. And after his Bering Sea experience, D’Arcy started investigating moving up. He applied for various jobs (for example at the Natural History Museum in London), but perhaps in part because he didn’t have fancier academic credentials (like a PhD)—and also had spent so much of his time organizing things rather than doing research—he never got any of them.

He was nevertheless increasingly sought after as a kind of statesman of science. And in 1898 he was appointed to the Fishery Board for Scotland (a role in which he continued for 43 years), and the next year he was the British delegate to the first International Conference on Oceanography.

D’Arcy was a serious collector of data. He maintained a team of people at the fish market, keeping track of the catches brought in from boats:

And then he took this data and created graphics and statistical analyses:

And over the years he became well known as a negotiator of fishing rights, both locally and internationally. He was also a collector of oceanographic data. He saw to it that there were detailed tide measurements made:

And had the data analyzed and decomposed into..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Our Latest R&D Output

I’m excited today to announce the latest output from our R&D pipeline: Version 11.2 of the Wolfram Language and Mathematica—available immediately on desktop (Mac, Windows, Linux) and cloud.

It was only this spring that we released Version 11.1. But after the summer we’re now ready for another impressive release—with all kinds of additions and enhancements, including 100+ entirely new functions:

We have a very deliberate strategy for our releases. Integer releases (like 11) concentrate on major complete new frameworks that we’ll be building on far into the future. “.1” releases (like 11.2) are intended as snapshots of the latest output from our R&D pipeline–delivering new capabilities large and small as soon as they’re ready.

Version 11.2 has a mixture of things in it—ranging from ones that provide finishing touches to existing major frameworks, to ones that are first hints of major frameworks under construction. One of my personal responsibilities is to make sure that everything we add is coherently designed, and fits into the long-term vision of the system in a unified way.

And by the time we’re getting ready for a release, I’ve been involved enough with most of the new functions we’re adding that they begin to feel like personal friends. So when we’re doing a .1 release and seeing what new functions are going to be ready for it, it’s a bit like making a party invitation list: who’s going to be able to come to the big celebration?

Years back there’d be a nice list, but it would be of modest length. Today, however, I’m just amazed at how fast our R&D pipeline is running, and how much comes out of it every month. Yes, we’ve been consistently building our Wolfram Language technology stack for more than 30 years—and we’ve got a great team. But it’s still a thrill for me to see just how much we’re actually able to deliver to all our users in a .1 release like 11.2.

Advances in Machine Learning

It’s hard to know where to begin. But let’s pick a current hot area: machine learning.

We’ve had functionality that would now be considered machine learning in the Wolfram Language for decades, and back in 2014 we introduced the “machine-learning superfunctions” Classify and Predict—to give broad access to modern machine learning. By early 2015, we had state-of-the-art deep-learning image identification in ImageIdentify, and then, last year, in Version 11, we began rolling out our full symbolic neural net computation system.

Our goal is to push the envelope of what’s possible in machine learning, but also to deliver everything in a nice, integrated way that makes it easy for a wide range of people to use, even if they’re not machine-learning experts. And in Version 11.2 we’ve actually used machine learning to add automation to our machine-learning capabilities.

So, in particular, Classify and Predict are significantly more powerful in Version 11.2. Their basic scheme is that you give them training data, and they’ll learn from it to automatically produce a machine-learning classifier or predictor. But a critical thing in doing this well is to know what features to extract from the data—whether it’s images, sounds, text, or whatever. And in Version 11.2 Classify and Predict have a variety of new kinds of built-in feature extractors that have been pre-trained on a wide range of kinds of data.

But the most obviously new aspect of Classify and Predict is how they select the core machine-learning method to use (as well as hyperparameters for it). (By the way, 11.2 also introduces things like optimized gradient-boosted trees.) And if you run Classify and Predict now in a notebook you’ll actually see them dynamically figuring out and optimizing what they’re doing (needless to say, using machine learning):

By the way, you can always press Stop to stop the training process. And with the new option TimeGoal you can explicitly say how long the training should be planned to be—from seconds to years.

As a field, machine learning is advancing very rapidly right now (in the course of my career, I’ve seen perhaps a dozen fields in this kind of hypergrowth—and it’s always exciting). And one of the things about our general symbolic neural net framework is that we’re able to take new advances and immediately integrate them into our long-term system—and build on them in all sorts of ways.

At the front lines of this is the function NetModel—to which new trained and untrained models are being added all the time. (The models are hosted in the cloud—but downloaded and cached for desktop or embedded use.) And so, for example, a few weeks ago NetModel got a new model for inferring geolocations of photographs—that’s based on basic research from just a few months ago:

NetModel["ResNet-101 Trained on YFCC100M Geotagged Data"]

Now if we give it a picture with sand dunes in it, its top inferences for possible locations seem to center around certain deserts:

 NetModel["ResNet-101 Trained on YFCC100M Geotagged Data"][
  CloudGet["https://wolfr.am/dunes"], {"TopProbabilities", 50}]]

NetModel handles networks that can be used for all sorts of purposes—not only as classifiers, but also, for example, as feature extractors.

Building on NetModel and our symbolic neural network framework, we’ve also been able to add new built-in classifiers to use directly from Classify. So now, in addition to things like sentiment, we have NSFW, face age and facial expression (yes, an actual tiger isn’t safe, but in a different sense):


Our built-in ImageIdentify function (whose underlying network you can access with NetModel) has been tuned and retrained for Version 11.2—but fundamentally it’s still a classifier. One of the important things that’s happening with machine learning is the development of new types of functions, supporting new kinds of workflows. We’ve got a lot of development going on in this direction, but for 11.2 one new (and fun) example is ImageRestyle—that takes a picture and applies the style of another picture to it:


And in honor of this new functionality, maybe it’s time to get the image on my personal home page replaced with something more “styled”—though it’s a bit hard to know what to choose:

ImageRestyle[#, , PerformanceGoal -> "Quality", 
   TargetDevice -> 
    "GPU"] & /@ {\[Placeholder], \[Placeholder], \[Placeholder], \
\[Placeholder], \[Placeholder], \[Placeholder]}

By the way, another new feature of 11.2 is the ability to directly export trained networks and other machine-learning functionality. If you’re only interested in an actual network, you can get in MXNet format—suitable for immediate execution wherever MXNet is supported. In typical real situations, there’s some pre- and post-processing that’s needed as well—and the complete functionality can be exported in WMLF (Wolfram Machine Learning Format).

Cloud (and iOS) Notebooks

We invented the idea of notebooks back in 1988, for Mathematica 1.0—and over the past 29 years we’ve been steadily refining and extending how they work on desktop systems. About nine years ago we also began the very complex process of bringing our notebook interface to web browsers—to be able to run notebooks directly in the cloud, without any need for local installation.

It’s been a long, hard journey. But between new features of the Wolfram Language and new web technologies (like isomorphic React, Flow, MobX)—and heroic efforts of software engineering—we’re finally reaching the point where our cloud notebooks are ready for robust prime-time use. Like, try this one:

We actually do continuous releases of the Wolfram Cloud—but with Version 11.2 of the Wolfram Language we’re able to add a final layer of polish and tuning to cloud notebooks.

You can create and compute directly on the web, and you can immediately “peel off” a notebook to run on the desktop. Or you can start on the desktop, and immediately push your notebook to the cloud, so it can be shared, embedded—and further edited or computed with—in the cloud.

By the way, when you’re using the Wolfram Cloud, you’re not limited to desktop systems. With the Wolfram Cloud App, you can work with notebooks on mobile devices too. And now that Version 11.2 is released, we’re able to roll out a new version of the Wolfram Cloud App, that makes it surprisingly realistic (thanks to some neat UX ideas) to write Wolfram Language code even on your phone.

Talking of mobile devices, there’s another big thing that’s coming: interactive Wolfram Notebooks running completely locally and natively on iOS devices—both tablets and phones. This has been another heroic software engineering project—which actually started nearly as long ago as the cloud notebook project.

The goal here is to be able to read and interact with—but not author—notebooks directly on an iOS device. And so now with the Wolfram Player App that will be released next week, you can have a notebook on your iOS device, and use Manipulate and other dynamic content, as well as read and navigate notebooks—with the whole interface natively adapted to the touch environment.

For years it’s been frustrating when people send me notebook attachments in email, and I’ve had to do things like upload them to the cloud to be able to read them on my phone. But now with native notebooks on iOS, I can immediately just read notebook attachments directly from email.

Mathematical Limits

Math was the first big application of the Wolfram Language (that’s why it was called Mathematica!)… and for more than 30 years we’ve been committed to aggressively pursuing R&D to expand the domain of math that can be made computational. And in Version 11.2 the biggest math advance we’ve made is in the area of limits.

Mathematica 1.0 back in 1988 already had a basic Limit function. And over the years Limit has gradually been enhanced. But in 11.2—as a result of algorithms we’ve developed over the past several years—it’s reached a completely new level.

The simple-minded way to compute a limit is to work out the first terms in a power series. But that doesn’t work when functions increase too rapidly, or have wild and woolly singularities. But in 11.2 the new algorithms we’ve developed have no problem handling things like this:

Limit[E^(E^x + x^2) (-Erf[E^-E^x - x] - Erf[x]), x -> \[Infinity]]

Limit[(3 x + Sqrt[9 x^2 + 4 x - Sin[x]]), x -> -\[Infinity]]

It’s very convenient that we have a test set of millions of complicated limit problems that people have asked Wolfram|Alpha about over the past few years—and I’m pleased to say that with our new algorithms we can now immediately handle more than 96% of them.

Limits are in a sense at the very core of calculus and continuous mathematics—and to do them correctly requires a huge tower of knowledge about a whole variety of areas of mathematics. Multivariate limits are particularly tricky—with the main takeaway from many textbooks basically being “it’s hard to get them right”. Well, in 11.2, thanks to our new algorithms (and with a lot of support from our algebra, functional analysis and geometry capabilities), we’re finally able to correctly do a very wide range of multivariate limits—saying whether there’s a definite answer, or whether the limit is provable indeterminate.

Version 11.2 also introduces two other convenient mathematical constructs: MaxLimit and MinLimit (sometimes known as lim sup and lim inf). Ordinary limits have a habit of being indeterminate whenever things get funky, but MaxLimit and MinLimit have definite values, and are what come up most often in applications.

So, for example, there isn’t a definite ordinary limit here:

Limit[Sin[x] + Cos[x/4], x -> \[Infinity]]

But there’s a MaxLimit, that turns out to be a complicated algebraic number:

MaxLimit[Sin[x] + Cos[x/4], x -> \[Infinity]] // FullSimplify


Another new construct in 11.2 is DiscreteLimit, that gives limits of sequences. Like here’s it’s illustrating the Prime Number Theorem:

DiscreteLimit[Prime[n]/(n Log[n]), n -> \[Infinity]]

And here it’s giving the limiting value of the solution to a recurrence relation:

 RSolveValue[{x[n + 1] == Sqrt[1 + x[n] + 1/x[n]], x[1] == 3}, x[n], 
  n], n -> \[Infinity]]
All Sorts of New Data

There’s always new data in the Wolfram Knowledgebase—flowing every second from all sorts of data feeds, and systematically being added by our curators and curation systems. The architecture of our cloud and desktop system allows both new data and new types of data (as well as natural language input for it) to be immediately available in the Wolfram Language as soon as it’s in the Wolfram Knowledgebase.

And between Version 11.1 and Version 11.2, there’ve been millions of updates to the Knowledgebase. There’ve also been some new types of data added. For example—after several years of development—we’ve now got well-curated data on all notable military conflicts, battles, etc. in history:

Entity["MilitaryConflict", "SecondPunicWar"][
 EntityProperty["MilitaryConflict", "Battles"]]


Another thing that’s new in 11.2 is greatly enhanced predictive caching of data in the Wolfram Language—making it much more efficient to compute with large volumes of curated data from the Wolfram Knowledgebase.

By the way, Version 11.2 is the first new version to be released since the Wolfram Data Repository was launched. And through the Data Repository, 11.2 has access to nearly 600 curated datasets across a very wide range of areas. 11.2 also now supports functions like ResourceSubmit, for programmatically submitting data for publication in the Wolfram Data Repository. (You can also publish data yourself just using

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Preparing for August 21, 2017

On August 21, 2017, there’s going to be a total eclipse of the Sun visible on a line across the US. But when exactly will the eclipse occur at a given location? Being able to predict astronomical events has historically been one of the great triumphs of exact science. But in 2017, how well can it actually be done?

The answer, I think, is well enough that even though the edge of totality moves at just over 1000 miles per hour it should be possible to predict when it will arrive at a given location to within perhaps a second. And as a demonstration of this, we’ve created a website to let anyone enter their geo location (or address) and then immediately compute when the eclipse will reach them—as well as generate many pages of other information.

It’s an Old Business

These days it’s easy to find out when the next solar eclipse will be; indeed built right into the Wolfram Language there’s just a function that tells you (in this form the output is the “time of greatest eclipse”):


It’s also easy to find out, and plot, where the region of totality will be:


Or to determine that the whole area of totality will be about 16% of the area of the US:

GeoArea[SolarEclipse["TotalPhasePolygon"]]/GeoArea[Entity["Country", "UnitedStates"]]

But computing eclipses is not exactly a new business. In fact, the Antikythera device from 2000 years ago even tried to do it—using 37 metal gears to approximate the motion of the Sun and Moon (yes, with the Earth at the center). To me there’s something unsettling—and cautionary—about the fact that the Antikythera device stands as such a solitary piece of technology, forgotten but not surpassed for more than 1600 years.

But right there on the bottom of the device there’s an arm that moves around, and when it points to an Η or Σ marking, it indicates a possible Sun or Moon eclipse. The way of setting dates on the device is a bit funky (after all, the modern calendar wouldn’t be invented for another 1500 years), but if one takes the simulation on the Wolfram Demonstrations Project (which was calibrated back in 2012 when the Demonstration was created), and turns the crank to set the device for August 21, 2017, here’s what one gets:

And, yes, all those gears move so as to line the moon indicator up with the Sun—and to make the arm on the bottom point right at an Η—just as it should for a solar eclipse. It’s amazing to see this computation successfully happen on a device designed 2000 years ago.

Of course the results are a lot more accurate today. Though, strangely, despite all the theoretical science that’s been done, the way we actually compute the position of the Sun and Moon is conceptually very much like the gears—and effectively epicycles—of the Antikythera device. It’s just that now we have the digital equivalent of hundreds of thousands of gears.

Why Do Eclipses Happen?

A total solar eclipse occurs when the moon gets in front of the Sun from the point of view of a particular location on the Earth. And it so happens that at this point in the Earth’s history the moon can just block the Sun because it has almost exactly the same angular diameter in the sky as the Sun (about 0.5° or 30 arc-minutes).

So when does the moon get between the Sun and the Earth? Well, basically every time there’s a new moon (i.e. once every lunar month). But we know there isn’t an eclipse every month. So how come?

Graphics[{Style[Disk[{0, 0}, .3/5], Yellow], 
  Style[Disk[{.8, 0}, .1/5], Gray], Style[Disk[{1, 0}, .15/5], Blue]}]

Well, actually, in the analogous situation of Ganymede and Jupiter, there is an eclipse every time Ganymede goes around Jupiter (which happens to be about once per week). Like the Earth, Jupiter’s orbit around the Sun lies in a particular plane (the “Plane of the Ecliptic"). And it turns out that Ganymede’s orbit around Jupiter also lies in essentially the same plane. So every time Ganymede reaches the “new moon” position (or, in official astronomy parlance, when it’s aligned “in syzygy”—pronounced sizz-ee-gee), it’s in the right place to cast its shadow onto Jupiter, and to eclipse the Sun wherever that shadow lands. (From Jupiter, Ganymede appears about 3 times the size of the Sun.)

But our moon is different. Its orbit doesn’t lie in the plane of the ecliptic. Instead, it’s inclined at about 5°. (How it got that way is unknown, but it’s presumably related to how the moon was formed.) But that 5° is what makes eclipses so comparatively rare: they can only happen when there’s a “new moon configuration” (syzygy) right at a time when the moon’s orbit passes through the Plane of the Ecliptic.

To show what’s going on, let’s draw an exaggerated version of everything. Here’s the moon going around the Earth, colored red whenever it’s close to the Plane of the Ecliptic:

Graphics3D[{With[{dt = 0, \[Theta] = 20 Degree},
   Table[{With[{p = {Sin[2 Pi (t + dt)/27.3] Cos[\[Theta]],
         Cos[2 Pi (t + dt)/27.3] Cos[\[Theta]],
         Cos[2 Pi (t + dt)/27.3] Sin[\[Theta]]}}, {Style[
        Line[{{0, 0, 0}, p}], Opacity[.1]],
       Style[Sphere[p, .05],
        Blend[{Red, GrayLevel[.8, .02]},
         Sqrt[Abs[Cos[2 Pi t/27.2]]]]]}],
     Style[Sphere[{0, 0, 0}, .1], Blue]}, {t, 0, 26}]], EdgeForm[Red],
   Style[InfinitePlane[{0, 0, 0}, {{1, 0, 0}, {0, 1, 0}}],
   Directive[Red, Opacity[.02]]]}, Lighting -> "Neutral",
 Boxed -> False] 

Now let’s look at what happens over the course of about a year. We’re showing a dot for where the moon is each day. And the dot is redder if the moon is closer to the Plane of the Ecliptic that day. (Note that if this was drawn to scale, you’d barely be able to see the moon’s orbit, and it wouldn’t ever seem to go backwards like it does here.)

With[{dt = 1}, 
 Graphics[{Style[Disk[{0, 0}, .1], Darker[Yellow]], 
   Table[{With[{p = .2 {Sin[2 Pi t/27.3], Cos[2 Pi t/27.3]} + {Sin[
           2 Pi t/365.25], Cos[2 Pi t/365.25]}}, {Style[
        Line[{{Sin[2 Pi t/365.25], Cos[2 Pi t/365.25]}, p}], 
       Style[Disk[p, .01], 
        Blend[{Red, GrayLevel[.8]}, 
         Sqrt[Abs[Cos[2 Pi (t + dt)/27.2]]]]]}], 
     Style[Disk[{Sin[2 Pi t/365.25], Cos[2 Pi t/365.25]}, .005], 
      Blue]}, {t, 360}]}]]

Now we can start to see how eclipses work. The basic point is that there’s a solar eclipse whenever the moon is both positioned between the Earth and the Sun, and it’s in the Plane of the Ecliptic. In the picture, those two conditions correspond to the moon being as far as possible towards the center, and as red as possible. So far we’re only showing the position of the (exaggerated) moon once per day. But to make things clearer, let’s show it four times a day—and now prune out cases where the moon isn’t at least roughly lined up with the Sun:

With[{dt=1},Graphics[{Style[Disk[{0,0},.1],Darker[Yellow]],Table[{With[{p=.2 {Sin[2 Pi t/27.3],Cos[2 Pi t/27.3]}+{Sin[2 Pi t/365.25],Cos[2 Pi t/365.25]}},If[Norm[p]>.81,{},{Style[Line[{{Sin[2 Pi t/365.25],Cos[2 Pi t/365.25]},p}],Opacity[.3]],Style[Disk[p,.01],Blend[{Red,GrayLevel[.8]},Sqrt[Abs[Cos[2 Pi (t+dt)/27.2]]]]]}]],Style[Disk[{Sin[2 Pi t/365.25],Cos[2 Pi t/365.25]},.005],Blue]},{t,1,360,.25}]}]]

And now we can see that at least in this particular case, there are two points (indicated by arrows) where the moon is lined up and in the plane of the ecliptic (so shown red)—and these points will then correspond to solar eclipses.

In different years, the picture will look slightly different, essentially because the moon is starting at a different place in its orbit at the beginning of the year. Here are schematic pictures for a few successive years:

  Table[With[{dt = 1}, 
    Graphics[{Table[{With[{p = .2 {Sin[2 Pi t/27.3], 
              Cos[2 Pi t/27.3]} + {Sin[2 Pi t/365.25], 
             Cos[2 Pi t/365.25]}}, 
         If[Norm[p] > .81, {}, {Style[Line[{{0, 0}, p}], 
            Blend[{Red, GrayLevel[.8]}, 
             Sqrt[Abs[Cos[2 Pi (t + dt)/27.2]]]]], 
           Style[Line[{{Sin[2 Pi t/365.25], Cos[2 Pi t/365.25]}, p}], 
           Style[Disk[p, .01], 
            Blend[{Red, GrayLevel[.8]}, 
             Sqrt[Abs[Cos[2 Pi (t + dt)/27.2]]]]]}]], 
        Style[Disk[{Sin[2 Pi t/365.25], Cos[2 Pi t/365.25]}, .005], 
         Blue]}, {t, 1 + n *365.25, 360 + n*365.25, .25}], 
      Style[Disk[{0, 0}, .1], Darker[Yellow]]}]], {n, 0, 5}], 3]]

It’s not so easy to see exactly when eclipses occur here—and it’s also not possible to tell which are total eclipses where the moon is exactly lined up, and which are only partial eclipses. But there’s at least an indication, for example, that there are “eclipse seasons” in different parts of the year where eclipses happen.

OK, so what does the real data look like? Here’s a plot for 20 years in the past and 20 years in the future, showing the actual days in each year when total and partial solar eclipses occur (the small dots everywhere indicate new moons):

coord[date_] := {DateValue[date, "Year"], 
  date - NextDate[DateObject[{DateValue[date, "Year"]}], "Instant"]}
ListPlot[coord /@ SolarEclipse[{Now - Quantity[20, "Years"], Now + Quantity[20, "Years"], All}], AspectRatio -> 1/3, Frame -> True]

The reason for the “drift” between successive years is just that the lunar month (29.53 days) doesn’t line up with the year, so the moon doesn’t go through a whole number of orbits in the course of a year, with the result that at the beginning of a new year, the moon is in a different phase. But as the picture makes clear, there’s quite a lot of regularity in the general times at which eclipses occur—and for example there are usually 2 eclipses in a given year—though there can be more (and in 0.2% of years there can be as many as 5, as there last were in 1935 ).

To see more detail about eclipses, let’s plot the time differences (in fractional years) between all successive solar eclipses for 100 years in the past and 100 years in the future:

ListLinePlot[Differences[SolarEclipse[{Now - Quantity[100, "Years"], Now + Quantity[100, "Years"], All}]]/Quantity[1, "Years"], Mesh -> All, PlotRange -> All, Frame -> True, AspectRatio -> 1/3, FrameTicks -> {None, Automatic}]

And now let’s plot the same time differences, but just for total solar eclipses:

ListLinePlot[Differences[SolarEclipse[{Now - Quantity[100, "Years"], Now + Quantity[100, "Years"], All}, EclipseType -> "Total"]]/Quantity[1, "Years"], Mesh -> All, PlotRange -> All, Frame -> True, AspectRatio -> 1/3, FrameTicks -> {None, Automatic}]

There’s obviously a fair amount of overall regularity here, but there are also lots of little fine structure and irregularities. And being able to correctly predict all these details has basically taken science the better part of a few thousand years.

Ancient History

It’s hard not to notice an eclipse, and presumably even from the earliest times people did. But were eclipses just reflections—or omens—associated with random goings-on in the heavens, perhaps in some kind of soap opera among the gods? Or were they things that could somehow be predicted?

A few thousand years ago, it wouldn’t have been clear what people like astrologers could conceivably predict. When will the moon be at a certain place in the sky? Will it rain tomorrow? What will the price of barley be? Who will win a battle? Even now, we’re not sure how predictable all of these are. But the one clear case where prediction and exact science have triumphed is astronomy.

At least as far as the Western tradition is concerned, it all seems to have started in ancient Babylon—where for many hundreds of years, careful observations were made, and, in keeping with the ways of that civilization, detailed records were kept. And even today we still have thousands of daily official diary entries written in what look like tiny chicken scratches preserved on little clay tablets (particularly from Ninevah, which happens now to be in Mosul, Iraq). “Night of the 14th: Cold north wind. Moon was in front of α Leonis. From 15th to 20th river rose 1/2 cubit. Barley was 1 kur 5 siit. 25th, last part of night, moon was 1 cubit 8 fingers behind ε Leonis. 28th, 74° after sunrise, solar eclipse…”

If one looks at what happens on a particular day, one probably can’t tell much. But by putting observations together over years or even hundreds of years it’s possible to see all sorts of repetitions and regularities. And back in Babylonian times the idea arose of using these to construct an ephemeris—a systematic table that said where a particular heavenly body such as the moon was expected to be at any particular time.

(Needless to say, reconstructing Babylonian astronomy is a complicated exercise in decoding what’s by now basically an alien culture. A key figure in this effort was a certain Otto Neugebauer, who happened to work down the hall from me at the Institute for Advanced Study in Princeton in the early 1980s. I would see him almost every day—a quiet white-haired chap, with a twinkle in his eye—and just sometimes I’d glimpse his huge filing system of index cards which I now realize was at the center of understanding Babylonian astronomy.)

One thing the Babylonians did was to measure surprisingly accurately the repetition period for the phases of the moon—the so-called synodic month (or “lunation period”) of about 29.53 days. And they noticed that 235 synodic months was very close to 19 years—so that about every 19 years dates and phases of the moon repeat their alignment, forming a so-called Metonic cycle (named after Meton of Athens, who described it in 432 BC).

It probably helps that the random constellations in the sky form a good pattern against which to measure the precise position of the moon (it reminds me of the modern fashion of wearing fractals to make motion capture for movies easier). But the Babylonians noticed all sorts of details of the motion of the moon. They knew about its “anomaly": its periodic speeding up and slowing down in the sky (now known to be a consequence of its slightly elliptical orbit). And they measured the average period of this—the so-called anomalistic month—to be about 27.55 days. They also noticed that the moon went above and below the Plane of the Ecliptic (now known to be because of the inclination of its orbit)—with an average period (the so-called draconic month) that they measured as about 27.21 days.

And by 400 BC they’d noticed that every so-called saros of about 18 years 11 days all these different periods essentially line up (223 synodic months, 239 anomalistic months and 242 draconic months)—with the result that the moon ends up at about the same position relative to the Sun. And this means that if there was an eclipse at one saros, then one can make the prediction that there’s going to be an eclipse at the next saros too.

When one’s absolutely precise about it, there are all sorts of effects that prevent precise repetition at each saros. But over timescales of more than 1300 years, there are in fact still strings of eclipses separated from each other by one saros. (Over the course of such a saros series, the locations of the eclipses effectively scan across the Earth; the upcoming eclipse is number 22 in a series of 77 that began in 1639 AD with an eclipse near the North Pole and will end in 3009 AD with an eclipse near the South Pole.)

Any given moment in time will be in the middle of quite a few saros series (right now it’s 40)—and successive eclipses will always come from different series. But knowing about the saros cycle is a great first step in predicting eclipses—and it’s for example what the Antikythera device uses. In a sense, it’s a quintessential piece of science: take many observations, then synthesize a theory from them, or a least a scheme for computation.

It’s not clear what the Babylonians thought about abstract, formal systems. But the Greeks were definitely into them. And by 300 BC Euclid had defined his abstract system for geometry. So when someone like Ptolemy did astronomy, they did it a bit like Euclid—effectively taking things like the saros cycle as axioms, and then proving from them often surprisingly elaborate geometrical theorems, such as that there must be at least two solar eclipses in a given..

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The Summer Camp Was a Success!

How far can one get in teaching computational thinking to high-school students in two weeks? Judging by the results of this year’s Wolfram High-School Summer Camp the answer is: remarkably far.

I’ve been increasingly realizing what an immense and unique opportunity there now is to teach computational thinking with the whole stack of technology we’ve built up around the Wolfram Language. But it was a thrill to see just how well this seems to actually work with real high-school students—and to see the kinds of projects they managed to complete in only two weeks.

We’ve been doing our high-school summer camp for 5 years now (as well as our 3-week Summer School for more experienced students for 15 years). And every time we do the camp, we figure out a little more. And I think that by now we really have it down—and we’re able to take even students who’ve never really been exposed to computation before, and by the end of the camp have them doing serious computational thinking—and fluently implementing their ideas by writing sometimes surprisingly sophisticated Wolfram Language code (as well as creating well-written notebooks and “computational essays” that communicate about what they’ve done).

Over the coming year, we’re going to be dramatically expanding our Computational Thinking Initiative, and working to bring analogs of the Summer Camp experience to as many students as possible. But the Summer Camp provides fascinating and important data about what’s possible.

The Setup for the Camp

So how did the Summer Camp actually work? We had a lot of applicants for the 40 slots we had available this year. Some had been pointed to the camp by parents, teachers, or previous attendees. But a large fraction had just seen mention of it in the Wolfram|Alpha sidebar. There were students from a range of kinds of schools around the US, and overseas (though we still have to figure out how to get more applicants from underserved populations). Our team had done interviews to pick the final students—and I thought the ones they’d selected were terrific.

The students’ past experience was quite diverse. Some were already accomplished programmers (almost always self-taught). Others had done a CS class or two. But quite a few had never really done anything computational before—even though they were often quite advanced in various STEM areas such as math. But almost regardless of background, it was striking to me how new the core concepts of computational thinking seemed to be to so many of the students.

How does one take an idea or a question about almost anything, and find a way to formulate it for a computer? To be fair, it’s only quite recently, with all the knowledge and automation that we’ve been able to build into the Wolfram Language, that it’s become realistic for kids to do these kinds of things for real. So it’s not terribly surprising that in their schools or elsewhere our students hadn’t really been exposed to such things before. But it’s now possible—and that means there’s a great new opportunity to seriously teach computational thinking to kids, and to position them to pursue the amazing range of directions that computational thinking is opening up.

It’s important, by the way, to distinguish between “computational thinking” and straight “coding”. Computational thinking is about formulating things in computational terms. Coding is about the actual mechanics of telling a computer what to do. One of our great goals with the Wolfram Language is to automate the process of coding as much as possible so people can concentrate on pure computational thinking. When one’s using lower-level languages, like C++ and Java, there’s no choice but to be involved with the detailed mechanics of coding. But with the Wolfram Language the exciting thing is that it’s possible to teach pure high-level computational thinking, without being forced to deal with the low-level mechanics of coding.

What does this mean in practice? I think it’s very empowering for students: as soon as they “get” a concept, they can immediately apply it, and do real things with it. And it was pretty neat at the Summer Camp to see how easily even students who’d never written programs before were able to express surprisingly sophisticated computational ideas in the Wolfram Language. Sometimes it seemed like students who’d learned a low-level language before were actually at a disadvantage. Though for me it was interesting a few times to witness the “aha” moment when a student realized that they didn’t have to break down their computations into tiny steps the way they’d been taught—and that they could turn some big blob of code they’d written into one simple line that they could immediately understand and extend.

Suggesting Projects

The Summer Camp program involves several hours each day of lectures and workshops aimed at bringing students up to speed with computational thinking and how to express it in the Wolfram Language. But the real core of the program is every student doing an individual, original, computational thinking project.

And, yes, this is a difficult thing to orchestrate. But over the years we’ve been doing our Summer School and Summer Camp we’ve developed a very successful way of setting this up. There are a bunch of pieces to it, and the details depend on the level of the students. But here let’s talk about high-school students, and this year’s Summer Camp.

Right before the camp we (well, actually, I) came up with a list of about 70 potential projects. Some are quite specific, some are quite open-ended, and some are more like “metaprojects” (e.g. pick a dataset in the Wolfram Data Repository and analyze it). Some are projects that could at least in some form already have been done quite a few years ago. But many projects have only just become possible—this year particularly as a result of all our recent advances in machine learning.

I tried to have a range of nominal difficulty levels for the projects. I say “nominal” because even a project that can in principle be done in an easy way can also always be done in a more elaborate and sophisticated way. I wanted to have projects that ranged from the extremely well defined and precise (implement a precise algorithm of this particular type), to ones that involved wrangling data or machine learning training, to ones that were basically free-form and where the student got to define the objective.

Many of the projects in this list might seem challenging for high-school students. But my calculation (which in fact worked out well) was that with the technology we now have, all of them are within range.

It’s perhaps interesting to compare the projects with what I suggested for this year’s Summer School. The Summer School caters to more experienced students—typically at the college, graduate school or postdoc level. And so I was able to suggest projects that require deeper mathematical or software engineering knowledge—or are just bigger, with a higher threshold to achieve a reasonable level of success.

Matching Projects to Students

Before students start picking projects, it’s important that they understand what a finished project should look like, and what’s involved in doing it. So at the very beginning of the camp, the instructors went through projects from previous camps, and discussed what the “output” of a project should be. Maybe it’ll be an active website; maybe an interactive Demonstration; maybe it’ll be a research paper. It’s got to be possible to make a notebook that describes the project and its results, and to make a post about it for Wolfram Community.

After talking about the general idea of projects, and giving examples of previous ones, the instructors did a quick survey of this year’s suggestions list, filling in a few details of what the imagined projects actually were. After this, the students were asked to pick their top three projects from our list, and then invent two more potential projects of their own.

It’s always an interesting challenge to find the right project for each student—and it’s something I’ve personally been involved in at our Summer Camp for the past several years. (And, yes, it helps that I have decades of experience in organizing professional and research projects and figuring out the best people to do them.)

It’s taken us a few iterations, but here’s the approach we’ve found works well. First, we randomly break the students up into groups of a dozen or so. Then we meet with each group, going around the room and asking each student a little about themselves, their interests and goals—and their list of projects.

After we’re finished with each group, we meet separately and try to come up with a project for each student. Sometimes it’ll be one of the projects straight from our list. Sometimes it’ll be a project that the student themself suggested. And sometimes it’ll be some creative combination of these, or even something completely different based on what they said they were interested in.

After we think we’ve come up with a good project, the next step is to meet individually with each student and actually suggest it to them. It’s very satisfying that a lot of the time the students seem really enthused about the projects we end up suggesting. But sometimes it becomes clear that a project just isn’t a good fit—and then sometimes we modify it in real time, but more often we circle back later with a different suggestion.

Once the projects are set, we assign an appropriate mentor to each student, taking into account both the student and the subject of the project. And then things are off and running. We have various checkpoints, like that students have to write up descriptions of their projects and post them on the internal Summer Camp site.

I personally wasn’t involved in the actual execution of the projects (though I did have a chance to check in on a few of them). So it was pretty interesting for me to see at the end of the camp what had actually happened. It’s worth mentioning that our scheme is that mentors can make suggestions about projects, but all the final code in a project should be created by the student. And if one version of the project ends up being too difficult, it’s up to the mentor to simplify it. So however the final project comes out, it really is the student’s work.

Much of the time, the Summer Camp will be the first time students have ever done an original project. It could potentially seem daunting. But I think the fact that we give so many examples of other projects, and that everyone else at the camp is also doing a project, really helps. And in the end experiencing the whole process of going from the idea for a project to a real, finished project is incredibly educational—and seems to have a big effect on many of our students.

A Few Case Studies

OK, so that’s the theory. So what actually happened at this year’s Summer Camp? Well, here are all the projects the students did, with the titles they gave them:

It’s a very interesting, impressive, and diverse list. But let me pick out a few semi-randomly to discuss in a bit more detail. Consider these as “case studies” for what high-school students can accomplish with the Wolfram Language in a couple of weeks at a summer camp.

Routing Airplanes around Mountains

One young man at our camp had quite a lot of math background, and told me he was interested in airplanes and flying, and had designed his own remote-control plane. I started thinking about all sorts of drone survey projects. But he didn’t have a drone with him—and we had to come up with a project that could actually be done in a couple of weeks. So I ended up suggesting the following: given two points on Earth, find how an airplane can get from one to the other by the shortest path that never needs to go above a certain altitude. (And, yes, a small-scale version of this would be relevant to things like drone surveying too.)

Here’s how the student did this project. First, he realized that one could think of possible flight paths as edges on a graph whose nodes are laid out on a grid on the Earth. Then he used the built-in GeoElevationData to delete nodes that couldn’t be visited because the elevation at that point was above the cutoff. Then he just used FindShortestPath to find the shortest path in the graph from the start to the end.

I thought this was a pretty clever solution. It was a nice piece of computational thinking to realize that the elements of paths could be thought of as edges on a graph with nodes removed. Needless to say, there were some additional details to get a really good result. First, the student added in diagonal connections on the grid, with appropriate weightings to still get the correct shortest path computation. And then he refined the path by successively merging line segments to better approximate a great-circle path, at each step using computational geometry to check that the path wouldn’t go through a “too-high” region.

Finding Kiwi Calls

You never know what people are going to come to Summer Camp with. A young man from New Zealand came to our camp with some overnight audio recordings from outside his house featuring occasional periods of (quite strange-sounding) squawking that were apparently the calls of one or more kiwi birds. What the young man wanted to do was automatic “kiwi voice recognition”, finding the calls, and perhaps distinguishing different birds.

I said I thought this wouldn’t be a particularly easy project, but he should try it anyway. Looking at what happened, it’s clear the project started out well. It was easy to pull out all intervals in his audio that weren’t just silence. But that broke up everything, including kiwi calls, into very small blocks. He solved that by the following interesting piece of code, that uses pattern matching to combine symbolic audio objects:

At this point it might just have worked to use unsupervised machine learning and FeatureSpacePlot to distinguish kiwi from non-kiwi sound clips. But machine learning is still quite a hit-or-miss business—and in this case it wasn’t a hit. So what did the student do? Well, he built himself a tiny lightweight user interface in a notebook, then started manually classifying sound clips. (Various instructors commented that it was fortunate he brought headphones…)

After classifying 200 clips, he used Classify to automatically classify all the other clips. He did a variety of transformations to the data—applying signal processing, generating a spectrogram, etc. And in the end he got his kiwi classifier to 82% accuracy: enough to make a reasonable first pass on finding kiwi calls—and going down a path to computational ornithology.

Biomechanics of Walking and Running

One young woman said she’d recently gotten a stress fracture in her foot that she was told was related to the force she was putting on it while running. She asked if she could make a computational model of what was going on. I have to say I was pessimistic about being able to do that in two weeks—and I suggested instead a project that I thought would be more manageable, involving studying possible gaits (walk, trot, etc.) for creatures with different numbers of legs. But I encouraged her to spend a little time seeing if she could do her original project—and I suggested that if she got to the stage of actually modeling bones, she could use our built-in anatomical data.

The next I knew it was a day before the end of the Summer Camp, and I was looking at what had happened with the projects… and I was really impressed! She’d found a paper with an appropriate model, understood it, and implemented it, and now she had an interactive demonstration of the force on a foot during walking or running. She’d even used the anatomical data to show a 3D image of what was happening.

She explained that when one walks there are two peaks in the force, but when one runs, there’s only one. And when I set her interactive demonstration for my own daily walking regimen I found out that (as she said was typical) I put a maximum force of about twice my weight on my foot when I walk.

Banana Ripeness Classifier

At first I couldn’t tell if he was really serious… but one young man insisted he wanted to use machine learning to tell when a piece of fruit is ripe. As it happens, I had used pretty much this exact example in a blog post some time ago discussing the use of machine learning in smart contracts. So I said, “sure, why don’t you try it”. I saw the student a few times during the Summer Camp, curiously always carrying a banana. And what I discovered at the end of the camp was that that very banana was a key element of his project.

At first he searched the web for images of bananas described as “underripe”, “overripe”, etc., then arranged them using FeatureSpacePlot:

Then he realized that he could get more quantitative by first looking at where in color space the pixels of the banana image lay. The result was that he was actually able to define a “banana ripeness scale”, where, as he described it: “A value of one was assigned to bananas that were on the brink of spoilage. A value of zero was assigned to a green banana fresh off a tree. A value of 0.5 was assigned to the ‘perfect’ banana.” It’s a nice example of how something everyday and qualitative can be made computational.

For his project, the student made a “Banana Classifier” app that he deployed through the Wolfram Cloud. And he even had an actual banana to test it on!

Number Internationalization

One of my suggested projects was to implement “international or historical numeral systems”—the analogs of things like Roman numerals but for different cultures and times. One young woman fluent in Korean said she’d like to do this project, starting with Korean.

As it happens, our built-in IntegerName function converts to traditional Korean numerals. So she set herself the task of converting from Korean numerals. It’s an interesting algorithmic exercise, and she solved it with some nice, elegant code.

By that point, she was on a roll… so she decided to go on to Burmese, and Thai. She tried to figure out Burmese from web sources… only to discover they were inconsistent… with the result that she ended up contacting a person who had an educational video about Burmese numerals, and eventually unscrambled the issue, wrote code to represent it, and then corrected the Wikipedia page about Burmese numerals. All in all, a great example of real-world algorithm curation. Oh, and she set up the conversions as a Wolfram Language microsite on the web.

Is That a Joke?

Can machine learning tell if something is funny? One young man at the Summer Camp wanted to find out. So for his project he used our Reddit API connection to pull jokes from the Jokes subreddit, and (presumably) non-jokes from the AskReddit subreddit. It took a bit of cleanup and data wrangling… but then he was able to feed his training data straight into the Classify function, and generated a classifier from which he then built a

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The Philosophy of Chemicals

“We’ve just got to decide: is a chemical like a city or like a number?” I spent my day yesterday—as I have for much of the past 30 years—designing new features of the Wolfram Language. And yesterday afternoon one of my meetings was a fast-paced discussion about how to extend the chemistry capabilities of the language.

At some level the problem we were discussing was quintessentially practical. But as so often turns out to be the case for things we do, it ultimately involves some deep intellectual issues. And to actually get the right answer—and to successfully design language features that will stand the test of time—we needed to plumb those depths, and talk about things that usually wouldn’t be considered outside of some kind of philosophy seminar.

Part of the issue, of course, is that we’re dealing with things that haven’t really ever come up before. Traditional computer languages don’t try to talk directly about things like chemicals; they just deal with abstract data. But in the Wolfram Language we’re trying to build in as much knowledge about everything as possible, and that means we have to deal with actual things in the world, like chemicals.

We’ve built a whole system in the Wolfram Language for handling what we call entities. An entity could be a city (like New York City), or a movie, or a planet—or a zillion other things. An entity has some kind of name (“New York City”). And it has definite properties (like population, land area, founding date, …).

We’ve long had a notion of chemical entities—like water, or ethanol, or tungsten carbide. Each of these chemical entities has properties, like molecular mass, or structure graph, or boiling point.

And we’ve got many hundreds of thousands of chemicals where we know lots of properties. But all of these are in a sense concrete chemicals: specific compounds that we could put in a test tube and do things with.

But what we were trying to figure out yesterday is how to handle abstract chemicals—chemicals that we just abstractly construct, say by giving an abstract graph representing their chemical structures. Should these be represented by entities, like water or New York City? Or should they be considered more abstract, like lists of numbers, or, for that matter, mathematical graphs?

Well, of course, among the abstract chemicals we can construct are chemicals that we already represent by entities, like sucrose or aspirin or whatever. But here there’s an immediate distinction to make. Are we talking about individual molecules of sucrose or aspirin? Or about these things as bulk materials?

At some level it’s a confusing distinction. Because, we might think, once we know the molecular structure, we know everything—it’s just a matter of calculating it out. And some properties—like molar mass—are basically trivial to calculate from the molecular structure. But others—like melting point—are very far from trivial.

OK, but is this just a temporary problem that one shouldn’t base a long-term language design on? Or is it something more fundamental that will never change? Well, conveniently enough, I happen to have done a bunch of basic science that essentially answers this: and, yes, it’s something fundamental. It’s connected to what I call computational irreducibility. And for example, the precise value of, say, the melting point for an infinite amount of some material may actually be fundamentally uncomputable. (It’s related to the undecidability of the tiling problem; fitting in tiles is like seeing how molecules will arrange to make a solid.)

So by knowing this piece of (rather leading-edge) basic science, we know that we can meaningfully make a distinction between bulk versions of chemicals and individual molecules. Clearly there’s a close relation between, say, water molecules, and bulk water. But there’s still something fundamentally and irreducibly different about them, and about the properties we can compute for them.

At Least the Atoms Should Be OK

Alright, so let’s talk about individual molecules. Obviously they’re made of atoms. And it seems like at least when we talk about atoms, we’re on fairly solid ground. It might be reasonable to say that any given molecule always has some definite collection of atoms in it—though maybe we’ll want to consider “parametrized molecules” when we talk about polymers and the like.

But at least it seems safe to consider types of atoms as entities. After all, each type of atom corresponds to a chemical element, and there are only a limited number of those on the periodic table. Now of course in principle one can imagine additional “chemical elements”; one could even think of a neutron star as being like a giant atomic nucleus. But again, there’s a reasonable distinction to be made: almost certainly there are only a limited number of fundamentally stable types of atoms—and most of the others have ridiculously short lifetimes.

There’s an immediate footnote, however. A “chemical element” isn’t quite as definite a thing as one might imagine. Because it’s always a mixture of different isotopes. And, say, from one tungsten mine to another, that mixture might change, giving a different effective atomic mass.

And actually this is a good reason to represent types of atoms by entities. Because then one just has to have a single entity representing tungsten that one can use in talking about molecules. And only if one wants to get properties of that type of atom that depend on qualifiers like which mine it’s from does one have to deal with such things.

In a few cases (think heavy water, for example), one will need to explicitly talk about isotopes in what is essentially a chemical context. But most of the time, it’s going to be enough just to specify a chemical element.

To specify a chemical element you just have to give its atomic number Z. And then textbooks will tell you that to specify a particular isotope you just have to say how many neutrons it contains. But that ignores the unexpected case of tantalum. Because, you see, one of the naturally occurring forms of tantalum (180mTa) is actually an excited state of the tantalum nucleus, which happens to be very stable. And to properly specify this, you have to give its excitation level as well as its neutron count.

In a sense, though, quantum mechanics saves one here. Because while there are an infinite number of possible excited states of a nucleus, quantum mechanics says that all of them can be characterized just by two discrete values: spin and parity.

Every isotope—and every excited state—is different, and has its own particular properties. But the world of possible isotopes is much more orderly than, say, the world of possible animals. Because quantum mechanics says that everything in the world of isotopes can be characterized just by a limited set of discrete quantum numbers.

We’ve gone from molecules to atoms to nuclei, so why not talk about particles too? Well, it’s a bigger can of worms. Yes, there are the well-known particles like electrons and protons that are pretty easy to talk about—and are readily represented by entities in the Wolfram Language. But then there’s a zoo of other particles. Some of them—just like nuclei—are pretty easy to characterize. You can basically say things like: “it’s a particular excited state of a charm-quark-anti-charm-quark system” or some such. But in particle physics one’s dealing with quantum field theory, not just quantum mechanics. And one can’t just “count elementary particles”; one also has to deal with the possibility of virtual particles and so on. And in the end the question of what kinds of particles can exist is a very complicated one—rife with computational irreducibility. (For example, what stable states there can be of the gluon field is a much more elaborate version of something like the tiling problem I mentioned in connection with melting points.)

Maybe one day we’ll have a complete theory of fundamental physics. And maybe it’ll even be simple. But exciting as that will be, it’s not going to help much here. Because computational irreducibility means that there’s essentially an irreducible distance between what’s underneath, and what phenomena emerge.

And in creating a language to describe the world, we need to talk in terms of things that can actually be observed and computed about. We need to pay attention to the basic physics—not least so we can avoid setups that will lead to confusion later. But we also need to pay attention to the actual history of science, and actual things that have been measured. Yes, there are, for example, an infinite number of possible isotopes. But for an awful lot of purposes it’s perfectly useful just to set up entities for ones that are known.

The Space of Possible Chemicals

But is it the same in chemistry? In nuclear physics, we think we know all the reasonably stable isotopes that exist—so any additional and exotic ones will be very short-lived, and therefore probably not important in practical nuclear processes. But it’s a different story in chemistry. There are tens of millions of chemicals that people have studied (and, for example, put into papers or patents). And there’s really no limit on the molecules that one might want to consider, and that might be useful.

But, OK, so how can we refer to all these potential molecules? Well, in a first approximation we can specify their chemical structures, by giving graphs in which every node is an atom, and every edge is a bond.

What really is a “bond”? While it’s incredibly useful in practical chemistry, it’s at some level a mushy concept—some kind of semiclassical approximation to a full quantum mechanical story. There are some standard extra bits: double bonds, ionization states, etc. But in practice chemistry is very successfully done just by characterizing molecular structures by appropriately labeled graphs of atoms and bonds.

OK, but should chemicals be represented by entities, or by abstract graphs? Well, if it’s a chemical one’s already heard of, like carbon dioxide, an entity seems convenient. But what if it’s a new chemical that’s never been discussed before? Well, one could think about inventing a new entity to represent it.

Any self-respecting entity, though, better have a name. So what would the name be? Well, in the Wolfram Language, it could just be the graph that represents the structure. But maybe one wants something that seems more like an ordinary textual name—a string. Well, there’s always the IUPAC way of naming chemicals with names like 1,1′-{[3-(dimethylamino)propyl]imino}bis-2-propanol. Or there’s the more computer-friendly SMILES version: CC(CN(CCCN(C)C)CC(C)O)O. And whatever underlying graph one has, one can always generate one of these strings to represent it.

There’s an immediate problem, though: the string isn’t unique. In fact, however one chooses to write down the graph, it can’t always be unique. A particular chemical structure corresponds to a particular graph. But there can be many ways to draw the graph—and many different representations for it. And in fact even the (“graph isomorphism”) problem of determining whether two representations correspond to the same graph can be difficult to solve.

What Is a Chemical in the End?

OK, so let’s imagine we represent a chemical structure by a graph. At first, it’s an abstract thing. There are atoms as nodes in the graph, but we don’t know how they’d be arranged in an actual molecule (and e.g. how many angstroms apart they’d be). Of course, the answer isn’t completely well defined. Are we talking about the lowest-energy configuration of the molecule? (What if there are multiple configurations of the same energy?) Is the molecule supposed to be on its own, or in water, or whatever? How was the molecule supposed to have been made? (Maybe it’s a protein that folded a particular way when it came off the ribosome.)

Well, if we just had an entity representing, say, “naturally occurring hemoglobin”, maybe we’d be better off. Because in a sense that entity could encapsulate all these details.

But if we want to talk about chemicals that have never actually been synthesized it’s a bit of a different story. And it feels as if we’d be better off just with an abstract representation of any possible chemical.

But let’s talk about some other cases, and analogies. Maybe we should just treat everything as an entity. Like every integer could be an entity. Yes, there are an infinite number of them. But at least it’s clear what names they should be given. With real numbers, things are already messier. For example, there’s no longer the same kind of uniqueness as with integers: 0.99999… is really the same as 1.00000…, but it’s written differently.

What about sequences of integers, or, for that matter, mathematical formulas? Well, every possible sequence or every possible formula could conceivably be a different entity. But this wouldn’t be particularly useful, because much of what one wants to do with sequences or formulas is to go inside them, and transform their structure. But what’s convenient about entities is that they’re each just “single things” that one doesn’t have to “go inside”.

So what’s the story with “abstract chemicals”? It’s going to be a mixture. But certainly one’s going to want to “go inside” and transform the structure. Which argues for representing the chemical by a graph.

But then there’s potentially a nasty discontinuity. We’ve got the entity of carbon dioxide, which we already know lots of properties about. And then we’ve got this graph that abstractly represents the carbon dioxide molecule.

We might worry that this would be confusing both to humans and programs. But the first thing to realize is that we can distinguish what these two things are representing. The entity represents the bulk naturally occurring version of the chemical—whose properties have potentially been measured. The graph represents an abstract theoretical chemical, whose properties would have to be computed.

But obviously there’s got to be a bridge. Given a concrete chemical entity, one of the properties will be the graph that represents the structure of the molecule. And given a graph, one will need some kind of ChemicalIdentify function, that—a bit like GeoIdentify or maybe ImageIdentify—tries to identify from the graph what chemical entity (if any) has a molecular structure that corresponds to that graph.

Philosophy Meets Chemistry Meets Math Meets Physics…

As I write out some of the issues, I realize how complicated all this may seem. And, yes, it is complicated. But in our meeting yesterday, it all went very quickly. Of course it helps that everyone there had seen similar issues before: this is the kind of thing that’s all over the foundations of what we do. But each case is different.

And somehow this case got a bit deeper and more philosophical than usual. “Let’s talk about naming stars”, someone said. Obviously there are nearby stars that we have explicit names for. And some other stars may have been identified in large-scale sky surveys, and given identifiers of some kind. But there are lots of stars in distant galaxies that will never have been named. So how should we represent them?

That led to talking about cities. Yes, there are definite, chartered cities that have officially been assigned names–and we probably have essentially all of these right now in the Wolfram Language, updated regularly. But what about some village that’s created for a single season by some nomadic people? How should we represent it? Well, it has a certain location, at least for a while. But is it even a definite single thing, or might it, say, devolve into two villages, or not a village at all?

One can argue almost endlessly about identity—and even existence—for many of these things. But ultimately it’s not the philosophy of such things that we’re interested in: we’re trying to build software that people will find useful. And so what matters in the end is what’s going to be useful.

Now of course that’s not a precise thing to know. But it’s like for language design in general: think of everything people might want to do, then see how to set up primitives that will let people do those things. Does one want some chemicals represented by entities? Yes, that’s useful. Does one want a way to represent arbitrary chemical structures by graphs? Yes, that’s useful.

But to see what to actually do, one has to understand quite deeply what’s really being represented in each case, and how everything is related. And that’s where the philosophy has to meet the chemistry, and the math, and the physics, and so on.

I’m happy to say that by the end of our hour-long meeting yesterday (informed by about 40 years of relevant experience I’ve had, and collectively 100+ years from people in the meeting), I think we’d come up with the essence of a really nice way to handle chemicals and chemical structures. It’s going to be a while before it’s all fully worked out and implemented in the Wolfram Language. But the ideas are going to help inform the way we compute and reason about chemistry for many years to come. And for me, figuring out things like this is an extremely satisfying way to spend my time. And I’m just glad that in my long-running effort to advance the Wolfram Language I get to do so much of it.

Read Full Article
Visit website
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
A British Train Station

A week ago a new train station, named “Cambridge North”, opened in Cambridge, UK.  Normally such an event would be far outside my sphere of awareness. (I think I last took a train to Cambridge in 1975.)  But last week people started sending me pictures of the new train station, wondering if I could identify the pattern on it:

And, yes, it does indeed look a lot like patterns I’ve spent years studying—that come from simple programs in the computational universe.  My first—and still favorite—examples of simple programs are one-dimensional cellular automata like this:

The system evolves line by line from the top, determining the color of each cell according to the rule underneath.  This particular cellular automata I called “rule 182”, because the bit pattern in the rule corresponds to the number 182 in binary.  There are altogether 256 possible cellular automata like this, and this is what all of them do:

Many of them show fairly simple behavior.  But the huge surprise I got when I first ran all these cellular automata in the early 1980s is that even though all the rules are very simple to state, some of them generate very complex behavior.  The first in the list that does that—and still my favorite example—is rule 30:

If one runs it for 400 steps one gets this:

And, yes, it’s remarkable that starting from one black cell at the top, and just repeatedly following a simple rule, it’s possible to get all this complexity.  I think it’s actually an example of a hugely important phenomenon, that’s central to how complexity gets made in nature, as well as to how we can get a new level of technology.  And in fact, I think it’s important enough that I spent more than a decade writing a 1200-page book (that just celebrated its 15th anniversary) based on it.

And for years I’ve actually had rule 30 on my business cards:

But back to the Cambridge North train station.  Its pattern is obviously not completely random.  But if it was made by a rule, what kind of rule?  Could it be a cellular automaton?

I zoomed in on a photograph of the pattern:

Suddenly, something seemed awfully familiar: the triangles, the stripes, the L shapes.  Wait a minute…it couldn’t actually be my favorite rule of all time, rule 30?

Clearly the pattern is tipped 45° from how I’d usually display a cellular automaton.  And there are black triangles in the photograph, not white ones like in rule 30. But if one black-white inverts the rule (so it’s now rule 135), one gets this:

And, yes, it’s the same kind of pattern as in the photograph!  But if it’s rule 30 (or rule 135) what’s its initial condition?  Rule 30 can actually be used as a cryptosystem—because it can be hard (maybe even NP complete) to reconstruct its initial condition.

But, OK, if it’s my favorite rule, I wondered if maybe it’s also my favorite initial condition—a single black cell.  And, yes, it is!  The train station pattern comes exactly from the (inverted) right-hand edge of my favorite rule 30 pattern!

Here’s the Wolfram Language code.  First run the cellular automaton, then rotate the pattern:

It’s a little trickier to pull out precisely the section of the pattern that’s used. Here’s the code (the PlotRange is what determines the part of the pattern that’s shown):

OK, so where is this pattern actually used at the train station?  Everywhere!

It’s made of perforated aluminum.  You can actually look through it, reminiscent of an old latticed window.  From inside, the pattern is left-right reversed—so if it’s rule 135 from outside, it’s rule 149 from inside.  And at night, the pattern is black-white inverted,  because there’s light coming from inside—so from the outside it’s “rule 135 by day, and rule 30 at night”.

What are some facts about the rule 30 pattern?  It’s extremely hard to rigorously prove things about it (and that’s interesting in itself—and closely related to the fundamental phenomenon of computational irreducibility).  But, for example—like, say, the digits of π—many aspects of it seem random.  And, for instance, black and white squares appear to occur with equal frequency—meaning that at the train station the panels let in about 50% of the outside light.

If one looks at sequences of n cells, it seems that all 2n configurations will occur on average with equal frequency.  But not everything is random.  And so, for example, if one looks at 3×2 blocks of cells, only 24 of the 32 possible ones ever occur.  (Maybe some people waiting for trains will figure out which blocks are missing…)

When we look at the pattern, our visual system particularly picks out the black triangles.  And, yes, it seems as if triangles of any size can ultimately occur, albeit with frequency decreasing exponentially with size.

If one looks carefully at the right-hand edge of the rule 30 pattern, one can see that it repeats.  However, the repetition period seems to increase exponentially as one goes in from the edge.

At the train station, there are lots of identical panels.  But rule 30 is actually an inexhaustible source of new patterns.  So what would happen if one just continued the evolution, and rendered it on successive panels?  Here’s the result.  It’s a pity about the hint of periodicity on the right-hand edge, and the big triangle on panel 5 (which might be a safety problem at the train station).

Fifteen more steps in from the edge, there’s no hint of that anymore:

What about other initial conditions?  If the initial conditions repeat, then so will the pattern.  But otherwise, so far as one can tell, the pattern will look essentially the same as with a single-cell initial condition.

One can try other rules too.  Here are a few from the same simplest 256-rule set as rule 30:

Moving deeper from the edge the results look a little different (for aficionados, rule 89 is a transformed version of rule 45, rule 182 of rule 90, and rule 193 of rule 110):

And starting from random initial conditions, rather than a single black cell, things again look different:

And here are a few more rules, started from random initial conditions:

Here’s a website (made in a couple of minutes with a tiny piece of Wolfram Language code) that lets you experiment (including with larger rule numbers, based on longer-range rules). (And if you want to explore more systematically, here’s a Wolfram Notebook to try.)

It’s amazing what’s out there in the computational universe of possible programs.  There’s an infinite range of possible patterns.  But it’s cool that the Cambridge North train station uses my all-time favorite discovery in the computational universe—rule 30!  And it looks great!

The Bigger Picture

There’s something curiously timeless about algorithmically generated forms.  A dodecahedron from ancient Egypt still looks crisp and modern today.  As do periodic tilings—or nested forms—even from centuries ago:

But can one generate richer forms algorithmically?  Before I discovered rule 30, I’d always assumed that any form generated from simple rules would always somehow end up being obviously simple.  But rule 30 was a big shock to my intuition—and from it I realized that actually in the computational universe of all possible rules, it’s actually very easy to get rich and complex behavior, even from simple underlying rules.

And what’s more, the patterns that are generated often have remarkable visual interest.  Here are a few produced by cellular automata (now with 3 possible colors for each cell, rather than 2):

There’s an amazing diversity of forms.  And, yes, they’re often complicated.  But because they’re based on simple underlying rules, they always have a certain logic to them: in a sense each of them tells a definite “algorithmic story”.

One thing that’s notable about forms we see in the computational universe is that they often look a lot like forms we see in nature.  And I don’t think that’s a coincidence.  Instead, I think what’s going on is that rules in the computational universe capture the essence of laws that govern lots of systems in nature—whether in physics, biology or wherever.   And maybe there’s a certain familiarity or comfort associated with forms in the computational universe that comes from their similarity to forms we’re used to in nature.

But is what we get from the computational universe art?  When we pick out something like rule 30 for a particular purpose, what we’re doing is conceptually a bit like photography: we’re not creating the underlying forms, but we are selecting the ones we choose to use.

In the computational universe, though, we can be more systematic.  Given some aesthetic criterion, we can automatically search through perhaps even millions or billions of possible rules to find optimal ones: in a sense automatically “discovering art” in the computational universe.

We did an experiment on this for music back in 2007: WolframTones.  And what’s remarkable is that even by sampling fairly small numbers of rules (cellular automata, as it happens), we’re able to produce all sorts of interesting short pieces of music—that often seem remarkably “creative” and “inventive”.

From a practical point of view, automatic discovery in the computational universe is important because it allows for mass customization.  It makes it easy to be “original” (and “creative”)—and to find something different every time, or to fit constraints that have never been seen before (say, a pattern in a complicated geometric region).

The Cambridge North train station uses a particular rule from the computational universe to make what amounts to an ornamental pattern.  But one can also use rules from the computational universe for other things in architecture.  And one can even imagine a building in which everything—from overall massing down to details of moldings—is completely determined by something close to a single rule.

One might assume that such a building would somehow be minimalist and sterile.  But the remarkable fact is that this doesn’t have to be true—and that instead there are plenty of rich, almost “organic” forms to be “mined” from the computational universe.

Ever since I started writing about one-dimensional cellular automata back in the early 1980s, there’s been all sorts of interesting art done with them.  Lots of different rules have been used.  Sometimes they’ve been what I called “class 4” rules that have a particularly organic look.  But often it’s been other rules—and rule 30 has certainly made its share of appearances—whether it’s on floors, shirts, tea cosies, kinetic installations,  or, recently, mass-customized scarves (with the knitting machine actually running the cellular automaton):

But today we’re celebrating a new and different manifestation of rule 30. Formed from permanent aluminum panels, in an ancient university town, a marvellous corner of the computational universe adorns one of the most practical of structures: a small train station. My compliments to the architects. May what they’ve made give generations of rail travelers a little glimpse of the wonders of the computational universe. And maybe perhaps a few, echoing the last words attributed to the traveler in the movie 2001: A Space Odyssey, exclaim “oh my gosh, it’s covered in rule 30s!”

(Thanks to Wolfram Summer School alum Alyssa Adams for sending us the photos of Cambridge North.)

Read Full Article
Visit website

Read for later

Articles marked as Favorite are saved for later viewing.
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free year
Free Preview