Once installed, you’ll have a few different options for how to use your new add-ons. First, you can open a Wolfram|Alpha sidebar inside Docs or Sheets by going to the Wolfram|Alpha for Docs or Wolfram|Alpha for Sheets Add-on menu (from within your Docs or Sheets file) and choosing Open Wolfram|Alpha Sidebar. This opens a sidebar that lets you type in your queries and send them to Wolfram|Alpha. When you click the orange equal sign button , result pods from your query will show up in the sidebar. You can then copy these results as images or plain text to use in your document. Or use the sidebar to look up the molecular structure of caffeine, visualize the Poisson distribution, find the processor speed for the Atari 400, get nutritional information for chocolate chip cookies, and all sorts of other things. It’s the full power of Wolfram|Alpha, right inside Google Drive.
The Wolfram|Alpha sidebar is invaluable when doing general research. But if you have a specific question you need answered, there’s an even simpler option for getting Wolfram|Alpha results. In either a Docs or Sheets file, just highlight some text and go to the Wolfram|Alpha for Docs or Wolfram|Alpha for Sheets Add-on menu, choose Compute Selection with Wolfram|Alpha, and Wolfram|Alpha will replace the selection with its result. For example, if you want to know the mass of a proton, just type “mass of the proton,” highlight it, compute the selection, and the mass of the proton will appear, units and all! What’s more, if you select multiple cells in Sheets, you can compute them all at the same time with a single click.
Whether you’re gearing up to tackle next semester’s history class—or just looking to make your daily grind a little easier—go ahead and try out the Wolfram|Alpha Add-ons for Google Drive today. Simplify your workflow, compute answers on the fly, and bring the power of Wolfram|Alpha to your spreadsheets and documents.
]]>Questions like “Where in the UK has the poorest food hygiene?”, “What kinds of places are the most unhygienic?”, and “What kinds of food are the most unhygienic?” spring to mind. I thought I would apply Mathematica and a little basic data science and provide the answers.
The collected data, over half a million records, is updated daily and is openly available from an API, but this API seems to be targeted at performing individual lookups, so I found it more efficient to import the 414 files from this site instead.
All data in this blog post was extracted on July 15, 2016. You can find the Wolfram Language code for importing and other utilities in the CDF at the foot of this post.
As a warmup, I started with somewhere I knew, so here is the Dataset representing my local city of Oxford.
There are 1,285 places to buy food in Oxford, and the rating scheme grades them from 0 (“Urgent improvement necessary”) through 5 (“Very good”).
We can throw the ratings onto a map of Oxford and see, as I would expect, concentrations of establishments around the tourist center and along major arterial roads.
We can see that the vast majority are rated 4 or 5 (in green). We should only be concerned about the 0, 1, and 2 ratings (“Urgent improvement necessary”, “Major improvement necessary”, and “Improvement necessary”), so let’s look at just those.
There are obvious clusters in the center (where all the tourists go) and along Cowley Road (leading to Temple Cowley), which is where a lot of students live. But these also have lots of good establishments. So to normalize for that, we must find the average rating for a location. Since no two establishments are in exactly the same place, I need to create a function that collects all the data within a certain distance of a geo position and finds the average rating.
We can now run that function over the entire map grid to create a moving average value of hygiene. I have used 0.4 miles for the averaging disk, which is large enough to collect quite a few establishments at a time but small enough to avoid blurring the whole city together.
My initial intuition proved right. Cowley Road and the area between the city center and the station are areas of poor average hygiene, but there is also a hotspot in the southwest that I can’t explain. The best average hygiene is in the north, Walton Manor to Summertown, which are the expensive parts of Oxford and the Headington area.
I am happy that the data is plausible and I have understood it, but there is another issue we must consider before going for our answers: data quality. While the Food Hygiene Rating Scheme is controlled by the national Food Standards Agency, it is operated by over 400 different local authorities. Are they all doing a consistent job? One of the promised benefits of open data is that we can hold our governments accountable—so let’s do that. This is the kind of analysis that I hope central government is doing too.
We can easily look at who is on top of the workload by counting the fraction of businesses that are not yet rated.
So if you eat out in North Norfolk, you might be nervous to discover that nearly 25% of establishments have never been inspected.
Suspicious in another way is that around a third of the authorities have inspected every business. That would be great if it were true, but since new businesses must open regularly, you would expect to find a few that are awaiting inspection, so this may just indicate that these authorities don’t record (or perhaps even know about) new establishments until they are inspected.
We can also see how often the average establishment is inspected. The best authorities inspect establishments at least once per year.
But alarmingly, Croydon has an average time since inspection of over 3.5 years. A lot can change in that time.
I can’t see an easy way to measure if the different authorities are applying the rules in a consistent way when they do inspect, so I am just going to have to trust that the values are equivalent.
So back to our original questions. First I am going to throw out all data that does not have a numerical rating. Unfortunately, this excludes Scotland, which runs a different scheme that provides only a pass-or-fail-type conclusion.
We still have plenty of data to work with…
The good news is that most establishments are “Good” or “Very good.”
The average rating value across the country is 4.37.
Here is a quick map of all the 0-rated establishments in the country.
The easiest way to group the data is by the local authority that collected it, since that is stored in every record. By that measure, Newham in London is the worst, with an average rating of 3.4.
And the best is Torridge in Devon at 4.86.
But we can use the "PostCode" key to be much more precise. A full UK postcode is shared by around 15 properties. That is too fine grained, as we will find a lot of postcodes with only one restaurant. We need a collection to infer anything about a neighborhood, so I will use only the first part of the postcode, and throw out all postcodes that do not contain at least 10 establishments.
Finally, I hooked up a postcode API to translate back from the partial postcode to a location name.
The result puts E13, in East London, at the bottom of the list, with adjacent postcodes E12, E7, E8, and E15 also on the list. Indeed, nearly all of the worst postcodes are parts of London, apart from a few Birmingham postcodes.
Topping the best hygiene-rated postcodes is Craigavon in Northern Ireland, with a perfect score.
Can we infer some long-distance trends? For the whole country, we have lots of data and are not looking for very small features. There is a much faster method than the one I used on Oxford. Essentially, by aggregating over square regions rather than circular, I can round each geo position once, rather than having to test it repeatedly for membership of the region. I round all the locations to the nearest 20 miles and then aggregate all the points that now share the same location. I then repeat the process, shifting the box centers by 5 miles to create a moving average square. The Wolfram Language code is attached in a CDF at the bottom of the blog. Here is the result.
So there is an unhygienic center in London (as we already saw) that spreads toward Birmingham (going around north Oxfordshire) before turning east at Manchester until it reaches Hull. There is another notable low area in South Wales around, but not centered on, Cardiff. Generally, rural areas appear to be more hygienic, particularly North Devon, North Wales, and East Cumbria.
Enough regional anthropology. Let’s consider what kind of food is safe. The analysis of the "BusinessType" key is reassuringly predictable. Fast food is the worst; schools and hospitals are the best.
We can drill deeper by inferring something about the food from the business name. Here is a function to measure the average hygiene rating for all establishments containing a particular word.
To reduce the search and ensure enough data for conclusions, I will pick out a list of all words that appear in at least 100 different business names.
And now for each word, we calculate the average rating for businesses using that word in their names.
Amusingly, “lucky” appears on the list of the worst word associations. The worst is “halal.” With the exception of Dixy (which appears to mostly be linked to a chain), they are words associated with small, independent businesses.
We can see it more easily, though less precisely, as a WordCloud of the 80 worst-rated words.
The words associated with the best ratings are mostly large chains, who presumably can put more effort into good management processes. At the top of the list is the Japanese-inspired restaurant chain Wagamama, followed by upmarket supermarket chain Waitrose. There are also some school- and hospital-related words.
Of course, none of this necessarily has anything to do with how good the food tastes, and it is unproven whether there is any link between satisfying the food inspectors and making safe food.
If you really care about food hygiene, then the best advice is probably just to never be rude to the waiter until after you have gotten your food!
Download this post as a Computable Document Format (CDF) file. New to CDF? Get your copy for free with this one-time download.
]]>
It is no secret that Wolfram|Alpha is a well-used tool for math students, especially those taking first-year college and university math courses. In fact, one of the most common responses I receive from students when I explain my role with Wolfram|Alpha is, “OMG, that site saved me during calculus.” This is usually a reference to the differential equation solver, or derivative and integral features of Wolfram|Alpha.
A majority of math topics that are taught at the high-school and first-year level are computation based, similar to the features listed above. This means questions on tests and exams are often in the following form:
Computation questions typically involve performing a series of calculations (i.e. steps) in order to obtain a final result. Topics that can be solved computationally can often be done so using repetitive approaches. Once a student has mastered the limited steps and rules associated with one of these topics, they should be able to handle just about any problem that is thrown at them on an assignment or an exam related to that topic. This is because computation-based questions are generally consistent in the approaches used to solve them. Similar to learning how to calculate derivatives of functions, once a student has gained experience with all the necessary “derivative rules,” answering these questions is a matter of repeatedly applying those rules.
The problem, though, is what about topics that are not computation based? More specifically, how do students study and practice questions for math topics that don’t have a limited set of rules or approaches? I encountered this problem as a student in a first-year discrete math course. The topic being taught was proofs by principle of mathematical induction, which I will give a brief background on. This topic was completely different than anything I had previously been taught in math, for a couple reasons:
It’s weird to think of a math problem that doesn’t have a nice, simple, clean answer at the bottom of the page. If a student was solving an equation on a test, they might use five lines to show their steps, and then at the very end they would likely have the final answer written in the form “x = 21.” Mathematical proofs, however, don’t work that way. In fact, the “answer” actually is the steps. The goal of a proof is to logically show why something is true.
Consider if you were playing the game Clue (a.k.a. Cluedo), a murder mystery board game. The goal of the game is to determine who the murderer is, the weapon used, and the location of the crime. Someone would therefore win by stating something along the lines of, “Colonel Mustard with the revolver in the dining room.” Now imagine instead of trying to figure out this information, you were told who the murderer was, the weapon used, and the location of the crime at the very beginning of the game. The goal now is then not to determine the conclusion (since you were already told it) but instead figure out why this is true. Based on your own cards and conclusions made from information being revealed throughout the game, you should eventually be able to prove using logic why the information you were told at the beginning of the game must be true. Therefore, you might win the game by stating something along the lines of, “Since I have all of the weapon cards besides the revolver, and Joe has all the location cards except the dining room, and I know neither of you have Colonel Mustard based on your cards played, I have proved the proposed murderer to be true.”
I am not at all suggesting that the above example would be a fun alteration to Clue; in fact, it would likely kill the fun of the game (bad joke). However, it demonstrates the type of question/answer format that proofs represent. Below is a sample induction proof question a first-year student might see on an exam:
Prove using mathematical induction that 8^n – 3^n is divisible by 5, for n > 0.
The assertion made, that 8^n – 3^n is divisible by 5 when n is greater than 0, is completely true (assuming n is an integer). However, the question is asking the student to logically show why the statement is correct. Just like in that alternate Clue example, you were told the information at the beginning of the game and then asked to prove why it’s true. Writing these proofs is not trivial for most students, and is often viewed as one of the more difficult math concepts to master.
Due to the complexity of these questions, students often rely on online resources for further help (e.g. Wolfram|Alpha). If students had a differential equation they were solving and wanted to verify their answer, they can easily input it into Wolfram|Alpha and be given the final answer as well as the step-by-step solution. This approach can also be taken for derivatives, integrals, simplifying expressions, etc.
… but what about proofs?
We’ve established that proofs are not considered to be computation questions. As a result, to my understanding, no calculator or online tool has been able to generate solutions for proof questions… until now.
I vividly remember in my first year wanting to verify my solutions for proofs on an assignment. I had written out what I thought were the correct solutions to the proof questions. But how could I check if my answers were right? Surprisingly, there were only two ways to verify the correctness of my proofs:
So why is it so easy to find a “derivative calculator” online, but not a “proof calculator”?
The answer is mainly due to the fact that proofs have generally not been considered computable. Since the same set of rules can’t be applied to cover 100% of proofs, a computer has difficulty creating the logical steps of which the proof is composed. My solution to this problem was to build a library of pattern-matched proofs (as explained further below). This approach demonstrated the existence of computation playing a role in constructing proofs, and led to the creation of a working “proof generator.”
Over a summer I began building a prototype application, which was able to perform a limited number of proofs using the principle of mathematical induction (PMI). PMI is a common tactic for constructing proofs. The logic for proving a query true via PMI is often compared to proving that a line of dominoes will all fall down in succession. First, you want to prove that the first domino will fall over if you push it. Second, you want to prove that if any given domino falls over, the one following it will also fall over. By proving these two facts, you are able to show that a line of dominoes will fall over if the first one is pushed.
This domino example well describes the logic behind induction proofs, which are composed of:
If both of these steps are done correctly, then the proof is complete.
Before development, I had discussed building this application with a professor at my undergraduate university (Algoma University). He compared this challenging idea to building a recipe book that contains every recipe in the world. You can keep adding as many recipes as you can get your hands on, but it is essentially impossible to include every recipe ever made. Similarly, I can keep adding more coverage for proofs to be generated, but I will never be able to include every proof that a user will ask for.
While this was a rather notable limitation, I thought about it in a slightly different sense. Instead I considered that if someone new to cooking wanted a cookbook, it might be a fairly large cookbook. There’s a wide range of recipes that they would want to try and make. At the same time, they would not likely be relying on a recipe for Gordon Ramsay’s Beef Wellington to be included in the book. The level of difficulty for preparing that dish is likely too high for someone who is brand-new to cooking. As for someone who is new to learning proofs (first-year university level), they likely won’t need access to a resource that generates very advanced proofs. As long as their resource can just cover queries used at the first-year level, then in their eyes the resource has terrific coverage. This was an important distinction made in the planning stage.
During the development of the prototype, I quickly realized there was a rather large challenge right out of the gate. Many of the proofs I wanted the application to cover involved simplifying expressions, which can be a very complex program on its own to write. It didn’t make sense to reinvent the wheel, and this was when I first discovered Wolfram|Alpha’s APIs. Using its APIs, I could simply make calls directly to Wolfram|Alpha (i.e. simplify an expression), and return the result back to my application. I had a few specific questions about the usage of the APIs, and so I decided to just contact Wolfram|Alpha directly with my questions.
The helpful person at the other end answered my questions quickly, and then the conversation took a direction I didn’t expect. After I explained the little side project I was building, I was asked to demonstrate the application to a few different members at Wolfram|Alpha (after signing a nondisclosure agreement, of course). At this point the application was fairly limited in terms of the number of proofs it could handle, but it performed well as a prototype or proof of concept. The demonstration went well, but I was once again surprised at the direction the meeting took. It was just a couple weeks after the demonstration that I was offered—and then accepted—a position with Wolfram|Alpha as a Math Content Developer.
I moved to the Wolfram|Alpha HQ in Champaign, Illinois, the following summer. There, I was able to work on several projects related to new math features being added to the site. However, my main project was to reimplement my induction proof program to become part of Wolfram|Alpha.
The goal of the project was that a student would be able to input any induction proof question they had in a first-year course. For that to become a reality, I scoured the internet and several textbooks to search for all of the induction proof problems I could find… there were a lot.
To be clear, this project was not a database of all induction questions I could find. For the program to work consistently for all proofs (even ones it hadn’t seen before), I needed to first generalize the types of induction proofs that students are being taught. The decision was made early on that the program would handle three main types of queries for proofs:
Using these three main types of proof queries, I then further broke down each of these query types into subsets of more specific types of proofs. Below is an example of what I mean by that.
Let’s say we want to write a proof for the following:
Prove 8^n – 3^n is divisible by 5, for n > 0
Instead of “hard-coding” the full solution of this proof into the application, I want to generalize it as much as I can so that it can possibly cover even more proofs. Therefore, I don’t add very specific proofs to the application, but instead add pattern-matched proofs.
In the expression 8^n – 3^n, I really don’t care all that much about the 8 and the 3. The reason I don’t care is because even if those numbers change, it’s not going to change the structure of the proof being generated. That means if a user instead asked to prove that 10^n – 3^n is divisible by 7, the exact same steps would be followed for the 8^n – 3^n example, just with different values. In order to take advantage of this, I would therefore write a proof solution for this type of query:
Prove a^n – b^n is divisible by d, for n > x
By pattern matching the user’s input, if it is detected that their query is in this form (i.e. follows this pattern), then their proof will be generated according to this structure. The variables (a, b, n, d, x) are then extracted in order to provide the values for the generated proof.
This concept is then applied to many different structures for proof queries. The pattern-matching approach seemed efficient in quickly covering most of the example proof questions I came across online and in textbooks. This approach is what allows the application to generate proofs for queries it hasn’t seen before, so long as it matches the pattern of one of the structures the app is aware of (of which there are many).
However, specific pattern matching is really only used for the expression divisibility and expression inequalities query types. For the summation/product equalities, the application is theoretically able to handle 100% of these queries. There is a specific mathematical approach for summation/product equalities that can be followed, regardless of the right-hand expression of the equality or the contents of the summation or product. This approach works both for proofs and disproofs of summation equalities. This is a nice feature, since it ensures complete coverage of induction proofs for this query type, so long as Wolfram|Alpha doesn’t time out due to large input.
For expression divisibility, most generated proofs are based solely off pattern matching the input. There is, however, a somewhat general-case algorithm used as a last-ditch effort, in case the given expression was not successfully pattern matched. The algorithm performs a certain manipulation on the expression in an attempt to put the expression into a specific form. This form is simply the addition of two terms, where one term is the inductive hypothesis and the other term contains a coefficient that has the given divisor as a factor. If this manipulation is successful, then a proof can be generated. Otherwise, it will fail.
As for expression inequalities, all the generated proofs are pattern matched since I am unaware of any general-case algorithm to apply toward expression inequality proofs. It makes more sense to pattern match the difference between the two expressions. Not only is this beneficial for inequality manipulation but this is also a crucial step in case any terms need to be eliminated. For example, here is a possible query:
Prove 2n + 7 + sin(n) < (n +7)^2 + sin(n), for n > 0
The proof generated here would ideally be pattern matched for the following:
Prove a n + c < (n + b)^d, for n > g
The problem is that the pattern-matched expression doesn’t include a sin(n) on each side of the inequality. However, if the difference between each side of the expression (e.g. left-hand side – right-hand side) is taken, the new query would just be 2n + 7 – (n+7)^2, which would be pattern matched against a n + c – (n+b)^d, which matches correctly.
It is also important to note that some of these variables can sometimes be optional (i.e. equal to 0 or 1), such as the constants, coefficients, and exponents.
Once testing for the application began, I noticed there were two types of queries that were consistently generating incorrect proofs. While the goal is to include coverage for as many proofs as possible, it is much, much, much worse to generate a proof that is mathematically incorrect as opposed to not generating a proof at all. As soon as the application starts producing invalid content, the quality and reliability of the application goes down the drain.
The first type of query that generated invalid proofs can be demonstrated with the following example:
Prove 4n + 7 > 2^n, for n ≥ 0
In this example, the base case (n = 0) correctly passes (since 7 > 1). However, the inductive step should fail because the actual claim being made is false (i.e. when n = 5, since 27 ≱ 32). But for whatever reason, the app attempted to generate an inductive step to make the proof valid. This resulted in faulty mathematics, and needed to be eliminated. Proofs using induction are terrific for verifying claims, but they are not so great for disproving claims. The decision was made then to not generate proofs (or “disproofs”) for expression inequality queries where the base case is valid but the given query is false.
The other type of query that generated invalid proofs can be explained using this example:
Prove 4n < 2^n, for n ≥ 0
This is actually a fairly tricky example. The graph below illustrates the comparison of these expressions:
The base case of this example is n = 0, which results in 4(0) < 2(0), which simplifies to 0 < 1, which is true. Since the base case passes, the inductive step can proceed. Like the previous example, this query also generated an invalid inductive step. The problem is that many of the manipulations that are done in the inductive step may be assuming a certain range of k. For example, in the above proof, one of the steps relies on the fact 3 < 2^k, for k ≥ 2. However, the range of k values between the base case and k ≥ 2, where n = k, has not been proven to satisfy the given claim of
“Prove 4n < 2^n”. Therefore, the base case must now also include n = 1 and n = 2 in the base case coverage. Note that a “modified proof” would need to suggest that n > 4 since the case that n = 4 is not true for 4n < 2^n.
If a manipulation is made in the inductive step that requires n ≥ 2 but the base case is n = 0, then we haven’t proven the query to be true for n = 1 or n = 2. This is very similar to the false paradox “all horses are the same color.” The solution to this problem was not to get rid of the proof altogether. Instead, the base case step would test multiple values of n if any assumption was to be made in the inductive step. Therefore, the query 4n < 2^n would fail in the base case because it is not true for
n = 1.
The final challenge with this project involved the natural language processing (NLP). This allows a user to ask a question in plain English and have Wolfram|Alpha understand what they’re looking for. While I had no applicable experience with NLP before, the existing parsing/scanning framework on Wolfram|Alpha made it fairly easy to integrate the NLP component with the application. The main challenge was trying to determine all the possible ways a user can ask Wolfram|Alpha to prove a query using induction. This continues to be an ongoing development, as different phrasings for queries are still being added.
Here’s a screen shot of the application on Wolfram|Alpha:
By clicking on the “Step-by-step solution” button (a Wolfram|Alpha Pro feature), you will be able to see the generated proof. All users, however, will be able to see the above content. Additional information has been added to the application in order to provide important details to the user. A feature added to this result page is that a different divisor is suggested when the proof is invalid.
Below is a screen shot of the generated proof with the “modified divisor”:
For the multiple-base case example discussed, two proofs were generated for this result—one that shows the initial proof (invalid), and then a second proof that recommends a different base case in order to make the proof valid:
One final, cool feature is that an invalid summation/product equality proof will be corrected with a new recommended expression:
The application went live on Wolfram|Alpha on October 15, 2015 (I’ll never forget it). This was approximately fifteen months after I began designing the prototype program. This date was also six days before I presented the application at the Wolfram Technology Conference on my twenty-first birthday. The success and feedback from this project has been more than I ever could have imagined.
By taking an idea and some initiative, I landed a position with the world’s largest computational knowledge engine (where I’ve been an employee for more than a year now). This initiative also played a key role in being accepted as a graduate student in the University of Waterloo’s symbolic computation department.
While the goal of the project was to generate induction proofs, this whole process was a terrific proof for the rewards that can result from imagination, originality, and hard work.
]]>
Basic Mathematica Primer (Korean)
Our first title is from a group of authors fluent in both Korean and the Wolfram Language. Introducing Korean-language speakers to the powerful fundamentals of Mathematica, the authors—Seong-Deog Yang, Jang hoon Lee, Jiwon Hwang, Chae Yeong Lee, and Myeong Hwan An—combine rich source code and friendly instructions for novices to the Wolfram Language, systematically covering all the basic knowledge needed to explore mathematics with Wolfram technology.
Mathematica Basic Training Course (Chinese)
The Wolfram Language is widely used in China, with its tools for symbolic computation, graphics, high-precision calculations, and more. Hanlong Li, Ying Sui, Shuxian Miu, and Ting Han explore applications in higher mathematics, linear algebra, differential equations, probability, computing methods, operations research, and mathematical modeling with a large selection of examples, including advanced features in Mathematica 10. The authors even offer examples of writing and calling your own software packages to develop programs with the Wolfram Language.
Mathematica-Based Digital Physics (Chinese)
Focusing on the domain of digital physics, Junqin Jiang combines Mathematica’s array of tools with research methods and programming design ideas to help the reader master physics concepts. With interactive examples covering quantum mechanics, electric and magnetic fields, and also numerical solutions and trajectories for dynamics and differential equations, Mathematica-Based Digital Physics promises to make learning the basic numerical methods for solving physics problems much easier than it would be with traditional textbooks.
Toolbox for Mathematics, Mathematica Basic (Japanese)
Etsuo Miyaoka has written a must-have book for not just Japanese Mathematica beginners but also for experienced users still exploring the features of Mathematica 10 and beyond. The first half is aimed at high-school- and early-college-level mathematics, and compares common mathematical expressions with Wolfram Language commands. The discussion then turns in the latter half to the mathematical expressions found in business and 3D schemes, and how Mathematica continues to be the definitive computing system to rely on.
Income Support Benefits Law (Japanese)
One of the domains that the Wolfram Language continues to stand out in worldwide is finance and economics. In this augmented edition, Konosuke Kimura uses Mathematica to create not only the programs but also the accompanying graphics and visualizations for creating linear graduated tax tables, computing income gaps, and calculating income tax revenue and annual expenditures for income support benefits.
Algorithmen von Hammurapi bis Gödel: Mit Beispielen aus den Computeralgebrasystemen Mathematica und Maxima, 4 Auflage (German)
Europe is also full of mathematicians, computer scientists, and other specialists that speak fluent Wolfram. Jochen Ziegenbalg, Oliver Ziegenbalg, and Bernd Ziegenbalg explore the motivation, development, and procedures of algorithms throughout history with meaningful and concrete examples. Using modern tools such as Mathematica’s computer algebra system, students, teachers, and even hobbyists can learn to appreciate the historical and humanistic dimensions of the algorithms all around them.
Methoden der Bioinformatik: Eine Einführung zur Anwendung in Biologie und Medizin, 2 Auflage (German)
Marc-Thorsten Hütt and Manuel Dehnert provide an intriguing and comprehensible introduction to both the mathematical foundations and concrete methods of bioinformatics. Covering questions in bioinformatics and systems biology, the authors give step-by-step implementations of important algorithms in Mathematica, exploring the concepts at the programming level as well. And this second edition extends on its predecessor by addressing more-current topics such as next-generation sequencing, GWAS data, and protein interaction networks.
These titles are just a few of the global family of books that include the Wolfram Language. You can find more Wolfram technologies books, both for English and other languages, by visiting the Wolfram Books site.
]]>
The biggest difference most people might notice between apples and oranges is in their appearance. In case you’ve forgotten what they look like, a simple EntityValue call can jog your memory:
And although “a picture is worth a thousand words,” we can go further. For example, we can even “see inside” the fruits by asking for their typical inside and outside colors:
But appearance isn’t the only way to compare apples to oranges. We can also get an overview of their nutritional profiles by generating nutrition labels based on typical serving sizes with the Wolfram Language’s built-in natural language processing capabilities:
It looks like the fruits are not all that different, nutritionally speaking. However, oranges do have well over the daily recommended value of Vitamin C.
Let’s see if we can find other nutritional differences that aren’t on the nutrition label by gathering nutritional properties on a per-gram basis:
Using the new implicit Entity syntax, we can consider all foods that are apples and oranges:
We can gather all of the nutritional data for these foods, keeping only “comparable” properties (i.e. those without missing data for both apples and oranges):
With a little more work, we can visualize all of the nonzero relative differences between an apple and an orange in a single plot with tooltips to show the properties (download the attached notebook to use tooltips):
Negative numbers here indicate that an orange has more of that nutrient than an apple. From this, we can see that oranges are more nutritious than apples, particularly with respect to vitamins. It’s also important to note the extreme cases at ±200% relative difference. These are nutrients where one fruit has no measurable content, but the other fruit does. We can see exactly what these are by making a grid with the five largest differences on each end of the spectrum:
So although people say “an apple a day keeps the doctor away,” it looks like eating an orange every day would be healthier. But how well do oranges stack up against other fruits and vegetables?
I’ve deployed an interactive Manipulate in the Wolfram Cloud where you can see just that. Here’s a screen shot of it comparing oranges and the “superfood” kale, which outshines oranges in vitamins and minerals (download the attached notebook to use the Manipulate):
So far, we’ve been comparing all apple varieties to all orange varieties. But what happens when we look at individual apples and oranges with different varieties and attributes? We can do this by starting with EntityList, which gives our ever-growing range of specifics:
We can then compare the individual fruits in nutrient spaces, such as this plot in potassium-calcium space:
But let’s not be limited by the fruits themselves—we can also look at their juices. Using the Ctrl+Equal interface makes this very simple:
We can easily see which brands sell both apple juice and orange juice:
We can even use nutrient spaces again to visualize the individual juices, but this time we can do it in three dimensions:
There is definitely an outlier, which corresponds to frozen, undiluted orange juice concentrate:
Using non-nutritional properties, we can learn more about this food:
Based on this kind of information, we can exclude foods with undesirable characteristics. In this particular case, we should exclude undiluted juices, which we can do by tweaking the implicit entity’s constraints with ContainsNone:
After the adjustment, the plot gives better results:
We can also extend this idea and compare apple juices and orange juices to other fruit juices:
Of course, the Wolfram Language is useful for more than just comparing fruits. With non-nutritional properties and images for thousands of foods, many applications are possible. For example, we can search for foods with specific non-nutritional properties, such as yellow, approximately spherical food types:
Or make an image collage of vegetables that have white or cream-colored insides, weighted by iron content:
In addition to whole foods, the Wolfram Language also has thousands of packaged foods with UPCs and images. With a little help from BarcodeRecognize, it’s easy to make a grocery store barcode scanner:
Remember when we plotted apples and oranges in 3D space? We can do this again, but this time with packaging images for nearly 100 pizzas:
Of course, we can also visualize the pizzas in a typical histogram of calories per 100 grams. Additionally, we can compare them to a typical pizza from a pizza chain, as reported by USDA estimates. The typical pizza calorie content is shown in the following plot as a red line:
It’s interesting to note that most packaged pizzas appear to have fewer calories than those from pizza chains. One explanation for this is that the common pizza-chain toppings (e.g. pepperoni, sausage, etc.) are high in calories, especially compared to the many vegetarian and less-calorie-heavy options available in packaged pizzas.
There are many other complicated visualization tools available, but nothing beats a good word cloud. This one is for leafy vegetables weighted according to their vitamin A content:
And, of course, we’re also working to align our food data to other domains. For example, consider this query for cherry-like Pokémon:
You can even make an image collage of food-related Pokémon:
We’re also continuing to add more data, so keep an eye out for updates!
Download this post as a Computable Document Format (CDF) file. New to CDF? Get your copy for free with this one-time download.
]]>
You can now use Wolfram|Alpha to discover information about 216 yoga poses. If you want to learn about a pose, you can search by either its English or Sanskrit name and find basic instructions, along with an illustration. You can also look at the muscles that the pose stretches and strengthens, get ideas for ways to vary the pose, or learn about preparatory poses that you can use to build up toward more difficult poses. If you are recovering from an injury or ailment, you can check a list of precautions and contraindications to discover if the pose might be aggravating for your condition. You can also learn about commonly practiced sequences of yoga poses, such as the Sun Salutation.
Suppose you are a new yoga student and recently took a class where the instructor taught the Downward-Facing Dog Pose. You can take another look at the pose with Wolfram|Alpha and learn more about it. As is true with any physical activity, practicing yoga poses can be strenuous and carries certain risks, so it is important to pay attention to your body’s signals and seek the guidance of a qualified teacher:
Continuing with the new-yoga-student scenario, you may have learned the Downward-Facing Dog Pose as part of the Sun Salutation sequence. You can use Wolfram|Alpha to jog your memory on the order of the poses in the sequence or how to coordinate the poses with your breathing:
Wolfram|Alpha can help you find yoga poses to meet your particular goals. Many beginners start yoga hoping to gain more flexibility in their legs and gain strength in their core. Wolfram|Alpha can help you identify the poses that will help you accomplish those goals, and lists them according to experience:
A common question I get as a yoga teacher is about how to work up to more advanced postures. Maybe you’ve been sitting on your mat before class and stared in amazement as the person across from you floated up into a handstand. I’ve been there too! Wolfram|Alpha can give you ideas about simpler poses that you could do to work toward a bigger goal by searching for preparatory poses:
Certain styles of yoga use codified sequences, which you can explore using Wolfram|Alpha. You will find the Primary Series and Second Series of Ashtanga Yoga, Bikram Yoga’s Twenty-Six Postures, Sivananda Yoga’s Twelve Basic Postures, and the Spiritual Warrior sequence of Jivamukti Yoga:
You can explore even more complex queries with the Wolfram Language, which can be accessed easily in the Wolfram Open Cloud. For example, you might wonder about the number of muscles that are listed for the “stretched muscles” property and ask, “What pose stretches the most muscles?” This is not necessarily a question I would have been able to answer from experiential knowledge, so it is interesting to me to see what the data has to say:
Seeing the answer, it makes sense that it would be Revolved Side Angle Pose. Revolved Side Angle Pose is an asymmetrical posture that incorporates opposites in the lower limbs, trunk, and upper limbs. As someone who practices this pose daily and watches several students grapple with it each day, I can attest to its complexity:
For me, the beauty of yoga is that no one ever completes it. When I started, there were poses that seemed miraculous and that I couldn’t hope to accomplish. But with practice, some of those poses slowly became part of my daily practice, and inevitably, I became aware of a new set of seemingly miraculous poses. With each accomplishment, a new possibility always arises; therefore, yoga is a discipline for the endlessly curious. One of the important lessons of yoga is that with consistent practice and gradual progression, one can transcend perceived limitations. Yoga grounds this lesson in the body so that through practice there is a sense of potential. My hope is that you’ll find information in Wolfram|Alpha’s yoga data that is useful to you today, inspires you for what could be, sparks your curiosity about yoga, and encourages you to practice!
]]>Join us for a free special virtual event, Solving Image Processing Problems: Wolfram Language Virtual Workshop, on June 22, 2016, 1–3pm US EDT (5–7pm GMT). Learn how to tackle problems involving images using current and upcoming features of the Wolfram Language and Mathematica 11. Also engage in interactive Q&A with the workshop’s hosts, Wolfram Language experts Shadi Ashnai and Markus van Almsick.
Do you recognize the famous image on the left? It’s the Leaning Tower of Pisa. On the right is the same image—but minus the leaning, courtesy of a few lines of Wolfram Language code. Throughout the workshop, we will explore numerous techniques to solve common image processing problems, including segmentation, filtering, registration, color processing, and morphological operations. Often in one or two lines of code, Wolfram technology can transform any 2D image or 3D model and extract important details and data.
From generating heat maps of an object’s motion to quantifying anatomy, we will highlight fascinating applications of Wolfram’s powerful built-in toolset that can be applied to countless areas, including your own personal projects.
To join us at the free virtual event on June 22, 2016, 1–3pm US EDT (5–7pm GMT), please register here. All are welcome, with no prior experience in image processing or the Wolfram Language necessary.
]]>Wolfram Language animations make it easier to understand and investigate concepts and phenomena. They’re also just plain fun. Among recent simple but stunning animations, you’ll find “Deformations of the Cairo Tiling” and “Contours of a Singular Surface” by Clayton Shonkwiler, a mathematician and artist interested in geometric models of physical systems, and “Transit of Mercury 2016” by Sander Huisman, a postdoc in Lyon, France, researching Lagrangian turbulence.
In “Facing Your Data with Chernoff Faces,” Anton Antonov explores using face-like diagrams to visualize multidimensional data, a concept introduced by Herman Chernoff in 1973. The result is that each depiction “gives a face” to each record in the dataset.
Parts like the eyes, eyebrows, mouth, and nose represent data values by their shape, size, and placement. Because humans easily recognize faces, it’s pretty easy to pick up on small changes in the depictions. Perhaps the biggest advantage of using Chernoff faces is discerning and classifying outliers in data.
Tushar Dwivedi, a student from the Wolfram Mentorships Program and High School Summer Camp, built a fingerprint identification and matching application using the Wolfram Cloud and the image processing framework in the Wolfram Language.
As Dwivedi points out, computational fingerprint analysis has been relevant in the field of criminology for a long time, but its applications are growing. For example, we now see it used in the fingerprint recognition functionality of smartphones. His example shows how the Wolfram Language makes it possible to detect fingerprints accurately, without specialized technology unavailable to the public.
Bianca Eifert, a PhD student from the University of Giessen, has designed a Wolfram Cloud–based application to view various crystal structures from VASP files. Currently working on a PhD in theoretical solid-state physics, she shows how she created her application, and provides sample VASP file content for you to grab.
Eifert’s earlier staff favorite, “Crystallica: A Package to Plot Crystal Structures,” is another to check out if you’re interested in crystal structures. It uses the Crystallica application available in the Wolfram Library Archive.
Dutch artist Theo Jansen is known for creating kinetic sculptures. His Strandbeest creations are wind-powered walking structures, and Community member Sander Huisman has animated the anatomy of Jansen’s beach beasts.
In his post, Huisman invites others to animate the Strandbeest walking over bumpy terrain. We can’t wait to see what members contribute to the discussion.
Wolfram’s own Ed Pegg recently shared a popular article, “Squeezing Pi from a Menger Sponge,” which was featured on the standupmaths YouTube channel.
In the Menger sponge, a step divides a cube into 27 cubes. Then the center and six touching cubes are removed. In Pegg’s example, fractals of measure zero were taken and tweaked to get π. He asks if you can break the fractal into pieces and make a sphere. Be sure to share your response in the Community comment thread.
These impressive examples are just a sampling of the inventive things being done with the Wolfram Language. Visit Wolfram Community and subscribe to Staff Picks notifications for updates on all posts selected by our editorial team.
]]>We invite you to join us at a special virtual event, Wolfram|Alpha in Your Classroom: Virtual Workshop for Educators, on June 15, 2016, 2–3pm US EDT (6–7pm GMT). Come see examples of how Wolfram|Alpha’s built-in data and analysis capabilities can be used to enrich many types of classes, and take the opportunity to preview upcoming tools from Wolfram that will make teaching and learning easier.
During the workshop, we will explore Wolfram Problem Generator. Problem Generator has the ability to generate unlimited practice problems for topics ranging from arithmetic to calculus. You can instantly create individual problems or entire problem sets, complete with answers. And if you are stuck trying to solve a given problem, detailed step-by-step solutions are available. While Problem Generator has been around for a while, it is currently only available to Wolfram|Alpha Pro subscribers. Soon, however, this will change, and you’ll be able to practice for free.
Another big upcoming change is a brand-new set of tools called Web Apps. Web Apps help you perform complex queries and calculations in all kinds of subjects, making it easy to solve difficult integrals, systems of equations, and lots of other problems. Web Apps aren’t just limited to math and science, though—there are also Web Apps to help with everyday topics, like finding out how many calories you ate at lunch, how long you should stay out in the sun, or what all the anagrams of the word “smile” are.
In addition to these new tools, we will be providing example lesson materials that highlight some of the exciting possibilities for using Wolfram|Alpha in the classroom. These materials draw upon Wolfram|Alpha’s massive collection of built-in data, as well as the ability to upload your own datasets. And instead of coding tedious algorithms, we will analyze the data instantly using both Wolfram|Alpha’s automatic data analysis capabilities and natural language queries.
To see these new features and learn more about using Wolfram|Alpha in your classroom, please register here to join us at the virtual event—again, it’s on June 15, 2016, 2–3pm US EDT (6–7pm GMT). All are welcome, and no programming experience is necessary! This event is part of a series of workshops for educators, which cover topics like how to use Wolfram Programming Lab and teaching computational thinking principles. Recordings of previous events are also available.
]]>In this blog, I will carefully calculate explicit numerical examples of gravitational crystal movements. The “really” in the title should be interpreted as a high-precision, numerical solution to an idealized model problem. It should not be interpreted as “real world.” No retardation, special or general relativistic effects, stability against perturbation, tidal effects, or so on are taken into account in the following calculations. More precisely, we will consider the simplest case of a gravitational crystal: two gravitationally interacting, rigid, periodic 2D planar arrays embedded in 3D (meaning a 1/distance^{2} force law) of masses that can move translationally with respect to each other (no rotations between the two lattices). Each infinite array can be considered a crystal, so we are looking at what could be called the two-crystal problem (parallel to, and at the same time in distinction to, the classical gravitational two-body problem).
Crystals have been considered for centuries as examples of eternal, never-changing objects. Interestingly, various other time-dependent versions of crystals have been suggested over the last few years. Shapere and Wilczek suggested space-time crystals in 2012, and Boyle, Khoo, and Smith suggested so-called choreographic crystals in 2014.
In the following, I will outline the detailed asymptotic calculation of the force inside a periodic array of point masses and the numerical methods to find periodic orbits in such a force field. Readers not interested in the calculation details should fast-forward to the interactive demonstration in the section “The resulting gravitational crystals.”
Within an infinite crystal-like array of point masses, no net force is exerted on any of the point masses due to symmetry cancellation of the forces of the other point masses. This means we can consider the whole infinite array of point masses as rigid. But the space between the point masses has a nontrivial force field.
To calculate orbits of masses, we will have to solve Newton’s famous . So, we need the force of an infinite array of 1/r potentials. We will consider the simplest possible case, namely a square lattice of point masses and lattice constant L. The force at a point {x,y} is given by the following double sum:
Unfortunately, we can’t sum this expression in closed form. Using the sum of the potential is not easier, either; it actually increases the likelihood of a complication in the form of the potential diverging. (Although deriving and subtracting the leading divergent term is possible: if we truncate the sums at ±M, we have a linearly divergent term 8 M sinh^{-1}(1).)
So one could consider a finite 2D array of (2M+1)×(2M+1) point masses in the limit M→∞.
But the convergence of the double sum is far too slow to get precise values for the force. (We want the orbit periodicity to be correct to, say, 7 digits. This means we need to solve the differential equation to about 9 digits, and for this we need the force to be correct to at least 12 digits.)
Because the force is proportional to 1/distance^{2}, and the number of point masses grows with distance squared, taking all points into account is critical for a precise force value. Any approximation can’t make use of a finite number of point masses, but must instead include all point masses.
Borrowing some ideas from York and Wang, Lindbo and Tornberg, and Bleibel for calculating the Madelung constant to high precision, we can make use of one of the most popular integrals in mathematics.
This allows us to write the force as:
Exchanging integration and summation, we can carry out the double sum over all (2∞+1)^{2} lattice points in terms of elliptic theta functions.
Here we carry out the gradient operation under the integral sign:
We obtain the following converging integral:
While the integral does converge, numerical evaluation is still quite time consuming, and is not suited for a right-hand-side calculation in a differential equation.
Now let’s remind ourselves about some properties of the Jacobi elliptic theta function 3. The two properties of relevance to us are its sum representation and its inversion formula.
The first identity shows that for t→0, the theta function (and its derivative) vanishes exponentially. The second identity shows that exponential decay can also be achieved at t→∞.
Using the sum representation, we can carry out the t integration in closed form after splitting the integration interval in two parts. As a result, we obtain for the force a sum representation that is exponentially convergent.
After some lengthy algebra, as one always says (which isn’t so bad when using the Wolfram Language, but is still too long for this short note), one obtains a formula for the force when using the above identities for ϑ_{3} and similar identities for ϑ´_{3}. Here is the x component of the force. Note that M is now the limit of the sum representation of the elliptic theta function, not the size of the point mass lattice. The resulting expression for the force components is pretty large, with a leaf count of nearly 4,000. (Open the cell in the attached notebook to see the full expression.)
Here is a condensed form for the force in the x direction that uses the abbreviation
r_{i j} = (x + i L)^{2} + (y + j L)^{2}:
Truncating the exponentially convergent sums shows that truncation at around 5 terms gives about 17 correct digits for the force.
The convergence speed is basically independent of the position {x, y}. In the next table, we use a point on the diagonal near to the point mass at the origin of the coordinate system.
For points near to a point mass, we recover, of course, the 1/distance^{2} law.
For an even faster numerical calculation of the force, we drop higher-order terms in the double sums and compile the force.
All digits of the force are correct to machine precision.
And the calculation of a single force value takes about a tenth of a millisecond, which is well suited for further numerical calculations.
For further use, we define the function forceXY that for approximate position values returns the 2D force vector.
So now that we have a fast-converging series expansion for the force for the full infinite array of point masses, we are in good shape to calculate orbits.
The simplest possible situation is two square lattices of identical lattice spaces with the same orientation, moving relative to each other. In this situation, every point mass of lattice 1 experiences the same cumulative force from lattice 2, and vice versa. And within each lattice, the total force on each point mass vanishes because of symmetry.
Similar to the well-known central force situation, we can also separate the center of mass from the relative motion. The result is the equation of motion for a single mass point in the field of one lattice.
Here is a plot of the magnitude of the resulting force.
And here is a plot of the direction field of the force. The dark red dots symbolize the positions of the point masses.
How much does the field strength of the periodic array differ from the field strength of a single point mass? The following graphic shows the relative difference. On the horizontal and vertical lines in the middle of the rows and columns of the point masses, the difference is maximal. Due to the singularity of the force at the point masses, the force of a single mass point and the one of the lattice become identical in the vicinity of a point mass.
The next plot shows the direction field of the difference between a single point mass and the periodized version.
Once we have the force field, inverting the relation =-grad numerically allows us (because the force is obviously conservative) to calculate the potential surface of the infinite square array of point masses.
Now lets us look at actual orbits in the potential shown in the last two images.
The following Manipulate allows us to interactively explore the motion of a particle in the gravitational field of the lattice of point masses.
The relatively large (five-dimensional) space of possible orbits becomes more manageable if we look especially for some symmetric orbits, e.g. we enforce that the orbit crosses the line x = 0 or
x = 1/2 horizontally. Many orbits that one would intuitively expect to exist that move around 1, 2, or 3 point masses fall into this category. We use a large 2D slider to allow a more fine-grained control of the initial conditions.
Another highly symmetric situation is a starting point along the diagonal with an initial velocity perpendicular to it.
For the desired motion we are looking for, we demand that after a period, the particle comes back to either its original position with its original velocity vector or has moved to an equivalent lattice position.
Given an initial position, velocity, mass, and approximate period, it is straightforward to write a simple root-finding routine to zoom into an actual periodic orbit. We implement this simply by solving the differential equation for a time greater than the approximate orbit time, and find the time where the sum of the difference of the initial and final positions and initial and final velocities is minimal. The function findPeriodicOrbit carries out the search. This method is well suited for orbits whose periods are not too long. This will yield a nice collection of orbits. For longer orbits, errors in the solution of the differential equation will accumulate, and more specialized methods could be employed, e.g. relaxation methods.
Given some starting values, findPeriodicOrbit attempts to find a periodic orbit, and returns the corresponding initial position and velocity.
Given initial conditions and a maximal solution time, the function minReturnData determines the exact time at which the differences between the initial and final positions and velocities are minimal. The most time-consuming step in the search process is the solution of the differential equation. To avoid repeating work, we do not include the period time as an explicit search variable, but rather solve the differential equation for a fixed time T and then carry out a one-dimensional minimization to find the time at which the sum of the position and velocity differences becomes minimal.
As the search will take about a minute per orbit, we monitor the current orbit shape to entertain us while we wait. Typically, after a couple hundred steps we either find a periodic orbit, or we know that we failed to find a periodic orbit. In the latter case, the local minimum of the function to be minimized (the sum of the norms of initial versus final positions and velocities) has a finite value and so does not correspond to a periodic orbit.
Here is a successful search for a periodic orbit. The initial conditions for the search we either get interactively from the above Manipulate or from a random search selecting viable candidate initial conditions.
Here is a successful search for an orbit that ends at an equivalent lattice position.
So what kind of periodic orbits can we find? As the result of about half a million solutions with random initial positions, velocities, masses, and solution times of the equations of motion, we find the following types of solutions:
2. Closed orbits around a finite (≥ 2) point mass
3. “Traveling orbits” that don’t return to the initial position but to an equivalent position in another lattice cell
(In this classification, we ignore “head-on” collision orbits and separatrix-like orbits along the symmetry lines between rows and columns of point masses.)
Here is a collection of initial values and periods for periodic orbits found in the carried-out searches. The small summary table gives the counts of the orbits found.
Using minReturnDistance, we can numerically check the accuracy of the orbits. At the “return time” (the last element of the sublists of orbitData), the sum of the differences of the position and velocity vectors is quite small.
Now let’s make some graphics showing the orbits from the list orbitData using the function showOrbit.
1. Orbits around a single point mass
In the simplest case, these are just topologically equivalent to a circle. This type of solution is not unexpected; for initial conditions close to a point mass, the influence of the other lattice point masses will be small.
2. Orbits around two point masses
In the simplest case, these are again topologically equivalent to a circle, but more complicated orbits exist. Here are some examples.
3. “Traveling orbits” (open orbits) that don’t return to the initial position but to an equivalent position in another lattice cell
These orbits come in self-crossing and non-self-crossing versions. Here are some examples.
Individually, the open orbits look quite different from the closed ones. When plotting the continuations of the open orbits, their relation to the closed orbits becomes much more obvious.
For instance, the following open orbit reminds me of the last closed orbit.
The last graphic suggests that closed orbits around a finite number of points could become traveling orbits after small perturbations by “hopping” from a closed orbit around a single or finite number of point masses to the next single or finite group of point masses.
But there are also situations where one intuitively might expect closed orbits to exist, but numerically one does not succeed in finding a precise solution. One example is a simple rounded-corner, triangle-shaped orbit that encloses three point masses.
Showing 100 orbits with slightly disturbed initial conditions gives an idea of why a smooth match of the initial point and the final point does not work out. While we can make the initial and final point match, the velocity vectors do not agree in this case.
Another orbit that seems not to exist, although one can make the initial and final points and velocities match pretty well, is the following double-slingshot orbit. But reducing the residue further by small modifications of the initial position and velocity seems not to be possible.
Here are a third and fourth type of orbit that nearly match up, but the function findPeriodicOrbit can’t find parameters that bring the difference below 10^{-5}.
Here are two graphics of the last two orbits.
There are many more periodic orbits. The above is just a small selection of all possible orbits. Exploring a family of trajectories at once shows the wide variety of orbits that can arise. We let all orbits start at the line segment {{x, 1/2}|-1/2 ≤ x ≤ 1/2} with an angle α(x) = 𝜋(1/2-|x|).
If we plot sufficiently many orbits and select the ones that do not move approximately uniformly, we can construct an elegant gravitational crystal church.
The last image nicely shows the “branching” of the trajectories at point masses where the overall shape of the trajectory changes discontinuously. Displaying the flow in the three-dimensional x-t-y space shows the branching even better.
We were looking for concrete periodic orbits in the field of an infinite square array of point masses. For more general results on trajectories in such a potential, see Knauf. Knauf proves that the behavior of average orbits is diffusive. Periodic orbits are the exception in the space of initial conditions. Almost all orbits will wander randomly around. So let’s have a quick look at a larger number of orbits. The following calculation will take about six hours, and evaluates the final points and velocities of masses starting at {x,0.5} with a velocity {0,v} on a dense x-v grid with 0 ≤ x ≤ 1 and 1 ≤ v ≤ 3.
If we display all final positions, we get the following graphic that gives a feeling of the theoretically predicted diffusive behavior of the orbits.
While diffusive in average, as we are solving a differential equation, we expect (at least piecewise) that the final positions depend continuously on the initial conditions. So we burn another six hours of CPU time and calculate the final positions of 800,000 test particles that start radially from a circle around a lattice point mass. (Because of the symmetry of the force field, we have only 100,000 different initial value problems to solve numerically.)
Here are the points of the final positions of the 800,000 points. We again see how nicely the point masses of the lattice temporarily deflect the test masses.
We repeat a variation of the last calculation and determine the minimum value of in the x-v plane, where x and v are the initial conditions of the particle starting at y = 0.5 perpendicular upward.
We solve the equations of motions for 0 ≤ t ≤ 2.5 and display the value of the minimum of in the time range 0.5 ≤ t ≤ 2.5. If the minimum occurs for t=0.5, we use a light gray color; if the minimum occurs for t=2.5, a dark gray color; and for 0.5 < t < 2.5, we color the sum of norms from pink to green. Not unexpectedly, the distance sum shows a fractal-like behavior, meaning the periodic orbits form a thinly spaced subset of initial conditions.
Now that we have the force field of a square array of point masses, we can also use this force to model electrostatic problems, as these obey the same force law.
Identical charges would form a Wigner crystal, which is hexagonal. Two interlaced square lattices of opposite charges would make a model for a 2D NaCl salt crystal.
By summing the (signed) forces of the four sublattices, we can again calculate a resulting force of a test particle.
The trajectories of a test charge become more irregular as compared with the gravitational model considered above. The following Manipulate allows us to get a feeling for the resulting trajectories. The (purple) test charge is attracted to the green charges of the lattice and repelled from the purple charges of the lattice.
We can now combine all the elements together to visualize the resulting gravitational crystals. We plot the resulting lattice movements in the reference frame of one lattice (the blue lattice). The red lattice moves with respect to the blue lattice.
Using detailed numerical calculation, we verified the existence of the suggested gravitational crystals. For the simplest case, the two square lattice, many periodic orbits of small period were found. More extensive searches would surely return more, longer period solutions.
Using the general form of the Poisson summation formula for general lattices, the above calculations could be extended to different lattices, e.g. hexagonal lattices or 3D lattices.
Download this post as a Computable Document Format (CDF) file. New to CDF? Get your copy for free with this one-time download.
]]>