Next month, Guinness World Records will officially celebrate its 60th anniversary as the leading authority on “record-breaking achievement.” A long-cherished favorite for holiday gifting and the coffee table, Guinness World Records not only provides a unique collection of knowledge but also encourages people to challenge the application of those facts. That’s not limited to the public, either; GWR itself holds the record for best-selling annual publication, a record set in 2013 that has yet to be overthrown.

As it’s their diamond anniversary, and such things should be commemorated, we wanted to join in with some unique, Wolfram|Alpha knowledge fun. We can tell you what the world’s largest cut diamond is or who currently holds the title of fastest human; we can even put some of these records to the test.

Looks like Superman will have to hold onto the record of “faster than a speeding bullet” for a little while longer.

Guinness tells us that the largest living tree is Hyperion, a redwood in California, and that the tallest living man is Sultan Kösen. How many Sultans would we need to reach the top of Hyperion?

Ever wondered how old the longest-lived animal was? Her name was Ming, and she was a mollusc (bet you thought it would be a tortoise!).

How about something more data driven? What is the most frequent word in the longest text, the Holy Bible (KJV)?

“The”—shocking. Maybe that’s too pedestrian. In this space age when Pluto can send love across the galaxy (who knew the planet had such a big heart?), maybe we should be taking our records to the stars. What if Javier Sotomayor took his 82kg self and high jumped on the moon?

It may be purely hypothetical, but at six times higher than the 1993 record of 2.45m, it would certainly be a giant leap for mankind! Perhaps Guinness should consider taking their 60th anniversary edition out of this world to continue inspiring all of us to dream bigger and reach higher.

]]>Are you familiar with the Reddit 60-second button? The Reddit experiment was a countdown that would vanish if it ever reached zero. Clicking a button gave the countdown another 60 seconds. One Community post brings Wolfram Language visualization and analysis to Reddit’s experiment, which has sparked questions spanning game theory, community psychology, and statistics. David Gathercole started by importing a dataset from April 3 to May 20 into *Mathematica* and charted some interesting findings. See what he discovered and contribute your own ideas.

Frank Kampas solved a *New York Times* 4×4 KENKEN using the Wolfram Language, and others offered suggestions for making that code even faster. One Community member wondered if the puzzle itself could be automatically and randomly generated to make a complete Demonstrations Project app. Do you have a solution for solving 6×6 grids? You can chime in here.

Alfonso Garcia-Parrado used the Wolfram Language with Raspberry Pi and the GSM module SIM908 to build a geo-location device with just a few lines of code. Check out his explanation to give it a try for yourself, or browse other topics related to Raspberry Pi and connected devices.

Inspired by the TED talk “Why City Flags May Be the Worst-Designed Thing You’ve Never Noticed,” Bernat Espigulé Pons sorted the flags of every country into similar groups, showing how simplistic designs increase the odds of duplicating flags. Browse the images for a peek at the similarities among country flags and snag the similarity graph of flags in CDF format.

Join Wolfram Community today to explore these and other topics, share the projects you’re working on, and collaborate with other Wolfram technology enthusiasts.

]]>`MailReceiverFunction` is a Wolfram Language function that I deploy to the cloud to operate on incoming emails. When I deploy a function, I get an email address. Emails sent to that address will be processed by the function.

For example, I have a neighborhood mailing list that people use for all sorts of things like missing cats, plumber recommendations, and furniture for sale. Recently, I was in the market for a new dining room table. Here is an example of a `MailReceiverFunction` that checks if incoming mail mentions a table, and if so, sends a second email to my Wolfram ID:

Now I can subscribe to the mailing list as “receiver+5DHCTKhQ@wolframcloud.com,” and I will only receive messages about tables. But I can do better. Why not search messages for the price and create a log with the information I want? The function `func` below will run in my Wolfram Cloud account every time the mail receiver address receives an email:

After some emails have been sent, I can retrieve the log by reading the log file in my Wolfram Cloud account.

Retrieving the data as a `Dataset` makes all sorts of sophisticated queries possible. Here, for example, are pictures of the tables that are under $200:

I’ve also had some fun using mail receivers as an address for receiving promotional emails. I made this one that creates a word cloud from incoming emails. When I come to a website that asks for an email address and I know I don’t want to be on their mailing list, I use this mail receiver instead. It’s usually not too hard to guess the source of the promotion.

Any Wolfram Language function can be used inside a mail receiver, so these examples are just a taste of what’s possible. I still spend plenty of time manually working my way through emails, but now as I read each message, I think about what a `MailReceiverFunction` could do with it instead.

`MailReceiverFunction` is supported in Version 10.2 of the Wolfram Language and *Mathematica*, and is rolling out soon in all other Wolfram products.

Download this post as a Computable Document Format (CDF) file.

Twenty-nine French students and three teachers traveled across the English Channel to attend the school, which drew scholars from the Créteil and the Nice and Versailles academies, as well as the Lycée d’Altitude de Briançon. The summer school was a result of the partnership between Wolfram, the three academies, and the INRIA Mediterranean Research Center.

