February 4, 2013 — Oleksandr Pavlyk, Kernel Technology

On January 23, 1913 of the Julian calendar, Andrey A. Markov presented for the Royal Academy of Sciences in St. Petersburg his analysis of Pushkin’s *Eugene Onegin*. He found that the sequence of consonants and vowels in the text could be well described as a random sequence, where the likely category of a letter depended only on the category of the previous or previous two letters.

At the time, the Russian Empire was using the Julian calendar. The 100th anniversary of the celebrated presentation is actually February 5, 2013, in the now used Gregorian calendar.

To perform his analysis, Markov invented what are now known as “Markov chains,” which can be represented as probabilistic state diagrams where the transitions between states are labeled with the probabilities of their occurrences.

January 8, 2013 — Jeffrey Bryant, Scientific Information Group

The physics involved in simulating galaxy collisions can be extremely complex. The most accurate simulations take into account not just points representing stars, but also magnetic fields and invisible dark matter, as well as *n*-body interactions allowing the individual stars to interact with each other. These complex simulations are usually carried out on large-scale supercomputers over long periods of time. One of the more interesting aspects of galaxy collisions is that they can create density variations resulting in all kinds of emergent structure. Density waves can develop that lead to star formation from compressed gas clouds.

A couple of years ago, I wrote a Demonstration that provides a simplified solution to galaxy collisions. This Demonstration is designed to run in real time inside a `Manipulate`, so the problem has been simplified by removing *n*-body interactions, dark matter, magnetic fields, and so on. Basically, it treats the two galaxies as large point masses with lots of massless test particles orbiting them. The test particles respond only to the two galaxy “centers.” In a real galaxy collision, the chances of two stars getting close enough to each other to interact directly is very remote, so it’s not too far of a stretch to ignore this effect for a first-order approximation. The more stars that are included in the simulation (by minimizing the star separation parameter), the more intricate the results (and the more computationally intense). In fact, as more stars are added, it becomes easier to see density variations where many test masses cluster together, but it still looks very discrete. Real galaxies, like the Milky Way, can have hundreds of billions of stars. Trying to carry out a point simulation with that many stars becomes a bit taxing on most home systems, and definitely exceeds the time constraints of a real-time dynamic tool like `Manipulate`. So how can we better visualize these density variations? I decided to try to modify my Demonstration to use one of the new features in *Mathematica* 9, namely volumetric rendering. This way, we can simulate the galaxy collisions with fewer numbers of points, but render the results as if there were billions of stars, resulting in a more realistic and informative visualization.

December 6, 2012 — Stephen Wolfram

There aren’t very many qualitatively different types of computer interfaces in use in the world today. But with the release of *Mathematica* 9 I think we have the first truly practical example of a new kind—the computed predictive interface.

If one’s dealing with a system that has a small fixed set of possible actions or inputs, one can typically build an interface out of elements like menus or forms. But if one has a more open-ended system, one typically has to define some kind of language. Usually this will be basically textual (as it is for the most part for *Mathematica*); sometimes it may be visual (as for Wolfram *SystemModeler*).

The challenge is then to make the language broad and powerful, while keeping it as easy as possible for humans to write and understand. And as a committed computer language designer for the past 30+ years, I have devoted an immense amount of effort to this.

But with Wolfram|Alpha I had a different idea. Don’t try to define the best possible artificial computer language, that humans then have to learn. Instead, use natural language, just like humans do among themselves, and then have the computer do its best to understand this. At first, it was not at all clear that such an approach was going to work. But one of the big things we’ve learned from Wolfram|Alpha is with enough effort (and enough built-in knowledge), it can. And indeed two years ago in *Mathematica* 8 we used what we’d done with Wolfram|Alpha to add to *Mathematica* the capability of taking free-form natural language input, and automatically generating from it precise *Mathematica* language code.

But let’s say one’s just got some output from *Mathematica*. What should one do next? One may know the appropriate *Mathematica* language input to give. Or at least one may be able to express what one wants to do in free-form natural language. But in both cases there’s a kind of creative act required: starting from nothing one has figure out what to say.

So can we make this easier? The answer, I think, is yes. And that’s what we’ve now done with the Predictive Interface in *Mathematica* 9.

The concept of the Predictive Interface is to take what you’ve done so far, and from it predict a few possibilities for what you’re likely to want to do next.

November 14, 2012 — Jon McLoone, International Business & Strategic Development

*Update: See our latest post on How the Wolfram Language Measures Up.*

I stumbled upon a nice project called Rosetta Code. Their stated aim is “to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another.”

After amusing myself by contributing a few solutions (Flood filling, Mean angle, and Sum digits of an integer being some of mine), I realized that the data hidden in the site provided an opportunity to quantify a claim that I have often made over the years—that *Mathematica* code tends to be shorter than equivalent code in other languages. This is due to both its high-level nature and built-in computational knowledge.

Here is what I found.

*Mathematica* code is typically less than a third of the length of the same tasks written in other languages, and often much better.

October 24, 2012 — Jason Martinez, Research Programmer

Earlier this month, on a nice day, Felix Baumgartner jumped from 39,045 meters, or 24.26 miles, above the Earth from a capsule lifted by a 334-foot-tall helium filled balloon (twice the height of Nelson’s column and 2.5 times the diameter of the Hindenberg). Wolfram|Alpha tells us the jump was equivalent to a fall from 4.4 Mount Everests stacked on top of each other, or falling 93% of the length of a marathon.

