May 22, 2013 — Jon McLoone, International Business & Strategic Development

The benefits of linking from *Mathematica* to other languages and tools differ from case to case. But unusually, in the case of the new *RLink* in *Mathematica* 9, I think the benefits have very little to do with R, the language. The real benefit, I believe, is in the connection it makes to the R community.

When we first added the *MathLink* libraries for C, there were real benefits in farming out intensive numerical work (though *Mathematica* performance improvements over the years and development of the compiler have greatly reduced the occasions where that would be worth the effort). Creating an Excel link added an alternative interface paradigm to *Mathematica* that wasn’t available in the *Mathematica* front end. But in the case of R, it isn’t immediately obvious that it does many things that you can’t already do in *Mathematica* or many that it does significantly better.

However, with *RLink* I now have immediate access to the work of the R community through the add-on libraries that they have created to extend R into their field. A great zoo of these free libraries fill out thousands of niches–sometimes popular, sometimes obscure–but lots of them. There are over 4,000 right here and more elsewhere. At a stroke, all of them are made immediately available to the *Mathematica* environment, interpreted through the R language runtime.

May 9, 2013 — Matthias Odisio, Mathematica Algorithm R&D

Detecting skin in images can be quite useful: it is one of the primary steps for various sophisticated systems aimed at detecting people, recognizing gestures, detecting faces, content-based filtering, and more. In spite of this host of applications, when I decided to develop a skin detector, my main motivation lay elsewhere. The research and development department I work in at Wolfram Research just underwent a gentle reorganization. With my colleagues who work on probability and statistics becoming closer neighbors, I felt like developing a small application that would make use of both *Mathematica*‘s image processing and statistics features; skin detection just came to my mind.

Skin tones and appearances vary, and so do flavors of skin detectors. The detector I wanted to develop is based on probabilistic models of pixel colors. For each pixel of an image given as input, the skin detector provides a probability that the pixel color belongs to a skin region.

April 24, 2013 — Stephen Wolfram

More than a million people have now used our Wolfram|Alpha Personal Analytics for Facebook. And as part of our latest update, in addition to collecting some anonymized statistics, we launched a Data Donor program that allows people to contribute detailed data to us for research purposes.

A few weeks ago we decided to start analyzing all this data. And I have to say that if nothing else it’s been a terrific example of the power of *Mathematica* and the Wolfram Language for doing data science. (It’ll also be good fodder for the Data Science course I’m starting to create.)

We’d always planned to use the data we collect to enhance our Personal Analytics system. But I couldn’t resist also trying to do some basic science with it.

I’ve always been interested in people and the trajectories of their lives. But I’ve never been able to combine that with my interest in science. Until now. And it’s been quite a thrill over the past few weeks to see the results we’ve been able to get. Sometimes confirming impressions I’ve had; sometimes showing things I never would have guessed. And all along reminding me of phenomena I’ve studied scientifically in *A New Kind of Science*.

So what does the data look like? Here are the social networks of a few Data Donors—with clusters of friends given different colors. (Anyone can find their own network using Wolfram|Alpha—or the `SocialMediaData`

function in *Mathematica*.)

March 5, 2013 — Wolfram Blog Team

Using *Mathematica* and other Wolfram technologies, Joseph Hirl, founder of Agilis Energy, has developed a new approach to energy analytics that is helping building owners and energy equipment suppliers around the world cut energy consumption and costs.

At the core of the company’s success is its *Mathematica*-based dynamic energy analysis application, which gives the full picture of a building’s performance, measures the impact of potential operational changes, and quantifies the results. About *Mathematica*‘s role in the development of the tool and the Agilis business, Hirl says, “The flexibility of *Mathematica* is tremendous. Our ability to build and develop this program with a lean staff has allowed us to build out a substantial business.”

The application, which has now been used at more than 800 sites in at least 12 different industries, begins with data streams, including high-interval smart meter data as well as *Mathematica*‘s built-in `WeatherData`. It then applies sophisticated statistics and dynamic visualization functionality to generate what Hirl calls an “MRI of a building,” a dynamic interface with a simulation of the building’s energy use and demand and forecasting and benchmarking tools.

February 4, 2013 — Oleksandr Pavlyk, Manager of Probability and Statistics, Mathematica Algorithm R&D

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.