Most of the students were among the best achievers at this year’s regional Mathematics Olympiads in France, and five of the Briançon scholars were supported by the MATh.en.JEANS program.

Wolfram lent the students the top floor of its offices for the duration of the school, and on day one they discovered the power and possibility of *Mathematica* for scientific calculation. They spent day two getting familiar with the tool through practical exercises, learning basic syntax, how to program in it, and how to use the comprehensive online help resources.

The rest of the course focused on a scientific journey through particular themes in mathematics and computer science. These took place in groups of two or three students, under supervision by experts.

On the mathematical front, the students were asked to learn new concepts, understand them via practical experimentation, and then illustrate them by producing interactive teaching applications. Two-dimensional parametric curves and fractal geometric structures were among the interesting projects the students came up with.

Where computer science was concerned, students created algorithms and understood them through implementation, making them work with practical applications. Some worked on classical methods of constraint programming (such as filtering, global search, and backtracking) to solve Sudoku puzzles, while others worked on coding/decoding text or steganography techniques that allow one image to be hidden inside another.

Other groups tried out a few tricks with classic board games like Connect Four, Oware, and Hex (the late John Nash was one of its inventors), targeting machine management of the games, automation of play, and developing/implementing strategies.

Another group set about solving mathematical challenges on the Project Euler website, and conquered more than 15 of them.

The students also attended technical presentations given by Wolfram developers who discussed their daily work and projects. Alec Titterton showed the learners the Computer-Based Math (CBM) educational system, Gerli Jõgeva described how CBM lessons are made, and Abdul Dakkak spoke about image technology. Anthony Zupnik gave additional talks on cloud computing and machine learning.

There was plenty of time for fun and culture after each day’s learning was done. We took several trips to Oxford, which included a visit to university sites like Balliol College and the Bridge of Sighs, the Oxford University Museum of Natural History, and the Pitt Rivers Museum. And speaking of rivers, the students also tried a spot of punting—a traditional Oxford pastime—on the Cherwell. There was also an excursion to the historic little town of Woodstock and nearby Blenheim Palace, former residence of Winston Churchill.

Soundbites from the students’ return home with their certificates included such lines as “a super experience,” “an exciting course,” and “too short a stay.” As for the education, the warmth of the group, and the kindness of their host families, everyone had only good things to say!

The Wolfram Language Summer School Oxford was an outstanding success, and we’re already hoping to repeat it in years to come!

]]>

The ISO specification also provides some alternative date representations, such as week dates (year, week of year, and day of week) and ordinal dates (year and day of year):

In addition to the ISO-8601 formats, we’ve added two new numerical representations of time to the Wolfram Language, `UnixTime`, which gives the number of seconds since January 1, 1970, 00:00:00 UTC, and `JulianDate`, which gives the number of days since November 24, 4714 BCE, 12:00:00 UTC:

`UnixTime` is a variation of `AbsoluteTime`, which gives the number of seconds since January 1, 1900, 00:00:00 in your local time zone; however, one important difference is that the output time zone is always in Coordinated Universal Time (UTC), which is one reason it’s frequently used for time stamps. `FromUnixTime` takes a `UnixTime` value and returns a corresponding `DateObject`:

`JulianDate` is frequently used in astronomical calculations, such as in the following approximation of `SiderealTime`:

The Wolfram Language has a built-in (higher resolution) `SiderealTime` function, which I can compare with the approximation above:

`JulianDate` can also be useful in representing many simple calendar systems, such as the Egyptian solar calendar, which has 365 days in every year, twelve 30-day months (plus one 5-day month), and no leap years. You can use the following function to get an Egyptian calendar date (which uses February 18, 747 BCE as its epoch date):

As a quick sanity check, I’ll put in the epoch date to verify I’m getting the correct results:

And the inverse operation is simple: just add the years, months, and days to the epoch, and `FromJulianDate` constructs an appropriate `DateObject` expression:

Once again I can verify our formula by using the calendar epoch:

And I can do the same with a more recent date, such as `Today`:

This works with any representation of dates in the Wolfram Language:

These are just some of the uses for the new date and time features in the Wolfram Language. Once available, share your examples through Wolfram Tweet-a-Program or Wolfram Community! Stay tuned!

]]>

A Primer of NMR Theory with Calculations in *Mathematica*

This text, written by Alan J. Benesi, presents the theory of NMR enhanced with *Mathematica* notebooks in short, focused chapters with brief explanations of well-defined topics, placing an emphasis on mathematical descriptions. Readers will find essential results from quantum mechanics that are concise and easy to use in predicting and simulating the results of NMR experiments. *Mathematica* notebooks implement the theory in the form of text, graphics, sound, and calculations. Based on class-tested methods developed by the author over his 25-year teaching career, these notebooks show exactly how the theory works and provide useful calculation templates for NMR researchers.

Clojure Data Analysis Cookbook, Second Edition

As data invades more and more of life and business, the need to analyze it effectively has never been greater. With Clojure and this book by Eric Rochester, you’ll soon be getting to grips with every aspect of data analysis, including working with *Mathematica* and R. You’ll start with practical recipes that show you how to load and clean your data, then get concise instructions to perform all the essential analysis tasks from basic statistics to sophisticated machine learning and data clustering algorithms. Get a more intuitive handle on your data through hands-on visualization techniques that allow you to provide interesting, informative, and compelling reports, and use Clojure to publish your findings to the web.