At 24.26 miles above the Earth, the atmosphere is very thin and cold, only about -14 degrees Fahrenheit on average. The temperature, unlike air pressure, does not change linearly with altitude at such heights. As Wolfram|Alpha shows us, it rises and falls depending on factors such as the decreased density of air with rising altitude, but also the absorption of UV light by the ozone layer.

At 39 kilometers, the horizon is roughly 439 miles away. At this layer of the atmosphere, called the stratosphere, the air pressure is only 3.3 millibars, equivalent to 0.33% of the air pressure at sea level. To put it another way, the mass of the air above 39 kilometers is only 0.32851% of the total air mass. Given this knowledge, we know that 99.67% of the world’s atmosphere lay beneath him. This information was important to Felix’s goal to break the sound barrier in free fall because the rate of drag is directly related to air pressure. With less air around him, there would be less drag, and thus he could reach a higher maximum speed. Of course, this would require him to wear an oxygenated suit to allow him to breathe, in addition to keeping him warm.

August 29, 2012 — William Sehorn, Software Technology

In Stephen Wolfram’s personal analytics blog post, he showed a number of interesting plots of the steps he’s recorded on his pedometer over the past two years. Each plot highlighted a different feature of his activity. For example, this daily step distribution makes it clear that Stephen is typically most physically active around noon:

In this blog post I’ll show you how to analyze your own pedometer data and make cool plots like Stephen’s. If you don’t have any data, you can use the attached sample data that corresponds to my own physical activity.

First we need to import the data and format it appropriately.

The data is formatted as pairs of time stamps and step counts in five-minute intervals.

June 14, 2012 — Paul-Jean Letourneau, Senior Data Scientist, Wolfram Research

Wouldn’t it be cool if you never had to remember another password again?

I read an article in *The New York Times* recently about using individual typing styles to identify people. A computer could authenticate you based on how you type your user name without ever requiring you to type a password.

To continue our series of posts about personal analytics, I want to show you how you can do a detailed analysis of your own typing style just by using *Mathematica*!

Here’s a fun little application that analyzes the way you type the word “wolfram.” It’s an embedded Computable Document Format (CDF) file, so you can try it out right here in your browser. Type “wolfram” into the input field and click the “save” button (or just press “Enter” on your keyboard). A bunch of charts will appear showing the time interval between each successive pair of characters you typed: w–o, o–l, l–f, f–r, r–a, and a–m. Do several trials: type “wolfram,” click “save,” rinse, and repeat (if you make a typo, that trial will just be ignored).

May 1, 2012 — Carlo Barbieri, Applied Research Group

In spring 2011, while adding the finishing touches to my PhD dissertation, I decided to enroll in the Wolfram Science Summer School (then called the NKS Summer School). I never suspected that my project at the Summer School would lead to a job and my involvement in one of the central features of Wolfram|Alpha Pro.

During my years as a graduate student I had the chance to live in three different countries and experience different working environments: other than my native Italy, I lived in Paris, where my PhD was based at ENS, and in Princeton, where I was lucky enough to spend time at the Institute for Advanced Study. However, at the end of my PhD, I felt that most of my interest in what I was doing was gone and that I needed to try something new.

Once at the Summer School, I had the chance to meet and chat with Stephen Wolfram as he helped me come up with a problem to work on. One of the first things I told him was that I was weary of open-ended academic kinds of problems and I was afraid no one was ever going to read my papers. I said that I wanted to deal with intellectual challenges, but I also wanted to tackle something that had a clear beginning and end.

His reply came as a disappointment, since what he suggested I work on was both completely outside my area of expertise and clearly one of those impossibly wide problems that I was now skeptical of. What did he say?

April 5, 2012 — Paul-Jean Letourneau, Senior Data Scientist, Wolfram Research

In Stephen Wolfram’s recent blog post about personal analytics, he showed a number of plots generated by analyzing his archive of personal data. One of the most common pieces of feedback we received was that people wanted to know how they could perform the same kind of analysis on their own data. So in this blog post I’m going to show you how to analyze your email the same way Stephen Wolfram did.

Naturally, we did all the data cleaning and analysis for Stephen’s data in *Mathematica*, so we’ll be using *Mathematica* for everything here as well. All the code can be downloaded here.

Let’s start with that really cool diurnal plot Stephen did of his outgoing email. This plot shows the date and time each email was sent, with years running along the *x* axis and times of day on the *y* axis:

February 9, 2012 — Stephen Wolfram

It’s a sad but true fact that most data that’s generated or collected—even with considerable effort—never gets any kind of serious analysis. But in a sense that’s not surprising. Because doing data science has always been hard. And even expert data scientists usually have to spend lots of time wrangling code and data to do any particular analysis.

I myself have been using computers to work with data for more than a third of a century. And over that time my tools and methods have gradually evolved. But this week—with the release of Wolfram|Alpha Pro—something dramatic has happened, that will forever change the way I approach data.

The key idea is automation. The concept in Wolfram|Alpha Pro is that I should just be able to take my data in whatever raw form it arrives, and throw it into Wolfram|Alpha Pro. And then Wolfram|Alpha Pro should automatically do a whole bunch of analysis, and then give me a well-organized report about my data. And if my data isn’t too large, this should all happen in a few seconds.

And what’s amazing to me is that it actually works. I’ve got all kinds of data lying around: measurements, business reports, personal analytics, whatever. And I’ve been feeding it into Wolfram|Alpha Pro. And Wolfram|Alpha Pro has been showing me visualizations and coming up with analyses that tell me all kinds of useful things about the data.