Geometric Design, An Artful Portfolio of Mathematical Graphics

Aristotle would have said that a geometer considers the shapes of things in the natural world not insofar as shapes are physical, but rather by abstracting the qualities of figure from the things themselves. In a philosophical sense, this book by Christopher Alan Arthur is thus one about geometry. Clearly for the mathematical reader at a level of study somewhat exceeding vector calculus, the book, with graphics and images produced with *Mathematica*, presents new possibilities of exotic shapes (by their torsion or concavity) still having desirable qualities such as differentiability, self-similarity, or compactness. Included in this book are many full-color pictures of tessellations, polyhedrons, unusual curves and surfaces, and fractals, along with their generating equations, coordinates, and diagrams.

Extension of *Mathematica* System Functionality

More and more, systems of computer mathematics find broader application in a number of natural, economical, and social fields. This book, by Viktor Aladjev and V. A. Vaganov, focuses on modular programming supported by *Mathematica*, one of the leaders in this field. Software tools presented in the book contain a number of useful and effective methods of procedural and functional programming that extend the system software and make it easier and more efficient to program the objects for various purposes. Furthermore, the book comes with freeware package AVZ_Package, which contains more than 680 procedures, functions, global variables, and other program objects.

New Symbolic Solutions of Biot’s 2D Pore Elasticity Problem

Alexander N. Papusha and Denis P. Gontarev’s article in *The Mathematica Journal* presents new symbolic solutions for the problem of pore elasticity and pore pressure. These techniques are based on the classic theoretical approach proposed by M. A. Biot. Both new symbolic and numerical solutions are applied to solve problems arising in offshore design technology, specifically dealing with the penetration of a gravity-based rig installed in the Arctic region of the North Sea of Russia. All symbolic approaches are based on solutions of the linear problem of the pore elasticity for homogeneous soil.

If you are interested in submitting an article to be considered for publication in *The Mathematica Journal*, check out our submissions page for material guidelines and more information. And for those of you who wish to be a part of the community of authors that have worked with Wolfram technologies, feel free to join the discussions taking place in our Authoring and Publishing group on Wolfram Community.

Some say that Tau Day is really the day to celebrate, and that τ(=2π) should be the most prominent constant, not π. It all started in 2001 with the famous opening line of a watershed essay by Bob Palais, a mathematician at the University of Utah:

“I know it will be called blasphemy by some, but I believe that π is wrong.”

Which has given rise in some circles to the celebration of Tau Day—or, as many people say, the one day on which you are allowed to eat two pies.

But is it true that τ is the better constant? In today’s world, it’s quite easy to test, and the Wolfram Language makes this task much simpler. (Indeed, Michael Trott’s recent blog post on dates in pi—itself inspired by Stephen Wolfram’s Pi Day of the Century post—made much use of the Wolfram Language.) I started by looking at 320,000 preprints from arXiv.org to see in practice how many formulas involve 2π rather than π alone, or other multiples of π.

Here is a `WordCloud` of some formulas containing 2π:

I found that only 18% of formulas considered involve 2π, suggesting that τ, after all, would not be a better choice.

But then why do τ supporters believe that we should switch to this new symbol? One reason is that using τ would make geometry and trigonometry easier to understand and learn. After all, when we learn trigonometry, we don’t measure angles in degrees, but in radians, and there are 2π radians in a circle. This means that 1/4 of a circle corresponds to 1/2 π radians, or π/2, and not a quarter of something! This counterintuitive madness would be resolved by the symbol τ, because every ratio of the circle would have a matching ratio of τ. For example, 1/4 would have an angle of τ/4.

I personally do not have strong feelings against π, and to be honest, I don’t think students would learn trigonometry faster if they were to use τ. Think about the two most important trigonometric functions, sine and cosine. What’s most helpful to remember about them is that sin= cos(2 π) = 1, and sin = cos(π) = –1. I have not only always preferred cosine simply because it’s easier to remember (there are no fractions in π and 2 π), I’ve also always recognized that sine and cosine are different because one is nonzero on integer multiples of π and the other is nonzero on some fractions of it. By using τ instead, this symmetry would be lost, and we would be left with the equalities sin = cos(τ) = 1 and sin = cos = –1.

Given these observations, it seems like choosing τ or π is a personal choice. That’s fair, but it’s not a rigorous approach for determining which constant is more useful.

Even the approach I had at the beginning could lead to the wrong conclusion. *The Tau Manifesto*, by Michael Hartl, gives some examples of places where 2π is most commonly used:

And indeed, all these formulas would be easier if we used τ. However, those are just six of the vast number of formulas that scientists use regularly, and as I mentioned before, not many mathematical expressions involve 2π. Nevertheless, it could happen that formulas not involving 2π would still be simpler if written in τ. For example, the expression 4 π² would simply become (τ²).

For this reason I looked back at the scientific articles to see whether using τ instead of 2π (and τ/2 instead of π) would make their formulas simpler. For instance, these are some that would be simpler in τ:

And these are some that would not:

Let me now try to explain what I mean by simpler by looking at an example: if I take the term containing π in the bottom-left formula of the *Tau Manifesto* equation table:

I can replace π with τ/2 using `ReplaceAll`, and I get:

Just by looking at these two expressions, you can see that the second one is simpler. It’s not just your intuition that tells you that; it’s clear that there are fewer symbols and constants in the replaced expression. We can look at their corresponding `TreeForm`s to demonstrate it explicitly:

To get a numeric difference, we can look at the leaf counts (number of leaves on the trees), which correspond to the number of symbols and constants in the original formulas:

To see whether τ had an overall simplifying impact, I computed the complexity of each formula (defined as their leaf counts, as computed above) involving π that appeared in the articles when using π and τ. To be more precise, I first deleted all the formulas that were either equal to π or 2 π. I felt it would have been unfair to consider those as well because very often, if they appear by themselves, they do not stand for formulas. I then compared the number of times the τ formulas were better with the number of times they were not, and only 43% of the formulas whose complexity changed at all were actually better, meaning that using τ would make more than half of them look more complex. In other words, based on this comparison, we should keep using π. However, this is not the end of the story.

One observation I made is that if an expression gets either more or less complex, it’s likely to have a leaf count that is less than 40. In fact, if you look at the percentage of formulas that are better when using π or τ and that have a number of leaves that is less than a fixed number, you get this picture:

where the *x* axis represents the upper bound on the number of leaves. This suggests that almost all formulas that become simpler have complexities less than 50, regardless of the symbol we choose.

A more relevant observation is that the situation changes drastically as the complexity of the formulas increases. Already by only considering formulas that have complexities greater than 3, like from earlier, only 48% are simpler in π against 52% that are simpler in τ. The graph below shows how the percentage of formulas that are better in either π or τ changes as a function of the complexity:

As you can see, as the number of leaves exceeds 48, the situation becomes chaotic. This is because only 0.4% of formulas have complexities greater than 50. There are not enough of these for us to deduce anything stable and reasonable about them, and the previous observation tells us that we should not really worry much about them anyway.

What this graph tells me is that in everyday life, and for anything more complex than fairly easy expressions like , we should indeed use τ for simplicity. But there is still something else I have not considered. What about different subjects?

It might be that formulas in physics look simpler in τ, but formulas in other subjects do not. The initial search I made included articles from different subjects; however, I didn’t initially check whether the majority of π-containing formulas were from a limited subset of those subjects, or whether the ones that became simpler with τ were mostly from a limited subset. In fact, if I just restrict analysis to articles in mathematics, the situation becomes the following:

Basically, only 23% of formulas benefit from using τ, and those benefits come only when the complexity is fairly high. For instance, something of this sort:

would be an expression that would be simpler in τ, and you probably have not seen many of this type of expression. This suggests that either scientists in different subjects should use different conventions depending on their field-specific formulas, or that all scientific disciplines should switch to τ even though it does not really make sense for some of them to do so. After all, in a democracy, the majority wins, and it is impossible to accommodate everyone.

However, the above formula shows something else that I want to point out. With τ, it becomes this:

And that is not much of an improvement: even though an expression could be easier in τ, the improvement might be so small that it is irrelevant. Consider for instance these two expressions together with their leaf counts:

And the corresponding expressions in τ:

The first formula is simpler in τ, but the leaf count is only 1/13 smaller than the original complexity, whereas the second expression is simpler in π and the replaced expression is 1/6 higher than the original complexity. In other words, the first case’s improvement was 1/13 and the second’s was -1/6 (the minus sign indicates negative improvement, as the expression in τ was worse). The mean of the vector is –0.044, a negative number, which means that using τ in these two expressions makes the whole vector 0.044 worse, although π and τ each improved one formula.

This vector approach is different from the one-count-per-equation one that I used earlier. It considers quantity of improvement instead of just an either/or binary, and it completely reverses the previous conclusions. I have computed these vectors for formulas having complexities bounded from below in the same way I did in the previous example. What I’ve seen is that the overall improvement in going from π to τ, computed as the mean of these vectors, looks like this as the complexity increases:

where the *least* worsening, -0.04, is achieved at a complexity of 5. As you can see, the improvement stays below 0 the whole time, meaning that while more formulas may be shorter with τ (depending on the field), on average those length decreases are outweighed by the length increases in the formulas that are getting longer.

To make my point, at the end of this scientific investigation: I think we should be happy with our old friend π and not switch to τ.

I have two final observations. The first is that if we had already lived in a τ world, the conclusion would have been different, and we would have chosen to stick with τ. If our expressions were already in τ and we were investigating whether switching to π would make them simpler, our vector-based graph would look like this:

That difference in behavior is because the vectors used to construct the graphs depend on the original complexities, and so change when the original changes.

This shows that for formulas that have a complexity greater than 2 (most of them do) and for which the complexity is not always greater than 18, the improvement in switching from τ to π would be negative again, suggesting that we should not accept the switch. Unfortunately for supporters of τ, we do not live in a τ world.

The second observation, which was brought to me by Michael Trott, is that 2/3 of the formulas shown in *The Tau Manifesto* (the green table at the beginning) don’t just have 2π in them, but the complex number 2π*i*. This suggests that maybe the question I was trying to answer is not the correct one. A better one could be this: would it make sense to have a new symbol τ for the complex number 2π*i*?

This new convention would require changing from π*i* to τ/2 as well, but that doesn’t affect the complexity of π*i*. In general, formulas having a π*i* term inside would either become simpler or preserve their complexity. To give you an idea, here’s a word cloud of formulas that would become simpler:

Which, after substituting τ= 2π*i*, become these:

You could argue that the percentage of improved formulas may not be high enough, and changing from 2π*i* to τ is not worth the effort. What evidence shows, however, is the opposite: of all formulas having a π*i* term, 75% would be simpler, and the remaining 25% would keep their original complexity—none would get worse. This is a strong point to make, and I am not in the position to do it, but I think the equality τ = 2π*i* looks more promising (and less historically disruptive) than τ = 2π.

Whatever your opinion on τ, I hope you have a lovely Tau Day. Please enjoy two pi(e)s today—imaginary or otherwise.

]]>

The new Wolfram Language Image Identification Project was the focus of much interest at the conference. Talks on the subject were particularly well received, and there were laughs aplenty when European CEO Conrad Wolfram demonstrated its ability to recognize the aforementioned tropical fruit… which happened to be the nearest object at hand during his opening keynote!

Tom Wickham-Jones’ keynote on the Wolfram Cloud Platform and Oliver Rübenkönig’s engaging “Writing Your Own PDE Solvers” talk were also voted among the most memorable and enjoyable sessions by the delegates in Frankfurt.

The conference covered a wide range of topics for those interested in Wolfram technologies, including *SystemModeler*, the Wolfram Language, and the Wolfram Data Drop. It also explored the technology and vision behind the Computer-Based MathTM education system.

Apart from learning and entertainment, there was also plenty of celebration at the Frankfurt event. Among those with something extra to cheer at the conference dinner was the UnRisk development team, which took one of this year’s Wolfram Innovator Awards. UnRisk was recognized for its highly sophisticated family of financial derivatives and risk analytics products, which are built around the Wolfram Language.

The other Innovator Award winner, also from the finance industry, was André Koppel, of André Koppel Software GmbH. A creator and seller of financial insolvency products that use Wolfram Language and CDF, Koppel has long been a terrific supporter of Wolfram and an advocate of our technology.

Another cause for celebration was the 25th anniversary of the partnership between Wolfram and ADDITIVE GmbH. Our German sales partner’s CEO Andreas Heilemann was on hand to wield the knife for cake-slicing duty on this auspicious occasion, of which we hope to share many more with ADDITIVE.

Stay tuned for news of the date and venue for EWTC 2016!

]]>Here I will concentrate on dates than can be described with a maximum of six digits. This means I’ll be able to uniquely encode all dates between Saturday, March 14, 2015, and Sunday, March 15, 1915—a time range of 36,525 days.

We start with a graphical visualization of the topic at hand to set the mood.

This year’s Pi Day was, like every year, on March 14.

Since the centurial Pi Day of the twentieth century, 36,525 days had passed.

We generate a list of all the 36,525 dates under consideration.

For later use, I define a function `dateNumber` that for a given date returns the sequential number of the date, with the first date, Mar 15 1915, numbered 1.

I allow the months January to September to be written without a leading zero—9 instead of 09 for September—and similarly for days. So, for some dates, multiple digit sequences represent them. The function `makeDateTuples` generates all tuples of single-digit integers that represent a date. One could use slightly different conventions and minimal changes of the code and always enforce short dates or always enforce zeros. With the optional inclusion of zeros for days and months, I get more possible matches and a richer result, so I will use these in the following. (And, if you prefer a European date format of day-month-year, then some larger adjustments have to be made to the definition of `makeDateTuples`.)

Some examples with four, two, and one representation:

The next plot shows which days from the last year are representable with four, five, and six digits. The first nine days of the months January to September just need four or five digits to be represented, and the last days of October, November, and December need six.

For a fast (constant time), repeated recognition of a tuple as a date, I define two functions `dateQ` and `dateOf`. `dateOf` gives a normalized form of a date digit sequence. We start with generating pairs of tuples and their date interpretations.

Here are some examples.

Most (77,350) tuples can be uniquely interpreted as dates; some (2,700) have two possible date interpretations.

Here are some of the digit sequences with two date interpretations.

Here are the two date interpretations of the sequence {1,2,1,5,4} as Jan 21 1954 or as Dec 1 1954 recovered by using the function `datesOf`.

These are the counts for the four-, five-, and six-digit representations of dates.

And these are the counts for the number of definitions set up for the function `datesOf`.

For all further calculations, I will use the first ten million decimal digits of pi (later I will see that ten million digits are enough to find any date). We allow for an easy substitution of pi by another constant.

Instead of using the full digit sequence as a string, I will use the digit sequence split into (overlapping) tuples. Then I can independently and quickly operate onto each tuple. And I index each tuple with the index representing the digit number. For example:

Using the above-defined `dateQ` and `dateOf` functions, I can now quickly find all digit sequences that have a date interpretation.

Here are some of the date interpretations found. Each sublist is of the form {* date, startingDigit, digitSequenceRepresentingTheDate*}.

We have found about 8.1 million dates represented as four digits, about 3.8 million dates as five digits, and about 365,000 dates represented as six digits, totaling more than 12 million dates altogether.

Note that I could have used string-processing functions (especially `StringPosition`) to find the positions of the date sequences. And, of course, I would have obtained the same result.

While the use of `StringPosition` is a good approach to deal with a single date, dealing with all 35,000 sequences would have taken much longer.

We pause a moment and have a look at the counts found for the 4-tuples. Out of the 10,000 possible 4-tuples, the 8,100 used appear each on average (1/10)⁴*10⁷=10⁴ times based on the randomness of the digits of pi. And approximately, I expect a standard deviation of about 100010^½≈31.6. Some quick calculations and a plot confirm these numbers.

The histogram of the counts shows the expected bell curve.

And the following graphic shows how often each of the 4-tuples that represent dates were found in the ten million decimal digits. We enumerate the 4-tuples by concatenating the digits; as a result, I see “empty” vertical stripes in the region where no 4-tuples are represented by dates.

Now I continue to process the found date positions. We group the results into sublists of identical dates.

Every date **does** indeed occur in the first 10 million digits, meaning I have 36,525 different dates found. (We will see later that I did not calculate many more digits than needed.)

Here is what a typical member of `dateGroups` looks like.

Now let’s do some statistics on the found dates. Here is the number of occurrences of each date in the first ten million digits of pi. Interestingly, and in the first moment maybe unexpectedly, many dates appear hundreds of times. The periodically occurring vertical stripes result from the October-November-December month quarters.

The mean spacing between the occurrences also clearly shows the early occurrence of four-digit years with average spacings below 10,000, the five-digit dates with spacings around 100,000, and the six-digit dates with spacings around one million.

For easier readability, I format the triples {* date, startingPosition, dateDigitSequence*} in a customized manner.

The most frequent date in the first ten million digits of pi is Aug 6 1939—it occurs 1,362 times.

Now let’s find the least occurring dates in the first ten million digits of pi. These three dates occur only once in the first ten million digits.

And all of these dates occur only twice in the first ten million digits.

Here is the distribution of the number of the date occurrences. The three peaks corresponding to the six-, five-, and four-digit date representations (from left to right) are clearly distinct. The dates that are represented by 6-tuples each occur only a very few times, and, as I have already seen above, appear on average about 1,200 times.

We can also accumulate by year and display the date interpretations per year (the smaller values at the beginning and end come from the truncation of the dates to ensure uniqueness.) The distribution is nearly uniform.

Let’s have a look at the dates with some “neat” date sequences and how often they occur. As the results in `dateGroups` are sorted by date, I can easily access a given date. When does the date 11-11-11 occur?

And where does the date 1-23-45 occur?

No date starts on its “own” position (meaning there is no example such as January 1, 1945 [1-1-4-5] in position 1145).

But one palindromic case exists: March 3, 1985 (3.3.8.5), which occurs at palindromic position 5833.

A very special date is January 9, 1936: 1.9.3.6 appears at the position of the 1,936^{th} prime, 16,747.

Let’s see what anniversaries happened on this day in history.

While no date appeared at its “own” position, if I slightly relax this condition and search for all dates that overlap with its digits’ positions, I do find some dates.

And at more than 100 positions within the first ten million digits of pi, I find the famous pi starting sequence 3,1,4,1 5 again.

Within the digits of pi I do not just find birthday dates, but also physical constant days, such as the ħ-day (the reduced Planck constant day), which was celebrated as the centurial instance on October 5, 1945.

Here are the positions of the matching date sequences.

And here is an attempt to visualize the appearance of all dates. In the date-digit plane, I place a point at the beginning of each date interpretation. We use a logarithmic scale for the digit position, and as a result, the number of points is much larger in the upper part of the graphic.

For the dates that appear early on in the digit sequence, the finite extension of the date over the digits can be visualized too. A date extends over four to six digits in the digit sequence. The next graphic shows all digits of all dates that start within the first 10,000 digits.

After coarse-graining, the distribution is quite uniform.

So far I have taken a date and looked at where this date starts in the digit sequence of pi. Now let’s look from the reverse direction: how many dates intersect at a given digit of pi? To find the total counts of dates for each digit, I loop over the dates and accumulate the counts for each digit.

A maximum of 20 dates occur at a given digit.

Here are two intervals of 200 digits each. We see that most digits are used in a date interpretation.

Above, I noted that I have about 12 million dates in the digit sequence under consideration. The digit sequence that I used was only ten million digits long, and each date needs about five digits. This means the dates need about 60 million digits. It follows that many of the ten million digits must be shared and used on average about five times. Only 2,005 out of the first ten million digits are not used in any of the date interpretations, meaning that 99.98% of all digits are used for date interpretations (not all as starting positions).

And here is the histogram of the distribution of the number of dates present at a certain digit. The back-of-the-envelope number of an average of six dates per digits is clearly visible.

The 2,005 positions that are not used are approximately uniformly distributed among the first ten million digits.

If I display the concrete positions of the non-used digits versus their expected average position, I obtain a random walk–like graph.

So, what are the neighboring digits around the unused digits? One hundred sixty two different five-neighborhoods exist. Looking at them immediately shows why the center digits cannot be part of a date: too many sequences of zeros before, at, or after.

And the largest unused block of digits that appears are the six digits between position 8,127,088 and 8,127,093.

At a given digit, dates from various years overlap. The next graphic shows the range from the earliest to the latest year as a function of the digit position.

These are the unused digits together with three left- and three right-neighboring digits.

Because the high coverage seems, in the first moment, maybe unexpected, I select a random digit position and select all dates that use this digit.

And here is a visualization of the overlap of the dates.

The most-used digit is the 1 at position 2,645,274: 20 possible date interpretations meet at it.

Here are the digits in its neighborhood and the possible date interpretations.

If I plot the years starting at a given digit for a larger amount of digits (say the first 10,000), then I see the relatively dense coverage of date interpretations in the digits-date plane.

Let’s now build a graph of dates that are “connected”. We’ll consider two dates connected if the two dates share a certain digit of the digit sequence (not necessarily the starting digit of a date).

Here is the same as the graph for the first 600 digits with communities emphasized.

We continue with calculating the mean distance between two occurrences of the same date.

The first occurrences of dates are the most interesting, so let’s extract these. We will work with two versions, one sorted by the date (the list `firstOccurrences`) they represent, and one sorted by the starting position (the list `firstOccurrencesSortedByOccurrence`) in the digits of pi.

Here are the possible date interpretations that start within the first 10 digits of pi.

And here are the other extremes: the dates that appear deepest into the digit expansion.

We see that Wed Nov 23 1960 starts only at position 9,982,546(=2 7 713039)—so by starting with the first ten million digits, I was a bit lucky to catch it. Here is a quick direct check of this record-setting date.

So, who are the lucky (well-known) people associated with this number through their birthday?

And what were the Moon phases on the top dozen out-pi-landish dates?

And while Wed Nov 23 1960 is furthest out in the decimal digit sequence, the last prime date in the list is Oct 22 1995.

In general, less than 10% of all first date appearances are prime.

Often one maps the digits of pi to a direction in the plane and forms a random walk. We do the same based on the date differences between consecutive first appearances of dates. We obtain typically looking 2D random walk images.

Here are the first-occurring date positions for the last few years. The bursts in October, November, and December of each year are caused by the need for five or six consecutive digits, while January to September can be encoded with fewer digits if I skip the optional zeros.

If I include all dates, I get, of course, a much denser filled graphic.

A logarithmic vertical axis shows that most dates occur between the thousandth and millionth digits.

To get a more intuitive understanding of overall uniformity and local randomness in the digit sequence (and as a result in the dates), I make a Voronoi tessellation of the day-digit plane based on points at the first occurrence of a date. The decreasing density for increasing digits results from the fact that I only take first-date occurrences into account.

Easter Sunday positions are a good date to visualize, as the date varies over the years.

The mean first occurrence as a function of the number of digits needed to specify a date depends, of course, on the number of digits needed to encode a date.

The mean occurrence is at 239,083, but due to the outliers at a few million digits, the standard deviation is much larger.

Here are the first occurrences of the “nice” dates that are formed by repetition of a single digit.

The detailed distribution of the number of occurrences of first dates has the largest density within the first few 10,000 digits.

A logarithmic axis shows the distribution much better, but because of the increasing bin sizes, the maximum has to be interpreted with care.

The last distribution is mostly a weighted superposition of the first occurrences of four-, five-, and six-digit sequences.

And here is the cumulative distribution of the dates as a function of the digits’ positions. We see that the first 1% of the ten million digits covers already 60% of all dates.

Slightly more dates start at even positions than at odd positions.

We could do the same with mod 3, mod 4, … . The left image shows the deviation of each congruence class from its average value, and the right image shows the higher congruences, all considered again mod 2.

The actual number of first occurrences per year fluctuates around the mean value.

The mean number of first-date interpretations sorted by month clearly shows the difference between the one-digit months and the two-digit months.

The mean number by day of the month (ranging from 1 to 31) is, on average, a slowly increasing function.

Finally, here are the mean occurrences by weekday. Most first date occurrences happen for dates that are Wednesdays.

Above I observed that most numbers participate in a possible date interpretation. Only relatively few numbers participate in a first-occurring date interpretation: 121,470.

Some of the position sequences overlap anyway, and I can form network chains of the dates with overlapping digit sequences.

The next graphic shows the increasing gap sizes between consecutive dates.

Distribution of the gap sizes:

Here are pairs of consecutively occurring date-interpretations that have the largest gap between them. The larger gaps were clearly visible in the penultimate graphic.

Now, the very special dates are the ones where the concatenated continued fraction (cf) expansion position agrees with the decimal expansion position. By concatenated continued fraction expansion, I mean the digits on the left at each level of the following continued fraction.

This gives the following cf-pi string:

And, interestingly, there is just one such date.

None of the calculations carried out so far were special to the digits in pi. The digits of any other irrational numbers (or even sufficiently long rational numbers) contain date interpretations. Running some overnight searches, it is straightforward to find many numeric expressions that contain the dates of this year (2015). Here they are put together in an interactive demonstration.

We now come to the end of our musings. As a last example, let’s interpret digit positions as seconds after this year’s pi-time at March 14 9:26:53. How long would I have to wait until seeing the digit sequence 3·1·4·1·5 in the decimal expansion of other constants? Can one find a (small) expression such that 3·1·4·1·5 does not occur in the first million digits? (The majority of the elements of the following list ξs are just directly written down random expressions; the last elements were found in a search for expressions that have the digit sequence 3·1·4·1·5 as far out as possible.)

Here are two rational numbers whose decimal expansions contain the digit sequence:

And here are two integers with the starting digit sequence of pi.

Using the neat new function `TimelinePlot` that Brett Champion described in his last blog post, I can easily show how long I would have to wait.

We encourage readers to explore the dates in the digits of pi more, or replace pi with another constant (for instance, Euler’s constant E, to justify the title of this post), and maybe even 10 by another base. The overall, qualitative structures will be the same for almost all irrational numbers. (For a change, try `ChampernowneNumber[10]`.) Will ten million digits be enough to find every date in, say, E (where is October 21, 2014?) Which special dates are hidden in other constants? These and many more things are left to explore.

Download this post as a Computable Document Format (CDF) file.

]]>—Dale Dougherty

I joined the maker movement last year, first by making simple things like a home alarm system, then by becoming a mentor in local hackathons and founding a Wolfram Meetup group in Barcelona. There is likely an open community of makers that you can join close to where you live; if not, the virtual community is open to everyone. So what are you waiting for? With the Raspberry Pi 2 combined with the Wolfram Language, you really have an amazing tool set you can use to make, tinker, and explore.

If there was one general complaint about the Raspberry Pi, it was about its overall performance when running desktop applications like *Mathematica*. The Raspberry Pi Foundation addressed this performance issue early this year by releasing the Raspberry Pi 2 with a quad-core processor and 1 GB of RAM, which has greatly improved the experience of interacting with the device via the Wolfram Language user interface.

Here are 10 different ways to write a “Hello, World!” program for your Pi.

1) Enter a string:

2) Create a panel:

3) Post “Hello, World!” in its own window:

4) Create a button that prints “Hello, World!”:

Hello, World!

5) Make your Raspberry Pi speak “Hello, World!”:

6) Deploy “Hello, World!” to the Wolfram Cloud:

7) Send a “Hello, World!” tweet:

8) Display “Hello!” over the world map and submit it to Wolfram Tweet-a-Program:

9) Program your Pi to say “Hello, World” in Morse code by blinking an LED:

Notice that the GPIO interface requires root privilege to control the LED, so you must start *Mathematica* as root from the Raspberry Pi terminal by typing `sudo mathematica` in the command line.

10) Apply sound to the “Hello, World” Morse code:

This list could go on and on—it’s limited only by your imagination. If you want to send more “Hello, World” Morse code, you can make an optical telegraph. The Community post Raspberry Pi goes to school, by Adriana O’Brien, shows you how.

*This image was created with Fritzing.*

One of the most useful things about using the Wolfram Language on the Pi is that it works seamlessly with the new Wolfram Data Drop open service. This allows you to make an activity tracker in just a few minutes. For example, using Data Drop and a PIR (Passive InfraRed) motion sensor, I kept track of all human movements in my home hallway for several months.

*This image was created with Fritzing.*

Every 20 minutes, the total number of counts was added to a databin, so I could monitor my hallway in real time from anywhere with Wolfram|Alpha. And if I wanted to, I could also analyze the data and create advanced visualizations like in this `DateListPlot` that distinguishes business days from weekends:

The Wolfram Data Drop also accepts images from the Raspberry Pi camera module, so you can easily make a remote motion trigger with a PIR sensor.

Or you can take several snapshots and make a time lapse, like in this tutorial on turning my animated plant into a moving animal:

The Wolfram Language has all sorts of image processing algorithms built in. But for some applications, the image that comes out with `DeviceRead`[`"RaspiCam"`] is just too small. To take the most out of your 5 MP camera module, use `Import` with the following specifications:

Yes, this is the view from my office window. There is a lot of detail that can be processed in many different ways:

The Wolfram Language on Raspberry Pi 2 is also great for rapid prototyping and 3D printing. It knows how to import and export hundreds of data formats and subformats. For example, here’s how to turn the skeletal polyhedron (specifically, a rhombicuboctahedron) drawn by Leonardo da Vinci into an object file that can be 3D printed:

Finally, let me invite you to join Wolfram Community and show off your own Raspberry Pi projects, discover new ideas to use as starting points in your future creations, or take advantage of the many helpful tutorials that have been posted by fellow users.

Download this post as a Computable Document Format (CDF) file.

]]>