*We’re pleased that despite the coronavirus pandemic and its impact on so many people and businesses we’re still able to launch today as planned… (Thanks to our dedicated team and the fact that remote working has been part of our company for decades…)*

It’s always an interesting time. We’re getting ready to wrap up a .1 version—to release the latest fruits of our research and development efforts. “Is it going to be a big release?”, I wonder. Of course, I know we’ve done a lot of work since we released Version 12.0 last April. All those design reviews (many livestreamed). All those new things we’ve built and figured out.

But then we start actually making the list for the new version. And—OMG—it goes on and on. Different teams are delivering on this or that project that started X years ago. A new function is being added for this. There’s some new innovation about that. Etc.

We started this journey a third of a century ago when we began the development of Version 1.0. And after all these years, it’s amazing how the energy of each new release seems to be ever greater.

And as we went on making the list for Version 12.1 we wondered, “Will it actually be our biggest .1 release ever?”. We finally got the answer: “Yes! And by a lot”.

Counting functions isn’t always the best measure, but it’s an indication. And in Version 12.1 there are a total of 182 completely new functions—as well as updates and enhancements to many hundreds more.

Back in 1988 when we released Version 1.0 a typical computer display was maybe 640 pixels across (oh, and it was a CRT). And I was recently using some notebooks of mine from the 1990s (yes, they still work, which is spectacular!), and I was amazed at what a small window size they were made for. But as I write this today, I’m looking at two 3000-pixel displays. And 4k displays aren’t uncommon. So one of the things we’ve done for Version 12.1 is to add systemwide support for the new world of very-high-resolution displays.

One might think that would be easy, and would just “come with the operating system”. But actually it’s taken two years of hard work to deliver full HiDPI support. Well over a thousand carefully designed icons and other assets went from being bitmaps to being work-at-any-size algorithmic graphics. Everything about rasterization (not just for `Rasterize`, but for 3D graphics textures, etc. etc.) had to be redone. Sizes of things—and their interactions with the tower of kludges that operating systems have introduced over the years—had to be respecified and rethought.

But now it’s done. And we’re ready for displays of any resolution:

By the way, talking of displays, another “infrastructure” enhancement in Version 12.1 is moving to Metal and Direct3D 11 for 3D graphics rendering on macOS and Windows. Right now these just make 3D graphics modestly faster. But they also lay the groundwork for full multithreaded rendering, as well as VR, AR and more.

We’ve been working towards it for nearly 15 years… but finally it’s here: computation with video! We introduced images into the language in 2008; audio in 2016. But now in Version 12.1 we for the first time have computation with video. There’ll be lots more coming in future releases, but there’s already quite a bit in 12.1.

So… just like `Image` and `Audio`, which symbolically represent images and audio, we now have `Video`.

This asks for five frames from a video:

✕
VideoFrameList[ Video["ExampleData/Caminandes.mp4", Appearance -> Automatic, AudioOutputDevice -> Automatic, SoundVolume -> Automatic], 5] |

This asks to make a time series of the mean color of every frame:

✕
VideoTimeSeries[Mean, Video["ExampleData/Caminandes.mp4", Appearance -> Automatic, AudioOutputDevice -> Automatic, SoundVolume -> Automatic]] |

And then one can just plot the time series:

✕
DateListPlot[%, PlotStyle -> {RGBColor[1, 0, 0], RGBColor[0, 1, 0], RGBColor[ 0, 0, 1]}] |

Video is a complicated area, with lots of different encodings optimized for different purposes. In Version 12.1 we’re supporting more than 250 of them, for import, export and transcoding. You can refer to a video on the web as well:

✕
Video["http://exampledata.wolfram.com/cars.avi"] |

And the big thing is that video is now getting integrated into everything. So, for example, you can immediately use image processing or audio processing or machine learning functions on video. Here’s an example plotting the location of cars in the video above:

✕
v = Video["http://exampledata.wolfram.com/cars.avi"] |

✕
ts = VideoTimeSeries[Point[ImagePosition[#, Entity["Word", "car"]]] &, v] |

✕
HighlightImage[ VideoExtractFrames[v, Quantity[5, "Seconds"]], {PointSize[Medium], Values[ts]}] |

Let’s say you’ve got a `Manipulate`, or an animation (say from `ListAnimate`). Well, now you can just immediately make a video of it:

✕
Video[CloudGet["https://wolfr.am/L9r00rk5"]] |

You can add an audio track, then export the whole thing directly to a file, the cloud, etc.

So is this new video capability really industrial strength? I’ve been recording hundreds of hours of video in connection with a new project I’m working on. So I decided to try our new capabilities on it. It’s spectacular! I could take a 4-hour video, and immediately extract a bunch of sample frames from it, and then—yes, in a few hours of CPU time—“summarize the whole video”, using `SpeechRecognize` to do speech-to-text on everything that was said and then generating a word cloud:

Speaking of audio, there’s new stuff in Version 12.1 there too. We’ve redone the GUI for in-notebook `Audio` objects. And we’ve introduced `SpeechInterpreter`, which is the spoken analog of the `Interpreter` function, here taking an audio object and returning what airline name was said in it:

✕
SpeechInterpreter["Airline"][CloudGet["https://wolfr.am/L9r410jA"]] |

In Version 12.0 we introduced the important function `TextCases` for extracting from text hundreds of kinds of entities and “text content types” (which as of 12.1 now have their own documentation pages). In 12.1 we’re also introducing `SpeechCases`, which does the same kind of thing for audio speech.

One of our major long-term projects is the creation of a full compiler for the Wolfram Language, targeting native machine code. Version 12.0 was the first exposure of this project. In Version 12.1 there’s now a spinoff from the project—which is actually a very important project in its own right: the new `DataStructure` function.

We’ve curated many kinds of things in the past: chemicals, equations, movies, foods, import-export formats, units, APIs, etc. And in each case we’ve made the things seamlessly computable as part of the Wolfram Language. Well, now we’re adding another category: data structures.

Think about all those data structures that get mentioned in textbooks, papers, libraries, etc. Our goal is to have all of them seamlessly usable directly in the Wolfram Language, and accessible in compiled code, etc. Of course it’s huge that we already have a universal “data structure”: the symbolic expressions in the Wolfram Language. And internal to the Wolfram Language we’ve always used all sorts of data structures, optimized for different purposes, and automatically selected by our algorithms and meta-algorithms.

But now with `DataStructure` there’s something new. If you have a particular kind of data structure you want to use, you can just ask for it by name, and use it.

Here’s how you create a linked list data structure:

✕
ds = CreateDataStructure["LinkedList"] |

Append a million random integers to the linked list (it takes 380 ms on my machine):

✕
Do[ds["Append", RandomInteger[]], 10^6] |

Now there’s immediate visualization of the structure:

✕
ds["Visualization"] |

Here’s the numerical mean of all the values:

✕
Mean[N[Normal[ds]]] |

Like so much of what we do `DataStructure` is set up to span from small scale and pedagogical to large scale and full industrial strength. Teaching a course about data structures? Now you can immediately use the Wolfram Language, storing everything you do in notebooks, automatically visualizing your data structures, etc. Building large-scale production code? Now you can have complete control over optimizing the data structures you’re using.

How does `DataStructure` work? Well, it’s all written in the Wolfram Language, and compiled using the compiler (which itself is also written in the Wolfram Language).

In Version 12.1 we’ve got most of the basic data structures covered, with various kinds of lists, arrays, sets, stacks, queues, hash tables, trees, and more. And here’s an important point: each one is documented with the running time for its various operations (“O(*n*)”, “O(*n* log(*n*))”, etc.), and the code ensures that that’s correct.

It’s pretty neat to see classic algorithms written directly for `DataStructure`.

Create a binary tree data structure (and visualize it):

✕
(ds = CreateDataStructure["BinaryTree", 3 -> {1 -> {0, Null}, Null}])["Visualization"] |

Here’s a function for rebalancing the tree:

✕
RightRotate[y_] := Module[{x, tmp}, x = y["Left"]; tmp = x["Right"]; x["SetRight", y]; y["SetLeft", tmp]; x] |

Now do it, and visualize the result:

✕
RightRotate[ds]["Visualization"] |

You’ve got a symbolic math expression and you want to figure out its rough value. If it’s a number you just use `N` to get a numerical approximation. But how do you get a symbolic approximation?

Ever since Version 1.0—and, in the history of math, ever since the 1600s—there’s been the idea of power series: find an essentially polynomial-like approximation to a function, as `Series` does. But not every mathematical expression can be reasonably approximated that way. It’s difficult math, but it’s very useful if one can make it work. We started introducing “asymptotic approximation” functions for specific cases (like integrals) in Version 11.3, but now in 12.1 we’re introducing the asymptotic superfunction `Asymptotic`.

Consider this inverse Laplace transform:

✕
InverseLaplaceTransform[1/(s Sqrt[s^3 + 1]), s, t] |

There’s no exact symbolic solution for it. But there is an asymptotic approximation when *t* is close to 0:

✕
Asymptotic[InverseLaplaceTransform[1/(s Sqrt[s^3 + 1]), s, t], t -> 0] |

Sometimes it’s convenient to not even try to evaluate something exactly—but just to leave it inactive until you give it to `Asymptotic`:

✕
Asymptotic[ DSolveValue[Sin[x]^2 y''[x] + x y[x] == 0, y[x], x], {x, 0, 5}] |

`Asymptotic` deals with functions of continuous variables. In Version 12.1 there’s also `DiscreteAsymptotic`. Here we’re asking for the asymptotic behavior of the `Prime` function:

✕
DiscreteAsymptotic[Prime[n], n -> Infinity] |

Or the factorial:

✕
DiscreteAsymptotic[n!, n -> Infinity] |

We can ask for more terms if we want:

✕
DiscreteAsymptotic[n!, n -> Infinity, SeriesTermGoal -> 5] |

Sometimes even quite simple functions can lead to quite exotic asymptotic approximations:

✕
DiscreteAsymptotic[BellB[n], n -> Infinity] |

Math is big, and math is important. And for the Wolfram Language (which also means for Mathematica) we’re always pushing the frontiers of what’s computable in math.

One long-term story has to do with special functions. Back in Version 1.0 we already had 70 special functions. We covered univariate hypergeometric functions—adding the general * _{p}F_{q}* case in Version 3.0. Over the years we’ve gradually added a few other kinds of hypergeometric functions (as well as 250 other new kinds of special functions). Typical hypergeometric functions are solutions to differential equations with three regular singular points. But in Version 12.1 we’ve generalized that. And now we have Heun functions, that solve equations with four regular singular points. That might not sound like a big deal, but actually they’re quite a mathematical jungle—for example with 192 known special cases. And they’re very much in vogue now, because they show up in the mathematics of black holes, quantum mechanics and conformal field theory. And, yes, Heun functions have a lot of arguments:

✕
Series[HeunG[a, q, \[Alpha], \[Beta], \[Gamma], \[Delta], z], {z, 0, 3}] |

By the way, when we “support a special function” these days, there’s a lot we do. It’s not just a question of evaluating the function to arbitrary precision anywhere in the complex plane (though that’s often hard enough). We also need to be able to compute asymptotic approximations, simplifications, singularities, etc. And we have to make sure the function can get produced in the results of functions like `Integrate`, `DSolve` and `Sum`.

One of our consistent goals in dealing with superfunctions like `DSolve` is to make them “handbook complete”. To be sure that the algorithms we have—that are built to handle arbitrary cases—successfully cover as much as possible of the cases that appear anywhere in the literature, or in any handbook. Realistically, over the years, we’ve done very well on this. But in Version 12.1 we’ve made a new, big push, particularly for `DSolve`.

Here’s an example (oh, and, yes, it happens to need Heun functions):

✕
DSolveValue[(d + c x + b x^2) y[x] + a x y'[x] + (-1 + x^2) y''[x] == 0, y[x], x] |

There’s a famous book from the 1940s that’s usually just called *Kamke*, and that’s a huge collection of solutions to differential equations, some extremely exotic. Well, we’ll soon be able to do 100% of the (concrete) equations in this book (we’re still testing the last few…).

In Version 12.0 we introduced functions like `ComplexPlot` and `ComplexPlot3D` for plotting complex functions of complex variables. In Version 12.1 we now also have complex contour plotting. Here we’re getting two sets of contours—from the `Abs` and the `Arg` of a complex function:

✕
ComplexContourPlot[ AbsArg[(z^2 - I)/(z^3 + I)], {z, -3 - 3 I, 3 + 3 I}, Contours -> 30] |

Also new in 12.1 is `ComplexRegionPlot`, which effectively solves equations and inequalities in the complex plane. Like here’s the (very much branch-cut-informed) solution to an equation whose analog would be trivial over the reals:

✕
ComplexRegionPlot[Sqrt[z^(2 + 2 I)] == z^(1 + I), {z, 10}] |

In a very different area of mathematics, another new function in Version 12.1 is `CategoricalDistribution`. We introduced the idea of symbolic representations of statistical distributions back in Version 6—with things like `NormalDistribution` and `PoissonDistribution`—and the idea has been extremely successful. But so far all our distributions have been distributions over numbers. In 12.1 we have our first distribution where the possible outcomes don’t need to be numbers.

Here’s a distribution where there are outcomes `x, y, z` with the specified probabilities:

✕
dist = CategoricalDistribution[{x, y, z}, {.1, .2, .7}] |

Given this distribution, one can do things like generate random variates:

✕
RandomVariate[dist, 10] |

Here’s a 3D categorical distribution:

✕
dist = CategoricalDistribution[{{"A", "B", "C"}, {"D", "E"}, {"X", "Y"}}, {{{2, 4}, {2, 1}}, {{2, 2}, {3, 2}}, {{4, 3}, {1, 3}}}] |

Now we can work out the PDF of the distribution, asking in this case what the probability to get `A`, `D`, `Y` is:

✕
PDF[dist, {"A", "D", "Y"}] |

By the way, if you want to “see the distribution” you can either click the + on the summary box, or explicitly use `Information`:

✕
Information[dist, "ProbabilityTable"] |

There are lots of uses of `CategoricalDistribution`, for example in machine learning. Here we’re creating a classifier:

✕
cf = Classify[{1, 2, 3, 4} -> {a, a, b, b}] |

If we just give it input 2.3, the classifier will give its best guess for the corresponding output:

✕
cf[2.3] |

But in 12.1 we can also ask for the distribution—and the result is a `CategoricalDistribution`:

✕
cf[2.3, "Distribution"] |

✕
Information[%, "ProbabilityTable"] |

In Version 12.0 we introduced industrial-scale convex optimization. We covered most of the usual problem classes (like linear, semidefinite, quadratic and conic). But there was one straggler: geometric optimization. And now we’re adding that for 12.1:

✕
GeometricOptimization[\[Pi] r (r + Sqrt[h^2 + r^2]), {1 <= \[Pi]/ 3 h r^2 }, {h, r}] |

✕
GeometricOptimization[ 1/(h w d), {h <= 2 w, d <= 2 w, h*w + h*d <= 50, 2 w*d <= 20}, {h, w, d}] |

You can solve all sorts of practical problems with `GeometricOptimization`—with thousands of variables if need be. As one example, consider laying out rectangles of certain sizes with a certain partial ordering in *x* and *y*. To specify the problem, you give a bunch of inequalities:

✕
With[{c1 = 0.25, c2 = 0.618}, ineqs = {{c1 + w[1] + x[1] <= x[2], c1 + w[1] + x[1] <= x[3], c1 + w[1] + x[1] <= x[4], c1 + w[1] + x[1] <= x[5], c1 + w[1] + x[1] <= x[6], c1 + w[1] + x[1] <= x[7], c1 + w[2] + x[2] <= x[3], c1 + w[4] + x[4] <= x[5], c1 + w[2] + x[2] <= x[3], c1 + w[2] + x[2] <= x[5], c1 + w[2] + x[2] <= x[7], c1 + w[4] + x[4] <= x[3], c1 + w[4] + x[4] <= x[5], c1 + w[4] + x[4] <= x[7], c1 + w[6] + x[6] <= x[5], c1 + w[8] + x[8] <= x[4], c1 + w[9] + x[9] <= x[4], c1 + w[10] + x[10] <= x[4], c1 + w[10] + x[10] <= x[6], c1 + w[6] + x[6] <= x[7], c1 + w[8] + x[8] <= x[9], c1 + w[8] + x[8] <= x[10], x[1] >= 0, x[8] >= 0, w[3] + x[3] <= \[ScriptW], w[5] + x[5] <= \[ScriptW], w[7] + x[7] <= \[ScriptW]}, {c1 + h[1] + y[1] <= y[6], c1 + h[1] + y[1] <= y[7], c1 + h[1] + y[1] <= y[8], c1 + h[1] + y[1] <= y[9], c1 + h[1] + y[1] <= y[10], c1 + h[2] + y[2] <= y[4], c1 + h[2] + y[2] <= y[9], c1 + h[4] + y[4] <= y[6], c1 + h[3] + y[3] <= y[5], c1 + h[5] + y[5] <= y[7], c1 + h[9] + y[9] <= y[6], c1 + h[9] + y[9] <= y[10], y[1] >= 0, y[2] >= 0, y[3] >= 0, h[6] + y[6] <= \[ScriptH], h[7] + y[7] <= \[ScriptH], h[8] + y[8] <= \[ScriptH], h[10] + y[10] <= \[ScriptH]}, {c2 <= h[1]/w[1] <= (1 + c2), c2 <= h[2]/w[2] <= (1 + c2), c2 <= h[3]/w[3] <= (1 + c2), c2 <= h[4]/w[4] <= (1 + c2), c2 <= h[5]/w[5] <= (1 + c2), c2 <= h[6]/w[6] <= (1 + c2), c2 <= h[7]/w[7] <= (1 + c2), c2 <= h[8]/w[8] <= (1 + c2), c2 <= h[9]/w[9] <= (1 + c2), c2 <= h[10]/w[10] <= (1 + c2)}, {h[1] w[1] == 1, h[2] w[2] == 2, h[3] w[3] == 3, h[4] w[4] == 4, h[5] w[5] == 5, h[6] w[6] == 6, h[7] w[7] == 7, h[8] w[8] == 8, h[9] w[9] == 9, h[10] w[10] == 10}}]; |

It then takes only about a second to generate an optimal solution:

In optimization, there are usually two broad types: continuous and discrete. Our convex optimization functions in 12.0 handled the case of continuous variables. But a major new feature—and innovation—in 12.1 is the addition of support for discrete (i.e. integer) variables, and for mixed discrete and continuous variables.

Here’s a very simple example:

✕
QuadraticOptimization[ 2 x^2 + 20 y^2 + 6 x y + 5 x, -x + y >= 2, {x \[Element] Integers, y \[Element] Reals}] |

If *x* wasn’t constrained to be an integer, the result would be different:

✕
QuadraticOptimization[ 2 x^2 + 20 y^2 + 6 x y + 5 x, -x + y >= 2, {x, y}] |

But—as with our other optimization capabilities—this can be scaled up, though the combinatorial optimization that’s involved is fundamentally more computationally difficult (and for example it’s often NP-complete). And actually the only reason we can do large-scale problems of this kind at all is that we’ve implemented a novel iteration-based technique that successfully unlocks mixed convex optimization.

I’ve been trying to make good vector plots for about 40 years, but in the past it just never worked. If the vectors got too short, you couldn’t see their direction—and if you made them longer they crashed into each other. But particularly after our success in Version 12.0 in cracking the `ComplexPlot` problem (which had also been languishing for a long time) we decided for Version 12.1 to try to solve the vector-plotting problem once and for all. And, I’m happy to say, we seem to have been able to do that.

So now, you can just ask `VectorPlot` (and all sorts of related functions) to make a vector plot, and you’ll automatically get something that’s a good representation of your vector field:

✕
VectorPlot[{2 x^2 - y^2, 3 x y}, {x, -5, 5}, {y, -5, 5}] |

✕
VectorPlot[{2 x^2 - y^2, 3 x y}, {x, -5, 5}, {y, -5, 5}, VectorPoints -> 30] |

What’s the trick? It’s basically about placing vectors on a hexagonal grid so they’re packed better, and are visually more uniform. (You can also make other choices if you want to.) And then it’s about using appropriately scaled color to represent vector magnitudes.

There are all sorts of other challenges too. Like being able to draw vectors in a region:

✕
VectorPlot[{2 x^2 - y^2, 3 x y}, {x, y} \[Element] Disk[{0, 0}, 3]] |

And putting together our complex-number-plotting capabilities with our new vector plotting, we also in 12.1 have `ComplexVectorPlot`:

✕
ComplexVectorPlot[z^ Log[z], {z, 6}, PlotLegends -> Automatic] |

Before there were gray scales, there were things like cross-hatching. Look at a book from a century ago (or less), and you’ll see all sorts of diagrams elegantly drawn with things like cross-hatching. Well, now we can do that too.

✕
Graphics[Style[RegularPolygon[5], HatchFilling[]]] |

✕
Plot[{Sin[x], Cos[x]}, {x, 0, 10}, Filling -> Axis, FillingStyle -> HatchFilling[]] |

Of course, everything is computable:

✕
Graphics[Table[ Style[Disk[RandomReal[10, 2]], HatchFilling[RandomReal[{0, 2 \[Pi]}]]], 50]] |

We also have an important generalization of cross-hatching: `PatternFilling`. Here are examples with named patterns:

✕
Graphics[Style[Disk[], PatternFilling["DiamondBox"]]] |

✕
Graphics[Style[Disk[], PatternFilling[{"Checkerboard", Red, Black}]]] |

You can use any image as a pattern too:

✕
GeoGraphics[ Style[Polygon[Entity["Country", "UnitedStates"]], PatternFilling[CloudGet["https://wolfr.am/L9r9AL5O"], 270]]] |

Version 12.1 also has what one can think of as 3D generalizations of these kinds of textures:

✕
Graphics3D[Style[Icosahedron[], HatchShading[]]] |

It looks pretty good even in black and white:

✕
Graphics3D[Style[Icosahedron[], HatchShading[]], Lighting -> "Accent"] |

There’s stipple shading too:

✕
Plot3D[Exp[-(x^2 + y^2)], {x, -2, 2}, {y, -2, 2}, PlotStyle -> {White, StippleShading[]}, Mesh -> None, Lighting -> "Accent"] |

In the past few versions, we’ve introduced deeper and deeper coverage of computational geometry. In coming versions, we’re going to be covering more and more of computational topology too. Things like `EulerCharacteristic` and `PolyhedronGenus` were already in Version 12.0. In Version 12.1 we’re introducing several powerful functions for dealing with the topology of simplicial complexes, of the kind that are for example used in representing meshes.

This makes a connectivity graph for the dimension-0 components of a dodecahedron, i.e. its corners:

✕
MeshConnectivityGraph[Dodecahedron[], 0] |

Here’s the corresponding result for the connectivity of lines to lines in the dodecahedron:

✕
MeshConnectivityGraph[Dodecahedron[], 1] |

And here’s the connectivity of corners to faces:

✕
MeshConnectivityGraph[Dodecahedron[], {0, 2}] |

It’s a very general function. Here are the graphs for different dimensional cells of a Menger sponge:

✕
Table[MeshConnectivityGraph[MengerMesh[2, 3], d], {d, 0, 3}] |

Given a mesh, it’s often useful to do what amounts to a topological search. For example, here’s a random Voronoi mesh:

✕
vm = VoronoiMesh[RandomReal[1, {200, 2}]] |

Here are the 10 closest mesh cells to position `{.5, .5}` (the `2` before each index indicates that these are dimension-2 cells):

✕
NearestMeshCells[vm, {.5, .5}, 10] |

Now highlight these cells:

✕
HighlightMesh[vm, %] |

`Dataset` has been a big success in the six years since it was first introduced in Version 10.0. Version 12.1 has the beginning of a major project to upgrade and extend the functionality of `Dataset`.

The first thing is something you might not notice, because now it “just works”. When you see a `Dataset` in a notebook, you’re just seeing its displayed form. But often there is lots of additional data that you’d get to by scrolling or drilling down. In Version 12.1 `Dataset` automatically stores that additional data directly in the notebook (at least up to a size specified by `$NotebookInlineStorageLimit`) so when you open the notebook again later, the `Dataset` is all there, and all ready to compute with.

In Version 12.1 a lot has been done with the formatting of `Dataset`. Something basic is that you can now say how many rows and columns to display by default:

✕
Dataset[CloudGet["https://wolfr.am/L9o1Pb7V"], MaxItems -> {4, 3}] |

In Version 12.1 there are many options that allow detailed programmatic control over the appearance of a display `Dataset`. Here’s a simple example:

✕
Dataset[CloudGet["https://wolfr.am/L9o1Pb7V"], MaxItems -> 5, HeaderBackground -> LightGreen, Background -> {{{LightBlue, LightOrange}}}, ItemDisplayFunction -> {"sex" -> (If[# === "female", \[Venus], \[Mars]] &)} ] |

A major new feature is “right-click” interactivity (which works on rows, columns and individual items):

`Dataset` is a powerful construct for displaying and computing with tabular data of any depth. But sometimes you just want to enter or edit simple 2D tabular data—and the user interface requirements for this are rather different from those for `Dataset`. So in Version 12.1 we’re introducing a new experimental function called `TableView`, which is a user interface for entering—and viewing—purely two-dimensional tabular data:

✕
TableView[{{5, 6}, {7, 3}}] |

Like a typical spreadsheet, `TableView` has fixed-width columns that you can manually adjust. It can efficiently handle large-scale data (think millions of items). The items can (by default) be either numbers or strings.

When you’ve finished editing a `TableView`, you can just ask for `Normal` and you’ll get lists of data out. (You can also feed it directly into a `Dataset`.) Like in a typical spreadsheet, `TableView` lets you put data wherever you want; if there’s a “hole”, it’ll show up as `Null` in lists you generate.

`TableView` is actually a dynamic control. So, for example, with `TableView[Dynamic[x]]` you can edit a `TableView`, and have its payload automatically be the value of some variable `x`. (And, yes, all of this is done efficiently, with minimal updates being made to the expression representing the value of `x`.)

Machine learning is all the rage these days. Of course, we were involved with it even a very long time ago. We introduced the first versions of our flagship highly automated machine-learning functions `Classify` and `Predict` back in 2014, and we introduced our first explicitly neural-net-based function—`ImageIdentify`—in early 2015.

And in the years since then we’ve built a very strong system for machine learning in general, and for neural nets in particular. Several things about it stand out. First, we’ve emphasized high automation—using machine learning to automate machine learning wherever possible, so that even non-experts can immediately make use of leading-edge capabilities. The second big thing is that we’ve been curating neural nets, just like we curate so many other things. So that means that we have pretrained classifiers and predictors and feature extractors that you can immediately and seamlessly use. And the other big thing is that our whole neural net system is symbolic—in the sense that neural nets are specified as computable, symbolic constructs that can be programmatically manipulated, visualized, etc.

In Version 12.1 we’ve continued our leading-edge development in machine learning. There are 25 new types of neural nets in our Wolfram Neural Net Repository, including ones like BERT and GPT-2. And the way things are set up, it’s immediate to use any of these nets. (Also, in Version 12.1 there’s support for the new ONNX neural net specification standard, which makes it easier to import the very latest neural nets that are being published in almost any format.)

This gets the symbolic representation of GPT-2 from our repository:

✕
gpt2 = NetModel["GPT-2 Transformer Trained on WebText Data", "Task" -> "LanguageModeling"] |

If you want to see what’s inside, just click—and keep clicking to drill down into more and more details:

Now you can immediately use GPT-2, for example progressively generating a random piece of text one token at a time:

✕
Nest[StringJoin[#, gpt2[#, "RandomSample"]] &, "Stephen Wolfram is", 20] |

Hmmmm. I wonder what that was trained on….

By the way, people sometimes talk about machine learning and neural nets as being in opposition to traditional programming language code. And in a way, that’s correct. A neural net just learns from real-world examples or experience, whereas a traditional programming language is about giving a precise abstract specification of what in detail a computer should do. We’re in a wonderful position with the Wolfram Language, because what we have is something that already spans these worlds: we have a full-scale computational language that takes advantage of all those precise computation capabilities, yet can meaningfully represent and compute about things in the real world.

So it’s been very satisfying in the past few years to see how modern machine learning can be integrated into the Wolfram Language. We’ve been particularly interested in new superfunctions—like `Predict`, `Classify`, `AnomalyDetection`, `LearnDistribution` and `SynthesizeMissingValues`—that do “symbolically specified” operations, but do them using neural nets and modern machine learning.

In Version 12.1 we’re continuing in this direction, and moving towards superfunctions that use more elaborate neural net workflows, like GANs. In particular, Version 12.1 introduces the symbolic `NetGANOperator`, as well as the new option `TrainingUpdateSchedule`. And it turns out these are the only things we had to change to allow our general `NetTrain` function to work with GANs.

A typical GAN setup is quite complicated (and that’s why we’re working on devising superfunctions that conveniently deliver applications of GANs). But here’s an example of a GAN in action in Version 12.1:

How do you add metadata annotations to something you’re computing with? For Version 12.1 we’ve begun rolling out a general framework for making annotations—and then computing with and from them.

Let’s talk first about the example of graphs. You can have both annotations that you can immediately “see in the graph” (like vertex colors), and ones that you can’t (like edge weights).

Here’s an example where we’re explicitly constructing a graph with annotations:

✕
Graph[{Annotation[1 -> 2, EdgeStyle -> Red], Annotation[2 -> 1, EdgeStyle -> Blue]}] |

Here we’re annotating the vertices:

✕
Graph[{Annotation[x, VertexStyle -> Red], Annotation[y, VertexStyle -> Blue]}, {x -> y, y -> x, y -> y}, VertexSize -> .2] |

`AnnotationValue` lets you query values of annotations:

✕
AnnotationValue[{%, x}, VertexStyle] |

Something important about `AnnotationValue` is that you can assign it. Set `g` to be the graph:

✕
g = CloudGet["https://wolfr.am/L9rgvixl"]; |

Now do an assignment to an annotation value:

✕
AnnotationValue[{g, x}, VertexStyle] = Green |

Now the graph has changed:

✕
g |

You can always delete the annotation if you want:

✕
AnnotationDelete[{g, x}, VertexStyle] |

If you don’t want to permanently modify a graph, you can just use `Annotate` to produce a new graph with annotations added (`3` and `5` are names of vertices):

✕
Annotate[{CloudGet["https://wolfr.am/L9rpqPJ0"], {3, 5}}, VertexSize -> .3] |

Some annotations are important for actual computations on graphs. An example is edge weighting. This puts edge-weight annotations into a graph—though by default they don’t get displayed:

✕
Graph[Catenate[ Table[Annotation[i -> j, EdgeWeight -> GCD[i, j]], {i, 5}, {j, 5}]]] |

This displays the edge weights:

✕
Graph[%, EdgeLabels -> "EdgeWeight"] |

And this actually does a computation that includes the weights:

✕
WeightedAdjacencyMatrix[ CloudGet["https://wolfr.am/L9rtJdd9"]] // MatrixForm |

You can use your own custom annotations too:

✕
Graph[{Annotation[x, "age" -> 10], Annotation[y, "age" -> 20]}, {x -> y, y -> x, y -> y}] |

This retrieves the value of the annotation:

✕
AnnotationValue[{CloudGet["https://wolfr.am/L9rx8Mxe"], x}, "age"] |

Annotations are ultimately stored in an `AnnotationRules` option:

✕
Options[CloudGet["https://wolfr.am/L9rx8Mxe"], AnnotationRules] |

You can always give all annotations as a setting for this option.

A major complexity with annotations is when in a computation they should be preserved—or combined—and when they should be dropped. We always try to keep annotations whenever it makes sense:

✕
TransitiveReductionGraph[CloudGet["https://wolfr.am/L9rBdIZt"]] |

Annotations are something quite general, that apply not only to graphs, but to an increasing number of other constructs too. But in Version 12.1 we’ve added something else that’s specific to graphs, and that handles a complicated case there. It has to do with multigraphs, i.e. graphs with multiple edges between the same vertices. Take the graph:

✕
Graph[{1 -> 2, 1 -> 2}] |

How do you distinguish these two edges? It’s not a question of annotation; you actually want these edges to be distinct, just like the vertices in the graph are distinct. Well, in Version 12.1, you can give names (or “tags”) to edges, just like you give names to vertices:

✕
EdgeTaggedGraph[{1 -> 2, 1 -> 2} -> {a, b}] |

In the edge list for this graph the edges are shown “tagged”:

✕
EdgeList[%] |

The tags are part of the edge specification:

✕
InputForm[%] |

But back to annotations. Another kind of structure that can be annotated just like graphs is a mesh. This is saying to annotate dimension-0 boundary cells with a style:

✕
Annotate[{MengerMesh[2], {0, "Boundary"}}, MeshCellStyle -> Red] |

A completely different kind of structure that can also use annotations is audio. This annotates an `Audio` object with information about where there’s voice activity in the audio:

✕
AudioAnnotate[ExampleData[{"Audio", "MaleVoice"}], "Voiced"] |

This retrieves the value of the annotation:

✕
AnnotationValue[%, "Voiced"] // TimelinePlot |

We’ll be rolling out annotations in lots of other things too. One that’s coming is images. But in preparation for that, in Version 12.1 we’ve added some new capabilities to `HighlightImage`.

Use machine learning to find what’s in the picture:

✕
ImageBoundingBoxes[CloudGet["https://wolfr.am/L9qz1zu4"]] |

Now `HighlightImage` can use the annotation information:

✕
HighlightImage[CloudGet["https://wolfr.am/L9qz1zu4"], %] |

`Nothing` has been a big success:

✕
{a, b, Nothing, c, Nothing} |

Before `Nothing`, you always had to poke at a list from the outside to get elements in it deleted. But `Nothing` is a symbolic way of specifying deletion that “works from the inside”.

Pretty much as soon as we’d invented `Nothing`, we realized we also wanted another piece of functionality: a symbolic object that would somehow automatically disgorge its contents into a list. People had been using idioms like `Sequence@@`… to do this. But `Sequence` is a slippery construct, and this idiom is fragile and ugly.

The functionality of our auto-inserter was easy to define. But what were we going to call it? For several years this very useful piece of functionality languished for want of a name. It came up several times in our livestreamed design reviews. Every time we would discuss it for a while—and often our viewers would offer good suggestions. But we were never happy with the name.

Finally, though, we decided we had to solve the problem. It was a painful naming process, culminating in a 90-minute livestream whose net effect was a change in one letter in the name. But in the end, we’re pretty happy with the name: `Splice`. `Splice` is a splice, like for film, or DNA—and it’s something that gets inserted. So now, as of Version 12.1 we have it:

✕
{a, b, Splice[{x, y, z}], c, d} |

Of course, the more common case is something like:

✕
{a, b, x, c, d} /. x -> Splice[{p, q, r}] |

There’s a lot of strange (and potentially buggy) `Flatten` operations that are going to be avoided by `Splice`.

One of the things we’re always trying to do in developing Wolfram Language is to identify important “lumps of computation” that we can conveniently encapsulate into functions (and where we can give those functions good names!). In Version 12.1 there’s a family of new functions that handle computations around subsets of elements in lists:

✕
SubsetCases[{a, b, a, b, a, c}, {x_, y_, x_}, Overlaps -> True] |

I must have written special cases of these functions a zillion times. But now we’ve got general functions that anyone can just use. These functions come up in lots of places. And actually we first implemented general versions of them in connection with semantic-query-type computations.

But on the theory that any sufficiently well-designed function eventually gets a very wide range of uses, I can report that I’ve recently found a most unexpected but spectacular use for `SubsetReplace` in the context of fundamental physics. But much more on that in a little while…

Talking about physics brings me to something else in 12.1: new functions for handling time. `DateInterval` now provides a symbolic representation for an interval of time. And there’s an interesting algebra of ordering that needs to be defined for it. Which includes the need for the symbols `InfinitePast` and `InfiniteFuture`:

✕
Today < InfiniteFuture |

We’re always working to make the Wolfram Language easier and more elegant to use, and Version 12.1 contains the latest in an idea we’ve been developing for symbolic functional programming. If you think of a built-in function as a verb, what we’re adding are adverbs: constructs that modify the operation of the verb.

A first example is `OperatorApplied`. Here’s the basic version of what it does:

✕
OperatorApplied[f][x][y] |

Why is this useful? Many functions have “operator forms”. For example, instead of

✕
Select[{1, 2, 3, 4}, PrimeQ] |

you can say

✕
Select[PrimeQ][{1, 2, 3, 4}] |

and that means you can just “pick up” the modified function and do things with it:

✕
Map[Select[PrimeQ], {{6, 7, 8}, {11, 12, 13, 14}}] |

or (using the operator form of `Map`):

✕
Map[Select[PrimeQ]][{{6, 7, 8}, {11, 12, 13, 14}}] |

OK, so what does `OperatorApplied` do? Basically it lets you create an operator form of any function.

Let’s say you have a function `f` that—like `Select`—usually takes two arguments. Well, then

✕
OperatorApplied[f][y] |

is a function that takes a single argument, and forms `f[x,y]` from it:

✕
OperatorApplied[f][y][x] |

`OperatorApplied` allows for some elegant programming, and often lets one avoid having to insert pure functions with `#` and `&` etc.

At first, `OperatorApplied` may seem like a very abstract “higher-order” construct. But it quickly becomes natural, and is particularly convenient when, for example, one has to provide a function for something—like as a setting for an option, the first argument to `Outer`, and so on.

By default, `OperatorApplied[f][y]` creates an operator form to be applied to an expression which will become the first argument of `f`. There’s a generalized form in which one specifies exactly how arguments should be knitted together, as in:

✕
OperatorApplied[f, 4 -> {3, 2, 1, 4}][x][y][z][u][v] |

`CurryApplied` is in a sense a “purer” variant of `OperatorApplied`, in which one specifies up front the number of arguments to expect, and then (unless specified otherwise) these arguments are always used in the order they appear. So, for example, this makes a function that expects two arguments:

✕
CurryApplied[f, 2][x][y] |

✕
CurryApplied[f, 2][x][y][z][u][v] |

Needless to say—given that it’s a purer construct—`CurryApplied` is itself curryable: it has an operator form in which one just gives the number of arguments to expect:

✕
CurryApplied[2][f][x][y][z][u][v] |

In Version 12.1, there’s another convenient adverb that we’ve introduced: `ReverseApplied`. As its name suggests, it specifies that a function should be applied in a reverse way:

✕
ReverseApplied[f][x, y, z] |

This is particularly convenient when you’re doing things like specifying sorting functions:

✕
Sort[{5, 6, 1, 7, 3, 7, 3}, ReverseApplied[NumericalOrder]] |

All of this symbolic functional programming emphasizes the importance of thinking about symbolic expressions structurally. And one new function to help with this is `ExpressionGraph`, which turns the tree structure (think `TreeForm`) of an expression into an actual graph that can be manipulated:

✕
ExpressionGraph[{{a, b}, {c, d, e}}] |

✕
ExpressionGraph[{{a, b}, {c, d, e}}, VertexLabels -> Automatic] |

While we’re talking about the niceties of programming, one additional feature of Version 12.1 is `TimeRemaining`, which, as the name suggests, tells you how much time you have left in a computation before a time constraint hits you. So, for example, here `TimeConstrained` said the computation should be allocated 5 seconds. But after the `Pause` used about 1 second, there was a little less than 4 seconds remaining:

✕
TimeConstrained[Pause[1]; TimeRemaining[], 5] |

If you’re writing sophisticated code, it’s very useful to be able to find out how much “temporal headroom” you have, to see for example whether it’s worth trying a different strategy, etc.

In using the Wolfram Language the emphasis is usually on *what* the result of a computation is, not *why* it is that. But in Version 11.3 we introduced `FindEquationalProof`, which generates proofs of assertions given axioms.

`AxiomaticTheory` provides a collection of standard axiom systems. One of them is an axiom system for group theory:

✕
axioms = AxiomaticTheory[{"GroupAxioms", "Multiplication" -> p, "Identity" -> e}] |

This axiom system is sufficient to allow proofs of general results about groups. For example, we can show that—even though the axioms only asserted that `e` is a right identity—it is possible to prove from the axioms that it is also a left identity:

✕
FindEquationalProof[p[e, x] == x, axioms] |

This dataset shows the actual steps in our automatically generated proof:

✕
Dataset[%["ProofDataset"], MaxItems -> {6, 1}] |

But if you want to prove a result not about groups in general, but about a specific finite group, then you need to add to the axioms the particular defining relations for your group. You can get these from `FiniteGroupData`—which has been much extended in 12.1. Here are the axioms for the quaternion group, given in a default notation:

✕
FiniteGroupData["Quaternion", "DefiningRelations"] |

To use these axioms in `FindEquationalProof`, we need to merge their notation with the notation we use for the underlying group axioms. In Version 12.1, you can do this directly in `AxiomaticTheory`:

✕
AxiomaticTheory[{"GroupAxioms", "Quaternion", "Multiplication" -> p, "Identity" -> e}] |

But to use the most common notation for quaternions, we have to specify a little more:

✕
AxiomaticTheory[{"GroupAxioms", "Quaternion", <|"Multiplication" -> p, "Inverse" -> inv, "Identity" -> e, "Generators" -> {i, j}|>}] |

But now we can prove theorems about the quaternions. This generates a 54-step proof that the 4th power of the generator we have called `i` is the identity:

✕
FindEquationalProof[p[i, p[i, p[i, i]]] == e, %] |

In addition to doing mathematical proofs, we can now use `FindEquationalProof` in Version 12.1 to do general proofs with arbitrary predicates (or, more specifically, general first-order logic). Here’s a famous example of a syllogism, based on the predicates `mortal` and `man`. `FindEquationalProof` gives a proof of the assertion that Socrates is mortal:

✕
FindEquationalProof[ mortal[socrates], {ForAll[x, Implies[man[x], mortal[x]]], man[socrates]}] |

I think it’s pretty neat that this is possible, but it must be admitted that the actual proof generated (which is 53 steps long in this case) is a bit hard to read, not least because it involves conversion to equational logic.

Still, `FindEquationalProof` can successfully automate lots of proofs. Here it’s solving a logic puzzle given by Lewis Carroll, that establishes (here with a 100-step proof) that babies cannot manage crocodiles:

✕
FindEquationalProof[ Not[Exists[x, And[baby[x], manageCrocodile[x]]]], {ForAll[x, Implies[baby[x], Not[logical[x]]]], ForAll[x, Implies[manageCrocodile[x], Not[despised[x]]]], ForAll[x, Implies[Not[logical[x]], despised[x]]]}] |

The Wolfram Language knows about many things. One of them is geography. And in Version 12.1 we’ve substantially updated and expanded our sources of geographic data (as well as upgrading our server-based algorithms). So, for example, the level of detail available in typical maps has increased substantially:

For many years now we’ve had outstanding geodetic computation in the Wolfram Language. And we also have excellent computational geometry for doing all sorts of computations on regions in Euclidean space. But of course the Earth is not flat, and one of the achievements of Version 12.1 is to bring our region-computation capabilities to the geo domain, handling non-flat regions.

It’s an interesting exercise in geometry. We have things like the polygon of the United States defined in geo coordinates—as a lat-long region on the Earth. But to use our computational geometry capabilities we need to make it something purely Euclidean. But we can do that by using our geodesy capabilities to embed it in full 3D space.

So now we can just compute the centroid of the region that is the US:

✕
RegionCentroid[Polygon[Entity["Country", "UnitedStates"]]] |

That third element in the geo position is a depth (in meters), and reflects the curvature of the US polygon. And, actually, we can see this directly too:

✕
DiscretizeRegion[Entity["Country", "UnitedStates"]["Polygon"]] |

This is a 3D object, so we can rotate it to see the curvature more clearly:

We can also work the other way around: taking geo regions and projecting them onto a flat map, then computing with them. One knows that Greenland looks very different sizes with different map projections. Here’s its “map area” in the Mercator projection (in units of degrees-squared):

✕
Area[GeoGridPosition[Entity["Country", "Greenland"]["Polygon"], "Mercator"]] |

But here it is (also in degrees-squared) in an area-preserving projection:

✕
Area[GeoGridPosition[Entity["Country", "Greenland"]["Polygon"], "CylindricalEqualArea"]] |

And as part of the effort to make “geo everything”, Version 12.1 also includes `GeoDensityPlot` and `GeoContourPlot`.

Every second of every day there is new data flowing into the Wolfram Knowledgebase that powers Wolfram|Alpha and Wolfram Language. Needless to say, it takes a lot of effort to keep everything as correct and up to date as possible. But beyond this, we continue to push to cover more and more domains, with the goal of making as many things in the world as possible computable.

I mentioned earlier in this piece how we’re extending our computational knowledge by curating one particular new domain: different types of data structures. But we’ve been covering a lot of different new areas as well. I was trying to think of something as different from data structures as possible to use as an example. I think we have one in Version 12.1: goat breeds. As people who’ve watched our livestreamed design reviews have commented, I tend to use (with a thought of the Babylonian astrologers who in a sense originated what is now our scientific enterprise) “entrails of the goat” as a metaphor for details that I don’t think should be exposed to users. But this is not why we have goats in Version 12.1.

For nearly a decade we’ve had some coverage of a few million species. We’ve gradually been deepening this coverage, essentially mining the natural history literature, where the most recent “result” on the number of teeth that a particular species of snail has might be from sometime in the 1800s. But we’ve also had a project to cover at much greater depth those species—and subspecies—of particular relevance to our primary species of users (i.e. us humans). And so it is that in Version 12.1 we’ve added coverage of (among many other things) breeds of goats:

✕
Entity["GoatBreed", "OberhasliGoat"]["Image"] |

✕
EntityList[ EntityClass["GoatBreed", "Origin" -> Entity["Country", "Spain"]]] |

It may seem a long way from the origins of the Wolfram Language and Mathematica in the domain of mathematical and technical computing, but one of our great realizations over the past thirty years is just how much in the world can be put in computable form. One example of an area that we’ve been covering at great depth—and with excellent results—is food. We’ve already got coverage of hundreds of thousands of foods—packaged, regional, and as-you’d-see-it-on-menu. In Version 12.1 we’ve added for example computable data about cooking times (and temperatures, etc.):

✕
Entity["FoodType", "Potato"][ EntityProperty["FoodType", "ApproximateCookingTimes"]] |

Books have ISBNs. Chemicals have CAS numbers. Academic papers have DOIs. Movies have ISANs. The world is full of standardized identifiers. And in Version 12.1 we’ve introduced the new symbolic construct `ExternalIdentifier` as a way to refer to external things that have identifiers—and to link them up, both among themselves, and to the entities and entity types that we have built into the Wolfram Language.

So, for example, here’s how my magnum opus shows up in ISBN space:

✕
ExternalIdentifier["ISBN10", "1-57955-008-8"] |

Right now we support 46 types of external identifiers, and our coverage will grow broader and deeper in the coming years. One particularly nice example that we’re already covering in some depth is Wikidata identifiers. This leverages both the structure of our built-in knowledgebase, and the work that we’ve done in areas like SPARQL support.

Let’s find our symbolic representation for me:

✕
\!\(\*NamespaceBox["LinguisticAssistant", DynamicModuleBox[{Typeset`query$$ = "stephen wolfram", Typeset`boxes$$ = TemplateBox[{"\"Stephen Wolfram\"", RowBox[{"Entity", "[", RowBox[{"\"Person\"", ",", "\"StephenWolfram::j276d\""}], "]"}], "\"Entity[\\\"Person\\\", \\\"StephenWolfram::j276d\ \\\"]\"", "\"person\""}, "Entity"], Typeset`allassumptions$$ = {}, Typeset`assumptions$$ = {}, Typeset`open$$ = {1}, Typeset`querystate$$ = {"Online" -> True, "Allowed" -> True, "mparse.jsp" -> 0.488214`6.140155222562331, "Messages" -> {}}}, DynamicBox[ ToBoxes[AlphaIntegration`LinguisticAssistantBoxes["", 4, Automatic, Dynamic[Typeset`query$$], Dynamic[Typeset`boxes$$], Dynamic[Typeset`allassumptions$$], Dynamic[Typeset`assumptions$$], Dynamic[Typeset`open$$], Dynamic[Typeset`querystate$$]], StandardForm], ImageSizeCache -> {117., {7., 16.}}, TrackedSymbols :> {Typeset`query$$, Typeset`boxes$$, Typeset`allassumptions$$, Typeset`assumptions$$, Typeset`open$$, Typeset`querystate$$}], DynamicModuleValues :> {}, UndoTrackedVariables :> {Typeset`open$$}], BaseStyle -> {"Deploy"}, DeleteWithContents -> True, Editable -> False, SelectWithContents -> True]\) |

Now we can use the `WikidataData` function to get my WikidataID:

✕
WikidataData[Entity["Person", "StephenWolfram::j276d"], "WikidataID"] |

✕
InputForm[%] |

Let’s ask what Wikidata classes I’m a member of:

✕
WikidataData[Entity["Person", "StephenWolfram::j276d"], "Classes"] |

Not that deep, but correct so far as I know.

There’s lots of data that’s been put into Wikidata over the past few years. Some of it is good; some of it is not. But with `WikidataData` in Version 12.1 you can systematically study what’s there.

As one example, let’s look at something that we’re unlikely to curate in the foreseeable future: famous hoaxes. First, let’s use `WikidataSearch` to search for hoaxes:

✕
WikidataSearch["hoax"] |

Hover over each of these to see more detail about what it is:

✕
WikidataSearch["hoax"] |

OK, the first one seems to be the category of hoaxes. So now we can take this and for example make a dataset of information about what’s in this entity class:

✕
WikidataData[ EntityClass[ ExternalIdentifier["WikidataID", "Q190084", <|"Label" -> "hoax", "Description" -> "deliberately fabricated falsehood made to masquerade as the truth"|>], All], "WikidataID"] |

We could use the Wikidata `ExternalIdentifier` that represents geo location, then ask for the locations of these hoaxes. Not too many have locations given, and I’m pretty suspicious about that one at Null Island (maybe it’s a hoax?):

✕
GeoListPlot[ Flatten[WikidataData[ EntityClass[ ExternalIdentifier["WikidataID", "Q190084", <|"Label" -> "hoax", "Description" -> "deliberately fabricated falsehood made to masquerade as the \ truth"|>], All], ExternalIdentifier["WikidataID", "P625", <|"Label" -> "coordinate location", "Description" -> "geocoordinates of the subject. For Earth, please note that \ only WGS84 coordinating system is supported at the moment"|>]]]] |

As another example, which gets a little more elaborate in terms of semantic querying, let’s ask for the opposites of things studied by philosophy, giving the result as an association:

✕
WikidataData[ EntityClass[All, ExternalIdentifier["WikidataID", "P2579", <|"Label" -> "studied by", "Description" -> "subject is studied by this science or domain"|>] -> ExternalIdentifier["WikidataID", "Q5891", <|"Label" -> "philosophy", "Description" -> "intellectual and/or logical study of general and fundamental \ problems"|>]], ExternalIdentifier["WikidataID", "P461", <|"Label" -> "opposite of", "Description" -> "item that is the opposite of this item"|>], "Association"] |

You have an image of a molecular structure diagram, say from a paper. But how can you get the molecule it represents in a computable form? Well, with Version 12.1 all you need do is use `MoleculeRecognize`:

✕
MoleculeRecognize[CloudGet["https://wolfr.am/L9rL9B2K"]] |

It’s the analog of `TextRecognize`, but for molecules. And what it produces is a Wolfram Language symbolic representation of the molecule. So, for example, you can then generate a 3D structure:

✕
mol = MoleculeRecognize[CloudGet["https://wolfr.am/L9rL9B2K"]]; |

✕
MoleculePlot3D[mol] |

Or you can compute the distribution of torsion angles of the structure:

✕
Histogram[MoleculeValue[mol, "TorsionAngle"], 360] |

You can also connect to the world of external identifiers:

✕
MoleculeValue[mol, "PubChemCompoundID"] |

But what’s really useful about `MoleculeRecognize` is that it can be used programmatically. Take all the images of chemicals from a paper, “molecule OCR” them—then do things like check whether the molecules are equivalent, or make a word cloud of their 3D structures:

✕
WordCloud[ MoleculePlot3D /@ DeleteDuplicates[MoleculeRecognize[{\!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qm4VVX5BvBSTGwSM8vUTEzTUjOHDNEyVDSaQ8kUS0HAqBwCC9RSaZJM Tc1GrTSFQrFBDQQtpcxyaLCyOacsxyybbF5/f+v/LJ7t6XI498K5Z59zv/d5 Tsa955y799rrXd/7DetbIycfNX7aGo95zGNmDn/kf8ZPmjVmxoxJx+434pF/ TDhy5vTDj5w6ZdyRx0w9fOqMUZPXfOSH8x953fvIa9gjrxQIBAKBQCAQCAQC gUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAg EAi0gH//+9/pb3/7W/rNb36Tbrnllvy69dZb00MPPZT+85//dPryAoEhCxy8 6aab0oIFC9LZZ5+dZs2alSZPnpxfRx99dDrzzDPTV77ylfTTn/40Pfzww52+ 3EBgSOHOO+9M5513XjrggAPSNttskzbccMO07rrrpic+8Yn59eQnPzltvPHG aeedd07Tp09PixYtSg8++GCnLzsQGBK4//7701lnnZVe8IIXZD4OGzYsbbLJ JmnXXXdN48aNS/vuu2964QtfmJ7+9Kenxz3ucWm99dZLY8eOTQsXLkx//vOf O335gUBPg9950UUXZT6utdZa2Xbutttuac6cOenLX/5y+s53vpO+9a1vZT4e f/zxaaeddkrDhw9P66yzTnrVq16VvvnNb4aPGgi0ET/4wQ/SG97whsw7NvS1 r31t5uY999yT+fvPf/4z/eMf/0h//etf0913350uuOCC9JKXvCStvfbamc94 e++993b6NgKBnoT47TnnnJM233zzpO3wqFGjluvX//73v//zfj/74x//mD75 yU+mrbfeOj32sY9No0ePTkuXLu3A1QcCvY8//OEPaebMmdmGsov+/+9+97um n8HTX//61+nQQw/Nvilbesopp2Q7GwgEVi9+9rOfpQkTJmR7KGZ77rnnZtu6 MtC/c+fOTeuvv37+7BFHHJF++9vfDsIVBwJDC1dffXXaY489luvcJUuWtPzZ 888/P2255Zb5s/I1P/7xj9t4pYHA0MTixYszN/Hsla98Zbrhhhta/qxaBjFe nx0zZkxatmxZG680EBia+PrXv77cju65557pG9/4RsufvfDCC3PcqPD7xhtv bOOVBgJDE3KfL3vZyzLP1BZ98YtfbOlzfNYPfvCD6SlPeUr+7GGHHZZuu+22 9l5sIDAEIT570EEH5bjPBhtskE4//fT0l7/8ZaWfU2s/bdq0HAsW2z3uuOOi LjAQaAPkQU866aQ0YsSIXP83fvz4rFmb1Q2pZ1CXtOOOO2Zub7HFFmnevHlR axQItAFynVdddVWO+ay55pppo402SrNnz877WuRXGuFn3/72t3Mct9T1vulN b8rvDwQC7QGNeuqpp6bNNtss85RdPOqoo9Jll12WfvKTn6Tbb789v26++eZ0 8cUXp4MPPjjrYjaUDzt//vz097//vdO3EQj0LGhUXMRL+9HYRhx88YtfnKZM mZJmzJiRX2984xvTDjvskOuKcHnkyJHpfe97X/ZNA4FAe0HD2tt97LHH5j0v 9qA9/vGPX75v1OsJT3hC/pl6pL333jt96EMfynVKrdQlBQKBVYdYEE176aWX pne/+91p4sSJaa+99sr7RtU5yNGo0WU7+bD2uvzrX//q9GUHAkMKdK/9aPal /fznP881DmK48qb2kP7qV79KDzzwQPY/+9oXEwgEBgf4R8Piov0seMvO4nBw MxDoDHCP/bR/BR+rwFWxIT1VgqOBQGdg7/ZnPvOZXOMnFlTFD3/4w+yH+v19 993XoSsMBIY27C3TM0XfsUsuueRRv/vc5z6Xtt122/SKV7wi+6WBQGDwIVa7 ++67p2c84xnZXlZxxhln5HyM/KjahkAgMPgQv2UrcfHTn/70o36n1l5dw/bb b5/3jQYCgcHH5z//+fS85z0vOBoI1BTB0UCg3lAv//znPz84GgjUFGqK9LYO jgYC9cT3vve9fDZEcDQQqCdwVO+w4GggUE+oTbDnrC+OfuQjH8l50+BoINA5 XHfddWmfffbpk6Mf/ehHcx+V4Ggg0Dk0s6Mf/vCH09Oe9rTg6BCCvcH2O8Ue 4frAOaL6YIc/OnRhH+Itt9ySrrjiivTZz34214A62/1rX/ta7vP68MMP9/k5 e6XkBbyc6RV7o9qD73//+yuM6zrjW6+j4Ghvwt5De5s+9alP5X7m6radd2ld 1oOOvtLvCm/Nk8YezJdffnk+t9b77McI29se6Pv3mte8JvzRIQZ7+Z1X8OY3 vznzUQ8rfc2dQfDMZz4zP3f9l9dbb7201VZb5V6tzhyp9rFy3p7zubzPet5X 39fAqqMZR88888z8c3VIzvgO9Ab01XCOO36K2+MmHr7+9a/P/ef0dH3/+9+f +1htt912mb94ePjhh+eeykXTOjNa71day9yJfujtQeGo2BDNU/UpSu7lWc96 Vrrgggs6eJWB1Qn7+t/73vdmW7nWWmulXXfdNWsmPunvf//7/HvnSOvtSufK n+vduskmm2Rf1e+BHaWNn/rUp2a+Rq/I9qBwVJ/O00477VF9re3xtr56NmII gd6AMwf23XfftMYaa6TnPOc5mV+42cgx/3buyIIFC/J5lvor64WOu4C/tK7+ rrgbWrc9+O53v5v7LAwfPjy95z3veVRc4Atf+ELeW+rV6tlqgXpDzypalj7y zKdPn55jt81isnfccUf+jPiQ3jneD/Tts5/97LTOOuvk9T042h44H3jcuHFZ y8i1VPuOnXPOOVnnRsyodyBfMnny5GwTxRo+8YlP/E+vuUawp3fffXeO7erj WrQW34g/6nwR/mucLdIelNyLeLvnZS0sOWz6VsxvqHDUXPzTn/6UtUSv+lY/ +tGP0qtf/ep8fqweOPInrUA8yJyojkuJGfku9jU42h4Uf/RJT3pSOuaYY7Km FSvS28i/h4IdNe/uuuuu9NWvfjVrCb7V0qVLs+3oNa6WvYh45QwCvulAUWJG bPIHPvCB4GibUDgqfsDv3GWXXXK8j58hTyYu35+zvrsNDz30UFq2bFk+R8Pc de9eaq9OPPHEdM011+T39ArUEonj4qg4BF9noNALS17OHNH7dWWaOdB/0C7O eXnRi16Un5k4vDyYWN+mm26ax97P+S3msHNhesWuiFdan+g12k+Ob/3118+a wVk3eOq+5R34AHwCOrjb4Z75Np7r2LFjW+7JarxoDf3Si70sHGVHTz755LCj qxHqM53rYozlrdWS4KN8tbz2xz72sXw+2v7775/9jbXXXjvb2JkzZ2bN61l1 K1f523IH4mFqZ7beeut8/+5djv7888/PuYZ3vOMdee3CU+856KCD0sc//vGc Q1xR/Wo3wJlaYkb98Uf5onq8qm/ARTyHonXFG/lHUQu46sArz0ht5Vve8pa0 44475tovZ4rut99+2QcVt2Mv5Knt/xZzf/nLX579UnUOdNIJJ5yQ9aGcWrfU lsgtuCf+2BFHHJF5RzOIiekBbr7p0y9eZA2Tb1i4cGHOTbAVxom+ML/9XHy0 G9cpPLLW8m3ECe1taqzDbYQ12Zh5v7P0Cq9LzIjmUuMSNfUDBx7h5pVXXplz oM4BNufUJtA9eHj99ddnv6s679gc56Xho7oU2khezVmkNKDYivyqOV1nqJlR m+p6S88JtTEvfelLs11wD433bszc1y9+8Ys8FydMmJDno1oP8/S4447L42md qjM8Pz61dUUdH47iJW2Pp2IRxmZF6w39Om/evOwD8IXoLnWEUDhqLtEY3bhm 1QFsov1nOGZ/Ao6xH3yu448/PvPPc1xR/tna6Dnh+JIlS/LZ3mpO+G5skHO+ 6Ub6sW45bLwr3Bw/fnzWC+5/9OjR+T7YA3uqml23eYeH1jB8Vp9TalTtjfcz HHBuVZ3m6IMPPpiuvfbadMopp+T4rectl+ZZuhfc5N/QRm9729uyfm28frpj 8eLFuXbBOdF0Ld+8+OWFo7gecd3+Aa/4+DfeeGM6++yz8/MQAzHOYrUHHnhg 7qtLz7V6pqj38MPUmNA11lP61xqqXtBz9jxpwE77Ja6TzTCfcNM8klsSq546 dWr60pe+lONf8sBVre7cKfdgbOzZKn6ne8djv8dH+fqy3nnhAK5aDzqtKfBM rIF/SCPRoXSD67UmeTa0rbHx3MR76CLjwg/Ha/Ex67q9LNYka7p6v2nTpvVZ Ux/50f7BM+BXqQGhz6x99JlnJX5pXb3pppvycxqIL1lqOMUD586dmzngu9kV 53+LKyxatCjblcH2Vc2d2267LV144YV5PskZmVuuj7/NnrIXjdwskCv0Pr6q /ZT0obMdi30pmsK9yWEcffTR+W/YF2Lts26Z+7SgvzGYcD80gbyuPZ/4Z116 7nOfm2MP9i2JyZb7+OUvf5l5xddWy4eH9Cxei4/Jy9BJ6gVx3LiIG1U1R3C0 /6BH5eHZNPOM3WQ/aRXctM7zzVaHJpULowH1QxJD4tvxb8UV5BbZGjwejHxF OUNVPMgaUWI87Lxr4YNbl2jfZjZezBbvcNrnxcf4nY050qIpxNf4YcbXZ3BV jbl4sf0IbPVgrFN0rb2dc+bMyeuk9dLa/LrXvS7vZ7FmN65LxoGOEsd2vc7N 479Y07xwlm+wxx57pFmzZmWfqPFZOqfLvYt/+55O6yfgc8lXuDbj3wzWXu8X Q5X/L3XIfcH43XnnnTmOygbRWmyBz5rnxrLZusxv4GPII48ZMybHQ4yzNV4O wXfgUztyzL7T9RkT/i1Nhav0kznCnpsj7cpvGxe61BpEl/nb5po1w5xlV8Ql W1mX2AHxI5/Tk8B6w4awLbiojq76HDxj/GB/rQP+Jv+O/WKT8LvEv9sBupou pUldozG3tqhDcQ/mRF/7WQpwlp4yT8038V58nThxYo5niyXS/rSJNanRJ6Ix 6AnzlF3udFzXM7bn2RqNByurjbPuukfrkzHDu0YYO/dmDVJ3x0/cbbfdsg20 HnvO9Kmx8x7vra5Vxris5cXvYjvlCIy1fQniku2u/3Ad5m7RWu985ztzjMJ8 pbXkXK1tnunqeo7GztrAh5IPocusS3J+Rx55ZH4+fGNzqz+2zHPGadrwrW99 a75++T/PxJ5ne4Gsp+U5uB/j6zPWV7Eoz9s6gTM0o/UDX1aXpvC3zQV7w+wV 87xdo7lprM01NsS9tDLexhJXPT/fa864R5qr2fj5nN/XpUeZa5k9e/byfhLq Opvpb/fLJxo2bNjyvZnV+3B/Yjr4J39OW1h/6SVzmy3EN/82/t7jvWq3ik2g bT1/ZyqZn7QdTltXnf3bmE9oN4oGtO6ay3w688d47bzzzlmHsre33nrrgPV2 8bus3+yUtUANAm3HZxK79P1szEB1ZjXvImZt7eTfFRtFm7AvVZ/bf0tMzRk6 +E0DiinxVa2h5gx/gz8/0OvyzN07n1NdiblhbVZvgrOueaB7Ajw/f8NnuyXv XYX7tkaKM/e117IR1vBJkyZlf1qdDu1R3m8sPEvfx1/EYxyVt7QOnnTSSblW 1HMWM6S35Kb4GXLJtInvYJesG+wtncUvpLvom06ua2WOWyesF3IU1p1SA8G/ ETfs71y1XtOifF1+prGjR/lM4lfWPLp/dc2vEh8TA6Kh7OHzDKwJ/r5aLPax eh8+U/iNqyV2xa7S4bhK/xub/sSVSl2xecefcB38RfUlYsrWbna6TvmfwUaV o/gkD9zMFlQ5il98tdJjwliqt7M2+z7xBrFvNoZ+4+N4+Y6rr7462095A3Fy 9sJ88V3suFiB9bP4DXRXp/2CAuuE6xQPpH/x0/zGLTFndU3yBCvT4u6TL+g+ 5WPZDc/A9xkb4yZm1Kq2G8h9eB56WYopqc+ic1xHieX25aviKl+ZLyJWSufQ O3Sz5y1OYW9NszVF7prtlUOjm3GTPVdHYd33/NnWuuWmOwHjSFvhiTVxZfWJ VY4Wu1ueofVezpL99F1sY185gRLrN4/ZHnPb37d2ymOV31vH6ay6rqGukb8m l0En8JvMcf+lFfiO9GvjXDW+xlHdf7FHPsf3NOf5orSEcWv3ulTGmr82f/78 nM+gX0p+uNQIWiuq1+Ie+HWeuZgeXwRXrVV0E57hPt1chXWLXqJD2F73TNeW Hn18Tj5jndbkOuBd73pX5oi1UF1FM61S5aj3s7vV3C/b6Xdi5XIGzfjudzQe f4tNLnWWnc6X9wclhmi9KbEOcTFrlLlqX43aOnPVOKkXwE1ano7HTVqZbhaL Mx70yGD7TUX/lphN2XfgmYj38VPoBratXFupgSg2US6RBsBv6265J3F99tp3 l1phNldMgn7iF7PJtHcn7r0bUDiqN4S1jH9Ay/T1Mr/kAvDQGNOn4PnSzGwo +2oOmo8rgzXcumCu0sfskXW021B6HRgjcTTzU/yz1MLwK8WA+Vilrtj8F38x buIlddB25T74/65VLbN7KLUceIiP1ZhFiQHTt3TulClTsi22ThUOsqu4Wfbc WMvFJPi+8iwry/EOdRSO4h0bQIPwj/p64afn1chRPiMb4udifmxqq2MuVkrv +SytzJZ0K9wzm8nmWKdKfFZchQYWCzVu/HDxYfEX8dq+8nSdBM5ZM8QD3v72 t+f7KPEhvmqJtVZ9btdPg4kb8ckPOeSQ5XvkvMT3vdhadpktsI4HN1eOKkfZ QbmRUpfR+GIjy3urHC19+Pxc7rQ/PUjEj8Qwfdbzk4vsZhQfT5zM3gp7xNhU Y8uG8N3U79F2dH1d/e2Sc7KGuA8+jrwqzcNO8l0b6woB59hF9pH9lKfybK3t NLQ1mR/fak31UIc5UvbdGUd+Pz+JPqPXzCf1GWIH7Cudxtdo5KhYPe3i5/QM 7dYqcNTf9Fl7T1rtF1V38KvoRmOhPsT9yXP4tzxSp3Vtqyj6V/xPrJcd5auy jZ51qWWmdaucc39yUfRy6Y/g3sPn7B+sd/LGOMo+4qOYP62GO7in5q3U9Ik5 mmeNHFUTisN+bt30vlbBh2F7fdba4Ln2EuQv1H+6PzXH4m5lLpc4Ersy2PXq /UXJOclZso9iSSXmRQfZJyhnIj5UoJ5YvN69izXQFoH+QUyOLy9eRIvxofhT dIiXtdA6ai55RvxOcaVGjppjasr83HPz81b2C1T35vqsNcKa0Euorl98u2os TW6GbTLuq9LLbjBR6grthZM7klel4fna4glsatEIVY6ytyWXHmgd6mLl5Iwh nsrJy3utCNXcS5Wj/Bb1DPYDyaPQxmIKrfx93FaLyNf1HK0bvYRmHLW/Rg8F 65q9HN2Cas2VvCp9oHZTzFEepcR9qxw1P3qhv9lgQ17vgAMOyGPopWZzIBxl Z0s/Nb+Tk2Yfmn0Xne15ikNYH9Tu+o5ei/M142jpC8vXkIfoNpS91bSPGjP5 GnqgaCg+bOlNHRwdGMTk2DEcWRWOAl/DPhcxenaRj2KPCl+2GvcrPfz1PRAr UverPt++DjHEXkMzjqrFEYczBmK93Yqyn00srBqv5YvTv8HRgaOck7E6OOo5 iffIwRTtKk6Lt/YG81+87EfzvORZijZWyy3m14v9hlvhqJoGOeVuRl95lGpO Ljg6MLBb4jSlRl7tWrNxZP/UkeC0PKpar6qNLGfGif2yp76znJlsH5eXuG+x tX6nfsXeq17zQwta4ahx4Bv0GsIfXXXghZi5ehC1JPatN8vb4aAaapyTL2ns JWEtZYflbtTqy7GWvZb0HF7ip5/RuXKz+qCYt72aM2uFo/REVZP0CvTyUo8d HB04yvnk9v7xD1d2ZqP3qx+hy9SDiTk1vr/U2bC5cqzsg+cjxyNHpq7Jz2hb uZwV9crqFbTCUXkvdb69Br5RydUFRwcOdrOcfddKTJXP6P1sarP3F656L3uN s/KB/r+f9bffR7eiFY7SFtbJXoO9LiVvEBytP3B2KNZntsJR9ZV0Sa+BRiu5 F/t7GveTBgJ1QCscFQPvVX9UHb17l1ujpQKBuqEVjtqzpW9Ir0HPhXLvelPw TwOBuqEVjtpHIqbea6jmR8OOBuqKVjhq77Q6j16DvVLqkaOmPlBnDOX8qD0T Ja6rB11o3UAd0QpHu7WmfmVQD67HjnvHVftkAoG6oRWOqq3Um7/XwI7qFRMc DdQZrXDUvp9u2j/aKqo9KPQ/YlcDgbqhFY7qYdCLMaNqXDdiRoG6ohWO6sPg nKRew+rY9yLO5FXX/omB7kcrHNUX1TkevYZV5aheHdYuZ7M1O+s2EFgVtNqH Qe+1XsOqclR9rx4Bzgq2hyoQaAeG8t40cVznng+Uo/ZN6acudxwx4UC70ApH 9Z3pxXrdan50IBy1T4reda5F3fsPB7oXQ7lXCm7pl7UqMaOyp3Eo7msMDA7s /Sj9QlbEUedY9eL+UXGeUsOgd3O1h30gUBfoReCMlGYcdY6a83F7DdWaej0n 9fYMBOqGVjjqzBS9iHsNzmMtfRj0oONbBgJ1QytaV8yoW/Oj+mBde+21WQeI vVZrDXC09MAOrRuoK5rFjJyJ7dxlZ0p24x5v+UvnibKV2267bd4XUNWz1VpA 5/Pdc889HbzaQKBvNOOo3IS+48400p+rW8BWspE4OXr06Fwnte666+a+rGK5 BXq7TpgwYfm5jvpCBgJ1QzOO6oMqrqIep5w1VmeU8y0vueSSdNhhh6WRI0fm vJF+6HonO2NKT9YC7y3n8kWvlEBdUeWoed147hSeetU9/8c+qvmxzji/Gzf1 YTrkkENy/3Q2U51BuQ98doZaOd+dPxpx3UAdYc/G1KlT89k3ztNV8+cswGZn dtQJzhll6+fOnbu8X7c4tLNAnGXo3AK1CdVYET916dKlmc+bb755PiP+xBNP zH3TA4G6ARfVJzibVfzWeav6WF522WU5hlLXXv0455znc889Nx144IHLda3z 7uQ6ndNDu1bXGrZTrkl9rViY8731atpmm21WepZQINBJ0LfO0LV/Qw9Ac5cd mjNnTj4Psk55Q2uGWNall16a+4Q5n1v/34033jjXDC1cuDCfKVs9C8R/77rr ruyn6rdgHXKu3hZbbJH9UecD8U3rrucDQxfsC/13zTXXZM3n/GR60byXP3Se uZ7unT5/la6VDxJrpms32GCDHK8Vuz3hhBPSddddl/Vq1fbTucuWLcs1CqNG jcpn5FmH+KH2fdLCztLrtfPZA72HckYVGyX24hw5NmrEiBH5v9OmTctnKNOP g91zwLXxke2n1htM7xa9IXCOXbz44ouz7ayuIf6/eFjRBxtuuGHmZ9EH6jPE mejbsJ+BbgIbJP5pftvrwo6qqWevdt9995xjlMMYDP2LP7fffnu6/PLLl2tU /c/UD1szaFf+ZdV24pvPzJ8/P+9pcXatdUZs6NBDD83fZZ2xHgU3A90M2k9t HP1r3xZ+0r98Veegn3XWWbmuoR37JnFH/68rr7wy50SKrt10001zDTyNqqcf 7Vu16XgnnzJr1qy0ww475HWFrlWnIE4k/lvNvwQC3Y6q/hWjUS8nP0Nnbrnl lvl8XXWw8jera977e2r05ICsBTQqru2yyy7ZVxbD4jtX/Uc8FRO66KKLMh/Z fbrWter3d/3112efM+K2gV5F0b90JQ1Jd2633XY511G4c8MNN6ySTcUzdQbn nXdemjhxYq4/kAviC6utsBbccccd/1NPISbE3rKdahfoWlrYZ+bNm5evudOx rkBgsIBHagJxyT6YffbZJ2tfelIsh/4Vd+1vLQAbt2TJkpyXVfvObuKZ73R+ ON+4MV5rPWAf9UJjb2lh17LnnnvmOt2+ahcCgaEC8159wxVXXJH9Rb5fqb2j Ndkv9emt1D+Ix4pN7b333lmf4udee+2VuadOmF/aqGvFhNRd2FPnb6otEhti 3xctWpT/dujawFAH/qkToD/Vw4qhbrXVVpljciJymPIbfMdmXBWTYgf5uKX2 ffHixbl2tsoz+vaBBx7I68LMmTPT9ttvn2O84rXqjORY7A+t1i4EAoH/5yr9 q8aB7Rs7dmyufdhoo41ynQDdSZOuSP/Ke6q1ZY/V4/k3nlV9TraUhnZ2GxtL 14oL4fapp56afWEx6KhDCARWjKJ/1arPnj07x29oUHaOX+lMJ/mSxviNf9Om YsO4XvUfcU5NLhu5//775++iqdUWz5gxI1111VVRhxAI9ANF/6p9XbBgQa6n pV/xSq5G3YEaJnmSqs3zuSrH/H/7WEu9k5p3Gtp32GvGF2Vvow4hEBgYSvzX +Z5yKfanqt+T61QLrCaCH9pXrRKbKu4jn6N2QS6FrnXmQ6mvFa8NXRsIrDpw FZ/0/OKX0qv2muCrGkO1P0X/lvpD78NjfObTqpfnq1brawOBwOoFDorTqtNT z77TTjtl+4ivkyZNyrnWM844I02ZMiXnUOw1UyPB51THr1d16NpAoL3AL1yV 23TesDpCNfKlDpdtLTVCBx98cPY5xYsaa3IDgUB7UfTvzTffnGO9fFW9QXGT /pVLiRqhQKDzEPOhf/mqdC6+0sLiueFzBgL1QNG/4rvsZjf0HwwEAoFAIBAI BAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKB QCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUCg2/F/bm+/Rg== "], {{0, 166.}, { 233., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->Automatic, ImageSizeRaw->{233., 166.}, PlotRange->{{0, 233.}, {0, 166.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qm8pWMdB3BbkrZJlKJEUVKKRqgQ2caEzDSUtZkYkQyzYWYoCQmlkdRM JaVNG7JFImU3pdFqaZH2sqRN25Pv4/Ncr+OuM/eee973/H+fzzHjzjnnvs/7 Pv/t91+etadMmzB1uWWWWWbGSg/9Z8LkI7aePn3yURPHPPQ/kw6dcdCBhx6w /7hDZx5w4AHTN5uy/EM/PPuh1zLLLrPMCg/9kQKBQCAQCAQCgUAgEAgEAoFA IBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUBgCfHf//43Pfjg g+mf//xnfv373/8e9Of+9a9/pf/85z8jfIUjh//97395DWXt/u5nTYdnZ71/ +ctf0j333JNf9913X/r73/+e/y3QbHjGDzzwQPrNb36TfvKTn6Qbb7wxXXPN Nfm1ePHidPfdd6d77703y0NvICPec/PNN6c77rgj/eMf/+j39/meP/7xj+mX v/xl+t3vfjfg+0cSrt0+//3vf5+vfdGiRT1r/973vpd+/vOf52slH00DXX3/ /fen22+/PV133XXpvPPOS2effXZ+ff7zn0/f/OY3837485//3OezD9Qb9v7P fvazdOGFF6bjjz8+ve1tb0t77LFH2m233fJr8uTJ6Zhjjkmf+tSn0ve///2s J1pt4t/+9rf873vuuWd617velX7wgx/0+zvJmj02Y8aMNH/+/LzHRgNkms67 6qqr0qmnnpoOPfTQtNdee/WsfZ999kmzZ89OZ555ZpYPdrEp9tBzv/POO9OX vvSlNHPmzPTGN74xbbXVVukVr3hF2njjjdPmm2+eXv/616e3v/3t6eMf/3h+ pj4TaA48z29/+9tp7ty56XWve11aY4010lOf+tS02mqrpWc+85lplVVWSU95 ylPy38eOHZsOOeSQ9PWvfz37AlUd8Ktf/Sq99a1vTcsvv3xaf/3107nnntvv 7yXv5GzllVdOW265Zf7OdoM9o8/IPVlfe+2105gxY9LTn/70vF5/Wvuqq66a XvziF2dd8LnPfS79+te/rr0OsHY+3rx589JrXvOavMYnP/nJ6VnPelZ6/vOf n+/F6quvntfv9fKXvzxNnz4975XQAc2AuP6GG27Icmu/P/7xj8/P33444IAD 0qxZs9KUKVPS1ltvnffDE57whCwTEyZMyL7CX//6157vIs98BuPOnv3sZ2d7 0R9+/OMfp0mTJuX321vnn3/+SC/3UaC7+Pr03jrrrJPXbm2bbLJJ2nvvvbM9 nDp1atphhx2yPiMD5GOLLbZIn/jEJ9If/vCHtl7vcMLa+XtHHHFEft6Pe9zj st4fN25cOvLII9OHPvSh9IEPfCA/f3rxBS94QVpppZXSM57xjLT//vvnGK/O HE/gYbDZ9j89b/+/9KUvTYcddlj2B2+99dYcm99yyy1Z1vn0r371q7McPOlJ T8q28Lvf/W6PDzBU+f/pT3/a83621e9sJ8S8H/3oR9OLXvSitMIKK6TnPve5 6S1veUuOYezvX/ziF9nf5Zd88IMfTDvvvHO2kSuuuGLWh5deeumgedFOA47P 89lggw3Scsstl+Xbc7cme0JMJJ5zD8RF73znO7OOtkfslRNPPDHzIYH6Ar// hS98IW200UZ5D9gLnis57m1f4/Y++clP5viQvXjOc56TTj/99MwFwFDlH6fG znr/euutl7mmdoHOwu3ttNNOeS2u9x3veEe66aabeuUhxfyXXHJJmjhxYtZ9 dCDb6J7UEfSbtZBnOm3atGnpRz/6Ua82XZzjWdkb9IS9st1226Wrr766K/Ii TQXOy57n14nBDzrooMwB9/dMxfwnnXRS9hXF+eRdbgCGKv933XVX2m+//fL7 11133RxXtwtk/H3ve1+Oedh+HNd3vvOdfn1aNpGOYgeXXXbZzI2xl3XjAVzv woULczxHlrfZZpt05ZVXDrgO8dqb3/zmrC/pDJxJNf4L1AvXX3992nHHHXv8 78985jMD5neK3dx+++2zDPCd+RBQlX8+ovgRx89PlDsSL+PNyou87brrrvn9 fI8vf/nL7Vh2BrstjiX7eM73vve9Odc9EPjDuBIxwNOe9rR0yimn1I4L46+J +3E5T3ziE3P8Nxhfnv57//vfn3W7Z48XwiEE6gn8/Ete8pIsfzgecf5gQI75 DeyAPAE5Zzer8o8n23333fN+OeOMM9JZZ52VY+h3v/vdPS/+xgtf+ML8fvmm r33tayO84keA88R1+d3in8H+bnERvwFPyHYefvjhteMB6T75XDIshvNsBuvD XHTRRemVr3xlvm/uHxsSqCf4gDgvz5I8s9WDAR/huOOOy3EwOzhnzpzMpVXl n2yQEbw6H4HPzMfnF5QX+0mHeD/O3d5qFy677LLMZfrdeD1x/2ChZkEc7LPy l6NVt7CkEOO96U1v6tG7Q7nv6h/E/j5LD+BEAvVEVf7JML53MBAD4ADYfjaE 7lC/V5V/P8eR4QnWWmut9LznPe9Rf3rRAbgH7+eHtNP/r8q/eqWhyDAOQLzk s7vsskvm0uqEqvzL837jG98Y9GfJv9ivPLOvfvWrI3ilgZFEVf7VvA3W/uPO 5IPEjuy3fLHYuSr/5JqdOPbYY9Npp52W8wTVP73k1+XVRyP+r8r/UGUYr4k7 K7oDL1YnqPdz3a5f/CUOHCyPf/HFF6dNN900f/a1r31t+ta3vjXCVxsYKchz 88k9S3WfhccfCOJHtUG4MzZejC8urso/fhinVmrmSz+N95W+GvUF6ohGo/7H vpXDH2rs4brFPnwfMY6c+WD1Zqfgt7/9bX5+8jdqHfH4g+m9wPHgcnAG7ptc gJxhoJ64/PLLs//HVxcH8uUGqmfBE+kHKbIjDpY3gKXJ/6k7+spXvjJsaxsI rtX+JQOulV8yEI9f6gXVLJB9HCcdN9i4qVNA1vlldDf/7cADD8w+wUA+AL2h D4Bv53NqgcV9gXpCTYc+H7l/dkCPi/xWXzqA7KsZwN2TGTKAA7722mvzvw9V /uWO8Gejwf+rf9PnJPdnL7sOPX9qonoD2RDj4Mo33HDDnpwp37lu+X/Q48fv of9e9rKX5XXJ0fa2lrJ29Rk+w17gcdRARz9gfcGXPeecc7LvzZcng+zgbbfd 1tPz7cXvYzPUAtsnr3rVq7LMkB01wcX/XZr6v8022yzX0rQL9rSaF7X9auDE 8zhQ9czy49Zc1u4+yfGpgVavgPfwkv/+4Q9/2LZrHk6I4axX/RN7vu2222Y/ zjOWy3EPvNR7qQf+4he/mHW9nE+p/dYXHfV/9QYZVAtCXtWD0AG4PT6+2M5L nK7WE+cvXuAv8B3Vj6oFWtL6/5KHHo38H9jb9B0Okg4Qy/Bvybm6f2v3J/8G V/qGN7wh5yzJi/uArxzNmQVLA8/MujxDz9Kzp4NxG3wa94A/9tnPfjadcMIJ Od6j8zx7/U/eE7V/9Qf7pg5v3333zbyO58u3Gz9+fK5z86LrceS4QvuEDLAF +IJS+w/6eUpeaajyL/4fjVwSnSXuwYPb3/rb9EDrA7J2f+Io+Uil7wn/bRZA 3Xi/VuAt9Fx5tp699Xv2/Dv3QF2wHL9cLa5DH7g+7QULFkTc3yDQ4/hwfoCc mL3gWeO4PXc6wd/5ivJ0YmVcnZ6YKviOBx98cK778b7CC/YFfJK+E3EEe8rm tBul/19vi7y2eiW5i7L20uvjGvkH9KKeQT5xEyDmlwuVwxUD0IP6gd0DL8+c /NMDdDV/IGS/ecD5lTkw+D3PWk+MHL6XWl79bh/5yEdyzacYsRV8ARyR3JLc fuEF+4L36x0wTwSPLs4YDfCF8Zpy22p71SXz9cva2X81TvJkcia4gCbFvXQg Llb89eEPfzgdddRRWY974fg9GzVP4v2qvxdoHugB+9uzVhdGJvByZJl95zP2 t/fl+8mxmpiB+ml8j/eLG+QdRjuexPfxacT9/CHr9vJ3P8MX1JHrHwzKzFPP V1zm+XnRC6WGo0k6L9A/8AL88yLzTYe9/6c//SnrvtYZn+J8suDfmyoD9J41 6sus9kDLh8oH4UHlTAPdAbZOn4s6ETmxpoPNs168nv1eQC/gukteoInzf+m0 K664InMx7kHVb6P/cSPiubr1OQSWHLgAtXk4L3XCTQdOQw+02UbVnjb+gDgY D0gGmsh90WlyfHhba63ONHIv5AXVR3z6059ubPwTeDTUtegJkOvTt9/0WY/q Hch+6xxCvXLqhOUo6UP/3zTw9fR/qQFTC8zmF6jxkxORE/jYxz4W8t8lKPIv 3y8GGG1ubqTRl/xXZ5SqBVD/3zTwcdSBqwVuXSOZZ/v1iYoNmsp/BB6NIv/V /t4moz/7X2qa5DWrtrEpKP2A+jnkfKuzUIr88wPVStZ13nFgaCjyry726KOP bjz325f8V3sUmir/+jDVf+rrcQ/0RRQU+ecbqA3uqz8q0CzI/+t1wXvhf+ta 5z5Y9CX/pUeRbIiNyUrTQKcV+Vf363yfAvPey6wzvV5NzH8EHgv5IH0e6oDN fGh63FfmAekF0utWUI3/1SnylZsG9T1qHvF/av71ehWoz1TLHfLfXdAfbi6u nJCa0KZDP4M+eOfeVfsWukH+cTty/7geOp8vVKCeu8w6DPnvHpQ5zyX/1/S8 j7kGZN9MUjFvQVX+5cbVxzUNdJqzEPB/rfJf4v+Q/+4CDsh8Rz2h73nPe2p3 xsVQoe5vzTXXzH3LdEFBVf6dBdpE/g/HWeYw6fOvzvQM+e9OOBfa2Xh6f/UD Nr0HwHm3alzs9b78f/LfRP6vKv+eefVMj+IXhfx3F9gAXFC3+P9F/tW5VOud q/KvB0CfcNNQlX/nwZnxX0AXOr8l5L+7oNfFTC78fzfU/xb5N+Ooeg5xN/B/ eq9LjUNr/G8mEx445L+74Mx7c6DMvhH/N33uQ5H//up/myr/ZQ5bb/yfGYDs QMh/d8HsDzO51P+o/296/V83y7/6f/l/NX6t8s8XKmfEhvx3D5zFs/HGG+dz Acr5vk1GkX+xrn7/gm6Qf7rdOca95f+D/+9OmG2tHqbb5B/XbcZlQTfIv95O sw2c5dwq/2Y46/8N+e8uFPsv/++cnKbn/6v8n5q3gm6Qf/6/3obe/H89v+6J 2mD7IPp/ugN4n7Fjx+b43/zXpuv9bvb/zTLX96//p1X+zfwxE9w8dHmg6P/t DhT599zL+b5Nhrnm6v+60f+vxv96IK+66qrc7+WF/9P/Iw/kzPam74PAw/Mg S96X/6/+r+n5P36uPlexrpo3s37lxfTC6oNusvzz7cz8N+tBzRfdbwaQ3mf3 wtlMdIMZgeH/Nxvm3ZpxSdeTB3Ef3/CWW27JNcBNrQO0z8m++n/zjvDezkHU F4cHbbL8V+d/Was6x8MOOyzfB8/eeVC4QXMgQv6bC36gs7D0+zv3hu9v34uJ nQ2mR16s2DQugL8zf/783PvnbE/5bnKAD3D+FR+ozP8TDzQpF2LtzmtxxpE1 OvPMup2DWP4k++ZAdoMf2I0gz/pa+fzqQMR7eD97Xz28c+DkgPWGOAP4hhtu yOfGNUEO5DXotLlz5+ZeBzJgvzvvzywQPhD5x43ph8YT0AEDnYPU6fDs9P2b 8+48Q+ebWrsYAAeiD9BZ0O4Jv4BeNCNIPOSskKb6gd0Ecu9sG/1efDv9vuZ9 qPkX+zvzTsy35557ZllQC0Ae7APxMjlwDmAdOSF+rLXrczbXbvPNN89ybo3y nnxgcnHyySfnc0HpQvdGLSy/WH2kWKBu/jC5NctNbG/O0YwZM/J5xuTc+ui4 Y445Jl1wwQU5JtIXJP+H/3M2sHMg9UfhB/gCoQfqh3LWlTP9zHR1vrfY1x5Q /0re7X1nY7Pz3ocPcD4GP4BttGfEBPaQ99WlPoDdY7/MuBXnmHHKxylrN+vf 2p2FRU6sXz0wfeDsa/yA83BxgmIGZ+KYn+Wedjroaf2Lznun162Hb0fnyfU4 79y8f/2A5FpdkF5AZ6I6D5XuZxs8e/4SntBZSeLG0AOdD/4qOXWWJd2u54td p/f5fP6fTJD36rxvz5YcyAuzlbiBNdZYI8uNHoE5c+bkfmG8YafaQ2tnr+gq Pa32ujjf/mfXyDMdZ787D6MKPo55yPQAPpAPgCvweWeCLFy4MPMm7lknxkSu yZrE+Z4vG77eeutluZfbN998wYIFeeZr67nO7ht+0LPXB8YXov/sF7NC1Q2a FcefqIsN6EaQS7rfXE+5Hvoe12MPkGHcjri+qss9+6peL2eC8g2dF+M7fJ4e mDRpUvYl2EP2tZNiArbZdTvL2H7l69N5bDldpr/J/h7ofE/xEr+A/ysGwovS AyVeUDfEHrKbncINkElx2jnnnJO5Hbk8vC6dZ9a/+Oaaa67J+qG/a7YPyhnp 4gP8AN1p/XKGciXmhrqHdfCFugXkkH9Ktp1fv/POO2d5tf/pfr6+elccWJH1 wg3R6eK81t6/Igd8CLUx9pLvYw+nTJmSa8bY2dHmyEqcw66p7xs/fnyO4/n6 +A06jC7DfQ7FfyVT9Jx6ODGR+0kOzA+ePXt2PjNP7cBo+kLWjt8o+p7P7hlZ vxo/8orD8J6hPCN7w9r4Qp41rtj38glwBfZE8YUiJhhd8Hf5+nLZfHs+n72P zyH37DW9UGZ7eV72tjNvzH2eNWtW3s/e0xvYOX4/eyA3YA+ID3FI9tzll1+e 7W677QGdx54tXrw496/w9dk914a/4P/yd92bpcll+h38BveIfPl+OTMzdE45 5ZR8brL3tNMXKnGO87rNbRa3q2vkp8lpyvN7tvT90uhm+2TRokU5nsCZ2FP8 Kc+en0E/4BG8r1N8oW6Be158NXWdbJ3nr45DnGtvinOruVxyYLad/ey8H7aM f2fPmI3dF8i2mZjmheDFS0yAH+Br4MjIQbtiAmvnm/B3zeu19hLjk0u+Pj+1 Nc5dUrCHfCTnZLB/fCo6VmygpwbX4HroypG2h9bONpvdpH5nww03zNciVp84 cWKWVRzAcJ7lws7ji/QGsQF8Ifyw+ABXxP8YbV+oW0AW8XT2t7iO/JW8lTOc 2Sk1PN5TdDKZ9P/0gRzgLrvsku24GJFOF9fy5waCvU0O8Mf2GjtbYgL2V0yA Qxspv9Ce5mvwR/ge7BC5V78ir6l39dJLL817cSQ4OjGSeyjGYnOtX0xQ7nv5 3SMhB6V+Qy5Tr9a4ceOyrvfadtttM2+npp8OHgnYS9Zmb+FX1BK47/IF9iB7 Y56sfVa1AfYBPYw37u/lc3Rbb/uGDRPD+J5O5F7bAffU+ul28Rd/jM63//H7 JV9PPsv+K5wwmSSzbJccoBw4+beHPTc+3lB8ZM+DDNIl9IDvdB3kUf0s31PN yXD5hXSedRTZk88r+ktsyhflv1T5jZGC9eBaxNVyInjVUkOFa5NfcD/t5+GI iTxDz10uk9yTNTLnfstRkEU5Or5gO2Jx68f7yJ/ac/yPUkfl//lC1fpp+oiv 4rn197Kn+RHiiar+pPPpNT4mX3ek9FunouTz+JfirenTp2f/m93h7+K73D9c VfH17QN/xwnj/cgk/pqfKHbFDc2bNy/bkoH48L7gd5ADtWLsrjmC5IBN8Hfx hTiDbl9SOaDzPG++Scnn4Tf8Dr43Xo680Ynt9j2tiY5TG8F/IgdkEgfhnA26 2HWT3SW9v/wNz9CcFjE9fa9Gxz2gA8kgfd9u7sV6+Hj2nGtgV8g/DgIH5ecF 7oG5g67dy7V7r+fnJZaiz+xPsYUYA6dT7JG5pfa8z7nP5KBbUPp0Cv/E1vD3 cDD8P/eKPyZ3W0AO2EFn+4jVxfh8dHuTXLqX9qz7Olz2Ajegn5YdLvWk7KF6 c/zUUPPmrsv7+S1iCjE2H7v07tr75F4MRAeNJvfkfuPhXA9fSH0RXoSOdj/U W/Ob2bHBXKf3FJ5Gzl3tntjGcycnYjf12dbOxxhtsDO4Af3jcgVsAc61wN5V g6TuWH2xNeBR3R8vcu9n9qj+Q74k28THsA/kdfhVPm/tVd3SVJR4XT8ePoed I/N0P65OzS75FhMVGfYnH5mfyKenH+xDPB09SwezoXj/kbCVfBRyoE5GbELH 8wtdL/9jsHlz/86meb/cHbnnV1h/O+LcJYF771nwheQg8a/uvetWe6C2TrzE R+/v3pf6Dbl6Mq72xrp9l/x74drYhE7i20v+max6xlXusSr/dBg7xo/ll5o7 YE/Snc5d5wvQAWw9rtX3dJP8e6b2P7snHnIWDfmRc7IH7Cu9Kf697KPyGTLD BpNz95GuoEvF+HhC3Iz3jTQKVyxv7neL0127mEMtcV9581Krz5/xvhJXi3PM q+C3iPHbFecuKfj7cqJ8L9fND+IT8A3YSM9BzFXlyEq9sr0tX0t/eobiHDG+ ekRrd986ee29oSr/8jS4CrAOL2svPansGj9VPzpeg19blX/ch7pm+0TdClvm hTOoe01S0f32P5+PH+3545h32GGHzDXZV+SrzG1hc/mJeGd8OFvJ5vKT5WbU +7GVVT+hHXBt9rNn77o9f3JMD5S8uXoD12UN1lTyzHQGm8cftF/EvcV3qEvt qX1oT5JZuVk+bpWnVa9Ah7tHfDa+rjiH/1zqldlAPRvsYOlTqCOq8m9P81t7 gz2DM7Fu76UDxRH0ArvvZ+IgewQXSFfgg7zkQfmd7mPddIB1F7/dDF66jpzY A4Wnw5+Kscva/ElXkG3+MP1AZvgJ4n32s8Sdowk6B8+AbyDH7KBrJAdqk/jK /FnyXepW6S+2r/To4PbqIvet8JzoLRwILqTEufSaPavGmP/L1rHznjndTUfq 3ZHvaIfPNpIYjPwXW8a3dY/0YbtfbD89Kf71efcGhyX3yC6SE/sJ3+Rn8iN1 O7uR7SOr5k6UuhI5LXqNP8+OFLkvfiJbWepSSx7MZ3Gv9lP1M50Atosep9/0 EJR6UvoA51t4TWuRzxAvt/Yn1RUlXyj+54/R6fw6e5nMy5kWf4f/ph6TjMj1 d1J/xZKiKv/0u5otfn158QHZCHaAb4Svkp/mA7NfOCU+oc+X2SX2i3+XY/KZ whu4n2q961QjQMfjs8XrbB/dL59Hxovut4fU78oFsRl0AxtK7skN/8hn9Ph3 6uyW0mMmfsP34LbKzB3P3B7h66gxbHe80g5Yj7wMzkvNoj3MhsnH8vlL/YZ4 tpN099KiKv/4HLlRfl958eX1GdvD7oW5LOQYRygmrsb/ZpSIa90nuVc6Emci FqA/7Sc+QJ3OsbYWOS16TY8m3Y/fLfufX1Rqb/n1VT8RH05m8AL4jzrIDD3g WsVrcuaeK59OfZJ1NsHm9Qd7k08rp8/Hx9uceeaZOf7rVN29NKjKP/nl69B3 fAEvvqCfmT3GnomN8NUldq3KP19fzrs191PmF3uP+zlcdd/tADlgw9lzHFCV 17dOfqOcqhi/xDt6W+VRcKninU6WGb6Yfe1V9cs818LryP2Q/W6CZ8Yf8vzc m07K5w0nqvLPttvrclo40epLHKTPlC4Uv5b7UZV/ekOs3Hqv/A5xVR3lnw/E L+IPqiktoAf4Au4JuV955ZWzn8BHKP5PJ8t9gT0up8FHEQcXsIFyYp4ZLqz6 b4HmoCr/7LxaEBwAm1198fdxPq01TVX55++KH/v7HXzk1tkunQxcV+E0qvLP T1QDghMTF5V8nhqTuug3elqOAi+J38R1FIT8dweqssnus99DiVMHU/9TzrH3 Hryg+LIuIOO9yT/7717Jm+GExYv4ozrY/AL+Pn+Oz9d65nbIf3dgsPn/vjAY +Rcjqw3wHrnUTqiLHizIvzncrfJf8kby32qd6lj/Qc+reZPXUIOsL7Ag5L87 0A7518dWfkfd4n+5MLkLnB4/pmlg//EXrWdu0mulriPkv7loh/yXc+zrKP/s o5ofHKjahaahyL/8hjrAgir/H/LfXLRD/tW8sS91lH91O0X+S29Ek6CGV62C XD8+o8C8MP0cnpk+PzU/geYBX60XFceFw67GuIOBHgC14urj1ITriW0FuRE/ e4/Zb62zbDsZJf+nbl+OrGkwl9Scklb51/+j1pH8q/3XzxBoHtSsql9Rw2se 8VDnd/ALyxku+sZ6qxPR9+O7vQfHVCeurPj/TY3/9b7w/1vlH2ejP5b8m+vS xDN3Aw/Pc1DDLw9M9ofay4UH1x8g70+X9CbbZVY9X6MdM+CGE/r3zEXRv2Te S9PAv1G/0Cr/agHUNEb8H+hmFPnHj1X58aZAXb8+l1b5j/xfIPCI/Jt7YCZS 06BWWU93q/wH/x8IPCL/epjVQTcNJf/XKv/iwVKzFfIf6FYU+ZcbbWL+z5wS 8y5a5V/NpnxQyH+gm1Hkv7X+tymQu+mN/zMPqMx1CfkPdCuaLv9mXfaW/w/+ LxBovvz3Vf8T8h8IpDzPyOyjpsp/X/xfyH8gkHJNo7lnTZV/9X/mvoT8BwKP BfnAjzVV/vvi/0P+A4GH/WP20ex35/g0DSH/gUDfcCaG+R9mITsvqmko8h/z vwKBx8J5BeZ/sY9Nln85AGeXFIT8BwKPzP9tav9vkX/n4OoFKAj5DwRSWrBg QZ6P23T+T39DzP8MBB6Ncv5X0+VfD6A5bQUh/4FASqeffnqWj0033TRdcskl o305ww7rW3311bP/7yz7gqr8O7/RmYeBQLfhxBNPzPwffrw6H7cpKPV/7L/z zAuq8u88Y2e+BQLdhsL/m1/c2v9vVprz85xnZMZZHVH4jf7if2eD3XHHHaN4 lYHA6MB8PP6x808vvvjinp+bYWhGNvuph+7666/PMXLdzoZ3pvG66677mPkm Vfk3/9dZ7oFAt0FMvM466zyG/2Pvzc5zrqGzAfbZZ5/cS0dunA1al/OizTQf P3582nXXXfPMn4Lg/wKBR+Zjts7/Z+fNAzIjT/y8yiqrZD3gfOMrrrgiz8uu gy9gdrPzntX+VTm+kP9A4JHzP5xfZv5ndb65c0zFBIcffnieD+Z8Ezz6hAkT ct+Qs1Duueeejj4TWBzzwAMPPMpn8TPnf+y0004h/4GuxllnnZX9/1VXXTVN nTo1XX311Znvc3Y20AfONyHvzsviK3iv8wKcDa6m1hlJZKzTzz0ouuDOO+/M dQFyHiuuuGI+s40eCwS6DTi+vfbaK9t2PPnuu++e+T7+8X333dejB9hH/MBx xx2Xz1PjB6gbGDt2bJo+fXqOFciV81Y6jRtwPfSYWMB1kvdNNtkkxzT6HnAg dTqzKRAYLvCLnV8szlcHaBYA2XAmpnyZM4/KmUnsp3Py9AnPmjUr5wxWW221 rDe22WabNHfu3NxDcPfdd3dMvhBH4WxP5zeZdbbddtvl63Xd5n+bfxK5v0A3 g22/7LLL0sknn5zPOJUvMxNAToCtdIYymS42Urx/2223Zd9f7myjjTbKPUR4 Qmclk6lrr702f2/xH9oNuopPz79xBrAzXOk3vc6uV80PvsO6Oj1uCQRGGmSa vJJb56XqB2Qj11prrZw7UyfofEPcgPfyqfn6t956a5o/f34PN+AsUbVE5E0c gTtoJzfg9zh/md9CP5FzXAW5d3177LFHrgly/k+dzmkOBNqBct5pVXZK/wzf AF/oPNX7778/v9dLXk1OkN7Yfvvtc6+92Bo3MHv27HTRRRdlbmCk9YCYw/nM F1xwQZo5c2buaZDb4MvIb4pP8Jt4jU7jKAKBTgJZZSOL70z+2VB5QOdlmxXi rOMHH3wwv5883XXXXbmHaN68eWnLLbdMa665ZtYFdMKcOXPShRdemOWTnA6n /Inx+S5qFE866aT8+9Q00lt4CbqAr08H1aFmIRDoFLCVuLOjjz461wKyp17k yuyQm266KfcIFL6PfddLg1OcMWNG9gHGjBmTuQFyKY7wfXjEojuWFH6X61u8 eHGONfbdd998jinfQ6w/efLkfB34vaGe+x4IBB6GeJ/tVEd38MEH5zrAEudP mTIl1wawvWSx+PdkWwyuf2C33XbL/oMcI7mUYzzttNPSjTfemGuMlqR+yPfT M3oW9e/yS/gnfA4cpHMNXFPk9QKB4YGYgK3VU48T5NvjCDfYYIPMFaixpSdK rZ0Xv/zKK6/MuTc+Az+A7lB7wz7LvdMTg5VT+QTfSXfwJeTw+Pp8EvG+vKQc JP+ik+sSA4E6gkzLp8sJiunJHB1A/rbaaqvMsekjIH8l1uYTyLOdf/756cgj j8zn7uLk2GvxAd5QnqA/kPt777031yUtXLgw7b333jlPKe/ID1G7aL7P7bff HnIfCIww6AG23vwwsienzq7zv+UC+feLFi3KMltiAvqAz37eeeeladOm5c+I 1dUZ9DV7yGflGekHHN4hhxzS87v4EnSJGQbO8w1fPxBoL8QEZE+cP2nSpB7+ bf311++pseHfe18BPcCO4w3UHqshuu666x7z3ThFOQb+vL5D/CNfA6+/xRZb 5J8504NvEfm8QGD0gMeTW1f7p6+Ofy8mkHcXk6sBIMvVWmK1RPrwbr755swd FvDf1e75N9+nNplfIY+Aa+BvnHvuudn/WNocQiAQGB6QablAPTZ6hsk+W62n YMcdd8ycvBkc+IPe5LbU7qkvUn+EHzS3R78hv0K/vlpDfcfh6wcCnQk2ns/P 95cfJMNiAn3Gcn9iBXUDbHzhBshzqd3DDZTeIj4Ef+LUU0/N9cf8jPD1A4HO Bz2AA5SnwwmqAWDLnTW433775Xm8+ojUDaoJ8j41QmIHfgMdoN5A3iDmcwQC 9QNbbbam2QFqAOTrxQP0AN7f7IBjjz0284D0A7lXXyTGFwPoL8L/BwKB+oKf j/9TI6QuGDfAvy9nc5QzOkvfoN6DkPtAoFkQE6jHVzeghkfdLn5AbaAeAzG+ XGHE+IFAc6EuSA2v+fxnnHFGjvHVBkV/XiDQPVDjw96H3AcCgUAgEAgEAoFA IBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAI BAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCARGG/8HT54sqw== "], {{0, 161.}, { 256., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->{60.703125, Automatic}, ImageSizeRaw->{256., 161.}, PlotRange->{{0, 256.}, {0, 161.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qnc5WP5P/CxDYMaKlmSopJSoexNRAijaFCaUo0YScY0QzUZTIORJYwR UilKNWSyJHtE0jYyEaN916Z90fr9ed+v1z3/2/mfZ5s5Z875nnN9Xq/DM89z nvOc5Xt/7uv6XJ/rujc+5OgJk1ccNWrU9NUe+8+ESe/eZdq0STP2X+uxfxw4 ZfoRh0857NC9phxz2OGHTdv+kJUe++bdj93WW2HUqJUf+38VCAQCgUAgEAgE AoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFA IBAIBAKBQCAQCAQCgUAgUFP873//q/7973+nm68DgUCgVfjLX/5S3XvvvdWi RYvS14FAINAqPPTQQ9X06dOrww47rPra174WMUwgEGgZFi9eXB1wwAHVBhts UF1wwQXV3//+904/pUAg0CP4zW9+U02ePLladdVVUwzz/e9/v9NPKRAI9Aj+ 8Y9/VLNnz67WXnvtaty4cdUtt9zS6acUCAR6BPSW+fPnVy984Qurddddt7ro oouq//znP51+WoFAoEfwzW9+sxo/fnw1evToasaMGdUjjzzS6acUCAR6BA8/ /HB1xBFHJA1m4sSJ1QMPPNDppxQIBHoE//rXv6q5c+dWT3va06qXvvSl1c03 3xx16kAg0DLgFPruhhtumDSYf/7zn51+SoFAoEfwwx/+sDr44IOrMWPGVNOm TUs5UyAQCLQC6tSzZs2q1lprrWqfffapvv71r3f6KQUCgR7CJz7xieq5z31u 9fznP7+64oorqv/+97+dfkqBQKBHoP/ola98ZfXEJz6xOuOMM6JXIBAItAy/ //3vq6OOOirVqY855pjUOxAIBAKtgJr0Bz7wgWqdddZJPY/mNgQCgUCrcOml l1abbrpp9aIXvai66qqrwgcTCARahi996UvVy1/+8hTDnHvuuamuFAgEAq3A T3/602rSpEnJB/OOd7yj+slPftLppxQIBHoE4pX3v//91VOf+tRq7733rr76 1a92+ikFAoEeAb2F7vKSl7ykes5znlNdfvnlocEEAoGWYeHChdWrXvWqavXV V69OO+200GACgUDLwPdy9NFHV2ussUaamfmjH/2o008pEAj0CJyFZNb3M5/5 zGqXXXZJNaVAIBBoFcxrMAsGx3zsYx9LM2ICgUCgFXCOwOtf//qkwegV+OUv f9nppxQIBHoENN0TTjihGjt2bNJ6zegNBAKBVkGvgHkNzhZYsGBBzGsIBAIt w+233556BcycOv300+N86kAg0DKYmfnGN76xWmWVVdL5AtErEAgEWgXzpWgw 5k1Fr0AgEGg1PvKRj1Qbb7xx0mHmzZtX/eAHP6h++9vfVn/961+TTyYQCASW FjfddFPywein3nbbbaspU6ZUH/zgB5Pe++Uvf7l68MEHq5///OfVn//85zhX NhAIjAjmNbz5zW+uVlxxxXR+rPOR1JO23nrrarfddktnmpx00kmpD/IrX/lK tXjx4uSVkVvpi4zeyEAgMBD4YI477rjUiySG2WabbVJNafPNN095kzMfN9lk k2qrrbaqdt999+otb3lLmu/w+c9/Pnlm8M2vfvWr6m9/+1vKp4JvAoFABs/L mWeemebZbbTRRqmf+otf/GI6y+Tkk09OHl+xzDOe8YxqvfXWq9Zff/3q2c9+ duKhvfbaqzr00EPTWQRmPtx5552Jb+g3+CbyqUCgv/HII49UM2fOrJ785Cen GEVcIg6ht9BdzAC/+uqrE+8ceeSR1X777Zdmx4htNthggxTfmCPje7vuumv1 tre9rTrvvPOqa665Jp3h9t3vfndJPhUIBPoHziv59Kc/Xb3sZS9LuRHu+MY3 vvH/5ThyKBwhNnGG0pVXXlmdddZZSQvWWyC+edaznpVm4olxzA/ffvvtq/Hj x1eTJ09O+dR1112Xfv9nP/tZ4rQ4/zoQ6E3gD9zymc98Jmkqa665ZupznDBh QvXZz362WrRoUfXjH/843aexr9rvyn1+/etfp9gE31x77bXV+eefn7gEVzkf 8ulPf3r1lKc8pVp33XWTfrPjjjumub8nnnhi9eEPf7i65ZZbUm0Kb/3xj39M fBPaTSBQb1jD4gdxC25Ze+21U+yCX3CCGrU45j3veU+a26BGjUcefvjhpp4Y j/foo49Wv/vd7xJf3HbbbdUnP/nJ5Ns76KCD0nyZLbfcMmk2ZkHIq/DPDjvs kLRieZc+KL/n98U3eC34JhCoF6xXs+suu+yyVHum6dJceHfVjF7wghckjRfP iDnUqf1M74D+JLENj6++AhzVzH9H06Xd6DWg3dxxxx1L8qlDDjmkGjduXPW8 5z0v6Tb+llzK33nFK16Rfi6+wWtmXsmnxDaBQKD7gRM+/vGPJy6hze68884p r7n77rtT/HDJJZdUp5xySjq3xHoXc/DDuPn6xS9+cfXqV7+6mj59evL9qhc9 8MADyfM7EN/gNNqufOr+++9Pc60uvvjixCNvetObEt/Qh3GNGpX4Rm0c/6lN yb3ETYHehOtDrCrnjhln9YTPUBwwf/78lK/ol3bOvX9b934u7nAfNaOHHnqo uuGGG1LMoWZEp3Xeo/wm84CYAwe84Q1vqKZOnVp96EMfSnzjd+VSerGb1adx kL/D1/ftb387+YcvvPDCasaMGanXkpdY7EQrxoFmX8V84N4EXvnFL36Rrhv+ BvscL1XwTL3wpz/9KX1+eILeIicSf9A5BoKakc9ajuJzl1PxyagZ4SaaipqR 2EauQ1PBXW9961tTLnXFFVek+jS+oakMxDeuJbEPDqEr33jjjdU555yTciXP V68CP02gd5D3O7n2qaeemnJw/obXvOY1aU/jE7fvBc90N3yOtBCeFpqtmEDc 4Yx7ccpw9dP8OOISWq/rghaj7qy3QM1os802S7GN2APX5OtFjiMXwjdq33hk sPq079OI5FL4CTeFT693INc1m/VTn/pU8m66XvTvq2E+6UlPSrmy6+bss89O +5prJT7/7gRO4Ds54IADki/Fmhcb0F6XtTYjX1Zbvu+++1KtWX40a9asdN7J HnvskTQU8Y2cKvcX0G7kOxdddNGSepHH8Dxjr+pt+Hx91q5H1wB/FP+CHJgG t//++yfNz/XC64lnDjzwwKTVfe9734szuroMcqLrr78+cYvP0fp2nv1I4pbh gqZin6Gp0Hvl0zwuatziG94Xuq26FO0m51K5l0mt3Cw9+RHuw11Rm+4NiD1c G3xS8maeCD0m8nS+TNcIznHmn76UOXPmpGvDfohn7Inu42fi59iHOg/1mi98 4QtpT+BvUwO2jtvBLc3gmqLtyIVouGpAcjJ1qT333DNxnXkz4htcoy6llrXv vvtW733ve1M+h2fiWqovXGf2OHvGRz/60ZQLiUl4Iuw18nU+BLXHHJvYp1yj +lGmTZuWtH48I++m0dD/8FTkTJ2Bz1R+K35Qi/HZWMuzZ89OOm2nYoKsFdN6 XR/4Q57GV7PPPvskT5/6Ny4U34h39DDx7AXqB35LvMEfTu9XexRDy33win5Y vig80eyazBoN3xRPOF8WXrInTZw4MfGVONn9Is5dfvjDH/6Q6r3yDjEoLdc6 5ofrpn4fz0V9AOfRcMXH6gae90477ZR6s8VbOClQH+T4gx7Hb7DddtulHAe3 8Gsff/zxyTcpz8nXY/ZHNfOGqznS+dUQab65x22LLbZIsbCaKB6L3tn2w+cj rvQ5+AzEAT5POUq3c7xrDZe4luTZeq/lVaHp1QO5vsivTT/RR09rUw9SV+Q1 MJ+s3OdyX4nrUy6PK5pdq9lzrpbksXlDxeV0YfnTsccem64Z+1U37aG9Au8/ nhe30Nt9priFRq+2U7cZup6v6y7y6+5H7nWVy+APuQytj3ZLa3nd616XvJN4 B//keYf2DbUAvEC7VT/CSTwMA33uvi82ouXxfMr75dP8V/py586dm3rlBsq5 AksH7yc9w2eZ633vfOc7k64WfB5oF+wBeuzltrRYuVDWYs3s4F/hk6KhZc4w y0ycKn/iZeDTxA/2RBzzuc99bsh9BZ/ZN/XE8lbRZvg7aTNqpfpf6HzRU7Ls 8F6LK2mkuIXmQk8TSwa3BNoBHKE2KFaQf9PLXHc4Qh1QPMLbhEdy7Jzzp+98 5zspzsAreIivTrxDs8UXegWGE3vkXhZx0QUXXJDido8nbvIcjjrqqLTnls8h MDJ4f8WXPhvvq32A5oVb8E4g0EpkTz+O0Adr9kZe0/rh1Z/FDnIlsU3+HXEE f5zcx2xDfgS84nqVE6k5877grJHmNXhG7wiuoyerC+A6MTyvHk8Ez3jkTCMD vVxc+trXvjbloLQ03KL2mz/bQKBV4EOizfJB0ljECOrF1rLYWQxh1nvJEdmv K46gBdJi/Y7rVT+JnhG99O6zrOeei9XVkXCY2IVvL89RzB5g9eysAQUGBm7B 1/wt9g61ore//e3p8416S6CVEB/wPNi3+B6t26yp8kOa06HPXgyROSLzimuU X1ePPR7CLWpJNBN1Tvpuq3N4sZL+OL24+vppzHQDvbiHH3546pmjGcU6aY7M Lep9OQ6kt9x1110RtwRaCt5bHgG6iBwcp4wdOzatVbwifpYL5Vwcv8if5CNm Eopr+FWsb+vcY6gl3XPPPW3P3z0P+y1+EyvluImGTDOiD+HAWDP/D7iFLzdz Cy+kWBC3hN4SaBXs7erA9np7V64Du954q/Smqs/kGCDrMmo6zrRxHh8vthlD 2a+r7w3vqCUtL71V7EUvltPpudVPaT/2nPTZ8m/qeStjr35FI7fYS9QEv/Wt b0WsF2gJ5DV4hSbi3Cs9hlljoZXytomdy/Uov6HdykcyF+UzJORPHsd1yx/X KT9T1qTVvukIPO35DC88I6bCjfJA3Lc0N3GQNer/4r7sRc4375PbcB/PfT2O 99otzxfIjy+esO597e/6Hf/2d93Hv31ND+ONK/+273s89/N/vkQ8i1vsIzhY 3479IGrQgVbAdSQXMhuVXmKeBk8Jvjj66KNTHz7uyf2muW6jh4h26376AMQs ajh+x3qmsXRDj2r2AZoHYq6a2hd+UVM3R8TaUvtSj9W/MNIbDYrvz/uEa8V+ 5c/NTON/He7j4XiPY3atmz6uW2+9Nf0d3/fe0s197e/6Hfmqv+s+/u38eP2j fI/l36aBi+k8V//nU/J+2BPELXQqOVHELYFWwbrDE/QSHKGGTId1DoQesTIX sufp43Dd2//FAurN/G2uU+vU79g3u61Wk8/OoM3QiMRY9CE8w6enr1ada6Q3 3kLatz5dvZzqa40/l58N9/Hc1+N4T91oXvq3PI7vm1mBx33t7/od//Z33ce/ fY07/W75t+0F+rc8V//PuazYhd4ibgm9JdAq4A71Zdxihpw1p3ed/1v8nTlC HK5GbY9Uo3bt0nvxC56ZN29eqjMtjY9leUN+R9/V58a3ow47atSodAa7/EB/ zUA3+g292vvl33leo7WqPubn5f2tXxzhd7xn7ufmd9wfR+Tvucnf3Mrvtevm OeBWr93nLs6KnCjQSshh6J+rrLJK8snpVZaTZ41FLsQHK8Z+97vfnfZ4nMJz 5Wv9hWJ3v1M3r6x9Wu5hr7fG7P38x2YCD3SjC3uPaNb+Lb8Q5+Eq+YiaVXl/ XG3WGg43E9T93Gjh7m8GRf6em/wFh5ffa9fN36etee28dHSoQKCVkBvxoLnG 9Car3WbgGD3N2dOfe4XE1scdd1zSANSo65yr05/5iL1+fZNyO3WngW7iHtoT zdq/8aqc0b5PSzZ7ory/+4rp5GVZa3XzO+4vLszfy+e0NH6vXTefrXqf1+6s IN6hQKCV4GvVF+gaM7tSjShDjcEeJ2ensYj9cw+hXAmvdHsuNBS83ryHi8/6 6Tw/XEjbXmGFFVJ/NF0tEGglSn4RozgbJMM+am47j5p6tZ7nXpuBUPILj7K4 okSOM+o8L8Q+4DNr1G3lvXT8FVdcsdprr71Sv3sg0EqU/EKnVVvJsKbEzOY/ qd2aidxr+p+arbzQ63/f+973OE8vfTvPvqrzLEU+OTNFG+cqyPUmTZqU4hc5 Mo9CINBKlPyiluLfJXBM9mz1ItRM1G29/pNOOulxfh31MH1M1l6ZN9YJ4kx6 tBx35syZ6TyxDPqQ8z28djxDSwsEWomSX8TK+v/6CYPxCx+b2pIaszpTHUGj VxNbaaWV0nkiYpmMkl/oMHrQA4FWouQXe7Xeon5CmR818otaMX8Kb6sZD3UE fuGdbFaDDn4JtBslv5hrWeov/YCs79rf9Uc04xc+OR6XOqLkFz1i6n4ZmV/o L3qz9IAEAq1EyS/+328aX+aX0aNHJ+9cqTNlfuGnpfHWESW/6N/Q65mBX5wJ pH6kNs+nEwi0EupDrrt+9ViV8Yt+77K+ov+Ph16/Dy9hHVHyi/kapf6S/S/4 xfxLfBMItBJiYrUD15/zefs1P2rmf1HTdZatXiNcU0eoH4lN8KeZX/oXM3iP 9Ybgl9BfAu0AD4Rrq5l/tx9Q6rtTp05Nvv8MfUM8y2ba+LqOwC/q0vK/Rg9d /uzpL8EvgXbAfCi+F+tr/PjxyfPRT3AWE3+y16+Oy1OXoR9Rzyd+MTemjpAf 5filkV9KfdfZDnpdA4FWgt6i98T60uvWr/Vpa2z27NmP01+yvmtmgz6sOqLU X+RHznvPyPwiP5Ib9lPvVWD5gOefruv6M7us9Hf2A7L+MmbMmHReUrP6Ua/w S2MPQMkveiP0mwUCrUTZo9+P/rrMLzx0NJZy1nfpfzGvpY4o+UUe3FifzvmR M6XpvYFAK2HeCV+n62/vvffuO/0l84u5Nvp0yj7pzC9mEZtJUUeU/DJhwoQB +wP60ZsQaD/EL87q69f6UeaXlVdeOeUI5QyDzC9m9DqXpY4o+aVRvy/5Jfqn A+2Aeom5zmLkfuYXa4xHvvSYZX5xNoI5OHVEyS+D1Y+iPh1oB5x55rybfo9f sv4kX8yguZjN3Q/84jy10vtTN/BFmi/BL9prM4rqjNL/EvzyeH4xk9sc817l lzxfSv3ImVX6BeoIPanmn9GoaWheV6A7MNj83X5AyS/q86XHjKZr9kuv8ot+ RrmxsyP0CdDi6ggeC/zIR8AnGHOyugf9zi9lf4AzEcz4z+j1/MhZse9617uq 1VZbrbb6Cz2ez9ocMHU+HiZn/Qa6A/3OL2V/QON8KZyy0UYbpbMN9TrWESW/ NM73cXaK/V7vQB35RW/VwoULl5yRZw7APffc8zgPU6Cz6Hd+KeOXE0444XEe Vp5dvdPOXqzzfMxyfl0z/25d59eJU84888zUg+pzsgeEB7m7UPLLnnvu+bjz SfoBpf4iVyhnLM2fPz+dS63H0ZmKdcRg81/qzC9iF+eG2hOdzeV1lN7kQHeg 5Jd+9FiV/KJ/uuzxK/27vdB/xJ/drD5dR37Ry6Anc5111knzBS+77LKIXboQ /X5+QMkv6ps0iYxe89fJA2+//fYlPyvPV6sTv9ClzftyTvFaa61VTZky5XFz hQPdg5JfGuuzwKskZ+Bf6kXdrOQXPsNyxnWv8cs222xTXX/99Ut+5kxHczHV p+vEL2bwibVxC850Bl546roTvALZXydW5rcroZ/6kksuqa688sran2XfDCW/ WGulN8tr3nLLLVNvdV3rR3QKc23WWGON9DrvvPPOJT8r52PWxf/CP3D22Wen nnazS33Ngx7oTlhPzq3I9ctyPitYY7vuumuq4cp3b7jhhrTHl3XcOqPkF7P0 S2+W2pIzc/3c664rzCZ3tjgvXdkjXfYHyJO6Pccwm8dnQkd6whOekPbFe++9 t2fOQu9F4H4eiIH6G2n01hgPCC8IrnGOBx6ihdb9sy35pfH8DtwrduOzq7Pn XF+Rsyh9lrSLjFLfNcOw27V9s8+OPfbY1M++2WabJc29fD2B7gNdJfdPN8bP IEd3bZoPsummm6ac1//t9c4cu//++xPP1FGbwY36Vnbaaacla8zryTALxtr0 HpRzYeoGr1OffLkWfY/eUs5evvvuu7v2daoN8QtsvfXWKXZxzdZFL+pn4Jfp 06cnjY/HWp2vnHEN/s33edZZZ6UZrvJemoRzgSZPnpz82XSbOmkzYm0xybnn npv2QmtMbHbNNdf0RFw2GGih6oT2h3z2tvfgtNNOS3o/Huqm1++58OWaU2QO mP2AptsrOXovw2c0b968asMNN0yxiTPQL7/88hSLlp+ffU1/rfrm8ccfX+24 445prj7/wXbbbZe0GbGAmmc5w7bb4LmJSfhAeD/pSrRPa0wOKEfCsXXjy+GC PmrG94knnpi4xWfutetB4iNR67366quTDlXO2uok8J3PSi87Xff000+PWZ41 grVmBi8fmTXmutOLI1eyx5e1P1+rM6jdil1ck+q3Pnf6sP4yjyen6KacKecI 1tZ5552XciG+/7Fjx6bXzafLZ77++uunGJyXl16BU7uZL4cDr11+gTN9bnJb n5e9wfmU22+/fbXFFlukPcYaxrli2muvvTZpNJ18/fa1u+66K+Vv8qKJEyem nqNuurYCg0OOJC7hX3Vt6XPfZJNNEl+ImWn21lmOZ1yvfodWYW6kPX/zzTdP a9OatXbVcx988MG0B3Y61ra27MfydzG2nmhrC6/wT8yYMaO69NJLUx3Xv70O 60+/sX2zG/lyuLA+xaJ8L2YYyGm9PjyiH4lG6rP33tBO8+fvvdl5552Tlq9n xD7TiXzE33VdZp+unK5b4qrA8GENqk+qR/PZ2c9oLPrG1I9oLzQYvJL5wv/V n6w/c31yTCAG4ksTa9MzrO1OeLfFWvbfG2+8McUjO+ywQ+qzVX/IvKJ2Kx4T 2/AW0rI9b140r8PrwZ8XX3zxEr6sA3CB127eLo6gLYlPcEf2GuAVPYI+RzkI vXTBggXJZ7jVVlstef0+fzyrZuh9Wl77hfdavMWnu+aaa6bn1ejPCtQL+EOd UvxhXdnr6Sz0Pz4Z2gzPXVmLyJqG+sMZZ5yR+iTtjznWdn6gNU6bWR71CX9D vGHftbbEIZ4LvrQHqsfjPXzayHv0iewp5BHFr/Zy2jfekTPw/3RrzmTt81v7 LMSeehrV+3yG8iA9EIN5Jb1+cSk+Vbv2fvld14FZd/rI8dCjjz7a9teBz+RD 9gR631VXXdX2vxtoP+QB1qe9T31lv/32W7I+xQDibPu8uWGlNmPN5XjB/uh6 dm3KNXAOr6UYqJ31XnxhfWR+xA/0IToDfjST7r777hvUN5HXKG9MXqPyRfv/ LrvsUp166qlJE9Cr1E05k/3e/u415lhSLiR3NftTboE7yxi0GfLnr2ZjRqj+ ERzl9ftMzeGizXn97eJZ77/3Pu9T9q2yNyxQf7h26PS33XZbikFwi/jajQZs Xoqf0WZKvsi5Fk3DHijXkj+7RukfznLmY2ulNuOx8B1u4/O371pbNFvxC26z XuQDw+UE3Cn/zzUzcTq+xFk4x9rrBo3Jni63u+6661J8QmOxF4g5cKznKRbI udBwkf0/8l+6Pd8sb4LXj3M8rp9Z963cL+R2N998c/J7yovCp9vbcP3ii5yb yxVcv+IS1xxtxvXbeJ3ZgxYtWpTORZTDu7+c3toXA1kPtI9liXn9rnyFHwIH 7LHHHolX/B0x08knn5yu1WWpA/kbnicfr/UqLqDhqDmVr2N5a0xeD/1LLEGb 5o8UY7jh1HPOOSfVy5Z1/Wdvgll/M2fOTDmvucQ+Rzkkjd9cmZFw92CQf3lf s6brfa+L7hVYesgp8IXPW7+KnMM6s0/aY/QY026aacBqvTwXu+22W1r/NA25 hhgo+2ZGsgY8Lh+ctXXKKackXtG/4HHVl4888sik3aqdtMrHYv3Yr/kv9PPk 2N1r8jqsP69joDqL5+w1Dncf9jhiqMY16/dxhvzVey4XElPk/EUMo17Uar0r 7zNmbU2dOjXFsPYMHCBOFa/y5w2Vfw0Gn5XHUR/gzXFuSr/NDOlnuF6ta/Eq Xx5fgliBjyRrpzRgfXTlnuO6kb+47l0z6jM5BvIYdB6a43D2P9evvIQPDq+J 2TPP4T2zQbIPtdXIGpPXoW5Kd8yvY999900xg728kdO8Z7gXH9Kg5B2DrUHx gtwz558Z3h+xkphBfVkMhVPN2ONHsvZpLO3a77M3gc5DJ6Zped/tGfIyvC7O XRoN3LVl/6Lpup6yT7dbtfRA++BasD/edNNNqRdEzpRjc37evIc25iVyCNyj DqGnSZxN0zAHwb412BwPj+O6dV07azHXkK1t+ReOsraXRw01a0xeh/VA58kc pxbeWEdVy8K96uL0cq91sDn3/CjyO6+r7N2Wc8pHaVp0a3/XudJ4je9M/Wd5 6RT+ln1G7dpz9TnQ5tTCxXhiPfrdcPmBpkzHzfN0aT7h0+1vZL7I/ix7Dr6w n7nmsm+m7IHMe6Drz/WkJ8E1ORC/lPUstRt/Q8zgb1ivzo2mwboWl3d/ntfl edF55Ezq+Go11noJPVrqOGb1jxkzJvVxiWUG4gK1E702OIuOml+XXEGd3GPR W+gu6lyD5WXthOdFA5fj0mZ8Nmpt3gcaMM4fjm/G4/BxumZouvYe8V431ecC nYO9LPvPxcy0mVwz4keXy6gbu87yNZPrM3hG3YeuV15Pvs4asXqzXMi+Zs3Z v8XiPBGNdfLlDfsznccamzt3bsrPGvfdfBaBXp/c64QrB5qNpIdBLKAvCHfl XM/7xxtw/vnnJ71H3agb+vxy3wjNyz5DBxLPyNtoM64L8d5AeZt8kT5vb3LN eL9inm6gRO7xydqM2pJ8Kefm8oPca13ygb3Lv8vYw7/xjZiGr0v+JB/wePIB NSl8tTzzgaHgOeOVZr0Ejfyy8sorJ32bvtCsfoaPrU3xDp3HY4LXKq+i73bj TMjciyFv9LmJY+hDak780mptOLHRNyWXFvvgU3xEPwsEmgFPWGdiEteUHEY+ Y29S2+G9E9M3y81zbeSOO+5I+5l9UJ7g99Ur/K442r7frbNKmqHkF/3aciTn aphLKQ9ofC00cnp5Pnu+Tt6yspeUNiNvFMvQVXCqnE5u6PMXe9lvaHiuD3Gv PaUXe9cDrUXWQHnx+Wbsx9aUeo/ah54lPjv7d9Zk7FsXXnhhqsW4JvM1pydK LuTx6ugRL/mFLq3utPrqq6f6th6GxnyqzvySgTvkv2I0r4Hub5+g6dNm5ID2 EVpw7mEwi7zb53QGugu0A7kMrU89JPdAqq3K1dVHaKRydDyUZ/bTCfl9eTzU herssZIX4kn8ovZlbam5yX/kDvKGMmfI/GLuFz9+nc9U9rktXrw49Sc4pyCf KUWj1qOvl9LrxLlRjw4sDegR9mj7ldoITxqOsX/Lu/GOXMj36JpqI3PmzEna r1yo7tcc/rB/4xd5n5pbniVrromehnK2OI3Y+mvUd+sKnz+OpM2JT2loOEau uOqqq6b3RU1N3tyNulKgHhAz87CYkWYft3dZY3IF/7eny8Vzn3I31EZaAbmd 15b5RS5IR7KmcAgdVF+W7wP9ml4hvqFhlefW1hl4Rq4nZlWLdjZK1rzlTfS1 3DtZJ30t0D2gtaj78OCag8DrIEfIHnPfr/t+3Qg9Fbx3mV/kDLgEp8gTcYxc wf5tXalz0yryuZLqt70E+a6YFb+IWfFrnmsmtuH5yb1T4YEJLA1yrdW8BPMO /H+kPb51QanvZn4Bfjnap9iNX0gfE03U/e3nvcgvcl31d/oSvZ8/isbGz6S+ qI8M5+beSfsNLo54JhBojoH4xVrjy1PDFcPQaPQQWW853uklfrF36I/SJ2Zu FO8CTx6NTe0Q7+Ab/kk8I6fUS81Pw2e5POfnBQJ1wUD8AmI2tTV8oq9PP5M6 i3yh1/jFazWLx3vh9fEw59eWe+LN6fF+8efhGfVGNX2chGc6NW81EOhWDMYv eU/HI7QINz7lXFfpFX6R3+hpUDvkL6Tvqic26ivul2tNuU8885Eao/5RMU+n +0ICgW7BYPwC6mR6NPVUjB49Ovnqcl2lV/hFX4C5MfIi2pIektz30Ax4R95k lrAZPzwLvJnqauoBtCq1Jo8ROVOgnzEUvwBtwZqz9nqNX+hMeuzlO+ZG8SbQ bYfDC7l/VE2b15BmI77DMzRg761YJ3gm0K9Qh6cjDMYv1oY1p/+c58598Yyz zurYH1BCLsObjVv0IOlnHGmfh54kPa+8UeIg2i9/pt5ZHgdnHgxnfp64yH3E Ux6Pt5h2TNcZTp2KF8nf4ZHksxgK9g3352Gvsw870L3gezfjRi+5nr+B9El6 gvkLZvrRe/UUmB2VfXd1BC+TMw30BSzr+a54I/cbeMx8Xh6vEL5R4zZ/TLzT 6PnO8+rpx3RifZY81GIpmrreJ30celUGm9esb1dfKh8oX8VQfMRH6W/Qp+Vz gUCrYTaKniPapJmXg/U7iFXwkf5PdWrroa79EfhAjwfPHN0FH3g9y+plyWfI mF2Gr2jF8s/cb8KfKD7JoG+JH3wG5n/x2civ3F+fgh59+rE5IM6GyHPRmvk8 9Wu4v35M3D9YLcvrtJ94bDkd/2gg0GqIS3jpXOM0y6F0AvGK/gi3OnuZ1ZvV oK0vfjr+llbWlq1f85B5iMwxNOc9zxsXh+T7eN9xu54uvbPiSPGUmJKmzn/k /B18I4cTE5lnLD5p7FER52RtTK47WI4kN+Lfodl7XPWwQKDVcA3ax/Uh0SKH 6gU371Kcow4rF6hjHda6VhOz5ulJ5nq26ywA7w+Nx1k0YhRaDG0F8I9cSO1J nxtekUfls7f1IZiP7L2mH4th3E/O5dyvxnkRJb+oYQ3GL/IxeZE+suCXQLuA I+xjfGL2vKFmnOAW80D5PcyH0TNQN1jXYgbxgjVt/kY7+1XFhDRjtTY3X+M4 nC42MTNQ/crccDO9aK057/S7WT+WG4mB3F+fgpym3A9GEr/4G7jM/Ingl0C7 wMNhH1cPUlNVrxgM1qI1qf/P+UZ6s+oE61afg9qOGQy00E6cYyR+wAfWNv3H rFFa2ED6D57xc/UpGguPIy+1/SFjJPwiz/VYkR8F2gk+Vbm+a5LWKUcaDHm+ lPs7z4QmWifgEvVosYu5UeZxdGLWhnoNvzCepvvyDw+lLeNGuZKYx34ghnQO T0bJL+pPclmxT7Ob90E/VeRHgXbC3AX+06XhF7MkxfN1gbyE30duYd6CM2g6 dY6RuRhmP3gf5SlytuFAfVv/kxyJ5utxsiZf8os5rvInOVizm3MezI3GU8Ev gXbB/uc6Wxp+MRfGGUJ1AS/ZwQcfnDRdtV7PvVO+WusbP4gf9BgM19NHL3ae sdfgPCYcmWeOl/yiRi2PlQc2u5k5rWfVfYNfAu1COX93pPyidqq+UQeUPQ78 KOZE+V6noJbE30L/oNuOZFaV+5vJg5vo1NlDXfIL/lGXEiM1u/G86OUMfgm0 E2JoM/JdZ/zxPO5qQvwtfOk0RX4wOiIt14xiuUWd+MXapXfwHpsb5cwHZ490 sico8wuO4MMbrq/P/dzf3K/GM6hKfhk3blzy24mTmt3wkhgm+CXQTohf8nXG 26VfBoeI2V2v5s7yh9EIeMNoi+ou7s+bqv7U7aCxzJo1K61n2gsPfqfnJ1vj Ygjvo/eY3284EHP5XPhgxChm1mQPUskv6mI4VGzT7GYOqHohfTn4JdAuOJsj z6OzH9oXxSc86vjGGjCvTTzuOjTLLl/D5tTyqncz8Ag9U60Iv+Q6cKeB43Cd 99E6H65Ors+Uro4XGn39I/HX8c3oT1XnDn4JtAvZz+Ka5KvwtRhloBvtInPM QQcdlM6h62boJdbzR8tUU5HPdUPPFJ8RjRmnix/x/FBnQ+rHwCc+I3Uf+awe xYyR+F/8LTmSzzL4JdAu8K3n+pHZSPoWb7311gFvfOk5rleLMd+uW2E90nHp S56znr/h5iHtBn+bHJTXX67DiyLXHOjccnmRWt/++++f6kbiSXkrj0vGSPhF D6acV507+CXQLtjPd99993RN2k8XLlyYNMSBbvoAc72pm/0v1qj6s9ekTsJr zAvYLWeKeB68R2ZsWt/6LPlxFyxYkLR0Ppd8E4Op23m/s3dXrQ8flbrwSPjF z5wPEflRoJ3Qy0unXZr6tP5evZHdCPu9Om4+v965cN02e1sMwz9Mx8pzFXh5 9Vuq/eSb/jCxpT4CeZ6v8Xzj7J2R6C/ei8iPAu3GsvBLt/rr6Ct0CfVoerUZ St2ax8nXzO0y+4XeK46hQ+PEfJPbufm5eVO0YTWxxjxKzKL+jof47gbrhce/ egjUAvGavu5AoNVYFn5Rrxa7dxv4dehE6l80UHPdunmOBI6Rpzr/mjfHc9ZP TcfVYyROVG8Wg5nZMJCGRKvHU/IsWs1gOjZ9l1Zsj5Cj0dYCgVZDfsMntzT8 Yi2Us9i6AXhEf/S2226btNM5c+akuVndDs+bL0UPgxkY8h/r3+xwe4D4i49u MM4Q06hLmVk11LngYh8+SnzFYzDYeQmBwNLCfDU5/3D1WmvX3ur+5n0PNS9m eUO9XD2anoE3m51j1O3AIfIXcQreaafP2GPH2QaBdsGcNDqFnF89YSi+sF75 wfSw0B471X/cDLx0ZgPzB3o9fMh1iF0CgV6FGJnnha+VTjHUTF0xPD+sdUzb 7SZdw3PnCcEv5nWL/esWuwQCvQTrj0dL3DKcM9r93P3MeRzKb7q8IX5xvoHa rP8P5wygQCAQGC7ommazdXL2QiAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQC gUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAg EAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgZHh/wDk A1Df "], {{0, 199.}, {280., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->Automatic, ImageSizeRaw->{280., 199.}, PlotRange->{{0, 280.}, {0, 199.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJztnQusbGdZ97lpiMZIjEai0bQNTdsUAxiVTwwoBCJEI0k/BJGQCLblolBD SwuFll7Ooff7/UZbCrQFwqUWhCIXobRQrhIUxYDFAu2BAsX7fT5+K/mt7z/v WbNn5uw9c2bOfv7J2jN7Zq0173rXev/v8zzvc9n/hUcdduRDHvSgBx398B/8 OewFxz35Fa94wav/7yN+8M/vvvzol7zo5Ucc/oyXH3PEi454xf954UN/8OH3 f7A9+sEPetDDfvA6KhQKhUKhUCgUCoVCoVAoFAqFQqFQKBQKhUKhUCgUCoXC QvA///M/o//+7/8e+59N/O///u+Gm+AcfvZf//VfY+echv/4j//otmzDpPYN 7V8oFLYf4IDkhlk45z//8z97rtoTDP2GHAXvAc5N2/itPf2dQqGw/vjXf/3X /n0rV80COSWPc8vzTUL+TnsuAEcllP9mPX+hUNh3oHyUXAEX/Pu///vc52rP Mw+fID/927/929i5bEd7HvmqUChsT8AVe8JRyjvwFNyX3DKLPunxeRzc9c// /M9jNiraxm9oH2t/q1Ao7Pv4x3/8x14mYvz/y7/8S//drHzQ8g3v4ZfUNTc6 NnU+jss2KP8l+L+4qlDYnki5Cq7wf3lhow3ke+QfzjHP+l3y1QMPPNDret/+ 9rfHeAkZUJ2Rff7pn/5pD6+4UCisI+CW888/f/TSl750dMYZZ4x27tw5Ovnk k0dnn3326KSTThqdeuqpG26nnXba6IQTThideOKJo9e//vXdsa997WtHF154 4ejd7373TG1o+RJ873vfG1111VUjUuK4PfKRjxyde+65o+9///u7HVcoFLYH khMe/vCHd68PechDxj7faHvYwx42euhDHzr6sR/7se7/Bz/4wd3xfM7/v/3b vz360Ic+1Ot12KZA68OV4POzzjqrO5ftYYNbC4VVArqEeoBzqPqFvjh872et XrLRlnqK9hU+Yz7P32vtL2lTybUsxqDjL8+X52p/d5WA7QpO+KEf+qExDpqV r374h3+4f8855CmP53v3efaznz26/fbbx+xkrgPSDu328trll19efFVYaQzN t9g3Lrjggm7+Zkyw+d5x4fM8z/h6xCMe0f2PHoNu853vfKf/TbhHHlT/aNsG HzF+fvzHf7yXJWgXbW39hiZd2ypATkhZKftp2ka/c93JLcpp9A2vP/IjP9LL b3fdddeY7wKwb3i176688sriq8JagOeWZ9q5FnvIpPGi/jHL2GIstp8xhhin P/VTPzU67rjjxtakUq5StktZ6dJLL+3Oye//6I/+aHc+2go4B9ewqjwFuFZ5 nH7wGrJvN9rsT/ug5TllrZ/7uZ8bmy/uuOOOXv5sfT+181988cXFV4WVxpA/ DoAXkId4/nnmlWfmkQPSbsvYZM5XDthvv/3GzvfZz362k6scU6xFpd7JOOc7 xlSOWdpIW2e5plWBvGT/wFlXXHHFTOuD6sD0xXXXXTe67LLLRrfcckuny8lR 2rWYD9JGBuhH+D91b/kd3i++Kqw6GCe59sPzzDpU6h/KU44Bx5nfTdocK2mz +Ymf+Ind9EX2+9znPteNydRdtLMIuIljUragra2v4zzxv8sE1+L12jds8/CC Mmer46Ffv/zlL+/6Wn3QPqLPzznnnH5f+zV919Gri68K6wBtr3ID8728IM/w /o1vfOPozW9+8+jaa68dvelNb+r+32h7znOeM/rJn/zJnrOc+9l+5md+ptdh HLusawHGHmMy4014z/p6ax+jrUPXsKqwL5UT4ZaLLrqo9yffaDM2WY5BToKf 0//8iU98YtfPysRyF7+nbVDkuc4777ziq8JKo31+Bc9pq7fAWynHzGIncgwx LvBN/MxnPjP6gz/4g06PS1sW5+Yzxpq29zy/chc6C8cw9hzvk8bUpGvbm+Ca htb50HNnkQntk9ZXAcB3/k8fc251RH/zU5/6VOcX6nmS24uvCusAbe25xnbJ JZf0cpXrgjzLyjCz+gsoDxCHAtQ7n/nMZ/ZrWcoB/v+JT3xibBxlu9AH0zZN 22hr7rvqNvfkBK/FNYPNwn6De1qbI/x+5pln9lznPVSvhDOVxX76p3+6O/51 r3td9136PaS+bWxhC/1VvBetrFwo7AlyXKc/4aT1waF9pyHlBtf/4C98vF1r VFaCs04//fRunxwH/h7clOtovIfDGAuOnRyH6ljZDm35bW46f4/9F2n/WiRf yQ/f+ta3drMRwj/PetazevnVa/S6kaVomzZK7gk+Dn6fa7Xcx/e85z3d+u7x xx8/OuWUU0YvfvGLx+KLPM74xkJhs1g0XzF+Wn9Un3lsVK7ra9difkdmct/2 91q+Yl9sWsJjUheEn3JdzN/3NdcikyMXpU8ukq+yf9PHIddIzBMoX8nd2Ntb GwDtYn995Y466qjRU57ylE7PTB+w9FXhFf5irlDOAqvqw1tYHyxDvgKp38EP PrvY433O00cb+aBt5xBfIY8RQwfaXAfqIJmDRXz3u9/t2wL4Ltfb0i601Vgk XwE4l621PeY9hKvoH234bPhG5P7wkWuKn/70p0e/9mu/1uvsuenzwsZvuk7D dx/72Md634l2PbNQmBeL5it5SbuSUN5hjLQ+pchYrEG2vqOT9EHWId2Xc/Le tt16661dXBx6y3Of+9zR0Ucf3XPU0HyPTLVoOWDRfGX8TcpVvmdecJ+Ue+Ev +cqYBnVtYnpsq/q7cUDJTW457+R6yKqv2xZWH4vmq5Rp5JIEz7JrhenjwDhp fRon8RX+V8D9yV3wO7/zO4O6UI6v17zmNd3+rJel3qLMsSjeWiRfKTOBdh6g L+iX1n4FeJ/+V2z777//6AlPeEJ/LPdJvzfOzWf0qX0Mx2Gnt68zDuKmm27a kusrbG8sQx9Mzsp8u7ySU8Xn3bg4/m/X0TfiK/y8AWOCdUftxYyZXOP0d4xj VJa78847+7Ytwwdi0XxFv374wx/uzy9v0Qf4zaUOnHGE+rAYi5C6oeeiT7HB 79q1q89JSr/97d/+bSfLuk8bX/qoRz1qoTp2YXtgGXyF7NKut8lZ11xzzW7j l/gd4kuSOybxFX7bcN5tt93W+xp5PsccPJUygNeS8gd5qFr7yqL0l0XylbLh b/zGb4xxjP0Cr2QOjlxfwJ/B9thG+st1jRe+8IW9zAnX5XqI89CXvvSl7v6p D2Lvsp///M//fEuusbB9sSx7O8gcDOpuzOlyCM+1vvCt3jiJr9ie9rSnjcW2 GO+jz1jqhW1MkPbjQw45ZHTzzTf3v7dI27AyXtqD8NGfJT8PSP+CIRsf8k/a j3iVs1o/0byHrg96L5LPsfvN4j9Fe775zW/uFhMPh2FHLBQ2g2l81fphp8wx S/wISDmJdb+08fpMy1NySBsDuJE+KB9lrM9HPvKR0Re/+MX+eNrA3E8OTr5n X68t7cPwqPb6IT/IrYAyT+atmjd+MNt2//3397HQv/ALv9DJlfJxypPozbPw FTwlvx166KGjI444otP/ZvVJo32/93u/1/Vx5h/6zd/8zZmvsVAYwizyVcbP gnl8/9K/MPG1r32tt4m78UzDVYxd/T/btrV8xTHqH4yz5z//+d3++KMyJuGp 5E0+u/feewdlR44nXkWfy0X5Y7e/y7i++uqrZ+J/6+rIHVwTuiy+mvTDAQcc MKbP8YrtCD9R+xFsxFeZ4wYOJ4YKzLL+oK/tDTfc0Nu9krMKhc1gGl+5Zu3z D/RXNsZ2mv5iLI4+ivg+4RPturlrgo6Tz3/+893+s/gzmAeK7bDDDuv3b+3m mROYccdvwI3tWvyOHTv6GOBF+LgjA9FuuIXrTbv2LFvmD035N9dYua42/8Pf /M3fjPl5TOKrlFmV0bL/psE4T34v2+29LRQ2g3nsV/pGz4PkDZ5lYjiIaW7P rX0Jm257XLZtSB+kXYcffni3n3lW+K30S0V20UdUX+3f//3f72008tbjH//4 /jcXFZOTPhbqbPLWtPw8rTwqr+irAVfJaeqC99xzz1h+a+9F/g/gK8+p7/rz nve87rtWPt4I1rHPNmonLBQ2g2l8lTZX3h955JFdjiVi/3j/x3/8xxtuxMsS w4FdJceQYyrX7rBhyTVD7ZwUj8P/d99991j8n9eR/Jrv77vvvm4N0vGUMd2e Y1F8lXp2ctAsOVtzH32dlK2UtVJGwmbntaf/wkb6oP5VvM9c07OuQdjPmefZ +1QobAaz2q/a3Lt8pr14Fnkg8/xpW0/5AN2FmA/1yNbWPYmv9GFwLKl7tn6q rkfiG6qs8IUvfGE3vSp13kX4M8CBabdKWUtf1mn9KZckP8EH/E9/8D3+V0J5 chZ9MGUhfo86Y2krm4aMN0+52bYXCpvBNL7KnOHteGljXSdtrtvxqiygPcMx h72jrTvctnOSPkisDWg5CmhzB4zXjEMx12crR4JFyVb8Jrpf+lrANUN57idt ri/I/X/4h384et/73tfp2l5b5n6x/zKn2CS+Si5kw7dtXr8Vz9vqt8VXhc1i FvkqZQ99lx3j0+ojOCaZs3PNymf5RS96UbdW6FiSU1rZZhJfOaaEcbwiz5M1 rQAyl+1IH9NFrg2CRccPboRZ7e17mq8vfVWGOLhQ2AxmtbenbbuV8zfa2jp7 6CvYcN/61reOvv71r8/VzknylWO99WGdRS5oxxNjLPOsLALFV4XCnmEaXzmm zLH+rne9q4sT+8AHPjB673vfO3r/+9+/4fanf/qn3b74D2BHyRow87az+Grz KL4qrDP2NB6nPXYS0KuwgZO7va0ZPY/fafHV1qD4qrDOmMWfYZK9dJovdp5b Ozc2o4wjnKedxVebR/FVYZ0xy/qg4xjbdtaNmgXYuFvfBHXCedtZfLV5FF8V 1hnz6IPwVcZlzDOejcXZk7XxbFvx1eZQfFVYZ8wSP5j5XoaO29PfnSe2p/hq a1B8VVhnzOt/JeapP5jnt47dvHxXfLU1KL4qrDP2dH2w5YZltLP4avMoviqs M4qviq9E8VVh1VF8VXwliq8Kq47iq+IrUXxVWHUUXxVfieKrwqqj+Kr4ShRf FVYdxVfFV6L4qrDqKL5aLl9xbnKB4YebeRCXWZuPfmmvjbgpcq9+8pOfHH30 ox/t6qFRF4ecP8R7znq/9a2jRi45OTgX56Tu0Mc+9rGZ2kd+xbwH5AQBxseb hz+vx5rVhdWHueWyJkDmksx8wJP8PHk+zCnMvvCCOa6yhouYJ7fCZtDGHiaP Ms5pI231+riGeXKDeq5lXqN5v7g228q9mqemw2bAb7UxnDwXOeZ5pvhM/hnK UT2E9pyZj3+W4/0tNmpV3nLLLd09eexjH9vXWPQVZJv9rLC6GHrG87mQn4by A/s8+nmeE92greNCrr5Z6zptJawRRf6sc889t8urbE5h2khbW64Gs/CW12jN MmQf+ITrnLcW0KyAC8xXYXuRR5aF5ATntfZ/YW7lWWPU6bfN1Jm1viIgv1rm /bd2EXIg8J6z/6J098Ji4P1ybOczI8cwPqw9MHRc3ndqit9+++2dTM+GbvDB D36w+86cw4sazxvhG9/4xui2224b3XnnnZ3OQhtp69A1zPIMo6dwrjvuuKM7 V9ZpWASUB7gn2b5lyauJ5CmR+TeMn/Jez5ojOrkvn5V55N6nPvWpY3Y06whQ qzKhPL1M20Rhc3Ceyeeufbbe8IY3DB6TnMN9b+vAs59jyX0XVad9CPw2z6Sy Ps/lkNw/1PZZ+HSI0/iM616ELOm4sg+t5zOpLYv6/fazrR7vk+yi05DPLbXg 4Czr6bKR4xaZ+M1vfvNuNo69MX8W5kd7v7QZ8D95PcmVTk1ycqcDa7TnnN7q BnzneM1xlPPxrPXotgJtGwDcRBuVqYbkhWnIvnOsLPq5b7nQGljLkLEm8UbK RLSHtlhrZx6wvzHtQ+efBp4pjucVu/rpp5/e2xetEUndRWStt7zlLb1tvrhq PeA8rdwOXD/hnqPDaXvidb/99uvWadr7m89r+3nWrctxvQx5IO29rW2lHXuT rmEWOEZAynKLAufm3u0Ne+AQhtYMs9+5D5utGTSrPphrP7t27RodffTR/Vow tSqVtX72Z3929Pa3v70/jrm5sNrwGWqfBWqQs5asj4/zkvf66quv7vZLLhLa G5xrh3LC7A0M6bvKkS3/zrrelufx/IvUL4Z+ByyTtzaSQ73fm+Vq70s+l7Oe M+3oglri1pdly5qWN91009LWVgubx/3339+/Zw0YPPGJT+zup3V/5Snu9THH HNPtk+OFcdvyUP6vjiiUD5YB7R9D9VSH2jwvn7a6ZukWexfe2/ShQGc49dRT u3lXvzWeZZ9tajFpG/BYgL44z/pLYXPwfllHFOSrYzNtScw5aaO0ZgQy9V13 3dXtw3G1plJYReS8yHqq/7O2vWPHju6Zpq61zzYb3HXjjTd2+zkWWn5aFd17 X0feP3V77wX3QN8dOO2XfumXOh1f3yRrlnJP2Y97njaJQmHVgHybcUOp6913 332jnTt39muF6efLPI0vvOsZzuXtunFhscj5wn5H7kr9iM+xPz7ykY/s7h1+ dtoo2eQpMCSTFQqrhNa+xjOb/gv6OjAns/adcQrveMc7ervAIv1+C7sj+zpj D5S54KnLL7+8W/dDlmKOUb9n/kG/xx8YblMu28w6WqGwSOTzPkku0sYoZ/Hc s/6tPsFnH//4x8fksrTxFhYP76NzhkBnR5dPm/ojHvGIPs7kK1/5yphPu5xX 8nFhFTGUNyLnVn3V/Pz444/vnvMDDjhgzG+H7eabb+59HLZizbMwG3JdOG1Z 1157bcdT6bPA//DVscce28WuCP3/RBvjXiisCob8U/zM55+4AH1Wzj777D4G lNef//mf73WMpz/96d0c38ahFRaDVm8zXhm5SlvVwQcf3K8Hcs+OOuqoXtfP +5RxhGCZcTWFwqzIWIUhH3uebXU93rMxP2O7Uq9AzrJuJuMElE6xPKTPL3Iu 94It49exXR133HH9MclPctM8uT0KhVWEXJZriHAW8zjzNbJVjgvGCTJXzv3w XetjWvbc6WjzBeUc4Hfo4L4np4bzhq+uk8BV2qdqTaSwr2KIr3jemZ/RJzIH EmvmjhNyaBmfKMqvZ360Ol/q7+m/gFxL3xuLgL1KnfCMM87ojzfGZm/FzRQK i0Y7Zox51l4iX6VPD36JT3rSk/pcasL3pXNMR/qog/RZgHfUAbFR5doHvgr8 z+trX/va0Ve/+tXuPCnjVv8X9lW0fJUxkeZ21geejTyMvj/kkEO6Y1Kuqrl9 PjAnmPcTjkp/EXyrWPPTVyHnjC9/+cv9frl26LkKhX0RG+XUMkcavvDE+Kev D/oJdvn9999/bG437rawMeB4c1K3oD/p15Rn9eHlHmhPh6dY3624zsJ2R9pv 0fOYt9VLyP8md/GKXQVow6pxMz+Qq5BlyUWGHIVMi86nvcrYZWIB9VnIfk5f 0orvLGxHIFcBxgdzORyWNni4ivUp1gwPPfTQikubA8qkvKpPk4MMOTb1vlyf JYeZuvpQnoW9lVu9UFg0NsrnnDkHncvVXfR1UDdJ/1LsLTVmZkfamogFVH5t +xe5ynzfmaMBWMNEVOxBYbuitW1pc2GcIQOkPYsxZY4H/BrB3s6nuDeRnN/m xBTy1dve9rauP/VXYE3DvDDksc4Y50KhMBnJWY43dBh0k4wzxB/IeDZs8Tfc cMNYDRAwVMdgX0Xa8dq6pmkj/63f+q3eTyHrd2KvOuecc3ofkcwNVLxVKAyj 1RGzJsU//MM/dDJW+lubk4Y1LeqzII+lTLHddMWssWy9bj+3r1Kvhv/lKuYE kNxXXFUobIzkLDdlBta1XvnKV47Vy5W/GHvE52KnT1ljO4y5lpftL9YAsUE9 7nGPG+uzjLM5+eST++Nd5xBVe7tQmI5J9nlhbofM96eeQx0L/U+3k79D5m7J GEH8bOUpc8Fot3rVq141WMMt3283GbVQmBdDfqXM/eYrZRydcMIJ3fq7taS1 H2Pbyrqs24WvAPqfNUrhmfRX15dNjjfHmPFQ6beeeaxqDbBQGEc7Jtq6im1N WmQJuIuc8MlVOR7f+c53dvtqw9mXYS4X++3WW28d86dybUIZK3Mn6seWMeUl VxUKk7FRzVeRtTWVv9BlTjzxxLFYQ+wyrNdjz7ryyiuXfSl7Bem/hmxpLaLW Z50+IYbJ/bNGc3suUfHMhcLWgvUtxiX5L1OW4PWaa64Z83NUVhuqjb3KSNt3 WxMecC2sN2TuYvRAa6fxPz5YmZsaFB8VCsuFdSy0ZVkbzxxz559/fref9UDX bd0rOWUojg+d9/rrrx9bf0BHzvwWqQMC+Lu4qlBYPhyD8FLmGXA9DDsOcYfa mIG+qOsyZtHZ8DXQTz1zS1933XVdjkPzFaMPGxd4ySWXjO65555u37vvvrt7 hefWjbMLhX0FKTede+65u+VGcTMnPHbldYqXbnVX/TV4Peigg8bWGbBRWW+Z +BrlKvzc5easCVkoFJaPlJUuuOCCsbwO6EXIG4xh4qRTzloH3kpdznUG3pun WD3YeCXseGeddVbv/zG0RjpUu6tQKCwe7Toi3HXRRReNreXnGiIyCUDmWIcc pXLLvffe26+PwrvmXWUdkGvjlevFnxaeQu/TVwReVpeEo4qnCoW9h7TrOEZ3 7NjRc5ZcpY7IK1iHeB3zT8FVcLM+65mvyv+pRSsHe22ZkzVz8FQ+40Jh+Whz yViTFZjbIWPm9HUgX906yFfam5CJzF2sbz/XYh1T5C8hF3l9+q/5f/mtFwqr CfP+pSxijIo2eGB9MbBsH29t6MAYb7mFV+rC45vBph+odnY+k6va/FXrID8W CoVxkNvBHCpyFz7gyCj4AiDDyA/LXutvfSrIQ6V/Pxu+VelPxntkQ2s1WnfD NUNQul6hsL5AbsK+rnx14IEH9nYs+Ivxb86t1KWW6Z+V+auU7ZCrtMHBr9Y7 02cBrjLGOe1UWRO7UCisD3LMEsMiZxmnoryFbkg+mvaYRUOfirRTwTesceqj gFylDyicRZtF5imEu1K2Kh+rQmE9oY3Z2juZDyrzlpLbAQ7Q12kZMBex9qes A6gPhu3Dj5/9U/8TrW9HoVBYL8hTjHHfM9Yzvs66C8ozF1988ZjNe5FIXoFv lPnSb931TNoF1FOtD885eD+pTmChUFgfZF1ixjZyDDJU8oFc5fobuuGybO/4 3MM7tIFN3/UDDjigb8+xxx7b7Zv1BNvchvAY+mWtCxYK6wl1rPTTMiYPPkq9 UG7wlbW5RUM7v7pf1v5R1jrjjDP6+hvKVvBS1ufItYH0ay8UCvsO4AE5wjoy +f7SSy/tOWFPa7S28S/WVxSuUWbco35i2N2tV5b+++uSW6JQKGwd9FtIn1L1 MXzHkXuI7RnCLOuI8ouykLnoQdZaZr0SfuL39FvIuoCtT2nlhCkUth8yVkWZ xvpXbsTBkPdB/YqcB/PwBXzY+pxfccUVnd4pN8FXmQMHpG8C65pp/y9dr1DY fnAdTb8nbEXasOCtlLvIOZw8NW9OZfy/4B3quxoHiF8Vv6XNDLtVy0u0TZ5L +3rZ1QuF7Qk5An4wH426WsbxkM/Tuqyz6IOp/yGXkVO+redjDgm4Sv2PNcPW R4H3WRO2UChsL2jLhhvgCu3p5JFyje7ggw/ufct5Jb8y9ZNnBbzG/lddddVu NRN5j2zFb1lji3jHRNYLGqrPWCgUtg9STpIL4IcLL7yw5xdtWqkjznNu5Snj ang1hxW2K/gsZTZztoOsYSq2U/3qQqHw/5G+Wda8UofDLq7eJtfAV8hDbNMA /xmrqF1MPZMN3TNrjmFPm5T/M+1VxVWFQmEI1G5Qf8scVKwlIiO5jieHyHXI Sqz5sX/a7eEvPkPnLBQKha2CPpqvf/3rO26Sd7I2KfnUjZFOHwR95+U33rPB V8hVhUKhsJVIv6mdO3d28pJ2eHgI27vxyO573nnndfuoP8Jb+qDCeaecckof q1woFApbBeze2rqRoeAiZSzlK3M94A+PjofOKKeZ+0H5Cp917ejrkD++UCis D9p6M3AW8TnG+7V1apS70PngLW3tyGW5xsf5yke9UChsNeQVY4zhmjPPPLOv A0/Mn/zV1pXWfgX09arYv0KhsAikXJVxxrw3dgdOSl+H1n89fara/HyFQqGw VTA/le+NM5R3Lrvsst4+ZQ6rlK1Am4fG/DSFQqGwlVCHSx9OZCx90eEkfd/N qayt3ToRIGvvFAqFwqIAV+n3LtDthnKB+pq1t3jNeGogDxYKhcJWIes2WHsZ 7jKmxnrw2NSzhoU8xvfGNJtrSxtY5YMpFApbjZSr0OngpYyvcW2Q3MmgjZEm bkdOg6/gvaq3VSgUFgHt7OhwWUcHTsLGjo8VfqTITa4FGm+IjJU+DrzXjlU1 twqFwlZCX3R4SN9P5Sa4Cs5ijdD1vsy3h6096++knlgoFApbDWxVcJFylXIT r3AR+WaUqXbt2jWWVw/ATcY7c0zauAqFQmErYR3TjF12PZB6y9qhWPeTq8jT 7ufwnRynnMX5lNUKhUJhXhhro1yErQo7kxwDR2lH18Y+C8wB6Dqir8lfQt2z 1g0LhcIQrE/vezmD99ip2A488MCxuhDYrbCVz1OzFD8IY6M5nhph6bulX5Zy WdWVKBQKLeQE/QwAXCGP+CrXpK18Fj5Bn8x1wDbHDLn+eI9+2MZVl89DoVBo 0cpY5mrPHMj8j91J7kFnmzXfHvYswP5srW6oLzznh6taX/pCoVAA1l5GtoJX 9KdSrtJnAc5SnsLPap7cVVlzR7hmyLmV3eRIfSIq70yhUBgC3KAdHB0t/aWQ e5R34LZJ9WuG4L55jDWbsdm3tSj0QS0UCoUW8BDrgMhT8JK+oAcddFBvX1cu Yj9lHmOg5wH7Z5wz75GnzEPDK7qhtq3SCQuFQgJOMF7GmjeZzwrIUeqA86zb GeOcx8BbaS/z91t7WflnFQrbC1nTQV8F675j+1a2MYeCdiU4ZBlAv0TOss5O 2rXSP4s2K5tNq1NhzfqqW18orBcY59/73vf695mDXZvRYx7zmDEfTmpvwQnL sHenPwX2LHRS7O/G/yjruRapXLaRf1bxVaGwvmBcp2wFZ2X90vQpsDYEWMZ4 T1kJTsr8M3CVNS14z/eZi3kju3/xVaGwfsjc69jL5Sr0QOxEyi9syFXKX3DB suzd3/zmN7tX+AWdT46SS42RNucfW9UCKxT2PcBX5loH2LS1a7Pha2Vu0NQV lxkLk36n8qs5ALG7Z/4sePbb3/72bscVCoV9B8gkJ5xwQu+vkHms4KqsO69c tQzO0kYG99gGdFf86H/xF39xN/8s+IvP1PVK7ysU9h3AAehbN954Y7/2hkzF ehx8RZ1AfQ58BXujHgS/L/dg16IN2LK0veufpa+D+xdnFQr7BuAf65qmXR3O Qm7he23e1ulaNrCVKVu1sYO0Dd0QjtKOlf5ZxVeFwnrCOECgbef000/v19fS ts6Yv/rqq/dmc2cC3AWPPupRjxrTYfVt3RP/rEKhsHegjXwoF8uOHTvG1tf0 DUXHuu6669ZKJuF60F2RD7M+j/yVNe8B9q91ur5CYbvAMapOxdjeuXNn73/Z 1jS98soru/3WIf9B+riiN1pD2ms54IADetkRO32uF2wkZ5UOWSgsH+bZc2yi E5100km9PwB2KuUrxvdVV121VN+qrcB9993XvcJb+OqjG8K/ylgZ/2juh2m+ pG1MY6FQWA6Uk9CBTjvttDHbjuMYmcR6pmBdfJfglvQNlWfNp5z+8K1/1kb1 DYuvCoW9B8Y09qqUO7TtYPN5wxvesJtMtQ71Sm2zNVZ9z/aEJzyhu970KTNO Wj7KPM8JZaxCobA8oCMhK8FV2KOH/Bauvfbaft+s57BOaOUh9D2uu/XPQjdM /yz05I04q1AoLA+MuVe96lVjOpG1/ZA1WAcEyCPauNQF94ZP6J4g63shR2ZM JNdPHnjzyytXaoOHo+WsQqGwPKQ8gC7HGDz55JO7calMgX7ke+WqfRnmkj/0 0EN3WweVt7PuD5hki0///kKhMD9yLb/9/5RTTunGpGuBbsQzX3/99XutzXsD yFDY4Mmdlf5Zcpa2Om335s+Cy8z5kEi//0KhMDtc/0vf0FNPPbWzURkTqA6E fKF/1brZqPYU6XcGP6kbY8+y1isbOnHykHNAylRp66o604XCfNDO7PyP/xF5 FrSnZw5O5Cz8q7Qzb5fxtmvXru7V2hmHHHLIWF4H+QtOh+szf1bKUMb0yF/b pf8Kha2EeTUZi8hVGe+bNbAuu+yy/ph5a9esM1KX87pTrsr8WXAY/qfIUMif 8BbH6O/e1sUoFArzA87Ctp61TPU7Qn7Att7aW9Zl/W8zkFPgcvU4rhsuwj8r +yv5neOSm+jf5Kd18v8vFFYFjBtsxchVQ/5VbG984xu7fXP90BoT2wWtbGT9 H2Qr86maR9V+Yx91yczBCoqvCoX5gQ3luOOOG/Ov0mcBOeEtb3lLtx/yhePN 1+2gz2TsJGBtos2Paj541ybS5+PMM8/suT35qny2CoVhsE7l2GDMOG4Yd3AV 40ybOj6R2pGJ+y1sDPoS7nnsYx87tjaBzGXNRfxtRerQbYwl/J85xgqF7Qw4 64EHHujew1WXX355b0s3d7nyAb5GhenQjg7XwO/UAIKrtP3pn3Xeeef1uiH4 zne+0726NtvKqvBWrR8WthvUXTK/HLodOdezppU8BX+hG4J1yF+1CjDPMxvy qXqh8YbG8ZAzzPki7WHpk5WyVfmTFrYb0tbiWGBuT3sLsgC8xfhCPtC/ocbL bDB/ljb1gw8+uO/PXDfEFk/MgDzV2rCQpzKnxXawDxYKLe6///7uFe76+te/ Ppa/ythAZADWB7eLz/pWIvU2fdqNN2QucK2VPqa/X/3qV/f+pOqC1mRM+Wqj nICFwr4In39zZ6YOmLxF/a2MdwPaWAqTYV9hR8/c7rx//OMf3/Uxenb6itDX xx577Ji9nWPSx6H8HQrbEdqg/v7v/77jJvKRtz5WxPCK4qo9g/qz84P+WQcd dFBvv2LTLx4b4YknntjrkiD5q2SrwnYF61JtrJt+jdhaALymXqMNJXNuFiaj jdfJ/Mq8h7NSH8yaZ9RD0wafx5XtqrAvQntt5gLQXgX/oAPmGDG/L+vszPXG LW+U27ew54DLuDdPetKTep8R9XA2fB9e9rKX9ffRe+d9adcLy8+0sM7wec4c CwB5Cdu6sW3IVYwTxgtcxTogKL5aPOxT5gf6PXMqu+ZBTgzrWHA/uH/GIHJf W18s71mhsE6Qo6wzBdDjvvGNb3RxIvpYZ51A7L1Cv8Qhriru2hok3zhv6E+C zwMbMu9rXvOaXr7yODApf1bxVWEdkX6d2J7gq/SvJv+4c/njHve4Pj+T+Xkn yVbFV1uDXLugz4kdMBei/u/6apEjA3hPUq7if/xNvC/lH1dYR+R4YH5Wx8hc AczpxLhp/8i5u+q7LA/KRPg6aHM3XhoZGF3xiCOO6Pah/5GZ1QvbGj7l81BY Nzj/Yvv47ne/O8ZP2nbZ8F8EzM+uPfG8T6qbXvXUtwbKvsi8WeuMeeNXf/VX O7mK+9TWZD366KPH/Bsqf1ZhXwG8QjwgvMR6E/M0PlXpZyX0UcAW77GTzll8 tbVo89Kgkz/mMY8Zi9kh57RrJOQku/fee/tjyj+rsO5gzoWrnJ8z1yWcpX+V NqtZbbTFV1uHjHFSps049F//9V/vuarNQXbaaaf1/llwVMYrFAqrCOP/gflA fW6Rk5SltLFbM5335a+w+sCf9+lPf3rPVcw9WY+I/FmZf6ZQWFXk3Jw2DGxV X/ziF7u1Jv0Q0QVZc1LWevvb3158teJI3wRipYgzxOauj6/zzute97pen6y4 g8KqQnt61i+Aw/CvMs4DruI5zzrxt956ax/3X/5VqwtjcIiX5j6R809fUvPC u8570kkn9cepVxYKqwbmU+dWdEHsVTn/ph8P23ve855u33YdvPhqNdHmRWbu YY2EdRN8e+Wum266qc9NViisIrKuCpyFraPNC+o8zPbhD3+4zxOQeS/Lv2p1 kWt9ylvUCst4HbgKcC9rbbCwqvDZhLPMC4otVhsHchVzMZ+hA6InuIHyr1pt ZH1tX33/K7/yK939fd/73tfti81SlA2rsIrweWbeVaYyf3HWM7jlllvG8u2p M5R/1eoj69P73nhQ5iDz+8BXrreUP0NhFaHd6hWveEVnp9JnXZ2Q7V3velc/ L2demY3qqxRfrQaG5pWUj/0uc2OlfaCwfGS8rmPM+2V9NzEUP+X32myAtma+ Ywynzp/j2nufx9KGnL+y9gLf+X4rYyLkl6zHaUwyNQLlKHO+IVfx2Qc+8IE+ DwnI6yy77L6P1g/Y8eMz2+Z2yOP8LOtfKMv5vc+TdRPz2cz/0wcWqK9mfjZr AvndutcrY50e/nCctrnKGMt8n/3i9ed6v/sDa8NpG8i1GPut7Xv7kT6Ww/K+ tnGnm8UQ733rW9/qXl/60pf269muc/v6zne+s3uOco5u660Utg+Yu7B1ffzj Hx996lOfGn3iE5/o3rt98IMfHH3oQx8a3XnnnaO77rpr9OlPf7rb773vfW+3 TsNnn//857vPOQ+f8f0999zTPUuMHcbMpHw2fE5+yPRtZux5/s997nOjz372 s107ho5fByR/OL7+4i/+outf+o9X+pdX+v8zn/lM955+/+hHP9r1Jxt9zP8c yyt9wufs98lPfrL7/u677+54zH4XQzKJ7WI/2kX+c85NGz7ykY905+WzrUDW PGf9z+fhmGOOGYtftp4dr/iCJn/Cq6UfbE9w/5m3yAWYPnjaOvGRx5Zg/MPQ lnFc5qBNOynnoxYZ8RTqHvrcM9+39n9zftE24ozS34b3mX97HaEcxLVbByHX czPntf1uH3P9eS/a/duaMMcff/zo7/7u73bze7HPs2a4uPjii8d8CHg2zjjj jC259nZ9mpww5G7L5838uTx32NZzrai1d1Tuye2DvO/5zPvM5DgyL+BQTW8/ z3GkzUF/GZ9/6pF96Utf6n4zcxnl/Jlc5Pkyv1Huv45IHStlCvoQm01yRXsf 6GP63XzY9EtbD7ztM/b7kz/5k9Ff//Vfj9nPMr8jfMaGTn/++ef3cXm+UmN8 q65dUC+F3Li2PWtu8j9ylTzb6sBtX67z81CYH3JP1uPJfKa58Sy14yifOXNy OVayHhkyPq+Z4yNtKu18n/FiyVfrDm19clXKqK1cxX3gNcdzW1ud77wn5lmR 7+xzcm/S73CAck7a48UVV1yx27295JJLNn3N6n5yJrq+Ps35DHG/3//+90+0 T7V+DKD8Cvd9aAfgtR0Hjhd0AcYDz7/jRXnK8cA8zqu5aN0vxxSyvfO9cUPI WdqFU74CfI5N2pq8qVu262jrglx7U7bNvpZX+D/z+rpl3v6UNx3zyl059of4 jftN32a8HlDGuuyyy/pjPAcy11agtbe/6U1v6s5P3gV+j9ebb765l6tsU67x 0N6Wr9bZPlCYD8xXWf/WcXH55Zd3OhtzV7ue7vPh9wA7w4tf/OLRYYcdNjr8 8MNHz372s7tz5hyateHYfC7Je9PagmkXPJm5Q3i/zr40bQ30Vu+D6+GGVl7I dbFcxwWsr7G29tznPrfLL/usZz2rzy9Ef8uD6pvKqOnTkPPFkHyFTWuzSL+J vD5sVLYPmcs+4pmzjZPuOedcx7mrMD+MZ+dZMP9M6oRnnnlmv29bv6K1c/r8 scbn/z5H5m/W5y/1yRtvvLGLvxfwl88mr0N25GzHuqGVIx2nzBHKR8oy0/y2 W1izzWOz3q5cry2b3GhDOTs47tJLL93NdnbhhRf2Omz682X7fJVvUg5uOcWc k4B5jueAdci0abJP1UcpiOSe1lbLdsEFF/T7ts/NLGNIOYDnlxqKqcNok+G9 MRgt4Dw4Km1qbJ43c4fYnqwn5GvrS7Y35+NF8pXHJP88+tGP7uyJ3N+sz0f+ Ic6LXJu1KjfiK+Hchb3eNspl/j8kF6nL5f/OmcxznGOSf1XJUIVF8xW2c+Uu nl/qKzFWXMP3N1lv9zlun8u0QasbJlLuS7/Tdv1eHlOf2lvz9SL5Km1DrlvA Aax3pL7vq+uFrU/9JL6SX9qct967zGGb+yhzA2tjDrXZay3/qsIQFs1XIP1l zj777O68rh+q51177bX9uc27Jhw3OXYAz3M+945PfZuE8z7IMbS3bGCLlq+8 duRVORuuYb0j7fT0vWt+HDOPfEXfpwzH8e19y/fJPcpNylUic323/lVlSy+A ZfCV/OF6lGOFsWme+ec85zndvml78bVd22L/BONSTjKuI9GOG2Wr1u69LCya r5BxUnZEZ4O38r7an8973vP6/kl9bhJfMSckT/Fe+bmN85E3rXniOl/2Qxt3 P8RL8lvJW4VF85WxE4m0/zoeWL8CQ3yVYwZdUn+GXO8G5JkkNiX9mNjwT2XN 6a/+6q/6NgzZypaFRfKVcYOAe6rM6TzhPZav8Jnw/mTs4DT5CsBVX/va1zo/ qZe85CX9OfH9Yj4ij8Kf/dmf7XbdopW5Es5xbRx/YXtjGfJVcgN2jDa3vFsb Y+v5k9fkImUBxsyxxx475kvqOFTX1DcDvx58vP/yL/9ykEeXhUXLV/Q391M5 iPU21385fxvfA9qY6kl8pZ8cMY3mU8+YBv3u9ttvv36dmbnobW9725j/QptD gvfaFuXcVk6s9cHCMviq/S25RR7Rt3vo/OqDxqgYCwTwNdU/gs+Rvaif0vqx +hv+HjUb8ffZW1i0fNVCOcZ72sZ6gln9GcAf/dEfjfnQ5Vwid7VzBffsqKOO Gn3lK1/ZLe/DNPtUu7Zb2L5YNF9pn3A88NrO8/g1Mh+LofVB61irb5CLoG2r 49B8Sa3POMcfeOCB3XvWJ7/85S9vouf2HBvxle2Er9IPfk/011wDxVaXcYdy zC//8i/332eb+H37Wnn1nHPO6XxR+YzzOBfQ166feA/4Lp8nfw/O0sbY2tQL hWmYxlc8txlnmvaRtDW1z1v6zqRv1Ve/+tUxTuE9MhHrhhmHk7AtrG8xr8tD 1p1LvZK5/2Uve1lnRz7yyCP7seacr76i77exdCD1j0XmX52Fr5Bvcl6YNT+m fe090YeDGjNyj/0Hp9Dv3pu8j+eee+5Y37ERQ6U8Je/R9/iovOAFLxi98pWv 7GIanvGMZ+xm10/5dufOnV2cM0jZaW/aFAvrgWl8deWVV3bfD+W8NH5r0jgy 51X6PhMnwu+g38E/xCbyO7fffvtu49g1oZan2LSdsD3lKU8Z3Xbbbf1vYtvK mpnYTlL2Ms8N9ixkhqH+2Ft8ZYwB8TD2b2vD2Whr4XU885nP7GWhjG0itxXH YZfPa6ZflGtbO6NyFdzkb8KH/p4cSQ3fNo5b7kpuqnW/wqyYRb5q/Ywn+R/z nA49e8pLzNk8/64PMj55z5zd6iMg7S4+8+iNKSM97WlP6/yzATE9reznOcln Zx1zNnkSLjQnrz5Ei/bLmiZfsRFv3Orfs+QfyFhM7wd5YNTXvMfKWnJLe25i BW2L80v6xr/jHe/o9svcDtzDvH/o/uibqa9zD7h/xnnl72YcTqEwhGl8xXM1 q22hlbWQc/RrZi5u52t557rrrtttbKbPOu1q20b8NHEmgN+Qn3j+GbPKV2kD 2rFjRy8bwFe0g9fWD14sav1wI76ifbQLvmjjNX2/0dZeCzk75Rn6O/t/KD8M /cXvXnXVVWO5a5JP3/3ud+9mA2h1uZTVDj744O44uMq2wMd5bNU/KcyCaXx1 ww039LV2stabep41KvNcvGJT/cIXvtD5Q6l/YP9obRnocjkv+5o+6cpBvGYu O9qQnJLHmHNX3mI/NmSytjbUNddc083tcuui16KmyVe0j3WO9N9sfS03wvXX X9/lY1GGzOuVr5/61Kd2+2Yu/MyJwFpg5gxKuU/QZ/ZvxttkDkDimJHvMm7U 9Y/kPPhq1usrbF9M46u0uWpfRR8wdtYt89f6fdortI2nPsjn+PGkf2PWPgDa r/wdz5F5I4TPe5vXLb9PXwfOQ7vavE5Zf2MR2IivMq4y5ZtcX5i2Ice0a3Nw j5zPeen3STUoaZf29jwH90vuzHmqvS6hLQubfuZFMy9q/n7ZsAqzYBpf8Yw6 NzrWh9ap22eb55LjGCPuI08pb1HLAGRcjHpB8sxQjjrGU+Z+ELmGr29jzv3I LYz79C9lvSp12UX7+2zEV+bWlFtSPtLmt9GWx+lnLod575B5kd0yNrytX0Te syEubGOb1LnbekhDa7y55qHfl/e7fNcLs2AaX6WvjvqFW/rzmPNlUt5xuYox xD7EcMAzGz3n6nGZSz7zzyTaOn5tXA9gbGhHts20H/uZ+m7ry7gITNMHucbM pZq58r0fkzY5yXXA9OFku+OOO3q7dvqm2D9+bn5R85Tx2xdddNHUa0s7ZF5n +mrYzqG+KBQ2wjS+gl+G5CrHVet/mFyV+Y/lK+Jh5p1LPae/z+u89XrdHxtz yim812+7Peei1gmn+TPwv7WNk/dTzpy06e/vfVOOpP4MyHpqAF5v1zqG+Ir3 xVeFvY1Z7FfIVdqd1FlSP7EOTo4V7BXY15///Od3z3lrK6FG76zrb9uJr7Rf mS8/+R89dpo+yPbkJz+5y41MnWT8Mtt88bluClyXyPYZj6N+mv20EYqvCovE NL5iXRuucU0wc0Za10Y/H+0Yk+qWqH+0+Y2mYTvxldd39dVX7+ZHMsv62VA9 Z5D5Drhn6X/Q+iYkX2W7iq8KexvT+Oqss87q953HDyv9yz02c+5m/oBp2G58 xUY7jYNq8wlP829Pv12OxU44zdc0OavlK9uUsaSTUHxVWCRm8W8XacNmHrcu SeZQb8dPq/Pl2JvVR3A78ZV2K9bnlEf1dZvFv505IHW9jXzGuW9DfgR8bj8V XxVWCbPy1aQ1/nlyIu/pM7md+MprRb6ZdOws8lUrkylnuZ+x0MVXhXXCNL7S nzmfJ8fDpGeslbPasdPmYZuG7chX+F1ob5rHRyn3z/yr7XUN+Xp6XPFVYVUx ja/wTW71hrZW5xA/5dhv16c8dtb8IduJr7Yiv+hWtG+WfMhDKL4qLBLT+Gor 84vuKYqviq8KBVB8VXw11L7iq8Iqoviq+GqofcVXhVVE8VXx1VD7iq8Kq4ji q+KrofYVXxVWEcVXxVdD7Su+Kqwiiq+Kr4baV3xVWEUUXy2fr/RHM2bA8Ws+ Md4bj5NtWFZOO/zg8RPOfDbk3SCv8Sxo/ez43xxeWZuH77IvCoVZoN+mvJD5 QHNONQelWMaciM+1z7h8xdgBs45fxryx1tTJMl+Xuf+oWWYfEO8oRyyCr7LP PD9tMC+o1whfyFfLzr1JX2V+UXkLn/tpaJ8JfYs53nzOXitoYx8KhY1APKxz m7ndMkcoedKte9Dm8FwWsu6BHDNrjnX4J/3xka/kK/OLkjPHa5oUU7eVgIPT t5/roe8dx7QJfayVZ5cBYxUyD6vPwiz5+hJZZ9dzcY0+Z6Lq4xTmxa5du8bq 8/mcvvWtbx3Ljw4WVedqCNTZsVYquUppF+2cJVdBC3IXYBciJ17m8eSzrOkC jAdeBLKuBr+ROdeVa5ED5TQ4hBjAWfPvbBbcb/okdTf6bKjGR4uhuHba3tbK 4JqH6owUChshazEM5R6Bx8CQHrPMZ8ycgYA2Z+2ujcBYYdxnW5N/87rgYXTe RcqPeW45t+WhzFm8bFk2f4/+MAfjvFxJ+7k+ZdWhawQ571TNicKsyJwJPGNt LPJQPpll2Ejbui2ZP3MeHcJ5X1sW4JozJruN6d4TGW6WdojMiUB/K7e6j/Ww bN+y6vOljJTvZ+nvodwPPkt8zjX6f+qL/lahsBGGnpEhe8ky1s2mIWt9bVUb JtnWMxfqVoP+zRzRqXsmhyV/LsuGZXvS5pfz2Kwwl2OeQ77lWrPu2rz5hQrb F8lX5lX3+XFctWOa12WuPz/wwAP9+8w9Pst8P4l7W05IuSvH6FYjf0+0cpVc uVG990Wh5RjbM+v9buVHof7u92kDbfMOFQobwXHRPi/tmG25bRlox7JIDpsV 0+SV/GyR8lWhUCgUCoVCoVAoFAqFQqFQKBQKhUKhUCgUCoVCoVAoFAqFQmF9 8f8AX55fDA== "], {{0, 241.}, {300., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->{50.24609375, Automatic}, ImageSizeRaw->{300., 241.}, PlotRange->{{0, 300.}, {0, 241.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qm8beX4B/DbgKIoU2ggpUJEaTQ0q0SaLkLRPFHppoSkLs1FkwZCs1IK GUJxRUJlHlKaKaXRECrr3/f1f1m2fc7d57TPXuvd+/l9Puuee/a4zlrv+7zP 83t+z/Muvs3um+4w57Rp02bM88g/m269z5p77rn1vpst8Mgv03ebsfOOu22/ 3Qa77bX9jtvvuco2cz3y4FmPHPPMMW3a3I/8rAKBQCAQCAQCgUAgEAgEAoFA IBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAI BAKBQCAQCAQCgUAgEAgEAoFAIBAIBAJF4i9/+Uv1u9/9rrr77rubPpVAINAi 3HvvvdWFF15YzZgxo/rsZz9b/f3vf2/6lAKBQAvAFnzta1+rXv3qV1cLLrhg tf/++ydfIhAIBG6//fbqPe95T/XEJz6xWnbZZavPfOYz1cMPP9z0aQUCgRbg sssuq9ZZZ51qjjnmqLbccsvquuuua/qUAoFAC8B3+MAHPlA9/elPr5Zeeunq lFNOqf72t781fVqBQKBh4BjEEssvv3z1tKc9LcUYt9xyS9OnFQgEWoCf//zn 1dve9rZq3nnnrdZcc83qm9/8ZtOnVCT++Mc/Vtdcc011xx13NH0qgUBfcP/9 91cf+9jHqiWWWKJ61rOeVc2cOTPG9yQgL3zqqacm3ubkk08O7UigePzzn/9M +cxXvvKV1eMf//jq7W9/e/IlHnrooaZPrTj8/ve/r3bbbbfE7a6++urVpZde mq5vIFAqcJJ77LFH9djHPrZ64QtfWJ177rlNn1Kx+Otf/1p9/OMfrxZffPHq KU95SrXvvvum6xsIlAicJHvwspe9rFpkkUWq973vfdX111/f9GkVjd/+9rfV O97xjmq++earXvKSl1TnnXde+GKB4sDv/c53vlO97nWvq+aff/4UM//iF7+I sfwoQUsmXnvFK15RzTPPPInz/c1vftP0aQUCE8Kdd96Z/AW24dnPfnbi08I2 9Ad33XVX9ZGPfCRdV8fRRx8dGvURhDW48ygB1rivfvWr1WqrrZbWuLe+9a3V z372s6ZPa6jAF+OTPeYxj0l61O9+97tNn1JgQLAW/OpXv6q+/OUvV6effnpa ez/xiU9Un//85xP3b/1oc82jGHmXXXZJMTI91Pnnn189+OCDTZ/WUAFXKddJ h/rkJz85cZWRMx5u/OMf/0ixJHtgzV1ppZWq5z73udUznvGMpBvAR73pTW+q 9t5776RFpD/0njbhgQceSOdP64Bjf+973xsc+xThxhtvrHbfffdU6/bSl740 1cqHHR5OuK9ql7bffvtkE+acc850zD333MmHdMw111wp9+0xtY9y4XLgbRoT P/rRj6rNNtssnWPWSZYSF5WIWbNmVWuvvXbKH1tTfv3rXzd9ShNCSXFzk/jl L39Zbb311kl/zAYstNBC1YYbbljttddeqUeCg45ggw02SL7EtGnTqsc97nHV Flts0ZrYnvb3oIMOSv6OGqwDDjggxUKBqcOf//zn6kMf+lD1hCc8IflsJ510 Uqtr3tgCPqZxce2111aXX355Gr/GjsfDVvwv6GaPPPLIauGFF04+wote9KLq gx/8YHXllVf+Fy993333Vd///veTz87HYCO855hjjmk8znBfL7nkkupVr3pV Oi95zauuuqrRcxoVuO70qdaLN7zhDdVPfvKTpk/pfyB3pZ/gxRdfXH30ox+t 3v3ud1dbbbVVWu/e+MY3pnXQ4+zFn/70p6ZPt1W44oor0nUyr57znOdUhx56 6Lhck7gTH8XHYE9wEvyPJoFjkM9cYIEFUn3mUUcd1aq4Z5hhfTnssMOSz2a9 cO3xl20Bv8Ba9/73vz/ltJxnjpXz4XePv+Y1r6mOO+640HT8P+Qhjj322OqZ z3zmhNbdH/7wh+m13rPYYoslv7KpPkx8h6985SvVKquskngH/EP4DoPFD37w g2qTTTZJPIS1xprTBl/dObAN2267bVo3jFd1OGIhvMnGG2+cfE6/exznZjzj 4NWpjjr4XHKBbCgtERsrjpgd+GBiEj6E977rXe9qzC+7+eab0/c7/2WWWSbl 3ZqOd0YNeAjXHW9tHu65557VDTfc0PRpJV/XXH/qU5+a5j7/WI2eOhJ8/I9/ /OPEsct5vfnNb07cFRtCj8+Pvueee5r+ExoFnQOO0TVZcskl0z3uFd/4xjdS 3Om9r3/969O1HjT4LOecc04al2ILHKoxERg8rDViPHlluohPf/rTjWpW8aSf +tSnqqWWWiqNUef04Q9/OI35Tv2O3+W+rJVsiTVPLEJnN8qocw8rr7xy0kT1 ClyleM17l1tuuaRDGjRwz/JqdJJqAtzP6DfbHNS8rLfeeinOsO40yUupxdtu u+2S34A7NfdvvfXWMV8vFhEnbbrppilOpa+z3tx2220DPOt2gT5gjTXWSHOc XkA+u1d02ofPfe5z6fFB6bHFM0cccUTilaxZYqPQ8DULsam4E58ljsdt4Qeb gLgh57Pk2/gSsxuTzlU+LsfNfAg5j1EFnwqv5BquuOKK1UUXXdTze3Ney3tx PeI5XMBZZ52VrvEXv/jF5OvLI/TbXvBb2TL7WFgf1l133erb3/523z4/MHmI M6dPn558iI022ihx2U3gjDPOSHyDee48rr766p7eVx/Xiy66aOLeRxU4Wv55 vhYnnHBCT/65+Ynj8R7vxQ/rL/T1r3892WxcgL4L/DvridoN98drcIeP1lbw HWl7fY/48sQTT0x95ALNQ9xvbKjttA7LfTbhQxjL/EraX/y1PGwvwE/gKo1r eygdcsghI5srpxujd6KbFMPjnT02O/ALdtxxx3Tt5Q3oFtkMdX377bdf8kVc W3Ecff4KK6yQ/BRzGleM22Sb8MPZv+gVdU7Sd4sRoxd1u2AcWHdyvvN73/ve QL8f3yj2ND6Ma/sa9MqV2hNFjoN9cP60U6OsmRJTWOtdj1VXXTVxfOPNV3Pa ei2XmPMeuGrvMXfx2GILGkzaKbaBreDn4Yn4HPw344fOKuea/vCHP6T3zy4W 4TvstNNOyaY57y984QutyLUH/gM+hHot9bN5H8Ne8ub9/H5+C/uQ/Ydev79u H+imrD+DPPe2gc/PRtKH0NFvvvnmyUbQqHf2f5DTpi+T63DtnvSkJyWdKh6j E/x964jYgo+28847pzjwec97Xrpn2V7gsfAH7iHfgtZJLMKPyfYigx3nN9Kz qCuW22aPAu0De7/PPvuk9RsHPlW1cj6Tb8AmZN2Lx4wTuUrz3FrUa2/BOidn fKsvaXM/g6mGOciHUM+N62Mj+BHW9tNOOy3xwHqKffKTn0y9B3N9J99L/gJP OF585l65b3IL5j1fw+fII7Ez9DS5TpQ+lw6Sro3dxnN+6UtfSj0daHB81/rr r59ez6b4ve5zNHEEusOctTZk/1HsOl5+caJw7Y0J89mYEuPyWXIOS75dDGqe 67fdy54nxpLPyO+zlpkDow7XlJ/PRljTre38CbbAtX35y1+e1nm2w3PW7te+ 9rXJt59ovZ5xo15CHQ+9xeGHH55qR/GaeiP73qyL9z24DH0O7XnF//AYW8LP YdfYL/6O3Lv8tXyUe+zcvvWtb6XH88GeyMPqW4unrj83mQM3z38ZVf5qdnCf 1dFaA/QPcV8ejT4l+wquuTVLDGGd4U/SK1g7xKrAd6XBMI58/4EHHjhbjlL+ DUeWtdZqCJrKv7QFeQ2038kFF1yQekCI68VunTUs8gXWA/VvOKd+1OGwL+IW 85WPQscg/qOzkZvI9oI9z4d7x5astdZayX7JU8t1up/+r5e986Tp8Hg+vJ5W 4wUveEGyR/Xn8uF789Htsfpzvg+/2y2+CvwL6h/oa/P+I5PpEWGMGp/0fNZz vog1K2sdfbYeNbhxPc5ALMp+yGF4Db+UT8Hn6PT7/C4eEjsbG7lWUZ/NUeYe cAx0TmytNVCcJTdh7RV36QEj16PmCX+AR+Az9tNP7IT75xzyWHDPnQN9LBvl 3tXtVq+H91pHutXviZX4JXJyfMp86HXhqD+WD7GQ8ckG4WMD3SG3SScl14mb xlv3On74GnwQvgI/RDzr2vNj+ZDuDZ9BLGxt41fU/RP+pLGLA+EXWx9w63xX 897apJex14lPrB1i12zLmq5LbhLsKy2TOIE/UK9pZU/ZCjbb4z/96U/TfRp0 3ZN7rQeFc8BFmsN8GOs2rf9EDnZGjT9OQ76r/pwxS6ehz6aemw62Ccdlb778 WP3wnM+zB8RNN9000OtSGujgxYjmHb9OjDdWvtHYM2/5GWeffXYam3yFnAOT t8Jb4afcA+ubud6NC/I5+Ctcle+2DoiZ2Qzjia/qc8wBNVm5vlNvJFqeUeYl XVfXha+OD2yivmoiEHu4h/KqtHHG10SPzCmyO/XH/d6ZK4HxOMjgKHuHa4xr 4uPLCaiFwDnX4TqKV41DNvktb3lL8vX5CtZ+foNxal7zb3vd/9M6iJ+i4fMZ bEQ3/9Ljnve6bBv41KNYCyx3KH7ga9PKq2Vtu/4Qt2W8vPjFL26kFmxUMVk7 2PkeY44Ogn2gmcn1EGwC/9D9FUPgna0DYkDcgVya2FaOgu2gv5loXag5To/n M+RcfYc+aTgLvgU9uPy6c/I6r6e541/rxUwDMCrI+0Ood2SXXatetelNgubS OYd9mDhwALh53B0umD+efSfrgscc4qTOn2JLOQGH9/d68E9x2DgB842vr3+A Ndrc19cNlyXes5eG+cpXwBXggcxZMZ98lHPvR47IZ/h7xTviwgsvvDDt3eF8 2a+6r4Avx1ewIc57VPYAYhfxv/IT8gNi7qZq7CaCsA+TAy5QbCYvZU7KJYvp cTAO/rrHttlmm1Qv0/nT+mGNdXh/r4cYnraa1tX3iPXF/XxWcT6/lb4Sz8u3 5zPgGXwvnZw522TeOOddrKH0XWwZ7nyY4XqrXWCr2WljpjMObCvcHzn0sA8T g3ojMXXO6RvvY8Xg9cPrcIJyNHVNSv4MdTUO4wjnn3l/j3mfXJE1qDNXVM9V e697ahwef/zxKU9B39yGvRDxFuINuXLnqUbZ+Q1zfxHX3pogN0TjwL8q5e/l 48lJ80/lDwK9wTjHt8nTyFeLv/kPNKzjHfwK+gE5Gut/fvyd73xnek4+EIcl tyh2d8gReYzmTU5z5syZyTbJXeT30zPlul/3UgwhjmljrkBvGPEPG8H2iYPE Jm2wX/0GHkgsIabg29GTldRPhc+pP6D8FJ4p0DuMZ3aC3gX3QEco3h7v8Lpc Wyv27nzOfMYpiOdxhvIJ/G+P5bhA3Gruq33I76VplTdjH/xsey9hNkJsJLdu 3uBKnXMp62qvwDfx4/iG8kTiq5Jyc9l/cJxyyilNn05gksB/mWPiDH5FCbX5 9FN4GNqLvG8jveUwAQfM3/N3qj9o0x4FvYCmBm8S/kPZ4G+IdfAYNIpTqcXt F/hEan30JcCnlLJn+URqDPmDcru0pW3XOnTDmWeemepwgn8oG2IM/QRKsg8g JqOFkJuR/2vjPmF18Afw+OJy523+yGP5P64fJ6WmFZ8yDP1vsj5KHmyUewKW DuNW7zHxRUn2AcwjeVfa78yntrUHgDyl/LH58vznPz/VL4nNzSGP0wrI29oT kQ0pIc4bD1n/QHsXNfnlosT4Yizwx/VFsK9Gt0NuRu0emzjo/Iw5ryYu1zvn HHT98Dg7LWchV1Xyvcj2IfyH8iH/aXyqsei1r1PbICdkHBqP9CT1Qw4ga0To CPCxfP1B7sfF3+Y3sA+5J4OcZT7kZHCRamC9ho3w95SqE832AYfMNgfKRd0+ tGEfvskAZ6meJGu92AI9Seix9RZRi+b3rB/TewlvNigbQT+ee1nQsKpjr4M/ QzuvH07WtNJ3lHo/+GnsoOtNgxMoF8PgP6jVUNdovTK35DT49DSHajf0UfW7 XkL0iP5eNkPt6SBQtw90cd1yErgR9S16Knkd7Rq+skTIyfKXwj6Uj2wf1GBN pp9UG0AfRW+Y/XP60c46Jmu0vjV6JHqNmINf38+a8bE40E77kHtk1A9/g/4Y +ml4ndxMqfuWh/8wPMj2Qfxbao8m/AMNOV2luSVn223e05XSnatNxQfusMMO qddSHbPLf+T+3PTOuE46WDyB2lh5VnpOtRP1+jEaoaxjt8+E/eW8rn6o41Zv QfOlzkZ9fal7lmf+IexD2TCu1XPQGamPbLuOYCx0sw/dcp5sxtFHH/3v19Vj KvlS9XO53zFfX88J+uD6oV8OTlHti/mMM1BHI0+sJtZ1pEWlMc48Q90+0BSq p/W6+iGuYBu8Rj/Vyy+/vChNdR1hH4YD1rhsH+TeS/Vn+eZym2oyzC9/i17X et2YZ8YrLkIMYg7La6hr9bdbo8UiNJk4wdwH2fjWH03/i/ohhsm947sdeW8I NiP3OqzHF7Pr2ep5PRvbXgszHsI+DAfq/kPJ+gd+gX7NxmPev9aabC8ePXNp seUy5DD0zFL/iW/J/fLxAUcddVSa/9Zw2iXaHlyA95rbeAs9NNgXdbBsCY5g 1113rWbMmPHvQw2t3tvqRHKMUbcP8hP2huB72PtH/ZXPEnfoycv2sC8+p1S+ OOzDcKDuP5RsH9Soihv0S84aJOt4XQfh99xz3RzEPeAJcv9n+yLop+1z9JrQ V1WfTvkPfDz/Qh8ueUj6Ru/F1+Ah5CPy4Zp29tKp2wexhXoR11qPPofPEtt4 HZthXrFlYqYS9dZhH4YHmZ+0LtpboVTQ8Vr/zUHrvtyEvhj5wEvy23OMjweg mTA3M3Ieod9xf90+qNvu5EQz2BW1GeIaNo7/c+211/b1XAaBsA/DAbzewQcf nNZVvjOfuER08pM4w87+czgG6z99kt4lXidHj4OcatT5SXY47xvUDeq07DPl tXJKJdrssA/DgXp8oT9MCb2Ru8G6q7dWji/Gym/yDcxN+QUxhziDnzHVPnxn frO+v01Gzp2q6eRr5J4c9qcqDWEfhgPy+HJ17IOejvJ6JaJX/QOwEfbqy3tW 4gmnumd+Pb6wD6le4vyC+uExMRL+gd1y6H1TYv8H+g7jKexD2bBuWj9pCeUE cW8lgi1Q8ygvYV6xebkvZae+SY86eQZabDok43eq5yC+M+8JpmcKG+B61w/x nbpvc8q52b+wl33O2wbXXf8o+SJ9kfUMDZQJ+j/xuPFozpSq15N/MM/lKMx5 +8vjHXF71uW8Z4ie11637LLLJv5Pz4VBzMEjjjgi2eBuWof6786JvsIet86V 3tPf4T6VopViH+R+2Do86yD4ncDUwH4K9tuQv5DH10+qRNTrN9k6OgKagqx/ UK/lEBPjAcRTYhG9LzprKacC5oj1VE9Ge0jbv4Sugp1Sc+539Vhqz/Eocp5s nn2x1Ws4T7xJKTaCVlz9W+x/UTayfTCvStY/sA/2de51/3gaJRonfaEHATpK +k08xKxZsxLPg8Pzu1omv7MJajjqvWhzH0f5Fn6PWo8SEPtvDgeGxT7gH4zJ 8fYQE9/rBaHmggZKrUnb984QG9FsiJvoN821EvbXozPDPYR9KBt1+7DVVlul OLdE8LvpGDtzAvWD9oEWMu/5WwLkn+VG7QmEvxCD+Dvavt+HPAyNelvsQ5O9 R0sGvQP9f2ctYwmw9uMO2IVhvvdsttoSfJ81Wd1om+vo3Bd1rosttliqYbFX o7ipqUNsZ5zT/hkvwzxW+g21jXoq5X4k3XQ7bYR7LBerR4LcQIkaol7BV2Aj 5Gxxq+YdvXjb9gRyT+TLjSm8sDwtjYmYTq1LU4c9ptXq0f/RApbaw6AJ8Lvp +UrzH6wL6inwjHKU9gkcdrDd8hvqT+2jrH9mG2q32AX6EfljvWjxPLmHZr2e Xe5W3sjP8Y6xXuNxeTY/O49u/cDza+vvF+/gqQK9oUR+Ukxubxm5dXqoXIc5 7DAP8SfsIS5CflRNaRMcK58GT0pfomcfP07+WO2beZh7hrMLfpdvplPVE2OP PfZImhu2zk+9ANXL2C+a7lWe2p7TnpPb9Zzcu8fzHtT0LfwpP2lMPd7t8Bqf 4bN8pt4+pfZQbAIl2odLL700+axZi4i/aztf1y/Qr9GGizHkNHARg9rXO9e2 5r3A2ARxhP191L2IJ3AktKA0ubvsskviH9gH/S74ePwdGhv+H027n3K2eAE1 rfZFo/vgj3jO35afy/3ArA8+x7n4/3h7AHiNz/BZPrON+9K3GaXZB2PTekAD RRNgbdE3YZQgzrBu0lvRfHRq2vq9b5j36p+jlza9hmsuvplvvvmSf4BjYCPY A7rJvEcgXpCv4Hn7eejvVep+Hk1gvHvW616u3cZA53gYb3yUZB+MUWMsxxXq nPDSo+I7ZLiXbIR9O3G09fvOVtBa8fnNVf40/0p/f71sOmvex/sOcYt1V09t vr1ac3bBfFf7Kn+p1w1fwbmwB519cWjX6UW9Xl17yT3zBgU21Lw0tv3kX+Gi +Y58IHuieG4ih3o5WkDxoN+NG5y+tZXGxmN+51/Ve7XS7MlbsA/sRFvtAxtg D1uxN96JTtq4DX/xX3PZvVUXbl8uWm2+BV9fLQcff9VVV032H6dpHo9lUz2u 5oOum23B7dhLCCcqTvDT7+IaNWdyhsbvWOuP8axvn/Pg78kfTHWtbMlgB/Q1 pkUSk6kRwMvgavjNuBo1/56byKGWVv5GDsLvdDQ+x9xXf+AxHA1tv9y0vWLk yLyG74ffZef5j8YPG9YmTYlxa43S4xnnYC/NNnD3TcN6zfbj9eiZxV25R651 Xo0JX8tjfqr/sN+5eV3nNX2OtYHNNYflIPTANC7wCjTe/Ae9hPTc41f06rep G8FT8CHUmgxqT6ISYV03Z9niXmsF+nUYO/o78wv1YbMHXc4/GQf6OVtn+BHi 2rPPPjv1bzVu+KVTaS/yZ+PE2VBrkjFb/07rDhuhJqEUncZUw3WwrqhZdR+t 7+qirAU0VXpi4PutD+a4cec+Wxfqvj5NprXJe3GNmd8xn+UO6CHpBibDH7iP +nfKLbJZ1sNh1qs8Gug9YHzLtfAFHXgdeydYA/JjU3H4HtwyP8Ph3uOYjCvj xrhwZM6Jptfr+JgzZ85MvoW1SvyDZ+6XveCDinNcF/ko49FYtV8eX0svV3F1 W3yZtkA8qreCPpruofXeOOID8AFz7MXWsgV8R3taWQtyDXz29dWX8iP5GLhG vOIJJ5yQ8qfjxSO9gr8hD+l7+X80lfikwP/CfXNt8uEeWaPNufrj/T7YJtwy n4B/Kb7gR7AH8tP0Rnqs4P2MI75G1p+wG7ipvPcLH/Scc85Jn2dN4atOZv7i zHyneEgvSHYJv5D3pzCW6DuNZRxL8A3/gX7bOL98f/S9dT/G0kOwseyJa5rv uXtofXcf6AWsW3w087mfugpjg65SzxvnSysxCpq2UsEm6SkgPhVvmKPyzPx7 nKaaY/vL07Ooz+BLGINZj8aP1btATMrvsdaLK+mU2IscG4wFz9Fu8o35scYr m8BeqVNkn/RbYiusjewGO2Hs1uufRxWur7yEmMH9wD+pF+/MH3QCH06n5Lri FcQh2T+gE5jKWhZ8kbpZ95Xt14/IPgGBdiHXQvMHzHdrN/++G/gd1imxhXhW zwRrQI4lM7fBXpjXeCjxLn0jrR9uqltOzbjgr+Q+0vS4/Bbv4x+zT/hz9meh hRb6tw5PHM3/GfVYgx1gk8UDuAKcYy86Kfde3iHHJO6ZGGJQMB70xnIvcaVy LqOWn247+Ac4SOsH30Fc2ksuwLqNe8Bl6S+Iy1b7guvmS2R7QVcrp0bjaH77 /DqfiG+wzx0dgzFqPaG5wX/Vx4qeL+yWeYA3s+axIzgKObhRBk6Bb8fnUtPp GvXqV7mm1gTX3h488lmDsrfiQzGN9cX4w20FV9kuyEvgoqw78qyT1R9meyFX zr8wb+VraRPEuHxIvq+YwR48+BWw/vMDPJfrlZ3DWOsIHo4uSoxjTMu/68U0 ylyEOSVOYI/xkvi+2cUWGe6DmNC1tD64toOs4aCVxl9lrtJaYS0INA/8AI6b X2oe8y17HVfjIdfw8RPEwXIR6q7pOvCZYmXjkg2QK+PfGtvyI/yR2a1fdNV8 DDbNuYthRln/ID7DHbCxYjQ+Wq89b9jV3KvTe3GWg67xUutpD2Tnj1eSoxr1 mLFp5HyYNUOdHRs+lX66cYgHpenM38NG+F5zHN8pb9pLvzR2Jefg2BXx0Shz W3gh/A0f3b3kn/Vq5/keeCT2QZ0XHnrQ9sE4yHVmxoF8at7rPDB4mF/6peME cEP2b6NXHvS4wDHIyRmbchTihF7Xjbwnk/dac+jGRxV1fnKie4DJK9LKTuYe 9BPyV+LbXPeJN404oxlYx2mkjCU9iOQzm9jrQm7CmMxzHHfRK/ik8njei9/C eYwq2AfaMflNvK2cEn3B7CAG4S/kvf7UVzW15ypbICdOM+9vwJmWur9jyTAm zCV6GL65+0BH0wTkLenzJuMDGMfGcxN5uTZCnxP5ZPcU14dz5KOP5Qt4XH5R vzBxP+2LGKXJPU/EGbhV+S55bLr+tvXNG3YYR2r31OzIJbgfTflxchf6tWcf gC6/F9/Wa9Qoy3N6r88Y9bUGv4MHzvt64nzpH3Pf/qx/9385A3vWyCfKd4gx 2Wc+WdOQA8Njy4urz9X/JzAYiEntRSDPrdZCTqzJ2ibcmPxJrhXGT/aSp5RL VScsH2ouqCOJPmH/ihvponO8kHVmrpV4Xgzi/3I//Hg1efwN8b5x0Ya9f9kv /aj4t+4vLkUtQGDqIXdIa8A207zr19GkXg3vbjznfgJqWWn/ZweaHjYh12YY 74PYF6/tyL1iaE/Ur7imcsDsBG6CvsD/cYC5TywfUm+4Nu11woeQrzVO6Srl qkrZo6RU0NipwWKT9efQM6Hp2gXjmY3Sw8RcN1bx8OPtSyAe9Xfwi41x44cG r+17Xw0KrptcL1+B74DfoUk113J9Ha2aOMRaoea7bf18+ZC5vwf7L68RNfxT C/UPehzLWeCxrMFt0KDU+8ThyWiz1WdefPHFya80VvDz6rz4FnTctJPWPraO Nkp9YeC/QUeCf8QBq2ORo2JXHccdd1yquVHn3YaYohtoZMRCeV8dY6SEvQRL hDFgLwJ+PL+TZrEfOsl+gT+Jb6ftMe/FxdYONcriDz4Frm369OlpvOT+NuIR vGQb7Fyg/5DPUs/Dt1Q3PKj9k0cJ+AUc8FprrZXmFK1h23w1sYF5jovSpyb3 QBM/sBVyb7m2m4/BRvA5abzaZOcC/YVcKx+Cxle+U81wW/2dUqHGXw8v+Ypc Q9vGWN054d/5w3wF2id8BJvGJoiL+D54STEzzUbT/Elg6kGPry4Yf6JGQw42 /MX+wJyTE1enYA3mw7e1J3UGfwcHqT+UnJzYAh+vpgAPqWfnKNdijRqMYX22 8xim4YpcVX+An9LDmm9uPZ41a1ZRtjfv0WSM+FnSuQf6B2uaegD8mbyLNa+N PnBJyP279I2UzxLbj3oflUCZyHlwa5x8J024tS8wOeDs8v4xrqcai+jDFigZ ajP0EKHdoedQFzDKPYEeDehj9PvESdLa4vPiWgZKR+7RzT4Y05G7mjj4CPZb VO+kBsv1dF0DgdIhX6Vfhb1E25ajLwU0h3wH+SC9FejkQncWGBbwGaIWY3Jg X+kb9KrHO+j1qu4iEAgE9OjS/1V9XvRMCQQCGfwuvcHVNapb0ve1yV5AgUCg PdDbQb81WmQ1LfoPRj4zEAjoLas+kw5K7ZJe4d32sQsEAqMHHCRduj3tNtlk k9RzMBAIBEC+R320eiZ1TZHPDAQCdeAacJSx/3EgEAgEAoFAIBAIBAKBQCAQ CAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQC gUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAg EAgEAoFAoB/4PxA7QG8= "], {{0, 166.}, {264., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->Automatic, ImageSizeRaw->{264., 166.}, PlotRange->{{0, 264.}, {0, 166.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJztnQmYjWXYx7v6vuorJTshoexLKAllDW2EslQSSVJISiqSJUKJECJlS6Xs S7SQLcouCtkiChUVJS3P53ef65nrOM6MMTO8c8z/d10nMufMeZ/33P/nXt/z 5nvgsfoPnXvOOec88X/H/lO/eaeqHTo0f+bODMf+p0G7J1q3atfywVvaPdmy VcsO1z/wP8f+ccSxx3fHHv977OGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQggh hBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQggh hBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQggh hBBCCCGEEEIIIYSIEf7777+4R1o+BhEsQdvAmX5/3ufo0aPu999/dz/99JM9 Dhw44I4cOeL+/fffeF/3zz//uD///NP99ddfCT6Pn/Ecfh+vSegYfvvtt7hj OHjwoL1OWkwb8Dn//fff7tChQ+7nn3+Os0NsLD674fn8HNtJCF6P/SVkqwnZ YEL2nRx4T47rhx9+cF988YV76623XNeuXd0zzzzj+vfv7z766CO3ZcsWO6ZI HbD27777zs2ZM8ctW7bMnhMNjp21LF261M2bN89eE3kMhw8fdrt27XKff/65 GzFihOvcubN79tln3cCBA91nn33mvv/+eztOcXYSbofLly9348ePdz169DAb eOmll9ysWbPct99+a9oMt0P0snnzZjdjxgy3evVqs8looL/du3e7+fPnuyVL lrj9+/ef8P7omOdgp6NGjXLPPfecvf+AAQPcJ5984rZu3RpVB8ldN79z0aJF 7uGHH3a5cuVyl156qcuePbu77LLLXObMme1RuXJl0+aePXuO2ws4H2PHjnV5 8+Z19erVc19//XXU92EP4T3uuOMOV7p0aTdu3Li4n/H72O84h40aNXI5c+Z0 GTNmtPfPkSOHy5Qpkx3XfffdZ1r8448/Umz9InXg7XDx4sWuTZs2Ln/+/Pa5 8/ljB1myZHHZsmVzt912m/vggw/MXjz8vW/fvi59+vRmw/H5Afb4SZMmueuu u87VrFnTLViw4Lj3x9fhH1q0aGE26HXAMaABjuGmm24ye//xxx9TxCfyvr/+ +qvtLxwTdn/NNde4hx56yA0bNsyNHj3adevWzVWvXt3OQ758+VyXLl3s/T3J 1SDH8Msvv7i3337b3pt1onf2Hn4ve9ETTzzhrr76apc1a1ZXrVo188vxxSQi 9sAGyH+IpdAY9o5O2rVr59544w2zg+eff95VrFjRNIH9YBc+JkquBnl/Yt0p U6aYrfv3b926tRs+fLj5HvxhlSpVTI8FChQw/7x3795kr501sO/UrVvXfjfa W7t27XHPwdaJG/v06WN7U9GiRd2rr75qPhuSq0HOy9y5c23tl19+uXvqqafc zp07j3st70Xs0LhxY9Pogw8+aP5YnB1gGytWrHBNmzY1jd1///0WU4bHe8SX 2Fb79u3NVrEjXgPJ1SD2RXx6++23W7z16KOPuvXr1x/3WnRAHIr28EUlS5Z0 Q4cOjdNBUmB9+/btcy+//LL5OOx748aNUZ+LzyVG7tevn8uTJ4+75ZZbLG+E 5GiQdW3bts10x95DDEA+GA32yffee8+VLVvW1ahRw02dOjXJaxepB+yQOgH7 OnZYu3ZtqytEA3snJ+M5xEyvvfZaXB6TVA3yevbzXr162fuzD5BzRsP7oxde eMF0EL4PJAXyWPJetHfVVVdZzplQnomGyFPvuusud+WVV7pXXnnF/j1Sgxs2 bDiunusf+NyFCxe6OnXqxGmQc/rxxx9bfFmiRAmLL+KD9aNPtPfuu++ads92 0kJfBjtctWqV+T7ioO7du8dbd/N6IxfBVtjvo2mQ/CqaDWKr5JLs416DvBcx FnZdpEgR820JnXNvx8SOhQsXtn0gqWD/M2fOdOXLl7c4Fy0kBGtFA8TF5I3k zZy/cA3iH1kX+0rkY8eOHaafm2++OU6D7EvvvPOOreXWW291X375ZZLXczbB uebzwT9Qu+M8na1a9PtwrVq1zD8R65wqXoMXX3yx+TFqpNFskFhy5MiRZn9e g9hvuG+k5pcQ+ILt27e7Tp06WX3iySefjLcOezLCtVO/fn33zTffnPQ17C+v v/66xeP33HOP5W3+9xBHX3HFFe7OO+90DzzwwAmPZs2aWbxNLO01SMwwZMgQ d8kll7h7773Xeg9pGXRGvEFtnpiL3IP+0PTp060Oxh58tmkR+2EfLl68uO3P 1CdOFa/B8847z3wZOoxmg/ha6g7UPL0GsUF0ie0SE6Lfk0EN0cfO2HVS7Za1 v/nmm3Y8DRs2tD0isa9Bb7yGnqHXILq86KKL7Peha/9gbf5PnkO8EE2DnJ/I fk1awfeksSV6o+iO/OD888+3c8q5e+SRRyyfxjfy3LNFi16D5CLs0b7OcCp4 DZ577rlmS+RqnLPIB/+O78IGvQbxK/QAsNsmTZpYvHYyeA0x66m8Jhqsnd5D 7ty5LRZOjP7RDL1z9E8fD5/sNcj6brjhBtMoe7h/EGfw54cffmi9durLXoPU WVg/fSB6f4mpdQY9u5TSENvwmX711Ve2t5Kr+L2sQoUK1o/iM8JusNOePXta 7Zpe1tnQn8F+Jk6caDZBLkNudjIibcBrkPOGjokbsLvIB7kXPQ5q++EapP9A LkoslhhfRB9j8ODBcTWcyHmTxEKfm/yUz5UYIL5alMfXj7ABapj0B9iTk1MX Dc8HOXfk5gnhfQUxMOculuF8sn5iiTFjxpj9ZciQwc4texlzIdTnyMGJ/8nZ 6cuQi1eqVMn2LvbNyJmRWIN8kBoLmqA2MXny5ASfz77D/oMNoAX+Pzl1UfwA 8zjFihVLVJ2Tz433pi7CzAB1EWLTpIAmfG+Q/jf+K6F9Nbx+xb5MfRaSo0Hy G84/MXq5cuVsT4hv9sDXRQcNGuQaNGhgz41FP+BrxPR6mAvC/xMfMZNRqlQp 9/jjj1u9OlpvjPnBMmXKmA7RI+eS88DvitVc0dsVeVWhQoWs3o6tRIP1oTfs jdiN2ih6TI4G2QOYjcEHXHvttTYrkpBdcWzEy9RD6JfT20sq2Do+lM+VPA1t EVtGe39f/2VegN4kcyzElpDc/uCmTZus70rs1bZtW+tZRtqSryujV/wFnxWx QDS9plY79DkfsQPngXoa5yxdunQ2d0HNAJtIqMaGztinmR8pWLCg6ZYYqmXL ltZjJp/GplPrOYBony31Jvw+dQZyHPrj0T5b1o9e6SNjs9Qm8WPJ0aDvvT/9 9NNmg5xLdBGfDpiNIS4hfqRPTZ6VHFgTv4Ocg3olvXKOh2PlGPyMOXU69lv6 eJwnagZ+nSkxJ0P8wb/xIDZnnf5aDY6B96JvwewQPoM6bmQfw8d2xKipzSf4 nI88DlvD31144YV2LolD3n///ah2wxpYV/ha/Hwhc1133323aZA6BPE88RE2 mhpzRd9v4dgi5335vOgJ0DtmP2IekjoHz/N2yN+ZIWF2kjjsxhtvtNkySO6c DL979uzZFu/z/lwrQP85UgfEGxMmTLBcgBoPx8IekBz8jAI+nXjY56Uc55o1 a2w/wk9TI+e42XuIGfiZx2sQDaONU9Wgnz3gPchxsaWOHTva3kC/n5klekbY G/H39ddfb7WkcH/hr8lg5o08iRibzyXo+iHHxfkhbyPnoweG32MfIZagRhWt DhV+/QB7Iv4tci38bn7O72U/5tygRXIq+sa8J/YR9F7EcWLj5FDETtQTsYNw fIxJjwD/jn03b97caivsW+vWrbOZZmbIqP1hI8xO+poAr2WG61Q0yGfhNej9 G7ZDbwN/QlyIxrF16mXUdIgZiVfxl8x18u8pAevnM0YT1AL8jDh7DfGuv24B jRIzcj4i1+X7O8TI8c27oUHq7vRgqI0y6+Lx+Q5z2pwD3h87RdfsC35+Hj/M 5xSZAxN/ca6I54jPyJlefPFFO9aUvs4kMfhrYLA7Pkf6OORwPucjhqIfG1/u y/kgRscfsN8zO+JroZGv4bnUdVgvexvniveizsbnQg7NsQRxDvjM2WPw2WgD /bDP4q8jj4e9mPNFvo+ds6eQ8/IaNIE98P/UjZkrC59pxB6Y80Ib2GhCGpw2 bZr5O+KP8L2A80pMjD9iH2NuFTvE/rBDrwtyMXwE/iGlYd/F75ETU/NgrXym xKm8J/tQtFqk1xbPodcXX38BW2FvJo/Dh/OacPzsOn6XmBgbolaEnpilZ58j zoqWL3l/Tn0Lm+WzwhbxD+wtfF7sxafbDv21n+S0rIP8ls+Q+Q2f8/G5n+wa SK9BzgO2iHbZt8hD8IuRtVD+zvrIFanp8F7UWIl1qZ0TH2BfZ+I66PBeJ7ON xHUcD7E3tuyvP4vvtayNdfTu3TturpEHdTtyIHwXWgqH1xBL0kMlJotvjtrP hlPb57rYSH/hz6PPGZg3YT/wczW8P+cyPo2nJOwJ2BIP9qcg9lDeN/wYEgPP ZX/Cf+C3sUPfR2UvPp12yDGyh1DTpGZMXEC/ij2cOgM5L34ssfg9C1vEDthT 2FuwS3wrcWjkWvw1cNSuyBmIY4jPiO/QM/0nfMbp+kx93kv8Qa+TWvcFF1xg vo9aGj6GvTKxBG2HQb9/rOJrFsTv3g7xI9ghvho7RCsp9Z0EPufDb3GtG3ke fo9YhhiC/Cep11n5fZlaOD7V+zfW9Nhjj1neG21uxsdV1NmJIdAA54DYhjiH uJ+9PCXPAb6Jfib5KT6DvJfYDf9NvYRYRDactvB5NnUsej/eDtmbyTn8nF1S 7cLX+chhyPPpV5GzkIuR8zOPkVI5Q/j3DJBzE2Pi34jVyQOpDbDvRMsViV3p YZHjeF9KnE/MxrEnZx7c146Yl6R+QpxJ7Mw+Qd7UoUMHi+uSOtMszg78nDv7 PzVV/50E6JKeAPZzKjULX2vAz+Br8U/kOfg+6kmtWrWya1tOx3f/+LoFvpX6 OJrH3qkxMGNBPT+apjhe6stowsfo5KnECcxvRYtrT3YOfN5Lfkt84c8BNUt6 bJ9++qm+c0QcBzbDnsz3YjAviE+k9ku/F3uhNpxQzO9rDeRTxIb4OWYFfK2B OhY5X3Kuq04s4XMz+EJ8L3rEF1M7I/aNlivi96kVkR/7XJFjp5ZIjQxfm5hz QCxPbYP6pO91omn6w9S7+bkQ0fC1V2po9EGpl2CH+AZqtdSFo9X/sUt6bdg9 vTdyHOyOejW1BnzQqdQaUmotaIqckNkFrqtmX2FNzDCiqWj7iu+lEj9Tn6dm RV8RLdFzI36Oliv6c0Atkf4QdUpeR97L36nBJPX6AZH28PPnzN5RP0BLxGf0 NbAvX//335uKbTHbT60auyOvIr+i/sk8RdBzAMSEPif134tHPoafog8Zn6aI a9lT6Av7uBY9UVdhXX5OxZ8DYnf6uz7vpcaDL+Y9VG8RScHX/9ES30+CttjX 0Rr1f2yLeR36Tvw7+sNnkgOuXLkyVdUa0Ao6QVNVq1Y1nbAe9hjqUswiRct7 iVnx//TNWRvaoq7CXBLxQrRzQCxPzx0fnJrOgYhNwmM6YjhqCvgR6qjs88R4 9PnIm6hJ0qON7BGnJsI1RW/Za4pjp29I/SVyrjv8HFBTYq3+HNCb5Bz4vJcY nl5raj4HIjbxeRLfeUN9hfiU67Kpo5LzEbcS88UC/vs6mUeh5kSOiKbQEjUp 5t1Za7RckRySuJbZX3ypPwf0M8h7Y+UciNgFu6R3yMwX/g9bjO9amtSO79Uz N8qsvO+REnczi0V9JVqu6GN05gA4B8Tm9CBj8RyI2MN/7zd9bfpdzMeHX5/i 6/PkVrGSC/lePT1SX3/Bt3HtALM05IqRvTx/Dsj/OAex/r0FInY4mQbJt/CT 5FbMp8UK/loO5t65XpW6KbkidVSu06HXHr6nSIMiKBLSoL/mm/kwbJdrrWKN 8HlaruPg+9vor3Ntfvh9VKRBERQJaZB8iNk2ao7kVeRLsYrPFZlrYR3UnMJn fKRBERRpRYMnQxoUQSENhpAGRVBIgyGkQREU0mAIaVAEhTQYQhoUQSENhpAG RVBIgyGkQREU0mAIaVAEhTQYQhoUQSENhpAGRVBIgyGkQREU0mAIaVAEhTQY QhoUQSENhpAGRVBIgyGkQREU0mAIaVAEhTQYQhoUQSENhpAGRVBIgyGkQREU 0mAIaVAEhTQYQhoUQSENhpAGRVBIgyGkQREU0mAIaVAEhTQYQhoUQZHWNMia uNdU5D2VpEERFKeiwfbt2wd8tEmHtXCvpd27d9u9dlmX7vkiUgMn0yA2261b N5clSxa7n2aswfqOHDli9+PlHtcdO3a0+3tyP/ADBw7EPU8aFEFxsvsucf/a UaNGmd0OGTIk4KNNPP6+idxbifvwcu8o7nPNGgsVKuS6du1qa/NIgyIoIjXY smVLu1dt+M/xI/iM8PsUpWbI91jDhg0b3IgRI1zNmjVdhgwZ7L68NWrUcIMH D7ZYNBxpUARFpAa5PyZxWyzeB9rnfNxnd8qUKa5JkyYue/bsLlOmTK5cuXKu S5cudo/r8HvS+9ft2bPH9ejRQxoUgYCP477R3Iude0dzP/edO3eaPUfaa2qE Y+R+wXv37nXz5893nTp1ckWKFLE9hT9btWrlFixY4I4ePXrc69Aevn3Xrl2m 2bp161rtqXXr1tKgOKOQ/02YMMEVLVrUYjbuVct9aqlhcN9MbDc1atHnfPjx FStWmC8vX768S58+vbviiitcvXr13Pjx4+3nka9jTfv27TNtcn/h4sWLm2ZL lCjh+vbt6w4fPhzQqkRaBJukdoEvqF+/vtkv/qB06dKud+/eZt/YMXlWatEi x8LesXHjRrunbu3atV3mzJldjhw5XLVq1UyP27ZtO+54vWbx+6tXr3YDBw40 v0/8yf2x69SpY78rvFYjxJkEuyYGHTp0qKtatarVMLDr6tWru5EjR7pNmzaZ 3QeZK/r4keOcOnWq3WM+V65cLmPGjK5s2bIWh65atcrWEvm6Q4cOuc2bN7tx 48ZZ3MnasmXL5ipXruz69OnjtmzZEtCqhDge4rT169db/Z56Pr1B9NioUSM3 efJks390cCZ9Ynj8uGjRIosfCxYsGNdraNGihcXOkbXb8JxvxowZVvfNnTu3 abZMmTLW81y+fPkJmhUiaLB5cqLFixdbjaJw4cJmt/nz53dt27a12seZyBWj xY+VKlWyvJWYmdiZnO/gwYMnvC5cs507d7Y1eM02a9bMzZkzx+pOQqRm8CPk R+SKDRs2dHnz5rVcsVSpUq5Xr14W96GP05ErRsaP6I3YkUeVKlVc//79zSdH y/nQ5Jo1a0yzFStWdOnSpbOcjxh09OjRyvlEzOFzxeHDh1vNI2fOnOaLyBuZ o6E2gl5SIlf08SN99FmzZllvIU+ePHF1og4dOtjsS/i8p39duGapi/Iar1nq ndu3b081dSUhkgJ9OOZPunfvbvlU1qxZzcbxkdOmTXM7duywuZqk2Hl4/EgM TD5KzwAfVqBAAde0aVM3c+bME/oG0TRL/upzPjS7cuXKE/qDQsQqaAV/s2TJ EtemTRvLr7B38jP+f+HChaecK6Ij+uJr1651gwYNspyPmQHiR/oO+Fr6J5HH EZ7zMQfj6zT8Sc43d+5cO1YhzkbQzf79+61W2rhxY8sViU/JFbkugVwxMX1F Py+HjyPn43f4ngGz1vT5wmPcaHWaChUqWJ+PfYCcb8yYMaZNxZ0iLYAvIs8a NmyYzUTTr6Of4fuK5IoJ9RV5PfUTen34U3I+3zOINl+GX6NXOXbs2Lg+H715 ctN+/fpZPhiL865CJAf8DTkZWuJ6Q2ak8WXUbnxfkVlqnhOpD/zk1q1bbWaV eWn8YWT8GK3PR5yKZulhcl3gsmXLLBcVIi2DFrluiDlMcsNixYod11ecN2+e XZeR2FzR53zMY/M7yfno8xF3Mo/dvHlzN3v27OOutxJChPwW+dikSZPMD5Ir okVyxZ49e1qdkh5dfLlieM5HXjlgwACbx6bX4HM++nzoWQgRP2iMXJFr8GvV qmWxKf0MckXyR3JFfFh4fOrnscn5qK1QFyWu5VpAepPkfLxOCJF46CuuW7fO vh+KXJGaDbUb6qkTJ060XJG+H7NjzAJMnz7dcj7vP8n5qNMsXbpUs51CJBE/ g0ovjz461yuiL65X5HsTyeuYu2a2k9481wH62U5+FivfpSFEasfPoFIrbdCg gcuXL5/1BKnblCxZ0v7ObJrP+cgrhRApDzEls21cr0hfES0Se9LnY7aTPp96 7EKcfujpMYNKP5/vPIs2jy2EEEIIIYQQQgghhBBCCCGEEEIIIYQQZ5r/B8g5 hOY= "], {{0, 154.}, {225., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSizeRaw->{225., 154.}, PlotRange->{{0, 225.}, {0, 154.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJztnNlTVEcUxq0kD3nMv5AHK0+aKisPqbJSpcYYNSkDgwhIUso6IpuyCIiI IqKiiIiKiIAiKkgUBCSkBJXNpSRgAEXQAmRXFlcW15P+OlxqmEG8M1zmMkX/ qq7IDDCnv9vndN/Tp/trZ1+N+2ezZs3y/5L9o3EKWujn5xRi8xX7xtbH30Pr 4+a6zCfATevm973z5+xFe3bZsOsLdpFAIBAIBAKBwrx+/Zry8/PJb+NGcrCz o+CgILrEvu/v61PbNIvi2bNnFBYaSr8sX05RUVGUde4c7Y2Opp8WL6aonTup s6NDbRMthtTUVPrd0ZGKi4tpeGiI3r59y/tpSUkJaaytKfHoUa63YGJevnxJ rs7OtG/vXnry5MmY9969e8f7ZdCmTdTQ0KCShZbDw4cPyXblSjp75gzvi/qc OX2a3Fxc6ObNmypYZ1nU1daSxsqKcnJy6P379wbv5+XmktOaNVRWWqqCdZbF 8+fPaS3TKiU5mV69emXwfmpKCm0KCKDamhoVrLMsPnz4QNu3bSMvT0+6e/fu mPcw3qzTaili+3Zqb29XyULLorW1lWu2ccMGqqqqosHBQWpqauJjjgsblypv 3x7X/wWGoG82NjbyMfvHRYto7pw59MP8+eTj7U3V1dV8PBfIB/0O/bOrq4s6 Ozv5/Bx+PTAwoLZpFknkjh1Uyubn6Kfw62Q2Hj148EBtsyyS8LAwunr1Kv// rVu36FhiIjWKObpJCC2VQ2ipHEJL5RBaKofQUjmElsohtFQOoaVyCC2Vg2t5 5QoNDw/T9evXhZaTYHNICFmtWEE/L1lCfzg68rymWOcxDqyfpaWl0Ypff6WE I0eopbmZ59l/Y7rGxcZSd3e32iZOe5CXRHzUurnRrqgoarh/n6+fIU/05s0b 6ujooINxceTm6kp5Fy9yzQWG3Ge6IW8e4O9PN27c4Gs9+rlzaApta2tr+c/6 +/nRP5WVXGcBUW9PD8WzvubO+mJ2djb19vZ+Mm8OjZETLi4q4r+HPtzM4gC0 nolgbMa6rbOTEx0+dIhaHz3i9RnG6AHN+/r6KO3kSXJeu5Z/7ZuB9UaY4yQf P041NTVcV1P7lBRLsba2e9cuKiwspMEZto6BPgUNlFpPhKa4J8b2bTWA/2Rl ZfF4pgvqp9C/mlm/AMeTkuhQfDxf99KltLSUTp44weOaOZBrh9x2KQnGzR0R EdTW1jbm9ZSUFPL18eFrrcDLy4u+mT2bTjB7decs6enpFBgQQP/euaO4beMh 1w657VKSQDZXwXNHm959xr3zZnajJgCs9/Cgb+fOpWVLl1J5efmov51ic2/U pd6ZAtvGQ64dctulJMZoGbZlC9mvWsXvedOIj6ihpRw71NJy4YIFvMYUczrp Qq3uageHMVruj4nh9Wg21tY8NmHerYaWcuyQ2y4lwWfa2dpS9J49vC5XulDf 48Tmdrpaxu7fT48fP+ax397OjvsYYry5tZRjh9x2KQk+M3zrVu4rmMtIF/Jg qEnT1xLjIubN+B4+hto0NbT8lB1y26UkxsRLqQ2I9xUVFWSj0XCf0bq7q6Ll RHZM97FHagPAnDz+4EH6bt48XjuthpYT2WEpWr548YJ/RZ0a6ilX29urpiVs QB5U3w41tBwaGuLPaPrPfIgteE/K7eD/Us4RzxjI6eIZA6+jJtVctZO6dgDU zJVcu2Zgh9x2qQ3yunh+MNdz40TorsNZIkJL5RBaKofQUjmElsohtFQOoaVy CC2Vo6ioiJKSkkZzh2qCXCZqkywNvh+nspLvEfX09KT6+nq1TaINvr7k6OBA 11jfxPOMJYB1EzyvIV+1MzKSjiYkTIt+uZX5OM6ZwDP2ltBQunfv3rR5PtRH qqdycXLi+dburi6+L9mbaYr6Kv0zCswF6juwrx+1CMgPIN+CGgfYibwRch7T Bd16Kqz1P2hs5HkB+DnyBZcvX6aVGg1ZW1lRQUGB2fYz4rPLysp4rSHWz3Ky s0f3o2MNHff6yOHDPH9+/vx5vm9dTSaqp+pi9zt6927y0Gqp4NIlXqeBfHZQ YCBfT0V7pgqcMxG6eTPfM13O9LxSXEzr162jbeHhfP8vbJTqvOqZr+NnsX6L Nox3LsVUMlE9FfpdxtmzvE4IOUDU+UE3vD/AtP6L9U2clxGzbx+1661JT5an T5/y+Iy/j3N4epid+Fxc2Mf/Z1YWtyuB/QzWgQB0xViEM2Y8Rvb5415M9f50 aJKbm8v9AutRj3TqqfDZ6APItUZGRPCxWzd/qPs3EDsxV0LMyszImPT5OIgp 6PsuTMMDsbF8PjteLQxew77puAMH/q/hZG2R6hCgN+5FBrMHa2ZJx45NaYzv 7++n/Lw8qqurG1NPNepTbN6BtT7YN9F9leqp4G+YQ8O/Ktjv4W8aC+IF5jsh wcFUXVXF+9hE9UQGNZws7mA/tVTDia/IsaMOWf+MCiWBHbi3kk64j4nj+JRc JP9Cf/b08OBrBdgfLse/MP7uYfEYaxF/Fxbyvm2MX+rWcGLcxBkKmLuhjdK9 Nsc5FNDTwKdGxm5TkOJZZmbmqH/1fMS/PhaPTQWfjTPi0k+d4vMmnNmlX6dl CnLPo8O+ENQ/oG7pUz5lDJJ/YVxC3EUtpTSHkhuPTWKkH7a0tFBMTAw/+0jy eVPO6DPmPDq0a6p8QIpnuE/+I3Oo7AsXKJjFNrnxeLKfLcUpU8/om27n0fF4 NjKHQl+4wObTxsbjyWKKJtP5PDrYPzTSDnPW+5qqiTiPzhBTNRHn0Rliqibi PDpDTNVEnEdnyGQ0EefRGWKqJuI8OkMmowk0Rn4BuWc87yKXgfnITOuPuiih yXTfu6UGQhOBQCAQCAQCgcAy+Q8sueNT "], {{0, 88.}, {83., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->{46.51171874999994, Automatic}, ImageSizeRaw->{83., 88.}, PlotRange->{{0, 83.}, {0, 88.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJztnQeQlNUSheW9hwWlZBAByRJERZCMCBIkJwklIChpCZYEyUmyQgEqIDko SVDJUJIRlAySg5KDkqMSldCPr6uuNU7N7hJ2mX+GPlXjlLszy/z/7dv39Olz 72Rs2Kpak/888cQTbePd/U+1Bh2Lt2nToHP1xHf/p2bLts2btoxoXK5lu4im EW0KNvzv3R+WvftYfvfxv7sPMRgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMjzXu 3Lkjt2/f1ueYeJ3B4FUQu1evXpVffvlFli5dKps3b5aLFy8GfO2tW7fk999/ l5UrV8r27dv1fQZDqIE43r9/v3z44Yfy1FNPSdGiRWXu3Ln6c39cvnxZxo8f L+nTp5e6devKoUOHgvCJDYaHA7G9b98+admypcSJE0eSJUsmTZo0CRjPxPzY sWMlderUUqtWLTl48GAQPrHB8HDwj/knn3xSXnjhBfnss880xn1hMW8IB7iY b9WqlcSLF09Spkyp3KVEiRKyePFiuXnz5j+vtZg3hANczLdu3VqSJ08uFStW lHfffVfjulGjRv+Ka4v58MXff/8t58+fl5MnT8qVK1eC/XFiFb4xnypVKmnX rp3MmjVL8uXLJ9mzZ5fPP//8H45jMR9+YPzPnTsnq1atkkGDBkmXLl3ku+++ kyNHjsj169eD/fFiBf4x/9FHH+n1du/eXZ599lkpWbKkchxeZzEfPkCjZjy3 bdsmQ4cOVb0ufvz4+siYMaPqGAsWLJATJ078i9+GA/xjvmfPnnLjxg1Zs2aN VK9eXfl948aNVcexmA99EOvk7wMHDsiUKVPkrbfeUq2OR+7cuaVYsWIa8wkT JpQcOXJIt27dNBYuXLigvchwQKCYB3/88YdMnTpVcubMKdmyZdN1D64XXcy7 Pq3Be4CzHz9+XObPny8RERHy3HPPSeLEiTXWW7RoIStWrNA1fty4cVKuXDkd Z2K/YMGCuhbs2LEjLLh+ZDHPz7n+Xr16SZo0aeTNN9/UXtWoUaMCxjyx/uef f8quXbuUGx4+fFj++uuvYF2WwQeMJfUp49K1a1fN3wkSJNBc1qBBA/n+++91 7JyfhHV+z5498sknn2i8o22wDlSoUEGmTZumaz6vCVVEFvPAcZwaNWpo3Nev X19/HyjmySFbt25VrYe1kTyyfPlyOX36tOX9IIEYZr1mXAYPHixFihSRp59+ WvN7lSpV5KuvvtK1O9D48F5yOuNP7+all16SRIkSSdq0aaVhw4aycOFC5fqB +vVeA5/RtyaJKua57kuXLsnXX38tr7zyimTKlEkKFSqkHN8/5vmbeBiofTNk yKD3J1euXNKnTx/18PB3DI8GjNu1a9d0XCdMmCDly5fX8UiRIoXy9X79+ulY 3YtXkNewRsybN0/H/Pnnn9e/Rd8SjWfdunX6e695Dl3dAt+As7HGnT17Vn8X Vcy73/M+fs4aFzduXF0XA/F5Xnv06FEZOXKkciHWA/hi8eLFZcyYMbJ3714d C0PsgHGGTx47dkxmz54t7733no5BkiRJlLO3adNGNm3apK+53xglp1ELTJo0 SSpVqqRrBbFfoEAB1bPhtP59+2ABzsEaBGdr2rSp9lhLlSqlHkoQXcwD7tHa tWulZs2aGvN40aKqYeFE3ANqgbx582p+eeaZZ/T9jAXzgs9liDkQk2fOnJEf fvhB2rdvr1zdaS/ojnAReM7D5mNigdyFpoG+ybiSC1lL0IGCyfW5B+Rycjp6 E/eA/EyfCQ8l3mHgfJVt27bV+QAX8YfjOJMnT5YXX3xR80a9evX0+ng/1+gf w45L8u+jCbAW8j54z/vvv69+ZOP6Dw/uH2ND/h4wYIDmXWKdsaQOY8xOnToV o9zD+c83btyo8wvemzRpUs391MSLFi3SNeFRcX13D37++WcZOHDgP/eA2qNq 1apat5D33T3g9dQx/Jy6kx5cIDCHyOvUQviIecZLT9zPmTNH8wv31r9/wXUT 2/R269Spo2MB3+E+9e7dW7Zs2aKf12t80OtwcYe+gn5ctmxZ1VbIu3il8Aii wfO62Lq3juuzhlDXZs6cWceWvNqxY0dZv3699nhjC+4esO58+eWXqq+6e/DG G29I//795ddff9WYDHQPnK4eXd7l98Qxz/A3+B25m7qe+tX1L/z/Df5d6gK4 funSpZVHkRvg+ujBcFBD9HDcEX44ffp0zSOMMbGGX6RTp06a8x/lXjbGlvw3 ceJEzatofKzp5NtPP/1U5yVaaEzB3QO09BkzZqg/jJzu7kGHDh2Ui1PDxvQ9 4N+Fozgtk/WkcOHCMmzYMOXz/v0LpyfQ74brc0/gglmzZtU6yPfzMa94P2sH 84G1kv1bj3MdQGyxZlKL4YNFE0Z7hDeyRuMRYUyCtWYyNuRVOBb6kC/XJzfC CR7Ww+N7D6hB0RJ97wG8KjZi3RdcJzUw14mOSb3KdVLb078gt/vXNI7rM18Y u2rVqim34nr4e3At5in3Cf8P/B/v25AhQ1TzDxVdOKbg+Cr8+eOPP1YNBh2B 9dVx9kBrazDgdP0NGzbomDmuny5dOuU/aCnkr/vNXdwDrhG+5H8P8MhwDx6l Zup4FddJffzyyy/r2sZ1urlHHPvHKdfBnCT+mResAeyzhee/+uqrmieYx9Tf PNMXYD7TS2S9DPf613evMlovnBAdAu8f/P2LL77QNdCL98FxfWKcXmaWLFmU e6AjwT1+/PFH5frRfXY3h+ANw4cP1/WDvO6Ve+B7nXAsaho0XLQetCP6F8zV QEADo19IToeb0c9q3ry57r+l/oXzo7US8+gD/C5cawDffgp8Fc2A2ox8iReA e7l79+5IazMvwZfrs/bDgZm38G70TsY8ENd3PJg6/JtvvlGdG/7Aw4v3wF0n fAWPBtfJHIfr41UiR/tyfebKb7/9pmsW8U4/Cy2IHOd0B9YI9Gf6iqwB5Avq hlD2fQSC66fg42Ves1YSI2gE5AO039jmq7EBrgtNnDh/7bXXNHbhAvSKmA/8 znF98h/xQ+8XLwtaH7kTPgOH/+mnn3Q+ePEecJ3oSGhGcH3nVapcubLGtDtT hNjG68e9gP+hOwXi6/yMOoi+GTEAXyQ+wgHOB7Z69WrVv+CHrOFwutq1a8vM mTOVC3hxnO8HxDW6Ev0g1nJiGQ3vnXfe0ZggH8J7OnfurGMMZ4cXwRvoZ3ql bokKjo8xlvSm4DnwcvYgomvye/I385/6l/GN6gwR5hFrGusd9QO1QKiDeGed g7PT20T/Ig7gq3BYdEkvcvYHhetxUufR20S3I/aZ3/AfvHDEOhyW/Dh69Gi9 P16PdX8wZvSFWa/Qavr27at6D+MNZ8MLQsyjL9/LtcVmr+VRg3UanzY+DdZB xpw6nnqeOR4u1+kPxh4tmvyFdgePY58WfIBaFX4A5wn1sXaf3z0YU9Y6eius YeiRjxuoSdBm8ew6vko8hPI43w+o/1jbqc/wceFnQJcN13tAvcL1wefQZOjT Piic9ycU92+yDjL/wzmvRwdf71Y43wOuD8+N03AfNM+7XEEtTA1k/jWDV+G0 GPoU1LbU61H1WIlj6lZqAPRrp3ni/UHzQtdy/jV8duZfM3gNxCMaHD5N9jdQ x1OjRwa0LjyceFbRKulpuJ8vWbJEvR1oHmgf1EHU/HhAbK+KwUsgXvGjotPR d6CXFajXRI7Hq8HeZOYHPgv24jtQG6DvsgcADcT17XgdvVzbq2LwCohlfATw EXq27E9etmyZ5n/Hc4hnYhYNO0+ePKrlsq/T36fnzipye5fxctMDRgejr8ne SPQx4/qGYIO8Tt8KXwX+Ifq26LPwFeKX2hTtnt4c84L4JafTw4Wz+2s1xDS9 Lnp7aEJuXzr9TXzM7rsljOsbggnilzxMjLK/Hl8lD/pxPNOv4Ywp8jcxS4+L OTFixIgo96qwtwBeX6ZMGeX6+Dzg+pzVA9e370sxBBPEKByGM9Toz9CLZq8b z/Rqydv4kuHl+EubNWumHizWBXylO3fuDHjWFhwI7g/Xd+cUoROxruBlCRff jiF04fq0br+i2+vmv4+XvaD4NfEtuLO2mC+R7VXBt0qf051TBNfHn88+Latv DaEANEjn04P3EMP4kfGgurO2AnF9eBFaDt50/C1wfOfjdv51+lr0AeA/PFP7 etXDani8QAxSjxLjnGPEXhV3tgtnbeFlwafrDzQh1grmDH0xt08BXxN8p0eP HuoDwgOK35N9iuzhYA6E69nshtACMYx+Tz+WOHX70uHveBr896r4wu3RpYZm 3ya1LnyfeYPPm2d+xgMfFFqqV87tMhjc2ZnsS4fro/mwr873XF3fM5Odps9e evzaxDrfNUG/AI83GhFnCrBXhb/H76mr2ctkNYDBK3D7p+EteHnQ5Yl7cj95 nHzu9mkRt3jV+W4JegP4GvC9+fN2eA/179tvv619YJ5ZOwwGLyHQWVvoO+y5 dWd2wmk4V4Q9XJwtwHyIDMQ9fh98PfhAObPIcr3Bi4Drs6+YPeTUo3jZ6Gc5 3wPnh8CB0H+i4unkfvQbfA9o/Hig+X+DwauA6+PjIc7h9M6/j97DvkzOZYgO 1MHUBej71MrseTEYQgVojnAcOA36Dpr9vbyHNQJ+RP+X/fgGQ6jAP37vNebd PLnX9xgMXgH+BFeTcrbWt99+G+17qGM5qw2fGj1cPJ8GQ6jAdz+u4/PReevx KLCvBe8nfB491GAIFbi9V/gt0dw5Hy8qHYbX4012Og8+/tj8XgGDITZA74o6 NH/+/LoHi7MDIzs3FI8+38Xy+uuva5+Ls2PNc2YINfh//zP7cvEjo2fC3cnt PPMa4h0PA74b1gT8lgZDKAKtnrNBOC+fuMdT/8EHH+hZ/nhu+E48zhzErwwH 4sxQ/JoGQyiDfhX+Gc42h+O47yjivFD20rJHke8D4mw5/DkGQzjAeYo585i9 huR2PGfsq0LTIbfH5PeBGQwGg8FgMBgMBoPBYDAYDAZDbOP/R7aOxQ== "], {{ 0, 72.}, {189., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->Automatic, ImageSizeRaw->{189., 72.}, PlotRange->{{0, 189.}, {0, 72.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3WWUXFWzBmDWd++P+/P7xx/cJbhDcHcI7iQQgiaQBJcEd3d3hwDB3Z3g 7u7uvm+efdfm9tdrMpaZ6dM99a7VkMx0ZvY5vWtX1Vtv1Zl+yIhB2/1riimm GPU/E/8zaPCey44cOXjv9f498S8bDB+1w7DhQ7dddfjoocOGjlx0yH9N/OKQ ia+3Jr7+e+IrBQKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCLSBv//+O/3+ ++/phx9+SF9//XX68ssv01dffZW+//779Ntvv+XvBwKBnsEff/yR7WvChAnp sssuS0ceeWQaM2ZMOuSQQ9IFF1yQHn300fTZZ59lmwzbCwQmD3zYm2++mc47 77y01VZbpaWWWirNPffcafbZZ08DBgxIiy++eNpoo43Scccdl5599tn0888/ N3rJgUDT4s8//8z2dthhh6WBAwdmW9tggw2yjzvhhBPS4Ycfnrbeeuu04IIL pnnnnTftuuuu6emnn852GggEuo4vvvginXXWWWmRRRZJCy+8cDr44IPTI488 kj7//PP066+/pu+++y49//zz6bTTTkvLLbdc9n0HHHBAevfdd9Nff/3V6OUH Ak0FPu6JJ55IgwYNSnPOOWe2t7feeit/vRbyNzZ46qmnprnmmistueSSafz4 8enHH39s0MoDgeYEPvLSSy9N88wzT1phhRXSww8/nDmStsCnPffcc2mzzTZL c8wxRxo7dmz6+OOP+3jFgUBzg80ceuih2cdtu+22Oa9rD59++mk66qijss1t ueWWHb4/EAj8J95+++00YsSI7Of233//9NFHH7X7fnU7flFOt8oqq6SXX365 j1YaCLQGXn/99TRs2LDMR+It+bH2oEZwzTXXpNlmmy0ts8wy6cUXX+yjlQYC rQGx4U477ZT93EEHHdRhfib/u/jii7PNhZ8LBLoOsSSuEhe53XbbpTfeeKNd jcknn3ySjjjiiBxbqtnhOAOBQOeB67/22mtzXU6seOedd05SY0IbRheGt2Sj nYlFA4HAfwL//8ILL2Sfhbvcc889c47G7mr9nfrBe++9l0488cSc+6mN33bb bZXXgLkGZ4V1iou9nDOhGQ00Et9++23WNPNz9F377bdfuv/++9MHH3yQ6+By PFqv448/Pi299NJZG3bggQem999/P+9bdmtP06tUqfeAremLcIY4Hy655JKc i6rlP/PMM/naqrTeQP8Bm2FfJ510Ulp++eXTAgsskHUpo0aNyrzK3nvvnePJ RRddNNvkHnvskfds0VvyG7Riaghq5r/88ktDr4cNWcNLL72UdTN8+Oqrr559 sxfuR23RGfLkk0/msyLsLtDXoPX68MMP05VXXpm233773EfAn4kjcZpsbZNN NsmaS36DDrOAH1QnZ698pJpfI3WY7O2xxx5Lu+22W163mHmNNdZIO++8c9pl l13S+uuvn88Vr6FDh6Zbb7017C7QENhzfBabuu6667J9HXvssdn/sUW6THro n376KcdtBb52yimn5PoBnfRVV12V93Aj4Ox47bXX0ujRo/N66Nn0H9133325 FomX1QdI082XzzLLLNkPPv744/2iT8JZ6Dojn60eSo5Gd1JszOekl+DBBx/M db2yR33dnt1www3TtNNOm7bZZpvMy9TaZV/hm2++yf21/BsdtvxN3lbrd+01 OewNN9yQ40x+EAerH7dVUT5PObg8QJ9IbawSqCbMapCzbbHFFrmnrraXx/fO PffcHI+qI5xxxhnZ//X1WVp0NXwcDrbwPG2BjR199NFpxhlnTGuuuWbeh/X9 FK0AZ6L4/6677so9kfy7Xix1nvB11QYOkC3xC4sttliON0sMyfZwFurqfN26 666bz9O+jNfsH3kcnmT++edPV1xxRfbTk4K9aB+qTYqJ5XVVr310BeIMZyHO WXwtp51pppnSzDPPnHbfffd85oTNVRvshx2JIaebbrrch8DOim+wv9XX8Zvy JPEanUtffa722O23357PhCWWWCLHux3Ft3ybcx9XdPbZZ+eYs9nh/PNZvPrq qznOHjx4cI49pplmmnwe0R3JzftD/toKMKMI/yCGxGf6M/8HbOudd97JMd30 00+f+Qs20Fe+wx66/vrr0wwzzJDnudCCdmTvr7zySp7/Yk/ii1xfs8K1ytFo F+SqeFs+XNyx0EIL5b/fdNNNuS7UijF0q8JnxTfg2H2WePdazg9PL15bccUV s93hD/uqdmAN6t3iJ/wJHqej38tPb7rppvkMobERizUjxMm4Ij3Haqr8mftf dLHycHzupPqRA9UG/dTVV1+dczpcBc1zbQxJB61eJ74UZ/ZW7YD9q23gKtm6 /XTPPffkupvf68/tcXPW67zgj/0b+Wlt/icuxdlWWaviHoiHaRFOPvnkPDtq 1llnzfa21lpr5br/U0891VJ5an+E/aefgB5FHMen3XHHHf98rvaqvcwH8oX1 ed/kgu9iC+oVYsnzzz8/62LYHR8s3+S3zCxrjztlr3gWvoDuDf9S/IC14jxd l2vBN1TJ9qzDPcDT0rSJO8T67jd9Hm2CM6e+ThJoXtjf9iN7Y3fsrzaGFKOZ lSmPWHbZZXtED22f2ff0MvLEvfba6x8tlzqc855tyMvkZ7gRtUS2VW8rfo45 nTvssEOORf1f7aO8j7+78cYbs/2KPdX88X+uqxF1x/q1iyvcf/ddvMHW5ptv vqy1cQ65lkavM9DzUPMRV4ohfe61MSTbo/nAXcrp8J2TU4Plf/gsvsjvXG21 1XJdTWzLj957773Zpr3PezbeeOPMX9J60aDYo2yy2CXeTo2KbfILet9r40o+ xDmBXxen2c9q/WwbH+i9fe0/imab33UPaEjdA/ffuYB3rdflBVoL9jcdVYkh xTe4whJD+uz5PlyGnKs7e9S/KfM1Tz/99Kz5NP+IHay88sp5vjsbYwPFR/ld 7F+dWw3A+vAKF110UX7JNdX1+WA1BXVxXF69VkVchv8zQ9d7/U7vHzlyZPaB +EH+vrfjTeuSQ7uP6qPsSzxsPezOPfA5OE+qEvsGeg+ldiCXwFuIa3pi5qW9 w2+xWTW/HXfcMde52Tb9tXrEzTffnH1tfZ5oj7IXmlHnAL6czeBKvNS/cSb2 rvhXbjqpOIxN8WsXXnhhrinY62LplVZaKde5HnjggV57hkO5B+ov48aNy/eA v1VnE1fo99BjjLMK7r//wGeNH9H3gzOzz53JkwP5Clu6++67MxcgH7TP2TWd y+WXX57j1o5iKLaPWxEP8nPDhw/Psea+++6bzjnnnOwf5Wcd+V973zWJR485 5pjsW6wHP8iH6hcquV5P7f1yD/Ag1ovjoUPADZV7gEMK7r9/Qu4j9mMj4q1a n2EP8hX2rBhRDNge/8eO/Cx7G9eN35CveD6J2JIN1caRHaH00tEW4vjUqMSR 7LGrsa5r8XNwF+xADZDfFb8OGTIk9/36+ZOT6/kdYmP8vph37bXX/kevhc9h 37iftnihQP9GqRvZ5/gNtS91WXEi/zKpfY+TlJ+U/ElPnmdxPfTQQzmOrQLv zbeI9/AuZqaxOfGeXI/WQ8yrztCVXK/otdisnFMciwPi26p4DwLVQul/xWOY V4uzx+fLgfwfp0jfLhep30M4bnnSOuusk/lOuhL2WUXeW64lrtZPITcUa/J7 uJ36XG9SKHotNoqXwdfIi6eeeup87uBr3AP3M3K2wKSAz5ZDrbrqqpmLZ2v4 fByAGQ/8ga/jIGn5azl6vk9sid+XszV6zkNHYDNiZr5bXdA1y/XEw3I9dT3x sHix3mZq9Vrm16t18mt4Grwq3gZ/E9x/oD3YV/gE+ZfaGT9HV8uO6InlKXQT +BZ5Ck4DN9nsuUnhStXqzaB3rog38T5yPdfsDCn9v0WvpRdfnsbOSh+fvht8 jRy42e9Lo2AfutfO8yrGSD0JfkksZK/hs+md689pfoHmioaEbdpfrcK/lV56 elSakJLrqW/oWePX+T25Ld+P+y96LfE2Hir0Wt2H+yZWcr6513h0570zrlVj czmOGh1OW11MjiJnc9aUM9t9kZ/gU7xaUafk7KEPUJOQ6/H5Yk71QeeM84gt skm6M/ehnvMNdB4lL7av6IfUb8XquGUztXALait8X6vFDrXPkMQp6Jd0pos3 7Sm5XpnpWl6teqbX5nqlridfm3LKKfO9kc/SEziH62f4BjqPkhfTF9Zq4qaa aqr8KnEEfa46Dx0g+2yl+82u5P+uHVeinmt/4SH1m8jv6Ji8rz+c684h/KXP 2yxe81rwLfZIdzVxgf+7r0UXSBOHD6cLLDohsbq5PaW/CX+g5uve06y20v6z h9SOxZi4bty5/E68Kabyd7kMjr0/aSlcp9iHDtm53Kr5RW+j9DHR7BVdoDlv Ygh5M3+mRupe08XrLWF77JD/sw/xwnR/zn522+znnvWXflI1XjyKOi8+nDbf 3ARc+sCBA/OZ05czUwLNi9LLZb+o7dIF4uH4NXmx+KFo4mp5O77Mv2GH8jz1 T/ZJd0vTgGehcWiW+L7YV1kr7kDeRn/ijCnciXsgvhIH8H9qv/RMOAVcXdXr cIHGwj6yn8SEzmmaOPsHN6XWQhdIE9eeLtAexGeqHavfDBgwIGudcC1ifnop evEq9SbXomi7+Hf8XMlLnCc0gTRQuCJfr4dr8gwS9WN+3v1q1jkkgd5F6WMS j+OAN99888wR8G00cWInsWNnNXFFr65OjFswE1LMxXbXW2+9PLPc9wrXXgXU 1j9oKPkrORstYPFxekxcg7PEvapfu5+Bx6TTcP/M7CizwwIBqO1jEhfpCREL lphQH0vRxHXHNuxBe06MpXcZz8fniVHNbJIL0XCwz0blekWfT/uo1siu8K/O G/7K1+S11qjerTanR80sLXYnLpCr8nt0J/JX75HT6QstOnn+38+oqn8P9C5K zlb6mMaOHZu5D5yjmMg5zh7wBD2Rj/hd7BoXw64LF2Nf0jDg2PuqN7kWzhE8 G1+m/mFeAX9Mr6QGYAZQqWs7E2gErRdXiUdyLTRO/KL7JffFXfJx/CSfWebp i8nV0cWroTPsX5CvyDHEds5qNV7xEp5f3CcW9L2e1sQVHpRenS/AaerpkC/y J+aL2Psd6dV7AmUugrUUPYW805nDZsTSbfWXsB3PdSs9Zvq7+UQzTJxZYoPS 90J773pB/iqe1lOA23W+NDuHG+gYtX1MehD5MjGeGErMV/gNsVJv1lfKs2PM uTC/w3611/kG2vwzzzwz+4S29OqTizLLrtQ/6JDxq+4BWyk+t70em8IR+ffO CdpD/c24WT3b7i2Nb7E3cI7Q9zrb2Kp/O7k954HqouQrzlb7yb5SR7LP9DGJ j4omri9ruPa02LbkUNbE9uRCdHpyJ7x8T/QN12rW1D/o43FDfh8trtkiZR5w Z2Np90p9XD6q/uj/bBW/ySbFrMVu/W4cFC5JPqvW6f1RO249yKPENfhr8ZK+ SvtMHOUZuPIV8VUjZ+Haj2p9ciK2xgbU1PneffbZJ+uK2Ep3dWRljlvpA1P/ EEfXz/zoiVhaHFF0qOJn9778TPGD38Wf42BoVaKO0Doosyf0Vvic6bLotdib WI4uVQ2uKjPMynNQxZQ4CesVh3nJgcRlYlG+o7O+uNQ/+JMy2wr3wZ7Vq8WB PR1LsyGzGP0e55uesxJjsn2fB200bSqOhq33F31Yq6K+xkQz4kwVz8gj+A3n cFVnmFkTGyh+GZ+BR5R38st8Q0c6str6R3mGi1yNrdFE+ru6iFi6p5+ZVJ4j Yt1id3G83LGs1Rkn3xM/izXwKs6RKpx7ga6h5GxmT8iPaCHFZvwam5M/0E74 /Jvh2VzOfrkRHZl9i5dnM/gO+SebaUtH1lb9Ay9a5lfxd7j63tKf+Zl+P25I 7FqeH1n4ErYnR1VrZ5N6p+V5UTtoLtifeLHaGpN9hofHgetjqufRmgX2Il6D rYjJxGyujR/Bs7Ite9y14fVr6x9qbHyk2NTXcPz8TG9z9GXGuf7Ntp4jYq23 3HJL1rA6E50NzpfwddVHyVdqe2xqa0zszwyYzswWrTKsna3oF621J2cKDsQz auRN7LLMBOATzWvFT+Ip8Yt9GUuzf3U/+gLrwaf4HNiVFxszP8s61ffwyT0x IzrQu/AZyXvEKfIDOVuZTeEz7K5eq6oo/ZF8Gx9X/IS4UQwp7vR3dWnxpxmN tFiNiNuslS5MPu1zKbNRSlxftND4LL5QnZA/r2KOHfh/2H906+pacjZ12TJv t5XzgzILp9S02Zh9zafgWUq/XqPnAasbsHtnAf7V7OLa2gHuBIfiez6/8syr QHWBu1O7oiUSx+CduzJ7u5lRagtsS0yJ93f+yKOqMhPAGvlZfBa+RO0Ap1lq oXya2gHtjZk9NN/qGlVYe6BtlDxHbtAbOqlmQNFNiqOr1BdUgEuWT9K8sDt6 G3xrbe2A/kVOJ0/F81TtGgKBZoPzwEx+uaY6Ya3Wku2p7+hJ4K/9OfxcIDB5 wJfgj9Us9C+pleoJKnFJ6UuvwrOFA4FWAb2nfgm9P+JMeXgjNa6BQKuDL8OP qBfiWsu8h0Ag0Hvg18SUEyZMyH4v8rZAoDEounS1O3pYdqnGqgbJNqPvIBDo OeBX9DfQpdNFizvpSs2npSfSF8QvqoP0x1pQINCTYG+0z3oZcZp0ezQ1ehG8 /Fndjv3pmaflDrsLBLoHtqPHUd2OfdGHqSHoATHv2jPe2CKdJk2bZ5KonYs1 +4POKBDoaYgV6UL5NnVyffB65MuczzIDUB+7eLPMkYheu0Cg6+Cn6ETpLPUk mbWLO2krblRP0Eeh/8B79Wfpow8EAp2HPA5noj4urlQfb69Wh880p4J2TKxp XlPEl4FA50HnZa6LeNFz+syKaM+G2KNZFHp0cSr68EIjFgh0HvI0/Ii+Of07 +gzaA3s0E1qPHS5TP1DkdIFA52FOhJ5H+ZlZtupz7YHN0Yp5xoN5AOZQhG4s EOg8cCBmuPBznjnWUX5Gh8LO1AxwnOwvtCmBQOdh7pf6mxlmegw87749G9KP rCfBvDMz3eR/odUMBDoP9kLP5dkFfJdZZuLNtnwdrsScRDEozmX06NFZjxII BLoGNqYObmaZubK0J2ypPA+yPDeM1tmzWtUVzAgeN25czOQLBLoBsaTZJ/yX +ZflWSV0JjSYZpaq4Y0ZMybPdcOfmC9YO0slEAh0DXReeH/aLtyI2hvbUz8w M5D/UzM3x9NcM9qwqBEEAt1HmRdoRiIfx9Y8L4gG0zOf6ZpHjBiRewrooZvh OROBQDOAzlKdHK+iJkBzMn78+KxvNs+hv8wsDQQCgUAgEAgEAoFAINB6wGng Pryajd+wXjW+Zlt3oG9BA4VX9zyQ+pe5kX05m4emXx+pZ+7g8HGOVe9nK89Y t256TS/3LuyuffwvS0EfNg== "], {{0, 98.}, {221., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->Automatic, ImageSizeRaw->{221., 98.}, PlotRange->{{0, 221.}, {0, 98.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qe8ZlV1Pn7/aoyJyScaiTQpAlIMHQSpglIEBASlE6oDiIB0EQlFAYNB kJIIOvSiIiUgbQQp0jvSERDpCIEgASkp++d357/wzOt9Zxi4c99z3lnP5/M6 OHdm7jn3nP3stZ71rLU/stVX1t3mne94xzt2e+8f/mfdLb+64q67bvm1z7// D/9nvZ12+9K2O4374mo77T5u23G7fmKrd/3hN//3D5/3/n/veMe7//BrSSQS iUQikUgkEolEIpFIJBKJRCKRSCQSiUQikUgkEolEIpFIJBKJRCKRSCQSiUQi kUgkEolEIpFIJBKJRCKRSCQSrccrr7xSHnrooXLjjTeWxx57rPzP//zPoC8p kUgMGK+//nr59a9/XU466aSy9dZbl7XXXrvsvPPO5dxzzy3PPPPMoC8vkUgM AP/93/9dnn766fLTn/607LDDDmWxxRYr0003Xfmbv/mbMtNMM5VPfvKTZf/9 9y/XXHNN+c///M9BX24ikRgD/O///m/53e9+V6677rpywAEHVB748Ic/XOab b76y6aablj322KPGELPNNluZY445yjrrrFOOOuqoctddd5XXXntt0JefSCSm El599dVyzz33lKOPPrqsu+66Za655qrcsOaaa5Z/+Zd/Kbfcckt5+OGHy+WX X17222+/sswyy5Tpp5++/P3f/33ZYostyqmnnloeffTRyjGJRGI48F//9V91 XZ9xxhll3LhxZf755685xHLLLVdjiCuuuKL89re/rVqEvOP3v/995Ymzzz67 fPnLXy4LLrhg5Yklllii7L777uWSSy4pzz///KBvK5FIvA2oQfzHf/xHjQf2 3HPPstRSS9V4AT9Y9+edd1555JFHat7QGxPgCbrD3XffXY4//viyySab1Hhj lllmKausskr51re+VWsdL7/88oDuLpFIvFVYt7feemv59re/XVZfffU39ISN NtqonHDCCVVPeOmllyZZx8QZYo/nnnuu3HDDDeXQQw+t3CD2wBXrrbdeOeaY Y8p9991X/1wikWg35Ahyg5NPPrlsvPHGZZ555qkxw6c//elyyCGH1HUuN7Ce mzGDGMLf83W/ih8C/hzt4oknnigTJkwoX/3qV8uSSy5Zcw65x7bbbltzkaee eiq1iUSihbCeaQgXXHBB2XHHHcviiy9e93m/7rXXXnVdP/7445U/etew/29t 0y0/+9nP1tzjzDPPrL/XhFhDXPLggw9WLQMv0C5nnHHGqmV8/etfr7nMCy+8 MJa3nkgk+sDaphNcf/31VWtcYYUVarww77zzlq222qqcfvrp5YEHHqj+yEnl ErxQ//qv/1oWWmihMsMMM5Sll1668spll11W66FN4CK/d8cdd5Rjjz221kJm nXXW+pHL/PM//3PNbXzPRCIxGFh/6pVqk3wKc845Z12ja621Vv292267re7l zVyhH+QXdATr/Qtf+EKZffbZK8+sttpq5bDDDiu33357zTECeEks8uyzz5ar rrqqHHjggeVTn/pUjSU++tGPVj2TJ5M38818/0QiMTqw3p588smaA2y55ZY1 xqcFqE/wPIrx5Rq9GsOk0FzvV199dTn44IOrZjHzzDNXDcN6p2vSJppxSGgT ejbkNrvttlv1YopB5DY77bRT9Wi6ntQmEompB+tLvZJfIeqV1iF+2H777atG aP2KK97qWmyu94suuqj6Ka1z/LPIIotUL7a6KB5pAmeoh9x///3VR7XZZpvV GgcNRM7DbyXOePHFF0fjR5FIJP5/WLM8S7/85S9rjXHVVVetPgQfuQB/Ap8C HWK0YvnQIn/1q1+VH/7wh9VX9bGPfazy0fLLL1/22WefcuWVV/5Jb4bvj8Nu uummcsQRR1SvtjxFfdV/82q71vRqJxJvH9FfKbbfcMMNa6xvjUa98tprr631 SutyasTvoUXiJpqGNR7ctMYaa1RtwtdcZ8B1WP9yCrGOnAen0CbEOqGb8mal NpFITDmiXnnhhRfWHF5s/6EPfagsvPDCZddddy0XX3xx1SBG8j6ONkKbiPUe fV14au65567axIknnlh5rFebkOv85je/Kf/2b/9WcyDeTTzBP0GrcB/8V4lE YvKwpuTo+ivtu9FfqTax+eab131Xji/fGOsZLrHe7fs0iF122aXylb7w0CbM jcAjTbhO93TnnXfWXIhvi5eT9rnyyitXr/bNN9+cXu1EYhKw9u69997qQ1Cv /MhHPlLXEE+BXJ6nwDobdEweWqR66CmnnFJ7O+U9NEx5xL777lvznuZ6b3q1 eTXoKO4L99Ex119//Vpb9W82c5VEYlqH9aYeYE82wylicB4luv9bqVeOBVwP LRJv0R1jbkRTi9Tn0ezNCG1CbqQPNLza6hy82l/60pdqPTRzjkTi/2AvvvTS S8sGG2xQ1wkNb7vttitnnXVWzd3HQmN4q4j1bhaVesY3vvGNmhO5Dx5OOdFp p51W+8ub+VDUR3g7w6utPkL31Pf185//vLX3nEiMJdQfxo8fX73N1oiYQa6u dtiVObGuM7RIcZAZlosuumiNgz7+8Y9XrYLW+u///u8T/b2oj9Af5CW40Syr 4447rjP3nkhMTVgzaofWhj4nvsipVa+c2oi5EXQUPaS0CXEEnWHFFVes8QVt QswUcJ984PxdYg+6Cw1m0DpLItEGNPnB+lALDIjd1Q3F23oguqDdhRYpLhIX HHnkkbUnRO6gr4P2am4Er2cAp9Ad9HAkPyQSf8Sk+IH+J3/njeKH6u25bjOa 2oQ+UPnDsssuW7UJsYR4ITgg+SGRGBmT4gd1C/3SCyywQJ3LQM/rGugIMdPy nHPOqXMifPRjhMaQ/JBIjIzJ8YO4gW6p9qcfoqsIbYKGiefERoHkh0RiZEwr /BAQM/Tqr8kPicTImNb4YSQkPyQSIyP5IfkhkeiH5Ifkh0SiH5Ifkh8SiX5I fkh+SCT6Ifkh+SGR6Ifkh+SHRKIfkh+SHxKJfkh+SH5IJPoh+SH5IZHoh+SH 5IdEoh+SH5IfEol+SH5Ifkgk+iH5IfkhkeiH5Ifkh0SiH5Ifkh8SiX5Ifkh+ SCT6Ifkh+SGR6Ifkh+SHRKIfkh+SHxKJfkh+SH5IJPoh+SH5IZHoh+SH5IdE oh+SH5IfEol+SH5Ifkgk+mFa4Qdnej/22GPl/PPPLz/5yU/queSB5IdEYmS8 mfN5559//rL99tuXBx98cIBX+tbgPL1nn3228oIzhpdZZpmy1lprlfPOOy/P 500kJoNJ8cPLL79crrnmmnLYYYeVs846q7zwwgsDvNIpg7XvDN4rrriinte9 3HLLlRlnnLHGQrvttlu59dZb3ziDM/khkRgZk+IHawxHPP300+X555+f6Ezb tsI1uubbbrutfPvb3y6rrrpqmWWWWcqss85a1l577XLssceWu+++u/6ZQPJD IjEygh/mm2++8vGPf7ycfPLJ5bXXXnvj69ZbfNqO119/veZAxx13XNlggw3K XHPNVWaYYYaywgorlIMPPrjGQu4X78X9+PW5554rp556alliiSWSHxKJBsTg OGHRRRct0003XVljjTXK8ccfXx555JHOrBHX+dRTT5Vzzz23bLfddmWBBRYo 008/fVlkkUXK7rvvXi666KLyxBNPVP5o8hwevP/++ys/rrbaavXvLLjggvXn 0QU+TCSmNqwR8bb9dbHFFisf+MAH6hpRr5Br2G/bulZcF03kF7/4Rdlrr73K UkstVeMFccOWW25ZfvSjH9V44pVXXpnoHvCJnOmcc84pW221VY2dcKP4wc/h vvvuG+BdJRLtgXXz6quvlt/85je17rfNNtuUeeaZp/zt3/5tXW9f+9rX6vr7 /e9/P+hLnQjW/C9/+cuqMayyyirlwx/+cNUf1SZoDHfccUd58cUX36hRgHv9 3e9+V6688sqy5557liWXXLLGDO5X3HH22WfXuEmckUgk/gjriE4nlvj+979f tTx7sTX3mc98phxxxBHl3nvvHfja8f0feuihqjGst956Zc455yx/93d/V+sT 9v7rrruu6glNjQHwG83yn/7pn8rKK69c+WS22WYr66+/fs2n7rnnnvLSSy9N xCeJRGJiiL2tL1reQQcdVGsaH/zgB8tHP/rRsummm9bc/PHHHx/zdRQag5xH jMOTISdYaKGFqsYwYcKE8uSTT9Y/1+SF4JPx48eXz3/+82WOOeaovIcj1G1v uummqsH08kkikRgZ1gldwnqj7fELLLzwwlWb8OuOO+5YLrjggrquxuJaIif4 6le/Wj7xiU+8kROMGzeunHHGGXX9u97m+rbeaQxyhq233rrWb/EczdK/8/Of /7z6v/gqkxcSiSmHdSMut/5OP/30Gj/wEdi3xRUHHnhgufnmm6sWMDVAF6Ej 0Bjs9zPPPHPNC8QB/XIC10x34IvaY489Kp/IP2iWtEh8wlvt305eSCTePqw/ e7j8/aijjqo10A996EOVKz73uc9Vv8ADDzxQ9+LRgJxArwedMXIC3+/Tn/50 zQluvPHGWrfozQms+TvvvLMceuihlU9mmmmmyifrrLNO1VTuuuuuqrGkxpBI jD6sf/VOsT7PsnqgOof6oFj/zDPPrBrBW11//n3ahj1efdK/KydYfPHFy957 710uvfTS8swzz/yJxuDvqb+cdNJJVW8MzZIvSn/Z9ddfX/2fqTEkElMXzXoo /wCfxLzzzlvXo1he3fCyyy6r8cabhXVLE7X+aR18nOIF/y4tEu/4fr05QfRe 8UarT/JtuA5eL9dx8cUXV75KjSGRGFtYm3J/Nc8TTjih+pnDg7DSSivVfZs/ wZqeHHDDaaedVn0MNAZ5i7xCDZPGICfoXd++txqLuEJPZmiWtMjQGHp9UYlE Ymwh1qcF0AR4C1ZcccWqX9IMNtpoo8odDz/8cF+vtvUrp/jGN75Ra6g0BvrB DTfcMGLdMTQGOgRfBj5Rr/zsZz9b9YrQGJIXEon2gKYolv/Zz35W64difNpB eLX1RtAORoJYQB3kxz/+ca07qEuO5GPAMyeeeGKNVWgMeGjZZZetdZSrrrpq RF9UIpFoB6xLMb11zKv9xS9+sdYVaQlLL710+cd//MeaE+CD3r+HD3BAr1YQ vRI0BjyDb/CCX3fZZZfqw+DT6O29SiQS7URoE/IAvZFrrrnmG7VG/33kkUdW H3ezj3wkmNGg9rDPPvtUjUEeIW7YbLPNqh9D7xV/RvJCItE9iAXUF66++uqa A+iRUF+Ye+65yz/8wz+UU045pTz66KN/Ug/FG3oojz766Kor0CvxC98FrwXd kwcqeSGR6DasYbG/+Qu82rvuuusbOQKv81e+8pXaO0GLxCf4Qi2DV1M9Qm4i dqBf0hh657skEonuI7QJPks9XhtvvHGd1SRnUPOQQ8hF9HbgDfyhB2vnnXeu GoMaR2oMicRwI+qht9xyS/nud79ba5Q4Iua6+HX22WcvG264Yc0/8En6GBKJ aQtyCfVOXkv1UHOl/+qv/qosv/zy5fDDD6/8wYOZvJBITJuInIO3Sr7BA4kr 5BK9/odEIjHtAQeoU/I28EJ+61vfmmj2fCLRFtDF1c3kvOYKteXDW8gvoFY4 bHtqkx/4I3i0h5Ef1GzVcG6//faBv0/Nj559Mzen1gyPYQFuME+Itm6mgT6A Nn3Mg9x///3rvJRhwrTAD7xiZvyq7epBG/S71Py4Hr35zhuckp7baQ18eJdc ckk9B+Hd7353eec739mqz3ve857a7+w8TLMMhgXDzg90FPGoOeA8XoN+j3o/ 73rXu2otmV+NVzVn5/wpPEP9wPoD5MDmGOy3337Vv9eGj/lqeiHV/fAXHhuW PGPY+UEtV9+ZeXz8HltssUX1lw/6nfJxHeZkOPfELB59s3rsEhOD5mAGiR4i NXhzm9Xe5GRt+OhL5BFaffXVq9fYvObm+fRdxjDzAz8XvcG94QYcL89wf4N+ p3xch/ka3if9+HKNCy+8cOBnGLQJdCPPcNttt63eHGcq0G3atD+L+R577LEa R+hdcG7ND3/4w1Gb9zhIDCs/uC96ln4Rve4+ZmC2LcenjfC986mJT+VBw7L3 vF14hvz85orI7fUFfO9732vl+4nvr7322rLJJpvUdURT0h/ZdQwrP3heYgXz MJ0f7v7MrmnTvgOux97j586jJoZ2LuEwPIO3C8/QPALPkDfHmjM3OUCXwPf2 gTczJ220IL4z80CvUnxfz1HOYw9yBoUzaPUrdP05DiM/iPc8O3mqfccMG2su zih0z+7Ru2bWLz1prD78qrypzVq5d8zew9MufzXzU49s27hsLOEZqkebkyiu 8gzNLYzcS+wuzhIf6jH0sx0L+P56m+US1ox5TPGcfM0etNNOO9U96Qtf+EJ9 rl3GMPKD+Xbnn39+1ZLl9WZ9m6/b/Lr3yUxdvan08LH6iA/WXXfdOtvTvhcQ RztTxExyZ5Idc8wxQ1Unm1J4B+Vdce4KjSa0W++snw0vhFnK5qv777EADrj1 1lvrfHf1MNzUzAfFM2eddVbtU/Du8UR0WXMeNn4Qc95///31bB6aJI7wnjW1 Inq4eVjmWfz1X/91+fM///Mx+/zlX/5lPUtMndzcreZ123s8BzGEM0PM+us3 N3SY4Z69k7QY85Y9Q+etRe2XZmmNmoVs/oDasJ/dWMA1eG7Ow5UP4ifcFO+X a3ee1b777lvfPx4Xe1VXY8Fh4wdzLMy2Eo+qGVqHzX0aPEucbv2ZdeH5jtXn 1FNPrV4oc8d7PZP2HucRqsWa0yU/EmNPa1CTpv9be+oBnmHoyqE7OyfK19SG xV2Tm4U2mvC9eKrxk9jGPDV8FbB+nBXBU4nrzWG0xrqIYeIHz01ub+6ms8Ht K3rPRvIcuW8fXxvEZ6T9xO+LVeVD6vyf+tSnKpeM5bs/aMQztPZokmrS6psB GhJe57FW79xhhx3qvNWxhGfH82D+wZJLLlk1Lt6VOA83tBMz3u1RckZnR42l hjpaGBZ+cB9iAnGfOph9RY4vl+gSvP/2npjr57yipmY/zPAM6bY0R7GBmrRn GHGWdadX5Zvf/GbV/8RZzpMfRA4mBhUD0kVci1zVcwvgAn5YsYUYg17R5Lmu YFj4wbq6/PLLq/ZnXdGQ6cxdy/tcr73HfkSnsPfISXpnjg8joibtGdIV6MdN 7Y+uLJ5ybqNnbOZZb+44lrD3uB4ag+sR94WmFFwn97FXeZb2rq7tV8PAD/YV 9YkDDjig7ju0Y37cLsZzIMa295jJ4b1z7rmYu2tcNyUID+LBBx88UWwQul/s 13J5dQP67XXXXTfQn4m4xXtHJ6IXmf+sdhHX5Jr5Y8WAoTmrp3cJw8APONn5 P2ph8na9O2bcdBnqd/JbNVFzQPVrqIEOK5qxgfdwr732euM8p8j37cVyR3UD vStteE/Frda8mIceYh2pnwXivsQY6hlini69m13nBxxtNoc5unw08nbehq7X BV2//VJ93Xvl3BI1vq7f10jwDGksatJxVqM11/SPOe+R3ux8Bj12fjZtgLiH 7sUryTNptjPNJDRlz4t+av47P4S4SI2qK8+x6/wQPhk9MXI8mrG8bxgQe486 Bo7gteELHSZ4/+j+YiV6JL3f/FP3Hl+3/vyeGJ4e48+2qYcNF5jzo4eMFqnm om4WaGpjcicz4ruiOXeZH+wrnoP9RH5HI1aHHpY8PXQVvEBXiZy8q7rKSLC2 PEM6f3idxIOBqOfoneaVEk+1jSOD43g2+GOdc21OY+SD4amSE9nDoi4Tfv82 o6v84Lr9zL/zne/UnzkvjRpzF659SkDTt/eo90ddhuY1DAivk3XTjA16Y3Ne RJqkOIoXsY2xeeRIPJ+8N6uuumq5+OKL3/i6e9KXTmt2L86f4rFqO7rKD66R zsCj5nnQiLvqUZsUIr52Von81t7jDPWu1clGgv2TpkJv4IUSdzdjA/coV+eF lV+pT7VZo1WDNr8DN8gjzP6J+2l6qmjO8ih7W3iq2oou8oN4jcedFmzfsa+I u9uUk44mws8rj8KFYvG2zUiZUkSPLd0uYgMzmCI2iF5InEGz1AvZ9nuOe9Jz Kh+Ua5hd1qx3ijHwhlgwNOc2o4v8EH0K3in1TH66Zq/TMCL6SrxzoeEN0hv0 dkF/9Az1z1orZkvaXyHmwvzgBz+otUxxE09lF/J1+aDzsJszK5q9Y80YQ71N HZcntK3oGj/YV8wQ57v3XsnL5efDPtfV/dl75FHqZHoazR5oYy4+OYTXSU1a vVKOaE5C7zyMDTbYoH5dL4YZw11AaCr68/Xp82v476ZHXIxBv7S34UcxRltj 367xgz3mhBNOqHok35A+vmllTkLsPeZUyjP23nvvMe9NeruI2Q00FGund85S 9DaZv2J/lat3bZajtW62nNyIDiGWaM6Jac42Uw/lI2+r5twlfoh9hfbr3TFn adjOI5kUPCt7j3xqnnnmqXvPT37yk06dreMZ8kXzCITXqek39O5NmDChciBd QrzUxR53PeqeDW2VRuaZNf2g5tPJmXCkeXRmbLaxx6Yr/OA6+VJdn7Whr1bf Uhdy0tGE9XXVVVeVz3/+8zW/irmaXUCsCx42/M7TZu5fxNYxW0VcxOvAL48r upg7xr3QVdReVlpppaq/BsJTZY8TQ5gtqOembegKP+BW74pamHfLOcJdi61H C/JbMbn81t4zfvz4ul+1Hc3YwPrXa9XUldUzzZiUU4THqO31v0nB/dKI9H7j APeLMyA8VfhRX5c9T90jNNq2oAv8gItpczgBF9tX+GS6lJOOJuJcD3uPn4c+ T3tPm2t/4XWyn6pX9sYGzXMu6P72U/trl+HexLx8DmbI0MzEvKEpxxw9feH2 PGccmIXYpnipC/xgb7Sv6NuOfaXLtb3RgBqv/NbPxN5Dz2tzjVds4HrlhdYC 30PEBjErwdkW7kVMZE58l3SVfgi9xbkYeFEPgNnkgYipxBhx9lab4uK284O9 0j5C46XZd2GvHAvYYzw39XP6l/3Y3tPGOll4ndSknTWqT6npdWrOhRE7iCGG 5YygOBdDDsj7qhdAr37oZs2zt3Cj3EqM0ZYem7bzA5+MvcTPVr5N543evmkd kd+KS3EnX17bPObhK7Y+rA2xAd9T0w8Qc2Hsn/R+s3266Ovoh5gT4/x494gH acyBOAfI3ken4PeI808G/Yl9KPhB7O69G/R1+eBYP8c4G/nLX/7yn9SJp7U4 onm/UdPxzHgq49zHNvG7d98ztCbUM80ObsYGrpWuHzPa1C6GMXeUX51zzjl1 /o13mQ7TnEUXMYazPOTQtCV9a2346I/D2+9///vLWmutVfWUQV+TDz2X16Hp M2ueZ8ZnI041O6TLOvebgfum0Vpr1ldoWOEJiXME+Xmb+e2g4bnwD4pv4hyb 0JXDa2h+vb3Ju+f+hpHzxUOeW8xA1HvB9xsIXzBecEbKBz/4wcojg/54bmIa 58S8613vKh/4wAcqjw/6uny8MzgrfDLNfSdiMjGFuIzGM0wxaRMR45kDYYah OWtNzyhPgX6M6HM3A7EtPws6Kr+rNUHDN6O1mVvTnvXWmeug1jfMuaN3lnam r9CnyePNvo33ve99let5p9rw8dzw1Z/92Z/VujTf8qCvKeYM0nxpVuLS5s+z uW/iEe9XW2aOjTZi9qK1jwPoMc11JH+3L4mzxIHOBmtLjSxqseIa2qS6ZXPO Ox5zf3wBw+6TFxfx8ahP4Pump1yeKI6iUYqz6IB6Owf9MZtHT7rYzvOzDuWD g74uH7PV5Gl0yZjrFz/TmANv3+Thj3POhs1PaX2ZXa2nW1y3+eab15wq1r+f hzkk5iuJucxwbFsvkxiC5hizlbz7cR5W4v+8f55h1Dh7Y+VBos31i9h7XJt3 n07Z9KDGTB5rxrXHXIRhgtkw/Mg4kP7oPMDmbEbvUa9vrC21sUB4jc1WMkMu vFHDqDNMKcIjJd/wjsczbEudus38ADHXT9wsh6XVN89Djn5Os8nkI/LbYYlT wzvDUx4zsppzTe3BfGP8uXILNcK29jLFvC996fQucU6Xz7UeLYTPLZ4h31ib 6jdt54fwVtt7/Pxirl9zJo95puYyWkNmCVx22WUDvuq3D/dnNq16n/vWs0BX CN+A+9ZDHL4x85V4jNqiS/YiZrTyAdHe+CjFQtOqRx56+8DNu6CptUU7grbz A8jPeAP5gORnfEDR5wJRWzZPyuwUOn+XziAZCXR99Vz7Cn/kgQceOFFswI9M p6RlRX9w2+OmOJMyertpXV2Z8z7aCM+D5+b5+agDt61+0wV+iJk7rk0OEX3B Mec4zr3m47DX8qA0z2brGsQAYqLtt9++5qTrrbdejQ3ifqIWZr/xdX/OPtT2 fL53bpxajD7UYeizmFLQ0T1Tz9C64ylv44yYLvAD2Hv4HdTHRvIBxSxk+YWv m13WnDvSJURswFOu1myOSLOXST1TPBEzYmgQXanbREztfRND4L5h05Qnh+aM OfUc2pr9rm26MnSFH8Jrp8fPuuGPEJvFnPc4D0O905oSd5th1sZ7mRTERPyg +v3kUrz4zTN/5Frqz/QIsQNdpi21sDcLz0x857yfyJ2G3f/ahBzCM2z2zbR1 Rm1X+AGaeg6dgTdKnB2IeqczmGjkZpd14QySJnAcX7nYm/ZAg4i5Y/Yd3gZ1 DPVMtQBabeRZXUHz3Bt+vBVXXLFVnq6piZhxr+8WN8TMh7bmwl3iB4h6UOw9 fIPi7YB6p3O06OPWmHpn22by9IN9Re07Zp/zNTR12JhxL6dQ61UL4K3uIuRD 6kz6EHhk5YNd15TfDOjOcQ4f37L11uYzf7rGD+En4auUu+n7s/c0Z/LQeaJm FPXOtu9NngMu4AsQG/FD2lciJ7W/0Fto/jEHw9yRtt9XP8S517xfYiH5IF5v iy9oaqB5jq93Uw7Z9jN/usYPEF4be4+1Yq5fU4uM/BZ3iDF4Ttq+N/XGBnKM pn8oZk7ymVtL+jG6MHNyUoizeeWDtEqzldqo4Y8GYjav2TC8sIsttljt5277 WusiP8RMEf0scojw2sReG/VOMQZ+UO90VlNb8/TwOtlX8J0aDV0lYqLm+fDy jjijt837zptBzI6hI+uxMcPCOaNtf//eCuIZmjtunek77kJ9rYv8AOG1sffQ +Z2LTOcPRH4b516LMdrqxeGTUcMUG8TsxYgNwke533771biC7qJ/e1g8AzFb Sf+t3gzPSx2769zXhP3KM3QGhv3KM9Sv1tb9qomu8kPMNNXT2TxLq+kTEJ9H vdOf0afRNn8anou+/zjPwpyQWB9ypXPPPbfmSnQJmn9ba2FvFZ4JDck9io/4 X9us2U0pPEO9yM7AoLWYV93WPpledJUfIHovaN94Wfx9xRVXTDQzXX6rr5Me pN6pV7ote1N4nQ466KDqJ1TnExs0Z5eKQd2fdaMHXz/+sGl47hPn0YnUpdV1 5YNt7SWZEsRZo+ZSewf1cNPOunJvXeYH6O29oDmI5QJ6EmgTdD9xhHpnW/am 0FHtK67dvtJ77WZamGnMK0nrjzPahg048corr6zzscwDMuu6+bPoKsSz5lHT yOwBZje2vU+mia7zQ8wWEJNaQ729F75+3333Vf3BHiy/pUsMmr/jPG7XJeYU G5hFHTmpGIGeIuahWZpxIRbqaj1zcgh/LH2fzsIjK3fsQo7eD3JHz4w2Zm15 hs3ZWV1A1/kBQouUX1hLvA/NOlnTd6R/C5cMOocPH5fYgG5vX4m+/9BOaPl8 5GZbmPEVXvJhBS7AidaTeqfZxG2atTsliH52+pfnS/9Sp+lKn0xgGPghZs3F elJbbvZeNPNbMYZcRE4yqH6YiA3U+2mS1oFaTMQ0rpvOIKYQ8zg3gQ7RFt1k aiFmkuNCz5C/EG+2TVN+M4hnGP2C6jNNL2xXMAz8AKFFWnNiiJg11zyjSX5r joo1R/Mb1DxbPhnz+9X8rQNep5jHGN4N88bEOjR99Ys29vZNDcgL5YN6TPiu zc6iOXeJG2OWvThV7mg/kvN2UVceFn6I2QLNmJ2epwYaX7cu1UB5DMTsYoyx 3pvEl973Zi6kBhPvP55Qw6Cj0Cy74P0cbcQ8ID2q4iu6bb+Za/jUurM/jPUH l43EW6GZq0fheD1CXe2TGRZ+gNh79DB4LlEPjLg9ZkHrmRZDRH/nWO1Nvo88 x/sidhYb2FfC6xS9I7R718drJ+Zpa2/f1EL4Y81HwKF6mcy46NWUcbufj1jL +zuWH/GneU+95xlGjzGPq/VED+9a/NPEMPEDhBapb9b+2zsfQX6r3uSdC0/V WPV3Rmwg3tRb1tt7Kv6JM9bUwuQgXek9HW3EjCzzY9Q7zdlsrsWmpqRH3PlO Y/lxFoT4Ru7XhPdLXOoZ6rPwDLvcJzNs/BBeVjNH7NG8NvrBI3+Peie/ivyf 9jdWvms1CT3ZfNRiAzWXyEn9Si+hVTbnwgxrPXNyiPmM9mhcGWczR6wVWqa9 QC+DnpWx/Ig9PUu5YcC16anl+beWPMPm17uIYeMHCK8Nz3JzPmPA/VmLdMEL L7xwzPwqYhszB8Us/LYRG0T9Rb+ZmMZ8Tb2cXdTtRxM4U31T35p6p1mNzVl0 uFOuLz70fMfyQ9tWvwx+jzOwDj300Fojo4GJU7uuKw8jP4QWGf3QcaZ8cxYd fUncRwsbS/0Bd9FMXUtzZlzzDCxzYTyTruasowX3H/NU6MlyMppEG+P1eIZx VgkNbNAem9HAMPIDWP+0SPNUxOsxT6Vtay7O3jVvTA8J3URM02Xf4Ggi5rHh TL0Zfj76F9r0HF2juX/qLLghzsAatEd3NDCs/ADRe2E+MC1C/N6ms4mAP9/s 4uYZWHmu1MSwN/Oei694jWKeq3y/DR86iTmhyy+/fPWG67cblj6ZYeYH/M13 aG8Wm+qdsze7v0G/Uz7ee3582ry8Qn7dnAuT+D+Isegzcns1KXGW2WHO2WnD h9Ys/7F+aJd8em2Kb94OhpkfoJkX8uOpa1qHg36nfLxLekK87/qRzIWZlua8 TwliHpCZje9973vLe97znlZ93ve+99WapmcY88aHAcPOD3EWiVoUXXnQ79FI Hz93fpq77rpraPad0UZolc5AkuePtR9qUh/1MTmPvhHv2jBh2PkB7D3q0M7W sQ4H/T41P66HLuJMnK719o01ov6jruidbctH3xVewF/Dxu/TAj+AOjW/gXNZ Bv0+NT+uh5aV9YpEG4Ef1GZoZOpH6svDyA+JRGLKIDfn0Yt+Qh41ferqzfaz YYuVEonE5GHdy8n5UvVDm4kgdviLv/iL6nXnZ+fvEPdmrS2RmHbA68V77Pxg fcS8x84d4M0xA8s8C/1yPEVmqasp8QJPq31CicS0gOhloZOba8OvN9NMM9Xa u7mZekn4VvUO8anpmeUVNR/LzFBzCXh6MudIJIYHURPSb+aMpphpKJ9wPjw+ cB4LTVIuYQYBD5++el4isYVZTDhEn4w6Tr+5OYlEohuIHkU+dd5w/erWOQ+h /mHntek1xge9a93652eVg6jPO+MST/CHmcc+YcKE2oOY2kQi0T1Yt3qTzB8x /8S6xgvWOc2B9qhXfXJzy+QTap9yD3NL5BtyErMRnSXIZ57aRCLRDUS90twh PifzDXme5BPmdKlVqF32nu2KT9Qz/H4vZ4gt4t8071XvKv3SvxnahB4ofz9z jkSifbAurW3r1BwU/WR0R3u99ewMAXN3zD9srmF84vfMaDUnj+Zg7tJIeYPf U+90Rrl5oGodZvDpm6ZNmHcUMUnyRCIxeFiHfMPqleaVmYXS1Ar23nvvmmNY 180cIDRLcxj1m/FG6X92RqCZa5Oa0+9rNEpzOfWl6Hniq/L9zMzRP0PTSG0i kRgcrD+9wGoNeECtQU3SejUX88wzz6zaZHOth2ZpZrI5yv4cP5R8wTkt/A7m /U1OT2jyywknnFD7pc1okss4a1ZuIx+Rl6Q2kUiMHaw3/eVqkvQA87asTR9n H8sv9An39lDgE/1J8gOzm+UHNEtxg7gDX5j7PCV9QpGfmOPW1CbkNnIc84b1 IOGozDkSiamHZr1SPcFsZp5HuYS5Voccckj1OoopejUGNQZr2OwyZy/Y583p klc4I5k34u30ZOEe9U59HLQJs3TkHHId3GO+vHppahOJxOjCerKuaAjOHGt6 op0JwI9gPhINopnzRw5AswyNIbzT6pNmDtAlR3MWsDhB7nL22WeXcePG1djE deKL0CbEMKlNJBJvH/Z+69fcZX4mnujwPZvHbK6p2RTNGfu9GoOz0mkM1qkZ ZuYAW6fmtE6Nvdy/KRYxjyVqKeKV0Cb0j4tl5EipTSQSUw7rJvZ+5wfFTH16 gXmFPAe33XZb1f+aazw0BjUL5x/bt8UL8hBxvjNDaQxjcZ5jcJt+D7mPs0px FG1CbqROon80+8gTiTeHqFfyETiP1Bn1/AXWlfN49FXxROOA5t7bqzFYi/or ejWGXl/UWABniVWckyt2USeJ3MhMGufTmuc+rZ1Bm0hMCawPvgH+pOY6Mk/f +WI80aHxBcIXxRNJY3BWsPnfYgY6JI0hfFGDhjjBLDVa5TbbbFN5L+ZJO0PX fdNWU5tIJP6IyNf5DsxYlqOrVdr7zW1xFnDv3h9xhjmdfErWW/ii8IrzHkJj aFOOP5I2Efcqb8Jnfg5dP7MwkRgt0BmuueaaOh/W3m+N65s4/PDDa32heU4j RO+VPMO+qxeTj5ovisagdkBjmJQHctDAWWIF9Vj5EN1VPVSsJOe49tprB32J iUQrYK3T6hZccMG6l+IJHiZ+gl6NgR5pf3WOEC9S+KJoDP4NcUaXZqTLlcRA cqc4Q0oPuntpU9yTSAwKNAfnTFsXNEh9TiNpDHyI1o2cg69A7k5jwBVqBG3Q GN4M3E9vvSLOoKRF8GiYY5M6RCLxR36gH3zyk5+sen7AHsoXpfeK30iMQXvk jaYxmAfXpRmych73K2Zo+jXFRT/96U8r3yU/JBJ/xKT4QUzA46THgsYgxohe CT7rLp2pguvoIubZmaGv3hkckPyQSIyMSfGDuFu+4dxpWv/48eOr9t/F82vU JOiOvFHyoyOOOOKN+0h+SCRGxqT4IfoZ1Df0S/f2XnUJdFO+Tl7QOMcPL0Dy QyIxMibFD010lRcCyQ+JxJTjzfJD15H8kEhMOZIfkh8SiX5Ifkh+SCT6Ifkh +SGR6Ifkh+SHRKIfkh+SHxKJfkh+SH5IJPoh+SH5IZHoh+SH5IdEoh+SH5If Eol+SH5Ifkgk+iH5IfkhkeiH5Ifkh0SiH5Ifkh8SiX5Ifkh+SCT6Ifkh+SGR 6Ifkh+SHRKIfkh+SHxKJfkh+SH5IJPoh+SH5IZHoh+SH5IdEoh+SH5IfEol+ SH5Ifkgk+iH5IfkhkeiHyfGDcyud59319ZL8kEhMOSbFD3jht7/9bbn99tvL vffeW9dRV9dN8kMiMeWY3Pnd55xzTtlkk03q5wc/+EH51a9+VV555ZXOnbfn mn/xi1/Uc4bnmmuucthhh5WXXnqpfi35IZEYGZPihxdffLHyw8orr1ymn376 stBCC5Vtt922nHfeeeXpp58ur7322gCvfMpgvT/00EPlkEMOKVtttVW54IIL anwEyQ+JxMiYXH7xxBNPlLPPPrtsvfXWZd555y0zzzxzWW655co+++xT92Nn esc6azteffXV8vDDD5c77rij3ncg+SGRGBnWifWAH5ZZZpnyox/9qK6jyB/8 av1YU8ccc0xZd911y+yzz14/a6yxRo3T6RNd1Sbc33PPPVfOOOOMynvJD4nE H/H888+XE088sSy66KJ1zW+33XZVx8MbzbjAevF711xzTTnooIPK8ssvX2aY YYYaU9Am/BsPPvjgRNzSZrjG119/veqvEyZMKNtss03lhgUWWKDei7pNIjGt g253ww03lO23376uD5/VV1+9fOc736kxw8svvzzRXmpNPf744zV/32WXXcrC Cy9ceQK/7LjjjuWiiy4qzzzzTP1zbYX7kRfdeOONVY/4zGc+U7lx7rnnrvzo 97vAcYnE1IZ1QIe0JsQFK6ywQq3/fexjHyubbrppOemkk6quh0diT/V3/P8H HnignHbaaWXzzTeva2uWWWYpK664Ytl///1rnNE2bcL1y4PuueeeMn78+LL+ +uvX65511lnLSiutVDkxcqVEIvFHNOOC3XbbrSy22GJVi1x88cVrXKBm8eST T04UF1hvuOW2224rRx99dFl77bXLbLPNVuaYY47630ceeWS58847awwyyHg9 +OyRRx4pZ511Vhk3blytxeBB97fHHnuUn/3sZzXXyLwikRgZ1hEfkbjg9NNP L1tssUWZZ555alwgrhAXXHfdddUX0cw5xAjPPvtsufLKK+ufWXrppWvOQfP0 b/z4xz8ujz322JhrE6ExuLbLL7+87LXXXvXa3M98881X65yu7de//nW9tkQi MXnYQ3GAuEAMwHMoLuArWmeddWo99O677/6TuIAf4tFHHy3nnntu2WGHHcr8 889fZppppvKJT3yi7L777uWSSy6pa3UstAn89cILL5RbbrmlHH744bXWQmOg r3zuc58rxx57bLnrrrsyl0gk3iKsMVrjFVdcUeMC9T8xuXW/5ZZb1hiDn6C3 HioGue+++2odQG0Dr0SOT+Ogh1q7U6OGiK/4Iu+///6qnWy88ca1xuL700bo kddff32taaYGmUi8fYgL5O7igp122qksuOCCZcYZZyxLLrlk1SouvfTSWvvs 1SZwwM0331w9EjyY/g6u4HH+3ve+V3s6cMlo5PzWOp4Sv/B4qcfQUOQSoTGo Yz711FOpMSQSowzrTz5hTR9//PFlww03rGtd3rHKKqvUfqebbrppRG2CF1tu If9fYoklKk/gGJ4D3ky66FvVJkJjiDiHr1OcI14IjYH3KTWGRGLqw96rbilH UA/kHbAW1QnXW2+98v3vf7/mFuKCZs4R3uYzzzyz9nDQLuUqyy67bPna175W 9UMx/5TUQ0NjuPXWW2uMwrehdkJnoJnQSdRPUmNIJMYW1rFYXW6x995717hA zULdUFygr8vXmz1ceII2QBfUC8p/EOsZz9AR9YdOLo7AUWIZdRYaw0YbbVQ1 BnzD13nggQeWq6++umqhqTEkEoNBxAVidzE8X4G4gG9CXPD1r3+9xvzigl5t gq+bTigv0RcVNVSaZ7/6Rnw/tdLzzz+/fOUrX6nagu+3yCKLlJ133rn6N/SU tcmXlUhMywhfolheDxdvlJwjvNqHHnpozQF4qZraIB7gubr44ovLAQccUPbc c8+qU/TWNZo+hquuuqr+WbUIcYe4YbPNNqs+TvEEH1QikWgfoofLGhbjiwdo kdawOuMpp5xSNYjmfJmICez5+rvEFb3/Js1TLwiP5lprrVV1Udyz5pprVo2B Jxr3ZC6RSLQfTa/2rrvuWnu38IRcQH3U7/MyT8onJc6gceIMsYEYQU8IjUF9 4pvf/Gbt8cBHWa9MJLqF3h4uvV5zzjlnXd/iCvGFGohaSDOfaMYTF154YdUY +Bj8PTVRvkyzXPBPzmhIJLqN8GrzOX/3u9+tPmdapHqoWTNmseinpF+odcSM CRqDeVZ0DPmE/OTkk09+o3aaSCSGB+oJTa+2+oacwzwWHibahP6uo446quoK Yg3csNpqq1VeoW/yOqTGkEgML6KHiwfaLBaagh4uuQPO4HlUr1xqqaXKvvvu W2dc4pXUGBKJaQPh1ZZXHHfccWWDDTaoPu3pppuuxhOhMeCR9DEkEtMmwqtt dpV+LZqDPIPGkD6GRCIBYgS+B14pWmZqDIlEIpFIJBKJRCKRSCQSiUQikUgk Eoku4P8BJiQ4iQ== "], {{0, 254.}, {264., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->{40.73046875, Automatic}, ImageSizeRaw->{264., 254.}, PlotRange->{{0, 264.}, {0, 254.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJztnQm8jNX/x+vfoleWVCK7a8mSiCxRkjVl30WWm+6VfYuLyBoi+xKSJaFI EYok+xLZl8h6o5CU9r3z8/6+Xsf/MWbuOnOfmbnf9+t1izFz53nOOZ9zvst5 zjfi2a4Nov/vhhtu6Hnblf80iIyp1KNHZN+GGa/8pXGXnu3bdYl67skuL0S1 i+rx8LM3XXlxxpWf2Cs/N1/5MYqiKIqiKIqiKIqiKIqiKIqiKIqiKIqiKIqi KIqiKIqiKIqiKIqiKIqiKIqiKIqiKIqiKIqiKIqiKIrr/Pvvv+b33383ly5d Mt9884356quvzJkzZ8yFCxfMjz/+aP766y+3L1EJMP/995/0M/1Nv589e1bG wddffy3j4rfffpNxovgX2v2PP/4wsbGxZtGiRea5554zDz30kMmePbvJnz+/ qV69uhk2bJjZsmWLuXz5srxfCT/Q1g8//CD9TH/XqFFD+j9XrlwyHqKiosyC BQvM6dOnzZ9//un25YYN6OmXX34xmzZtMpGRkeaee+4xd955p7T7fffdZ/Ll y2fuvfdekzFjRlOsWDHz6quvmnPnzqkOw4x//vlHbJ4pU6aY4sWLm7Rp05qs WbNK/zMOcufObe666y4ZC08//bTZuHGjzNtK8sG2QH9NmzY1mTJlMpUqVTIT JkwwR44cEZsE+2P16tWmbdu2okvmxcGDB5uLFy+6femKn2D9w+YcM2aMKVCg gMmbN69p166d+fTTT2VdZBwwHkaPHm0efvhhGSd16tQRHapdmjyY+06ePGli YmJkfmvZsqXZu3fvdWsc78MnGDVqlGiQfli4cKG8roQ++H6LFy82jz76qKyB 06ZNM7/++ut17+O1NWvWmNq1a5ucOXOarl27yrhQkg426NKlS03FihVN6dKl xdb3BXo7deqU6du3r9go0dHR4j8qoY1zHs6RI4fp3Lmz2KS++Omnn8ySJUtk zJQpU8bMnz9f/ZJk8N1335mxY8eaPHnyiK2Jrx0XtD/rX9myZU21atXERlVC G+Lg69evN40aNTIlS5Y0c+fOjfP9aPbo0aOi1WzZspkBAwbIXK4kHux47Ih+ /fqJHco8iMbigv7asGGDadiwYYL6Swl+fv75Z1nXiAMkdF4lFjBy5EixR9u3 bx/nuqn4Bj97//79YlOyDuJvB+IzSnBDzOX111+XmHezZs3M7t27E/wZfEdi eQn5jHI9qkEFnBpMqJ6S8hnlev7++29z6NAhsSXI/YwYMSLeOCd52V27dpk2 bdpI3mjcuHEpdLVKoEBPs2bNMiVKlBCfcMeOHfF+5vvvvzdTp041hQsXNi1a tJB5WUk8xLLOnz9vhg4dKnHOLl26mG+//TbOz+B7f/DBB6ZKlSqmfPnyEs9W Qhv6dOXKlebJJ580FSpUMO+9916ccU7+jVwi8XHyhD169JDYnpI0yAvNmTNH 7PqaNWtKfMzXWmg1yz4Z1sAmTZqoDRIG4F+QE2YfGv3KHrW4YnPkCNetW2fq 168v+2fYz4FNpSQNbMvPP/9c9qjh3/Xs2VPyE546RH/o9aOPPjK1atUyERER YrsSJ1VCH/ZCkZcvVKiQqVy5suSM6Vvnemj3ch87dswMHDhQ9moQH9+2bZuL Vx4esAebPGupUqVknxI2xuHDh6VfiFujPWwPbFDanJwQ+wU/++wzty9d8RNo 68CBA6Zjx44mS5YsYpcuW7ZM7B76n3GAvblv3z5ZJ1n/7r//fjNx4kSdh/0A eULamr26tGvmzJll/wN2/muvvSb70/C7sVPoH3S4du1a3RsRZqAl9g3T1/h5 7BklV0HsmzWyd+/eskeR8fHAAw+YV155Rf1AP4KeiHVhg9SrV09yrzw/wbMS PENBDp+42QsvvKAxsDCG9fDgwYOmf//+pmjRotLvPCvBGECX+CDs1WavVHz7 OZSkwZqIbYqPOHPmTDNkyBCZB999913ZK6p7tMMf+ywp/c2cTAzu5Zdflnwg /oc+P6ooiqIoiqIo4YsvW5/X1Q9IHcTV1zoOAgfxFvYO8jwTMVLbztZHZx8b Z2vps2LhDfs2yDmQr3Lm/ojX2VwxuWM9w8K/oDOeCZs8ebKcZ8BzvfbcLLtP u3v37rKnl70ySnjCnjPOjeG8oGefffaaPTB2bzd7hcnTM08r/gMNssaRF7r7 7rtNr1695Kwn4P/sD2zQoIGcbzdv3jyXr1YJFMy3PDfB2ZZVq1Y1H3744dV/ s8/tct4F+2k4f1bxH6pBBVSD7qEaVEA16B6qQQVUg+6hGlRANegeqkEFVIPu oRpUQDXoHqpBBVSD7qEaVEA16B6qQQVUg+6hGlRANegeqkEFVIPuoRpUQDXo HqpBBVSD7qEaVEA16B6qQQVUg+6hGlRANegeqkEFVIPuoRpUQDXoHr40yOup XYOp6Rwxbxq0968aDCyeGqQGGmf48HPu3DmzZs0aqTeXmjTIOXOcIcfYo7ZC ajjn36lBzm6i1hZnqXF+E+epUe9ONRgYnBqkzgtnaq1atUrOVxs+fLjUeaQe VmrQIGf2ob0vv/xSasK9+OKLcp4YdfeofxnOa6LVYNu2bU25cuWkthK1t1j/ Fi1aJPYRte9Ug/6HcXfmzBnTr18/c/PNN0u9HWrU33TTTSZNmjRSe4f5r2TJ klK3NxzPlkRbnKdJO7z//vtS94vaU7feequ0B+c6UieauYrzVsNRi9z/1q1b pb4ktZaoc3bLLbfIGODPjAHapH379tJO4dgGboCNRS2d7du3iw1y4403Xm3z IkWKSE1C+oPXChYsKGdLcg5wuIxDW1+WM4zxezlHlRqzadOmldrEzDvURr3j jjukBiNrADXDOeeWz4VDGzCnor+TJ09KvS3WQOZi+p3avNQbZDwwBmiHpk2b ytmjqcVGDxTW5jp69Ki0O7Ym6x115h577DGpeUbdVepd4R9Se5X2z549u9gq jNcLFy6E9Di08w9nGGN3YWvffvvtUn+RGNTbb78t8w01afk760CGDBnMgw8+ KHPR7t27xV8K1XFo5x/68ZNPPjEdOnSQe0yXLp0pXLiw6dSpk9m8ebM5dOiQ GTdunKlQoYKMD2IGxGwYN8ePHw97G93foD1inbGxsWJbNWnSRLTFj63zSf1B 51n3jNPVq1ebZ555Rvooffr0Mj/iPzIOid2E0jikDRg3+HizZ8+W8cS4w86q VKmSmTRpksSiLNwbMYkZM2aYihUryvtor8cffzwkxyHXyZnaxFp27twpdSax d5h/WPtZ56g56ayzi92zZ88eqZVevHjxq7VhGzduLLY7tqlnDXvlWmzdCHxp 4i1RUVEma9asV/XE3zds2CDzojdszWxiMk888YTYJqwJ1EemjjYxDOqWB7Ov aH0+1jbGTfPmza/WG2YNJP5y+PBhn5+nbTgLnjFbrFgxGYd8njWStTIUfEX6 h3764osvJN5CbQPsbsZCjRo1pNYn/ewL5potW7aIT2htdOI0rVq1knmazwZ7 G6Q01t4gxr5x40apK46dYf0dYg/Lly9PcG1jfhd6w1ZFf9gl2Cc1a9YU2y0Y 50OnzbV27Vrx6RhzrH3MP+3atZO28Zx/bG7M816wI4hdYLvhOzIXYR9go/P7 8S2DzUa38w/2zzvvvCO5JuYQ/I/y5ctLrV38koTMofwubB9qj7Rs2VJsd7RI vKBHjx7SluHkLycV7t36O3v37pU8A5rB3mDeeuqpp8SOYu5ObDvxfuZD6yti x7CW0BfkNfAtsGOwd9zsA2tzMV6wr1m/mH/QHvMPsc7FixdLG3nCWORz1ITG LvWcV/gz44z1D3vMjkN+PzY6dlsw2OjOmBPzA/MG/Y/9Q835Ll26SDzOl/0T F9ZGnzt3rqlVq5bMa7RB6dKlxb9m3IWyv5wcuGfsDea1N954Q/KtjDvWK2wP cn6sZcnFOR/iKzIOWROIow0dOlRiOm71gW0DbMdp06ZJPIFxxzgh/oRvx/jx Bde9cOFCWd+JTRCD8jav8D2s/eRs+L3Y6KwvxBbxK/EVuQ435iI7B+Ozk18n lmTtnxYtWoj9423+SSy0Cb41tetZUxlnzMn4ztOnT3e1DVIaG285ffq0zO8N GzaU8UB7EGMnx8rc5O+2sOOQdRW9Mw75TuKrjHX6gBhsSvSBbQPWL9sG2FvY zNgBrIX4QvFdC2OTeA22KvMKcQjmroMHD3qdV1hH+L2MdfTH9+Er1q5dW2x0 9G73/wUaG3NinmUOrly5ssw/WbJkkfgTNe7imn+SCjn+/fv3i1+Nv2zj7KyR zGcp2QZJIaHX5Wv/Iu2Oz8ceP/wS1iQbb3n++eclxoyvHEgYh8Q0iNtjj9AH 6BHfgxgs8aBA+evOmBNtQK4zV65coh9rcyWmDdAYsRvmcWKl6In5jD8zrsml eYuFMsaw7bp16yb5VWujt27dWq6LmAVjNVBtYPcZ0N74+vQB101/vPTSS5Jn CKQGrJ9C/hD7gbiNsw2wmbAn4qrzm9Dv8dd92PwoNl1ccwSv03fMwazrrP9O iKksWLBA5h/sjbx580rcb8mSJeK3pBS2D4id0Qf46fQB+26IpRF7Za7wl69o fT7uke/EF8M/dbYBMdCk2lxolrl90KBBYkswprFnyeksXbrUayyUPuV6VqxY ITYfth9zAb5iTEyMxHPIC/izDazPx/4B9M/8Y+dg2n3Tpk3X1NUNNHZNwF/G T6ENbP4L28jzWuwcyvjGZvLlv9h7RQOMeVurNjkwXukT7AN8Dl+/k9exddjD yJjytCXQMHFl7pG1n/nbzT199AHzHX3AfEzcEC2yJjGe8RW55uTkMugn+uHA gQPie9k4u405+asN6He+h/mDmIbdr4DGO3fuLHFA7pXr8fQV6SdsWnxFrsvm c8h5Y9cmJ5/jjLtZn485GO0x55HnS+k52BNnG9SpU0f6iJg69+0ETeIn4Vev XLlS9OsN5i1iu8x/aAF/P7kwd+GjYC8wf/nKEdh1rkyZMuJjYFc5oR/pC/wg X9fvBrbNmB+qV68utilrCTESYiVcb2J9RafPh59Rt25daT98MGICjEVsRX/D 99JfjGtiquwZQovWV8QOp588NUUbcD3EpsuWLSvXSRugS64f/z2xfpJzbzl+ ODYy10LevFq1ajKn0+7BAlpk7afPnLl/C/9GvhIbBtuBedUbrFk8x0OfowXa L7n4S4PBDus48z73yj0wBokR4CuyJ4P4f3x+ktPnw69gX4FdW5j/2evp3OMT KNAUY4kxQ7yDuAP3wxzz5ptv+tQU98dcjz1qfUWunxwb+yYS4ita3wVfFZ+P tY7vZ/zQrgMGDJDxG8x7JbyhGkwZGFvM3Vw7eXLrK0ZERJiuXbuKTe7NpnPu M8CvIe6Gn0O+hRw5ezTQJP2TkjAfoCmeN7H7t1gb8X98xV+sXUsOtU2bNmLP sn5xP8St42sDm+ejvfgs8w96xkbGF0xJn8+fqAZTFusr4tdi07EWoEV8WWf8 n/cxFvkz/iP5J96Dz8dYpx3wH2hDt0AbXB+6IB5tNYXPiKaIkeKPefMVWfvp U+7D5rcT0gbsq8PnI9ZI7oV9L276fP4gmDSIT0e7e/7wOj5oOGjQgk134sQJ iafY+D++EvYd8X/yvvhY7MNgLyM65T2PPPJIwHy+pGI1xZioV6+eaIo+LVWq lOiGeJrVlBPagPwpviL35WwD/Dz8PdsG+I+0AT417cVnaINgzbclBqcGiWUz 33jTAXbUxx9/HBANMgdGRkbKd9Mnnj+8Pn78eNnrEC4atFg/CRvTxv8ZZ8TQ 8LHwGxnPzP/s2ycG6JmbCRaspugrnqtAU/hrxEmIDeIressr2jYgt+JsA3TJ Z4m12Dbo06ePPG8VrG2QFKwGyd+gL2x5bzrAPsDnpk38rUGeVyanQ7+xl8Hz h9eJ69Mv4aZBsDYd+Zno6Gh5XpZnRm+77Tbx+ci5M/8xD4YC+GXEh4i/YF+i H/Iz+IrkDb09exlfGxCDCqU2SAxWg+QRmW/I33jTAes/cxT+i781yLkRzH34 5vjYnj+8jg/Ee8JRgxbsDfLeEydOlPsmboPdGUz5loRiNUX8hb3saApbkrme 9RyNMvY8fUVnG2Cb4VuGahskFKtB8po29+pLB7wHez0QtihxMuwR/CDPH14n rxuOtqgn2GrEOfF/sMWIwTthvFr/IBR8IWf8xT5fwLrIXI/Nap+9dN6LbQP2 GtAG5CTDGactSi6fPL03HRCrwTcOhC2amuKi8RGXBm18Ct+AeI7nfotgxu7r 5rkefF38RPxFdMn+cvYNWVKrBoMhLqoajFuD+ELMkYxb8vuh2A7k73n2kudd ec4L/wc/x3mfqkHVoJvEpUHWPfbV8FwUMVP6IxTB7mTccZ/k29njw75Ti2pQ NegmqUGD8aEaTHkNEu9kLoxLg3wfe35Vg6rBcMNqkPwb+RtfGsSOJ87MPgi0 4A8NEm9mHwXxZ/KzvmIMvM5Y5EwzrhF/IlxRDaY+DRKPYg8Dz9PwvCOxK2+g QZ4hY48we6c8Y+ZJgRgDfgDPVHE2XFzPDzI3sIfLnj0brqgGU58G7Z4G1kL2 EbOHwRv2OTD2yKIF9s0o/kc1mPo0qAQXqkHVoOIuqkHVoOIuqkHVoOIuqkHV oOIuqkHVoOIuqkHVoOIuqkHVoOIuqkHVoOIuqsHrNcg9K0pKoRpUDSruohpU DSruohpUDSruohpUDSruohpUDSruohpUDSruohpUDSruohpUDSruohpUDSru ohpUDSruohpUDSrukto0yJnbnrVrVIOKm6QWDaI7atpzvi21wZ3nWqoGFTeJ T4M8x0NNVM54DUUNoj3OyUR3nNU8bdo0OVeTGmgW1aDiJnFpkH/jLOSmTZvK eePbtm1z8UoTD7UIqVvAec1Tp06VuvPUGqHuEmfbWlSDipvEpUFbTxMdUrPc V32OYIO6iZzTfurUKbNo0SKZQ6glS/1Bznen3gG1dy2qQcVNPDXI+AuFerve sD4f8wa1Sqg5SG0R6i4XK1ZM6p5t3bpV3uPE1ll0toGipBRocNWqVTL+qP09 adIkqT9AHdtQ0aL1+S5dumR27NhhRo4caUqXLm3Spk0rtdap77V06dLr1nE+ R2yGeiIzZ84U/VGzV8+yUFIS6n9QB6dRo0ayXpQsWdIMHz7c7N69W+rzYI8G sxa5PmJH1A6iLgm1sjJkyGCyZcsmf548ebLYnc57sJolRkrtk1GjRkm9enxF ag6HYuxJCV3wnVj35s6dK7GKrFmzSn3GatWqmVmzZpkjR46Ircb7ggnr88XG xsoaFxkZaXLlyiXXTr3KgQMHSp0gtObEapb74v7QHHMPNbK5Z+KmxFAVJSVh XWA93L9/v4xd1kLiF+ixefPmZtmyZTLW8aPcXhP5fuxk5o1169aZPn36SD3Z 9OnTm8KFC5u2bduKbc39OPHUbJs2bUR3aLZUqVKmb9++Zt++ffK7FcUtGN/4 TNR97NChg8QzsM/y5csn8Qxs1vPnz7viK1r7EfsYO3ns2LGmfPnyJl26dCZ3 7tymQYMGZt68eeITen4On4/rRrO9e/eW+0KzRYoUMdHR0RK/wS9WlGCBNYO6 4cQmmjRpImMcLbI+jhgxwuzdu9dcvnxZ7LqUuh7s4WPHjonO6tevbzJnziw/ 7B8YM2aMrG/efD6rWXw+bFS0FxERYRo3biy1nbE73V7bFcUXrHcnTpwwU6ZM MVWrVhXbLVOmTJJHQwvsNWH9CJSvyO/Fpjx79qzkTzp27Cj6yZgxoylRooTk Hsg1ePP50CzXZzWLzWl9vvHjx0t92WDzcRXFG6wR+FG7du0y/fr1M8WLF5d8 d/bs2U3r1q0lr3bmzBmx9/y1ntg17OLFi2bz5s1m0KBBsgajvYIFC8r34qOi MydWs1zP8uXLTVRUlMmZM6d8js/36tXL7Ny5U30+JSRBF9ifxO2Je+TPn1/s 00KFCpmYmBizZcsWsV+T6yva/WXENNlfVqVKFVnDcuTIYWrWrCl5PL7H89r4 Xl7HZx0wYMDVOA3XR8yUuYJ4qKKEOqw1xDfwperVqyf5ALRYtmxZ8cuILSYl r2jjltiIixcvlrw6OT7is+TOhwwZYg4dOnTNZ5w+3549e8y4cePkveQH8+TJ IzbonDlzJIaqKOEGtif+Fr6VzStmyZJFfEXGPfGThOYV0StrGGts9+7dxd5E 1+wv69Spk8RpPe1HG6fhGsht1q1bV3xVfD72Zo8ePVr+TX0+JZxhHUIH+Fj4 iuTZWLfwwfDZVqxYIXtU4vMVsRHx74hx4ruxv6xZs2ay1uITen4neUriNPx+ cgt8H/Yq+9Pw+XhGyfl8oKKEO+gCe5DnK/AVCxQoIOtY0aJFxTfbvn27aAm7 0ZsW8TNZO8uVKyf7yyZMmCA2qed3sBbye/A9Bw8eLPtbsTtZN/lenu3gdylK agWbkvUJPbEHjDgK6xP7oCdOnCjP8aERT/uQNQvblf0txGK8/V4+xz4e9n9W rFhR9pex/tWuXdvMmDHjmmeRFCW1g6YOHz4seXHOwcBH4wef7a233pKcY0Ly ivw77zt+/LiZP3++5NWxdcnNo8Nhw4bJ96jPpyjXY31Fcug9e/YUu5GYCfFK fDjWPNYub7kMp89Hbp64jN2rQ26+W7duYo967glVFOV6WKPYD0b8hDgNe0/J 8eMr9u/fX573Y4+n9RXt2S/4kOTmiY0Sp2GPZ6tWrWS/teeeUEVR4gdt8azs 7NmzxSbFV2RdJK/BGUvk/sg78v/p06fLnjK0x/vq1KkjPh97QhVFSR74isRd hg4dKnFQfDt8RfL9+HecHcVr+H08F2GfA1SfT1H8BzYnOcFNmzaZzp07y74y 1rw0adJIHNXm5tevX3/dnlBFUfwHOQf2kXHOIHs6yWHgM3IWmueeUEVRAgda JM5CzkK1pyiKoiiKoiiKoiiKoiiKoiiKoiiKoiiK8v/8DyvCCzs= "], {{0, 154.}, { 225., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSizeRaw->{225., 154.}, PlotRange->{{0, 225.}, {0, 154.}}]\), \!\(\* GraphicsBox[ TagBox[RasterBox[CompressedData[" 1:eJzt3Qm8z2X6//FZ/vObJVmzbxHZ4siu7FkqQkKiLKeyRLZIZQlpISqiRWWp VKijVBJZQrYip5SQfd/DMTXTzFy/ed/zuM3356+ZzjfH59zH6/l4nBlLuM/n nM/9uT/Xfd3XVSSxV4vOv/nVr351zx/++T8tOg2o27dvp/tvyvrPn7TqeU+3 Lj3vvOO6nv3u7HJn32qJv/3nL7b79a9+1f+fH//vnz82AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA4Bz4xz/+4T4AAGH78ccfbefOnbZq1So7dOhQ1MMBAMTp 73//u+3atcvGjBljdevWtaeeesq+//77qIcFAIiD5vR9+/bZiBEjLEuWLFa/ fn376KOPoh4WACBOf/7zn23evHluPs+TJ4/179/fjh07FvWwAABx8Gt1xV8K FSpkVapUsenTp7NnCgCB+stf/mKrV6+2Nm3aWLZs2axDhw62efPmqIcFAIiD 1uRHjx61KVOmWOnSpa1kyZI2fvx4lxMDAAiP5u+vv/7a7rrrLrdf2rx5c7d2 BwCER2v1EydO2KxZs6x69epWuHBhGz58uNtDBQCER/ulO3bssGHDhlnu3Lmt Tp06NmfOHPZLASBQOnO0aNEia9y4seXKlct69Ohhu3fvjnpYAIA4aK1+4MAB e/rpp61IkSJWvnx5mzp1Kmt1AAjUX//6V1uzZo3deuutLrexXbt2bv8UABAe rcl1lnTatGmWkJBgxYsXt1GjRllKSkrUQwMAxOFvf/ubO3fUr18/u+SSS+za a6+1xYsXRz0sAECcTp065fJeateubfnz57cBAwZQjxcAAqX9UuW8PProo5Yv Xz676qqrLCkpif1SAAjUDz/8YCtWrLBWrVq53MYuXbrY9u3box4WACAOvhbM iy++6PZKy5Yta88995yr+wUACI9qwaxfv96t0bNnz2433XSTy3UEAIRHa/Xj x4/bjBkzrGLFiu4s0sMPP2wnT56MemgAgDgot3Hr1q32wAMPWM6cOa1Bgwb0 uQOAgKlG44IFC+y6666zvHnzutx11REAAITH14IZO3asFSxY0CpXruzOmmoN DwAIj2rBfPbZZ9a2bVu3X9q+fXvbuHFj1MMCAMTB14JRnzv1uNPHuHHjXI1e AEB4lNu4YcMGV1tddRubNWtmK1eujHpYAIA4aK2uPMbZs2dbjRo1XJ+7oUOH unxHAEB4fC0Y5amrz53qfL333nvUggGAQKkWzNKlS61p06auHm+3bt3ocwcA gdKaXLV3J0yY4OIv6nOnvVPF2wEA4VFu47p166xjx46WNWtWl+Oo2jAAgPD4 WjCvv/6663OnWjCPPPKIO3MKAAiPrwWjPkhaq6t2wCeffBL1sAAAcdJaXTXW 1Q9JtRvfeOONqIcEAIiD9kS//vpr6969u6sXcOONN1pycnLUwwIAxEFr9KlT p1qxYsWsXLlyNnHiRGoFAECA1MNu+fLl1qJFC5ejnpiYaNu2bYt6WACAVFLO i2rvjhkzxtVTr1atmr355pvkpwNAgBRfmTdvntWpU8fN6ffcc487gwQACIvy F7ds2WL333+/5ciRw+rXr2+LFy+m3gsABEh1GRVnUT2Ayy+/3EaPHm0pKSlR DwsAkEqqB7B27Vrr0KGDy11s3bo19QAAIEC+z9ELL7xwum7XSy+95Go0AgDC orl7yZIldsMNN1iuXLmsa9eutmvXrqiHBQBIJfXB2LNnjz366KNuPlePI/U6 0n4pACAsqrU4Z84cN5cXKlTIhgwZ4uIwAICw+Jou6iutfdHrr7/eVqxYEfWw AABxOHHihL322mtWunRpK1mypI0dO5Ya6QAQIOUufvrpp66HkWq6tGvXzjZu 3Bj1sAAAqaTcxcOHD9v48eOtQIECrjb6K6+84uZ5AEBYlLuoM//qXaSaLn37 9nV1uwAAYfE1XR544AEXc6ldu7bNnTuXmi4AEKBTp07ZO++8Y5UrV3a9ox96 6CHX/wIAEBblLn755ZfWpUsXV3exWbNmtmbNmqiHBQBIJcVWjhw54mq6XHbZ ZS5/ccKECfSjA4AAqR+dzhO1atXKcubMaXfeeSc1XQAgQKrpsnv3bnvkkUcs T548VqVKFZs5c6b7dQBAWBRfmT9/vtWrV8/y589vAwYMcHEYAEBYlLu4efNm 69+/v4u5qKbL8uXLyV0EgACppsvrr79uZcqUsaJFi9rIkSOp6QIAAdJZ/3Xr 1lliYqLLXVRtF2q6AEB4FFs5ePCgq+mifnTlypVz/eiUow4ACItyF5ctW+bO FSmO3q1bN9u3b1/UwwIApJJyFHfu3GnDhw93uYvUdAGAcGkPVD1FVdNFtXQH Dhzo9koBAGHxa/TBgwdb1qxZXT3dVatWRT0sAEAcNKcrbq56i5kyZbKaNWu6 HtIAgDAp9qJzow0aNHDx9H79+tmxY8eiHhYAIA5aq+/fv9+eeOIJK1iwoFWq VMmdO2KPFADCpFzG1atXu3NG2bJlsw4dOrgaAQCA8GhNrnjL1KlTXa30EiVK 2Lhx4zhzBACB0vy9YcMG6969u2XOnNmdP9LaHQAQHq3VT5486fqPXn311Vao UCEbNmwYNbwAIFBn5qvrTOn7778f9bAAAHFST4xFixa580e5c+e23r172+HD h6MeFgAgDlqrq0ajekoXKVLEKlSoYK+88gq5jQAQKNVSX7Nmjd12220uBtOu XTu3fwoACI/W5N99951NmzbNEhISrFixYu5MknrbAQDCo/l706ZNLp6eJUsW F19funRp1MMCAMQpJSXF5b3UqlXL8ufPb4MGDXL5jgCA8Gi/dNeuXa5fRvbs 2V3e+ttvvx31sAAAcVJu45IlS+yGG25wfe169Ojhan4BAMKj/VLlp0+cONGK Fy/u+k9PmjSJ3EYACJRyG5OTky0xMdHlNrZq1crWrVsX9bAAAHHQmvz48eM2 Y8YMq1ixojuL9Nhjj7m5HgAQHuU2fvvtt9a/f3+3VldfpAULFkQ9LABAnE6d OmVz5861evXqWd68ee2+++5z63cAQHiU27h3714bOXKkq+9VrVo1e/PNN9kv BYBA/fDDD/bJJ59YixYtLEeOHNa5c2eXww4ACI/W5EePHrXJkydbyZIlrUyZ Mvb888+7NTwAIDzqc7d+/Xrr0qWL2y9t3rw5fe4AIFBaq584ccKSkpKsatWq VrhwYRsxYoT95S9/iXpoAIA4KLdx27ZtNnDgQBdXVy7Mhx9+GPWwAABxUv/p +fPnW8OGDV0eTN++fe3IkSNRDwsAEAfti6qe15gxYyxfvnxWuXJle/3118lt BIBAKYau/dE2bdpYtmzZrFOnTrZly5aohwUAiIPW5MeOHbOXX37Z5TUqv3H8 +PEuNwYAEB7N3+pBfffdd7vcRtVaX758edTDAgDEwfek1jkk1WxUjXX9GAAQ Ht+PWnkv6nHXuHFjW7FiRdTDAgDEQX2np0+fbmXLlrVixYrZ448/7vIcAQBh UV8M9TxSvssll1xit956q23evDnqYQEAUklx9IMHD9rYsWMtf/78lpCQ4OLo 5LwAQHhUd3fp0qUuz0Vr9O7du9uBAweiHhYAIJV0hnTHjh02dOhQy5kzp9Ws WdPef/99zpACQIBSUlJcXcYKFSq4uItqealWIwAgLIqXf/PNN9azZ09XD+DG G290+6QAgLD480WTJk1y54tKlChhTz31FLXTASBAyl387LPPrG3btm6N3rFj R9u+fXvUwwIApJLW6MpreeKJJyxv3rxWqVIlV1tX50gBAGH5/vvvXS+jOnXq WK5cuaxXr1526NChqIcFAEglrcUVYxk0aJCr6dKoUSNbtmwZuYsAECBf0+WK K66wQoUK2fDhw6npAgABUu7iV199ZV27dnX10Vu2bOl+DgAIi2IrR48etYkT J9qll15q5cuXdzVdlP8CAAiL8s4VN2/atKmLo99xxx22Z8+eqIcFAEgl1XTZ t2+fjRw50tXo8jVdyF0EgPBoD1RzePXq1S1Pnjx27733ujOkAICwaC2+ZcsW N4/rvOj1119vq1atIncRAAKkGovTpk2zUqVKna7pQu4iAITH13Rp166dZcmS xW655Ra3ZgcAhEWxlcOHD9v48eMtX758VrlyZVfThX50ABAe9aNbtGiRNWzY 0OW6dOvWjX50ABAg5S7u3bvXHn74YcuRI4fVrVvX5s+f734dABCWU6dO2dtv v+1q6OrMqGq60I8OAMLja7rcddddrqZLs2bNXD86chcBICy+H92UKVOsWLFi rvbic88952LrAICwqKbLypUrrVWrVm6Nftttt9mOHTuiHhYAIJW0/6maXKrp on501apVszfffJOaLgAQIN+PTvW5lI/ev39/+tEBQIBicxdV06VBgwb28ccf sy8KAAHSnL5//343p2fKlMnq1atnCxcujHpYAIA4KSf9gw8+sNq1a1uBAgVc D2nq6QJAmHz85bHHHrNcuXLZVVddZUlJScRfACBQykP/5JNPrHnz5q4/3Z13 3mm7du2KelgAgDhoTX7kyBF3zkg1AcqWLWsvvPACtRgBIFCav7/88kvXQ1rn jm6++Wb3cwBAeLRWV72umTNnWsWKFe2yyy5z55DobQQAYdJ+qWoCKPfF56t/ 9NFHUQ8LABAnrcvnzZtn11xzjeXOndv69Onj+h4BAMLjzyE98cQTrlZAlSpV bPr06eQ2AkCg1GN6zZo1duutt7oYTKdOnWzbtm1RDwsAEAdfT/3ll1+2EiVK uJrqWreHUqtR47/Q3yu4BlwDIJbm740bN1qvXr0sS5Ys1rRpU1u9enXUw/qP NGbVlPz000/de4b2Bi60e9pfg88++8zWrl17QV8D9QRYsWKFpaSkRD0kIF3Q vaD+pKqprlowQ4YMSZf3h/YAjh075urW3HLLLa5PU9WqVe2+++6zzz///II4 OxV7Ddq2bXvWa5DR53Zdg+PHj9uSJUtcD8Yrr7zS2rRp434O4F/3iGoEDBs2 zNUMqFOnjpsz0gvNUar/rvcHvU+UKVPGLr74Yvvd735nf/jDHyxnzpxWt25d Gz9+vB04cMB9PhmNroFqO2jeHjBgwE9egyeffNK2b9+eYa+BenWpn+6DDz5o FSpUcN+vefLksa5du9qmTZuiHiKQbmjOXLp0qes5rfnh7rvvdnkxUdM+ru5V 1R5Tbo7uYZ9TP3bsWFc/uHz58vbHP/7RChUqZC1btnT9m3SuKqOsV7X21t71 U0895dbkl1xyyf+5Bo888ohbq2pu13uWvobTpk1zdSAy0jXQmQrVsrj22mtd HTqdg7766qttwoQJ7jmm+R7Av/haMM8884wVLFjQ1YJ58cUXI5sTdA/v3r3b Jk+e7O5hrcW0LtW8rrlN9QwUgzh48KCrBa/8etWwUX34UqVKuXWb3sW1tg11 XlO8WO8dr7/+ul1//fWWP3/+09dA6/GzXYMiRYrYRRddZJdffrnLY9IZhNCv gWLms2fPdrEmfW9qLlfMSWv1devWuWsQ6ucHpCWtiXWPdOzY0d03illv2LDh vI5BMQM9W9577z2XY6k5SvOY8nIUM1ZdSd3DPrbgYxJaw2l9rjHrDJXWsZr7 tDewfv36YHJ5RJ+b3jMWLFhg7du3d/UbdA1Kliz5X6/BW2+95eY+XQN9DStV qmSDBw92839I10Cf08mTJ2358uXWs2dP95zW56N3sS5dutiiRYvcXJ8RY0zA uXJmLZiiRYvaqFGjzsveo4+ZK16sXqmlS5d297BiCZrX3n//fbdm1XPnp/68 +n5888039vzzz1utWrVcPEZzW/369d37uXpsp+c5wF8D5bEoZq53JeUi6XNo 3bq1e8793GugGIViM/7P+2ugd5/0fg30fPr6669dXE3P5Rw5crh4oGpE67mt r+NPXQMA/5fWclu2bHHzquYDzQVpXQtG96f+TeXGq1eH4sX6uO6661zuvGKl mut+7vi1htV+qvZ89WzwsfabbrrJzQla/6W3d3V/DRRTUYxYn7+uv/Y9p0yZ 4n4vNddA5w6U56l9CMXaFY9J79dAawft1b/00kvueaRnka6B9hAUb9u8ebN7 ZgFIHd03H374oTVs2NDFZbUPlxb8e4HWn40bN3Y1CrQ21z08evRoFzOJd+7R /KA1reLJ3bt3d3FYxdo1x/fo0cPlM2tPLep5TWtm1dlRzKRJkyaWN29eN07N w3pHSk5O/kXXQLF2xXCUL6QYjt9v6Ny5s4tfpJdroHibcq30Tla4cOHT8bYH HnjAPZuImQPx8/OM9qU0rygWkBY05ygvTXOs5nLFi/V+oBjq0aNHf3H817/H a52vWjbKidH6V7kz1atXt4ceesidt4oiFuHjxdrHVb8pneHNnDmz+//evXu7 Xz+X12Dnzp3uuaEYTux+g2Lt2kPRv3O+50z9ezoHsWrVKvd1176nj7clJiba /Pnz3TMppH0AIL3SPKf7TXO75oS0+jf097/zzjs2fPhwt05T/uS5jpX6uUPP D+X1KNau9apyaRo1auTyezR3nI85zcfMtWep/VvlYWp+1fpc+7u6FuobmxbX QO9feoYp1q4zCLGxdl0X7bGej+ebf85oLHof8/E2xcz1vvbaa6+5Z1Bafd8B ODd0L585Z8Q+O35uvDheWu9p7av3gIEDB7q4kmLtyq3x82lanrHXe4neGTR/ ak7VHKYYQ40aNdxz5dtvv03zM/663oq1q6bAo48+auXKlXPXQHmgWsMr1q5r lFZj0Ndg37599uqrr7r8TD3L9H6id4Zx48a5/V19PxBnAdIv3Z+KhypGP2nS JPfjKGkNrHlF7wXq4ac4vuYVvfvrrNWyZcvO6Rl7zWN6D9B8eeONN57OM1de i+I/im2d7zNSPtaur4ly+TWna0zab+jWrZstXrzYrevP1Zh8TQP9e7fddpvb r9W/p1hTv379XPyFmDkQBt3Pyj9TXovmUMUWouZjIFu3bnVnLlW7TLFcxdoV C1C+iH7vl8QifMxH7wXap/Uxc82fqlOiPUq9n0QVLz5zv0HPG7076Br43P4v vvjiF8WBfMxH7wWKmWvfU9dZ63OdP1COquJtF0KtHiBq/p7Xu7g+fio24udH 5S6otlLsHKXf0/2q+Kje9du1a+d+rLkyPeRJawzaq9Tcpfwe5RH+6U9/cmt3 xXaVR5jaWIS/borfjxgxwp370Typ2LWvXaCcvfRylt0/e5QT/uyzz1rNmjXd fkNsrF3jTe3XS88CxZMUU9Eehq9poHyqqVOnpipHFcAvp/tNuektWrRw+cK6 t892D2odlpSU5Prg3XvvvafPteicn961tQ+mNZ/mSJ1l0pluzZ/6M4qBpAd6 DumZpLiL8ucUg1BOt9bWyq+bM2fOzzpj73OsFR/XfOhzTGrXru3mS+0LnsuY xrnk4yOKgwwdOtRdAz3fFCdp1aqVzZo162fFR3xNgxkzZrjaMz62pZpbY8aM cc+O9JgfD2R02q/TvOvvba2vlOt85r2o+1NzmN6nb775Zhez0H2tulM6Q6Pc Eu0Jak9S97d+rFiH8ug0x6UXvu6fnjOaw5VPp7w6zUcJCQmunorOMmnuO/Ma +Bzrd999181/+nPKK1HMXGeflGOtvcn08G7y3/jcfuUSKkakz0XrdsVNlNeu 2gRn28v1+6+KKSnGpjxzXTudR77nnnvctdM7TwjXAMiIYuf0X//61+7dWftn WofGOtuc7uMPmh+1Lvv444/dfa25XD/WXK6/Jz2+e2vs+tx9rF01xDSn6Yy6 clRGjhzpYgp+bte6W/Ocro3mPc1jOuOkvHM9A/W+ElqOdWwNGdWK0PlTvW8o Fl65cmUbNGiQqwXk89p1vZTnrnwi1QHWf+trGiifSN8HoV2DC4HPRTvbOuVC cSFdg9g5/be//a2r5ao5S3GT2Nzhs83psXStFI/RvqP2xfTjEPhaWspLefzx x935Vr2vKG9FzybFhPV7OpelPUXNY9pj1O+plqLmw9BzrH2sXfO3Ym/ab1BM SvO1ajc899xz7kyuYuY6x+VrGuhdTGf8VdNA30dIX2L3fNR3QB9+nXIh0Xu5 ak7oXlZs1Ne6y6hzu5/TFXfQeXLFy/25ENVa937OnK68F8VSb7/9dvfjkCgW obW28vv0rqEYktbtyl9RbEVnl7R+Vb6M5jbNfxktx9rH2tUvUOfD9GzXNdDz TdfD1zTQ9dC+sO6NjFTDPiPx5ySefvpptx+ur52+jnpGKydAuVgZ/eumeVvz kGp5K6as+KI+VF9J93A8OQEh8HO6ao8ob0F18lSTRHOYYsvKb5b/NqeLciAU o9XaNcSaej7Wru8D1UxQ/o7Wqnp30fNOewOKF8fWwM2IfF679s6Vn6lroF5L ip2rxoPyNrWvkJGvQaj8OQnd04qJ6X7VO5diivo6+vN3+t6eO3duhluXiO97 qO9fxQwUI9U10PulfqxroP9XrFE5ARltLz92TlcOh+KiEydOdHteWo/pjLnm 558zp2cUPnas91T1cFX9WvWj0L1yoeRY++ebclJVf03rPeWZ69zBhXINQuL3 fNSLW8/h4sWLu/iY8pm0B646d7q3O3To4PpH+Rwl1epXbDE91Hn7pfx9q89H uXna89E10PuJPm/dy3qO6cyhrouvdafro72yjHANJHZO1/uJYg/a29QaXc81 xY0VS72Q5nRPz3tdHz3z00ue+fnmY7LKdUmPe9341/uxYoF6x9Z+h85JKH6q dajmMT2H9f2r72XtfbzyyisuJ0BnfPXfKQdXuWvnqxZQWvDnY7QfpPio3ks0 n9erV899vsrP0/evPhSTUg6uzt9pXtcemfbR1B9Svxf6Pv+Zc7pi6Po1vbfo 6645XOe6dU0utDkdSM9i+x4qTu77t1arVs29V+kePXPv2ucEKH9J+Qy+FpDv 86v8p7SsBXSu+RqBmsO0/lQeteIs2h9UXoP2fM6MrcTW+9M7uHICfv/737u5 TddRtU1CugZnOtucruukOIOeearHra+78mAUk2FOB6KluSY2Xqz5WLEU7Wlr z0fnpf/bubHYnAC9k2uvJLbPr87lpefcED8vK4agWIrvU6w4ufKNf04tb99b R+fvdAZRf4ffb1BvT53BSK9nB0Xj8h+xzjani77misGozrfe5ZQHo689czoQ DV+fQ3O2zgioHl1svFj7Hanp3+r3TJR3rPW5YhG+toPW+qo9p5hOeorH+Fig xqXcK9Wx1vykWIvOwiu3QTkOqdnz0X/rzyAqZ0/XQM9I/d2qX+TrIaWnuV3j UaxJY9acHZuT8lNzuugZpf0xncHRNdOzXF9v5nTg/NK8o/inz030ddh0z6r3 4y852xd7PkFnEXwtIOW+6e9X71/F5KOe03xuovLMFRdWrEl7Anr++Nz7X3IN 9Ge136DcR+V065yK5nf9WDEaX8MqSr6Ota9JqHNFeg7FntX/T3O6xq8/r5xz 5UH95je/cbEq5nTg/NA9qBiC1lba8/S16JWzorPOPl58rv4t3+c3thaQYhFt 27Z1a8IockPOrOGsHHPN5crtUcxEPeu1h38uxuXzILXfoOurd6Ezcx/P1b+V Gj6vSfOz6pkoJu7jbTorqTF7/2lOF63p9e6h2h46Z6qvMXM6kLb8Pax4seLD /h72ZwQU7z4XfQ/PxtcCUt6f1oB+DlVus2Kxvh5SWvO5iarhPGDAAPfvK9ak 55rmdo0vrfoe6u9UHEt7FrH1kGL7L2hdfz7mdj1HfbxN8SBfx7pNmzYur0nj jB2HrpmePaqlqPcZjTWW76mpdYLeyfS1Vb8gvQcCOPe0jtJZdq0TtdbSPayY p84C6l5Ni76HZ/KxCN3n6jOofBBfD0l5Inp3Vxwkreb22HOw+vd8j2HVClTc 4XzU5Ijt86va2b4eksaheI/i+fo6pdU18LEm1d9Qvqnf61B+pn7tbHlNomun canPmNbrZzvT7/OF9MxS3ErvYHr/AHDu6B7WfK14sd6ZFe/08WLloG3atOm8 19XxazrFIlRP29dD0rpVNZY1v+q9/1z2C9M7gvZstefpa6bq2ab88bPlJqY1 /86k3Efl/+kMgJ5vypu84YYb3Nx5Lq+BjzVpHa38Ut8vTPmHOoOQnJz8H2ty 6Nf9OVHtk/zUe4z+HT23NXZ9fvrv0kvPCyBksfWLFetQ7FZzhq9f7Gs4R7lH qbWf1nVLlixx51VU/0dzu2Laqs2s9/tfkhvi3wt0Dla5lPp7NZcrlt+zZ08X E1Y9iijPA52t17H2FzXWTp06ubrV5+IaKLdS8R5f/1U5loq/qf5rWl0DxXd0 /lbvX4rnXKhnLIFfwt/DWnfpjL5ywxVnUT6H6rHovVhr1vRyrtHnPupdQjmD 2lfTePWh2K3vlRBPryzlm2ivT3u/ii/oGii3Uut15Wmkp/pRvtex+ijofIDy gxTn17uE6lOrh3q810DvQv4a6EMxL10DXfO0jDVpPa+zVr4Pver4Afj5fG6i YpmqWaw4teZG1QxULp1iuOl1reT3LhUL0jygOlFasyu/0tc8VP/Zn9MrS/+d zu4rXzA21qSauIoJKyaQHsXWhFKs7FxcA98zzV8D5U/6nmlpTWsLxdQVV1JM 6f777z9n+VRARub3pvR+q1ipz030sVLliIdyL/m8P8WG1OdL7xmqYar4r3Iy tI49W91H/VzxYMWadF4z9gyrr316LuPTaSm2/4J6Met9xdda0DXQ+8zZ4v8/ dQ3UR1OxrfN9DXz/C50z0x6w5nbtrwI4O7/XqPp/ykX0sVLd+126dHH3tmKl IcxjZ4qtzay4r6+zr/x2fa6an3yc2Z+D9f2AFbNQ7EKxJuWfKy8vxLqfvtaC 6rfqGmitq/X2z70GWp/rDIDyMxVvi+IaKLajvQLl92he176Gr7UO4N90f+od XbmJlSpVOt0rS3kjb7311um6iSGL7YOommKqJaJ5XXODzqGrXpj2UXVO1efl aS5TvEG5khmlX9iZuY++7qPyMbWO1zXQuVzF23wNAvWtUG5i1NdA49dzSfFA 1ZtQrWLV+Eov+zlAeqBYqNZePjcxtleW9tIyWs+/2JqHyi1X7qNiEdrzVFzB r18Va9Icpz7GGa0vh899VBxN86PP//ypa7B+/fp00y9M6w/li6rPsp65enfQ 9ymAf8coFWv2Z9m193Qh9MryNQ+Vm6i8P81l6pWlvAqdw1QMKqP3yvLXQGeB lQ+jr////M//pOtr4OP8es/QO6VySfXcCf0dCjgXYnsPaV2uvIKoYqVR0eeq vA7tF6hnmmpHprfcxLSmz9VfA/WgSO/XQM8YneFVfq3WIg0aNHC58QD+HWNV DsOFutaJPdfINQjjGigmqDNUms+1h62aw7F1wgAA4fA1ebWvr73cypUru73v 9BDzBwCknnKxVKdA54WVu6O+K8rfAgCER2ty1beZMmWKOw+mMxXKZSK3EQDC pD1u5Zuqppj2S5s3b+7q2QMAwqTzA++8846rF6CaocOHDw9inxcA8P/TfqnO xmou17k5nYFVXi4AIEyqUaP8etV8UF2L7t27u5oWAIDwaL9U9bxU60A1JNUX VXun5DYCQJh0Zkp1ldUHRHWL9P/UggGAMGlNrrOkqqOp+mOXXXaZO5OU0erQ AcCFQrnpOnekvh3qzaX4umquAwDCE1trVGdL1adPvVAAAOFR/otqe9WrV8/V 9urTp4/rowEACIviLuqLrnr4ymds1KiRLVmyhNwXAAiQ6gRPnz7dEhIS3P6o +hFq3Q4ACIvyGJOTk+322293PWZbtWrletwBAMKi2Ip67Kk3tnrZKY9RPavS a58mAMBPUx31ZcuWuZqM6o9xxx132I4dO6IeFgAglZS7uGfPHhc7V57LVVdd ZUlJSdRQB4AAaQ907ty5VqtWLcufP78NGDDAxWEAAGHRWnzz5s127733upiL zoyuXLmS3EUACIyv7TJt2jQrU6aMFS9e3MaMGUMvDAAIkHJa1q5da+3bt3e5 i7fccgs1GAEgQFqjHz582CZMmGCFChU6XSud3EUACI/iKzrz36RJE8uVKxc9 jQAgUL7u4ogRI9x8XqNGDZs9e7b7dQBAWNTf4v3337fq1au7uMuQIUPsxIkT UQ8LAJBKP/74o9sH7dmzp6uNfsMNN7h9UnIXASAsmre/++47mzp1qpUoUcJ9 jB071tUFAACERTktn376qctZ1Bpd/aO3bNkS9bAAAKmkNfrBgwdt3LhxVqBA AatYsaK9+uqr1HQBgAApd3HhwoWub5HqdPXu3Zt+dAAQIK3Ft2/f7vJbVNOl du3aNmfOHPZFASBAyl189913rWrVqnbppZfa8OHDXY86AEBYlLu4fv1669q1 q2XNmtX1vKAfHQCER7GVo0eP2ksvveT6RZcuXdqeeeYZaroAQICUd75ixQpr 2bKl5ciRwxITE23Xrl1RDwsAkEqq3bJv3z57/PHHLW/evFa5cmV74403yF0E gACpH92CBQvsmmuusXz58ln//v1dHAYAEBatxXU+VP3odF5UOenLli0jdxEA AnTq1ClLSkqyChUqWNGiRe2xxx5z+YwAgLAopyU5Odluv/12t0Zv3bo1/egA IECKrRw5csSef/55K1y4sF1xxRXux8pRBwCERXO31uidOnWyzJkzW4cOHWz/ /v1RDwsAEAftjX777bd2zz33WKZMmaxhw4ZubxQAEKaUlBRX2+Xqq6+2/Pnz u7pdymsEAIRHZ4327NljjzzyiOXOnft0/2jyGAEgTFqXL1myxPUaVW1d1e/a vXt31MMCAMTB579MnDjR5acnJCTYpEmTWKsDQKCUp7527Vpr3769ZcmSxW6+ +WZq7AJAoLQmP378uE2fPt3Kly/vau2OHj2aGl4AECjN31u3brX777/fsmfP 7uq+LFq0KOphAQDipDovc+fOtTp16riau/369XOxdgBAeJTbqLOkY8aMcTV3 q1WrZjNnzmS/FAAC9cMPP9gnn3ziepEqBqP6Xtu2bYt6WACAOPi+pMpnLF68 uJUqVcrGjx/vetsBAMKj+l4bNmywHj16uPpeWrN/9tlnUQ8LABAn1YJRr4xK lSpZoUKFbOjQoXby5MmohwUAiIP2S3fu3GkPPvig5ciRw+rVq2cffvhh1MMC AMRJtWAWL15sTZo0sVy5clnv3r3t4MGDUQ8LABAH7ZceOnTIJkyYYAULFrQr r7zSpk6dyvlSAAjUmbVg2rVrZxs3box6WACAOPhaMK+++qqVLFnSLr/8cnvy ySfJbQSAQPk+d3379rWLL77Y1VpfsWJF1MMCAMTp1KlTNmfOHKtVq5YVKFDA Bg8ebCdOnIh6WACAOCi3cd++fTZy5EjXD+mqq66yWbNmRT0sAECcVAtm2bJl p2vBdO7c2fbu3Rv1sAAAcfB97p577jl3trRs2bL24osvktsIAIFSbmNycrIl Jia6WjDqc7d+/fqohwUAiIPW6tobVV31ChUquD53o0aNcnEZAEB4tF+6Y8cO GzhwoDuH1LBhQ/rcAUDA1Odu3rx5ds0117haMH369HF11wEA4VEM5sCBAzZ6 9Gg3p1epUsWmT59OnzsACJTqA+g8acuWLS1r1qzWqVMn2759e9TDAgDEQWvy Y8eO2eTJk12fu2LFitkTTzzh4u0AgPAoN111Gu+++26X23jTTTe5XEcAQHh8 XF35jIq/qB/SwoULox4WACAOykv/+OOPrXHjxq7HXbdu3VwfDQBAWBQ33717 t40YMcLV9dIa/aOPPiL3BQACpPq7SUlJlpCQcLr+rn4NABCWH3/80e2N9urV y8XRmzZtamvWrGGNDgABOnnypL388stWpEgRK1GihI0bN87V9wIAhEVnjVav Xm1t2rRxa/TbbrvNtm7dGvWwAACppNiK8lrGjh1refLkserVq9tbb71FDXUA CND3339vc+fOdX1JVeeld+/erk8GACAsvsbukCFDLFu2bNagQQNbvHgx+6IA ECDlKb755pt2xRVXWOHChV1eOr0wACA8yl386quvrGvXrq4PRosWLeyLL76I elgAgDgcP37cJk2a5HpLly9f3qZMmULuIgAESPGVJUuWWJMmTSx79ux2++23 265du6IeFgAglXzdxTFjxljOnDmtRo0aNnv2bHIXASBAyl2cM2eOy0PPmzev DRgwwMVhAABh0Vpc50Pvu+8+ty/asGFDW7ZsGbmLABAg1XSZNm2a60lXqlQp e+aZZ4i5AECAVNNl5cqVrhedetLdcssttmXLlqiHBQBIJcVWjh49ahMmTHDn /6tUqWIzZsygdzQABEj7ovPnz7c6deq4/kU9e/a0w4cPRz0sAEAqKV6+bdu2 0/ui9KMDgHCppsusWbPcWdGiRYvayJEjXWwdABAWnfVPTk62Tp06WaZMmaxZ s2bu5wCA8Ogskeq4XHrppVa2bFl78cUXyV0EgAApvqLzRFqbq6ZLly5d7ODB g1EPCwCQSspR3Lt3rz366KOWI0cOq1atmiUlJbEvCgAB8v3oVJ8rX758NnDg QLdXCgAIi+LlmzZtsj59+rh9UfWjU11dAEB4UlJS3BlR9aMrXry4Pfnkk66n EQAgLMpdXLt2rd1666128cUXW9u2bd15IwBAWLT/qfP+48ePd3XRExISbPLk yeyLAkCAtEZfs2aNtWvXztVdvOOOO+zYsWNRDwsAEAftjap2br9+/eyiiy6y +vXr2+LFi6MeFgAgTsphnDdvntWtW9fy5Mnj6nbp1wAA4dFZo/3799vo0aNd nfSqVavazJkziakDQKBUE2DFihWun1G2bNksMTHRduzYEfWwAABx0Jrc1+5S bV31HX322WdZqwNAoHTG6Msvv7Q777zT5anfeOON9vnnn0c9LABAnFTf5e23 37aKFStaoUKF7OGHH6bOLgAESvP31q1bbcCAAa7ui3JhPvzww6iHBQCI0w8/ /GALFy50dbxy5szpctepzwgAYdK+6KFDh+zpp5929QIUh3nttdfYLwWAQCm3 cfXq1da6dWvLkiWLq++l86YAgDCdPHnSrc9LlCjhPlTni7U6AIRJuY0bNmyw u+66y9WCady4sa1cuTLqYQEA4qS90Xfffdf1Ji1QoIANGzbM1XIEAIRHtWB2 7txpgwcPdnH1mjVr2nvvvRf1sAAAcVJu46JFi+zaa6+1HDlyWK9evVysHQAQ Hu2Lqk/GxIkTrWDBgla+fHmbOnUq+6UAEKjYfkiqBaMcR+2fAgDCpHjL9OnT rUyZMlasWDF76qmnXLwdABAe1YLZtGmTi6crt7FRo0a2dOnSqIcFAIiTetp9 8MEHdvXVV1u+fPls0KBB9LkDgEAp1rJnzx5Xgzd79uxWvXp1V5sXABAm5TYq 5tKkSRPX565bt2525MiRqIcFAIiDchi/++47mzRpkhUpUsTKlSvnfkxuIwCE SbmN69ats44dO7r9UvW5++KLL6IeFgAgTikpKfbWW29ZQkKC60v9+OOPu7pf AIDw+D539957r2XOnNnq16/v+iMBAMKkPEb1K61du7blyZPH9THV+h0AEB7l Nu7fv99GjRrlepeqJq/iMQCAMKnP3fLly6158+auHm9iYqLt27cv6mEBAOJ0 4sQJV6vxsssuc/Vgnn/+eWrBAECglO+yfv1669y5s2XKlMmaNm3q6jgCAMKk PnezZs2yypUrW40aNWz27NlRDwkAECd/vnTVqlX20UcfuXgMACBsiqPrg1oB AAAAAAAAAAAAAACcX/8L6YKfvQ== "], {{0, 347.}, {373., 0}}, {0, 255}, ColorFunction->RGBColor, ImageResolution->72], BoxForm`ImageTag["Byte", ColorSpace -> "RGB", Interleaving -> True], Selectable->False], DefaultBaseStyle->"ImageGraphics", ImageSize->{57.40625, Automatic}, ImageSizeRaw->{373., 347.}, PlotRange->{{0, 373.}, {0, 347.}}]\), CloudGet["https://wolfr.am/KR7FBcsM"]}], MoleculeEquivalentQ]] |

Something else that’s new in 12.1—and a first sign of something big to come—is the ability to import data about molecular orbitals:

✕
Import["ExampleData/Pyridinecarbonitrile_MO_25_29.cub", "Graphics3D"] |

We launched the Wolfram Function Repository in June 2019, and there are already 1146 functions published in it. One of the innovations in the Function Repository is a very streamlined process for submitting new functions, applicable both for the public Function Repository, and for individual deployment on a single machine, or in the cloud.

In Version 12.1 we’re introducing a new, streamlined submission mechanism for the Data Repository. File > New > Repository Item > Data Repository Item gives you:

Then if you’ve got, say, a `Dataset`, you just insert it in the notebook, then add examples (using the Insert ResourceObject button to insert references to the object you’re creating). When you’re done, press Deploy, and you can deploy locally, or privately or publicly to the cloud. Lots of checking just happens automatically (and if there’s something wrong you’ll usually get a suggestion about how to fix it).

My goal was to make it so that a simple Data Repository entry could be created in just a few minutes, and I think we’ve streamlined and automated things to the point where that’s now possible.

We want the Wolfram Language to provide a consistent computational representation of as much as possible. And that means that in addition to things like the molecules we just discussed, we want our language to be able to represent—and seamlessly interact with—all the other kinds of computational systems that exist in the world, whether they be programs, languages, databases or whatever. The list of kinds of things we can deal with is very long—but in Version 12.1 we’ve made some significant additions.

The Wolfram Language has been able to call programs in other languages through what’s now WSTP since 1989, but in recent years we’ve been working to make it ever easier and more automatic to do this. And for example in Version 11.2 we introduced `ExternalEvaluate`, which provides a high-level way to directly evaluate code in external languages, and, whenever possible, to get results back in a symbolic form that can be seamlessly used in the Wolfram Language.

In Version 12.1 we’ve added Julia, Ruby and R to our collection of external languages. There are all sorts of practical issues, of course. We have to make sure that an appropriate installation exists on a user’s computer, and that the data types used in programs can be meaningfully converted to Wolfram Language.

But in the end it’s very convenient. In a notebook, just type > at the beginning of a line, select your language, and enter the code, and evaluate:

✕
> [1,2,3+3] |

But this doesn’t only work interactively. It’s also very convenient programmatically. For example, you can create a function in the external language, that is then represented symbolically in the Wolfram Language as an `ExternalFunction` object, and which, when called, runs code in the external language:

✕
> def square(x) x * x end |

✕
% /@ {45, 135, 678, 34} |

For each different language, however, one’s dealing with a whole new world of structures. But since we have built-in support for ZeroMQ (as well as having a connection to Jupyter available), we at least have the plumbing to deal with a very wide range of languages.

But particularly for languages like Python where we have full built-in connectivity, one of the significant things that becomes possible is to have functions that work just like standard Wolfram Language functions but are fully or partly implemented in a completely different language. Of course, to have this work seamlessly requires quite a bit of system support, for automated installation, sandboxing, etc. And for example, one of the things that’s coming is the ability to call functions containing Python code even in the Wolfram Cloud.

In addition to external languages, another area of expansion is external storage systems of all kinds. We’ve already got extensive support for the Bitcoin and Ethereum blockchains; in Version 12.1 we added support for the ARK blockchain. In addition, we introduced support for two external file storage systems: IPFS and Dropbox.

This is all it takes to put a Spikey into the globally accessible IPFS file system:

✕
ExternalStoragePut[CloudGet["https://wolfr.am/L9rTMCn6"], ExternalStorageBase -> "IPFS"] |

Here’s the content identifier:

✕
%["CID"] |

And now we can get our Spikey back:

✕
ExternalStorageGet["QmcNotbm3RZLv7caaPasU8LiHjNCCuuEemrCgbLAsN49TZ"] |

You can do the same kind of thing with Dropbox, and after authentication (either through a browser, or through our new `SystemCredential` mechanism, discussed below) you can put expressions or upload files, and they’ll immediately show up in your Dropbox filesystem.

Given the framework that’s been introduced in 12.1, we’re now in a position to add connections to other external file storage systems, and those will be coming in future versions.

In addition to plain files, we also have a sophisticated framework for dealing with relational databases. Much of this was introduced in Version 12.0, but there are some additions in 12.1. For example, you can now also connect directly to Oracle databases. In addition, there are new functions for representing relational set operations: `UnionedEntityClass`, `IntersectedEntityClass`, `ComplementedEntityClass`.

And, of course, these work not only on external databases but also on our own built-in knowledgebase:

✕
SortedEntityClass[UnionedEntityClass[ \!\(\* NamespaceBox["LinguisticAssistant", DynamicModuleBox[{Typeset`query$$ = "EU", Typeset`boxes$$ = TemplateBox[{"\"European Union\"", RowBox[{"EntityClass", "[", RowBox[{"\"Country\"", ",", "\"EuropeanUnion\""}], "]"}], "\"EntityClass[\\\"Country\\\", \\\"EuropeanUnion\\\"]\"", "\"countries\""}, "EntityClass"], Typeset`allassumptions$$ = {{ "type" -> "Clash", "word" -> "EU", "template" -> "Assuming \"${word}\" is ${desc1}. Use as \ ${desc2} instead", "count" -> "2", "Values" -> {{ "name" -> "CountryClass", "desc" -> "a class of countries", "input" -> "*C.EU-_*CountryClass-"}, { "name" -> "Unit", "desc" -> "a unit", "input" -> "*C.EU-_*Unit-"}}}}, Typeset`assumptions$$ = {}, Typeset`open$$ = {1, 2}, Typeset`querystate$$ = { "Online" -> True, "Allowed" -> True, "mparse.jsp" -> 0.363881`6.012504373043238, "Messages" -> {}}}, DynamicBox[ToBoxes[ AlphaIntegration`LinguisticAssistantBoxes["", 4, Automatic, Dynamic[Typeset`query$$], Dynamic[Typeset`boxes$$], Dynamic[Typeset`allassumptions$$], Dynamic[Typeset`assumptions$$], Dynamic[Typeset`open$$], Dynamic[Typeset`querystate$$]], StandardForm], ImageSizeCache->{232., {7., 15.}}, TrackedSymbols:>{ Typeset`query$$, Typeset`boxes$$, Typeset`allassumptions$$, Typeset`assumptions$$, Typeset`open$$, Typeset`querystate$$}], DynamicModuleValues:>{}, UndoTrackedVariables:>{Typeset`open$$}], BaseStyle->{"Deploy"}, DeleteWithContents->True, Editable->False, SelectWithContents->True]\), EntityClass["AdministrativeDivision", "AllUSStatesPlusDC"]], "Population" -> "Descending"][{"Name", "Population"}] // Dataset |

We’ve been very active over the years in supporting as many file formats as possible. In Version 12.1 we’ve added the popular new HEIF image format. We’ve also updated our DICOM importer, so you can take those CT scans and MRIs and immediately start analyzing them with `Image3D` and our 3D image processing.

Like, this is part of our director of R&D’s knee:

✕
knee = Import["knee_mr/DICOMDIR", {"Image3D", 1, 1, 1}]; Image3D[knee, ColorFunction -> (Blend[{{0., RGBColor[0.05635, 0.081, 0.07687, 0.]}, {0.0777045, RGBColor[0.702347, 0.222888, 0.0171385, 0.0230167]}, {0.3, RGBColor[1., 0.6036, 0., 0.303215]}, {0.66, RGBColor[1., 0.9658, 0.4926, 0.661561]}, {1., RGBColor[1., 0.6436, 0.03622, 1.]}}, #]& )] // ImageAdjust // Blur[#, 3] & |

In Version 11.3, we added `MailServerConnect` for connecting directly to mail servers. In 12.1, we’ve added a layer of caching, as well as a variety of new capabilities, that make the Wolfram Language uniquely powerful for programmatic mail processing. In addition, in Version 12.1 we’ve upgraded our capabilities for importing mail messages from EML and MBOX, in particular adding more controls for attachments.

Yet another new feature of 12.1 is stronger support for ZIP and TAR files, both their creation through `CreateArchive`, and their extraction through `ExtractArchive`—so you can now routinely handle tens of thousands of files, and gigabytes of data.

Whenever one is connecting to external sites or services, there are often issues of authentication. We’d had some nice symbolic ways to represent authentication for some time, like `SecuredAuthenticationKey` (that stores OAuth credentials). But for example in cases where you’ve got to give a username and password, there’s always been the issue of where you store those. In the end, you want to give them as part of the value for an `Authentication` option. But you don’t want to have them lying around in plaintext.

And in Version 12.1 there’s a nice solution to this: `SystemCredential`. `SystemCredential` ties into your system keychain—the encrypted storage that’s provided by your operating system, and secured by the login on your computer.

It’s as easy as this to store things in your system keychain:

✕
SystemCredential["secret"] = "it's a secret" |

✕
SystemCredential["secret"] |

✕
Length[PacletFind[]] |

In my Wolfram Language system right now, I have 467 paclets installed. What is a paclet? It’s a modular package of code and other resources that gets installed into a Wolfram Language system to deliver pretty much any kind of functionality.

We first invented paclets in 2006, and we’ve been increasingly using them to do incremental distribution of a great many pieces of Wolfram Language functionality. Paclets are versioned, and can be set to automatically update themselves. Up until now, paclets have basically been something that (at least officially) only we create and distribute, from our central paclet server.

But as of Version 12.1, we’re opening up our paclet system so anyone can use it, and we’re making it a fully documented and supported part of the Wolfram Language. Ultimately, a paclet is a file structure that contains assets or resources of various kinds, together with a special PacletInfo.wl file that defines how the paclet should integrate itself into a Wolfram Language system.

A paclet can set up code to execute at startup time. It can set up symbols whose definitions will be autoloaded. It can install documentation. It can put items into menus. And in general it can set up assets to be used in almost any part of the fairly complex structure that is a deployed Wolfram Language system.

Typically a paclet is distributed as a single archive file, and there are many ways someone can get such a paclet file. We maintain a central paclet server that’s used by the Wolfram Language system to get automatic downloads. But in the near future, we’re also going to have a full paclet repository through which users will be able to distribute paclets. (We’re also going to make it possible for Wolfram Enterprise Private Clouds to have their own paclet repositories.)

I might mention how I see the Wolfram Paclet Repository relating to our Wolfram Function Repository. The Function Repository is built to extend the functionality of the Wolfram Language one function at a time, always maintaining the overall structure and consistency of the language. The Paclet Repository will let people distribute complete environments that may serve some particular purpose, but may not maintain the structure and consistency of the overall language. Paclets will be extremely useful, and we intend them to be as freely used as possible. So whereas the Wolfram Function Repository has a curation process to ensure a certain level of design consistency, we plan to make the Wolfram Paclet Repository basically completely open.

The goal is to allow a rich ecosystem of user-contributed paclets to develop. The Paclet Repository will serve as a smooth distribution channel for Wolfram Language material. (And by the way, I think it will be quite common for functions in the Function Repository to actually be based on code that’s distributed through the Paclet Repository—with the Function Repository serving as a streamlined and structured presentation mechanism for the functions.)

In Version 12.1 there are a variety of functions for creating and managing paclets. With the Wolfram Language, `PacletObject` is the symbolic representation of a paclet. Here’s a trivial example of what a paclet might be like:

✕
PacletObject[<|"Name" -> "TrivialPaclet", "Version" -> "1.0", "Extensions" -> {{"Kernel", "Context" -> "TrivialPackage`"}}|>] |

This can then be packaged into a .paclet file using `CreatePacletArchive`—and this file can then be distributed just as a file, or can be put on a paclet server. Once someone has the file, it’s just a question of using `PacletInstall`, and the paclet will come to life, inserting the necessary hooks into a Wolfram Language system so that its contents are appropriately used or exposed.

Well, that’s already a lot. But there’s even more too. `FaceAlign`. `FindImageText`. `Around` in `Classify` and `ListPlot3D`. `SubsetCount`. `GenerateFileSignature`. RSA digital signatures. Much faster `MailSearch`. `Initialization` tied to notebooks or cells. And so on. Here’s the whole list. Check it out!

We’ve been working towards it for many years, but now it’s finally here: an incredibly smooth workflow for publishing Wolfram Notebooks to the web—that makes possible a new level of interactive publishing and computation-enabled communication.

You create a Wolfram Notebook—using all the power of the Wolfram Language and the Wolfram Notebook system—on the desktop or in the cloud. Then you just press a button to publish it to the Wolfram Cloud—and immediately anyone anywhere can both read and interact with it on the web.

It’s an unprecedentedly easy way to get rich, interactive, computational content onto the web. And—together with the power of the Wolfram Language as a computational language—it promises to usher in a new era of computational communication, and to be a crucial driver for the development of “computational X” fields.

When a Wolfram Notebook is published to the cloud, it’s immediately something people can read and interact with. But it’s more than that. Because if you press the Make Your Own Copy button, you’ll get your own copy of the notebook, which you can not only read and interact with, but also edit and do computation in, right on the web. And what this means is that the notebook becomes not just something you look at, but something you can immediately use and build on.

And, by the way, we’ve set it up so that anyone can make their own copy of a published notebook, and start using it; all they need is a (free) Cloud Basic account. And people with Cloud Basic accounts can even publish their own notebooks in the cloud, though if they want to store them long term they’ll have to upgrade their account. (Through the Wolfram Foundation, we’re also developing a permanent curated Notebook Archive for public-interest notebooks.)

There are lots of other important workflows too. On a computer, you can immediately download notebooks to your desktop, and run them there natively using the latest version of the Wolfram Player that we’ve made freely available for many years. You can also run notebooks natively on iOS devices using the Wolfram Player app. And the Wolfram Cloud app (on iOS or Android) gives you a streamlined way to make your own copy of a notebook to work with in the cloud.

You can publish a Wolfram Notebook to the cloud, and you can use it as a complete, rich webpage. But you can also embed the notebook inside an existing webpage, providing anything from a single (perhaps dynamically updated) graphic to a full interactive interface or embedded document.

And, by the way, the exact same technology that enables Wolfram Notebooks in the cloud also allows you to immediately set up Wolfram Language APIs or form interfaces, for use either directly on the web, or through client libraries in languages like Python and Java.

We invented notebooks in 1988 as the main interface for Mathematica Version 1.0, and over the past three decades, many millions of Wolfram Notebooks have been made. Some record ongoing work, some are exercises, and some contain discoveries small and large. Some are expositions, presentations or online books and papers. Some are interactive demonstrations. And with the emergence of the Wolfram Language as a full-scale computational language, more and more now serve as rich computational essays, communicating with unprecedented effectiveness in a mixture of human language and computational language.

Over the years, we’ve progressively polished the notebook experience with a long series of user interface innovations, adapted and optimized for successive generations of desktop systems. But what’s allowed us now to do full-scale notebook publishing on the web is that—after many years of work—we’ve managed to get a polished version of Wolfram Notebooks that run in the cloud, much as they do on desktop.

Create a notebook on the desktop or in the cloud, complete with all its code, hierarchical sections, interactive elements, large graphics, etc. When it’s published as a cloud notebook people will be able to visit it just like they would visit any webpage, except that it’ll automatically “come alive” and allow all sorts of interaction.

Some of that interaction will happen locally inside the web browser; some of it will automatically access servers in the cloud. But in the end—reflecting our whole hyperarchitecture approach—Wolfram Notebooks will run seamlessly across desktop, cloud and mobile. Create your content once, and let people not only read it anywhere, but also interact with it, as well as modify and compute with it.

When you first go to a Wolfram Notebook in the cloud it might look like an ordinary webpage. But the fact that it’s an active, computational document means there are lots of things you can immediately do with it. If you see a graphic, you’ll immediately be able to resize it. If it’s 3D, you’ll be able to rotate it too. Notebooks are typically organized in a hierarchy of cells, and you can immediately open and close groups of cells to navigate the hierarchy.

There can also be dynamic interactive content. In the Wolfram Language, functions like `Manipulate` automatically set up interactive user interfaces in notebooks, with sliders and so on—and these are automatically active in a published cloud notebook. Other content can be dynamic too: using functions like `Dynamic` you can for example dynamically pull data in real time from the Wolfram Knowledgebase or the Wolfram Data Drop or—if the user allows it—from their computer’s camera or microphone.

When you write a computational essay you typically want people to read your Wolfram Language code, because it’s part of how you’re communicating your content. But in a Wolfram Notebook you can also use `Iconize` to just show an iconized version of details of your code (like, say, options for how to display graphics):

Normally when you do a computation in a Wolfram Notebook, there’ll be a succession of `In[ ]` and `Out[ ]` cells. But you can always double-click the `Out[ ]` cell to close the `In[ ]` cell, so people at first just see the output, and not the computational language code that made it.

One of the great things about the Wolfram Language is how integrated and self-contained it is. And that means that it’s realistic to pick up even fragments of code from anywhere in a notebook, and expect to have it work it elsewhere. In a published notebook, just click a piece of code and it’ll get copied so you can paste it into a notebook you’re creating, on the cloud or the desktop.

A great source of “ready-made” interactive content for Wolfram Notebooks is the 12,000+ interactive Demonstrations in the Wolfram Demonstrations Project. Press Copy to Clipboard and you can paste the Demonstration (together with closed cells containing its code) into any notebook.

Once you’ve assembled the notebook you want, you can publish it. On the desktop, go to File > Publish to Cloud. In the cloud, just press Publish. You can either specify the name for the published notebook—or you can let the system automatically pick a UUID name. But you can take any notebook—even a large one—and very quickly have a published version in the cloud.

It didn’t take long after we invented notebooks back in 1988 for me to start thinking about using them to enable a new kind of computational publishing, with things like computational journals and computational books. And, indeed, even very early on, there started to be impressive examples of what could be done.

But with computation tied to the desktop, there was always a limit to what could be done. Even before the web, we invented systems for distributing notebooks as desktop files. Later, when web browsers existed, we built plugins to access desktop computation capabilities from within browsers. And already in the mid-1990s we built mechanisms for generating content through web servers from within webpages. But it was only with modern web technology and with the whole framework of the Wolfram Cloud that the kind of streamlined notebook publishing that we’re releasing today has become possible.

But given what we now have, I think there’s finally an opportunity to transform things like scientific and technical publishing—and to make them truly take advantage of the computational paradigm. Yes, there can be rich interactive diagrams, that anyone can use on the web. And, yes, things can be dynamically updated, for example based on real-time data from the Wolfram Knowledgebase or elsewhere.

But important as these things are, I think they ultimately pale in comparison to what Wolfram Notebooks can do for the usability and reproducibility of knowledge. Because a Wolfram Notebook doesn’t just give you something to read or even interact with; it can also give you everything you need to actually use—or reproduce—what it says.

Either directly within the notebook, or in the Wolfram Data Repository, or elsewhere in the cloud, there can for example be underlying data—say from observations or experiments. Then there can be code in the notebook that computes graphics or other outputs that can be derived from this data. And, yes, that code could be there just to be there—and could be hidden away in some kind of unreadable computational footnote.

But there’s something much more powerful that’s now uniquely possible with the Wolfram Language as it exists today: it’s possible to use the language not just to provide code for a computer to run, but also to express things in computational language in a way that not just computers, but also humans, can readily understand. Technical papers often use mathematical notation to succinctly express mathematical ideas. What we’ve been working toward all these years with the Wolfram Language is to provide a full-scale computational language that can also express computational ideas.

So let’s say you’ve got a technical paper that’s presented as a Wolfram Notebook, with lots of its content in the Wolfram Language. What can you do with it? You can certainly run the computational language code to make sure it produces what the paper says. But more important, you can take pieces of that computational language code and build on it, using it yourself in your own notebook, running it for different cases, modifying it, etc.

Of course, the fact that this can actually work in practice is incredibly nontrivial, and relies on a huge amount of unique development that we’ve done. Because first and foremost, it requires a coherently designed, full-scale symbolic computational language—because that’s the only way it’s realistic to be able to take even small fragments of code and have them work on their own, or in different situations. But there’s more too: it’s also critical that code that works now goes on working in the future, and with the design discipline we’ve had in the Wolfram Language we have an impressive history of compatibility spanning more than 30 years.

Back in the 1970s when I started writing technical papers, they typically began as handwritten documents. Later they were typed on a typewriter. Then when a journal was going to publish them, they would get copyedited and typeset, before being printed. It was a laborious—and inevitably somewhat expensive—process.

By the 1980s, personal computers with word processors and typesetting systems were becoming common—and pretty soon journals could expect “camera-ready” electronic versions of papers. (As it happens, in 1986 I started what may have been the first journal to routinely accept such things.)

And as the technology improved, the quality of what an author could readily make and what a publisher could produce in a fully typeset journal gradually converged, leaving the primary role of the journal being around branding and selectivity, and for many people calling its value into question.

But for computational journals it’s a new story. Because if a paper has computational language code in it, there’s the immediate question of whether the code actually runs, and runs correctly. It’s a little like the old process of copyediting a paper so it could be typeset. There’s real human work—and understanding—that’s needed to make sure the code runs correctly. The good news is that one can use methods from software quality assurance, now enhanced by things like modern machine learning. But there’s still real work to be done—and as a result there’s real value to be added by the process of “official publication” in a computational journal, and there’s a real reason to actually have a computational journal as an organized, potentially commercial, thing.

We’ve been doing review and curation of submissions to the Wolfram Demonstrations Project for a dozen years now. And, yes, it takes work. But the result is that we can be confident that the Demonstrations we publish actually run, and will go on doing so. For the Wolfram Data Repository we also have a review process, there to ensure that data is computable at an appropriate level.

One day there’ll surely be “first-run” computational journals, where new results are routinely reported through computational essays. But even before that, we can expect ancillary computational journals, that provide genuine “computation-backed” and “data-backed” publication. There just hasn’t been the technology to make this work properly in the past. Now, with the Wolfram Language, and the new streamlined web publishing of Wolfram Notebooks, everything that’s needed finally exists.

It’s always a sign that something is important when it immediately changes the way one works. And that’s certainly something that’s happened for me with notebook publishing.

I might give a talk where I build up a notebook, say doing a live experiment or a demonstration. And then at the end of the talk, I’ll do something new: I’ll publish the notebook to the cloud (either by pressing the button or using `CloudPublish`). Then I’ll make a QR code of the notebook URL (say using `BarcodeImage`), and show it big on the screen. People in the audience can then hold up their phones to read the QR code—and then just click the URL, and immediately be able to start using my notebook in the Wolfram Cloud on their phones.

I can tell that notebook publishing is getting me to write more, because now I have a convenient way to distribute what I write. I’ll often do computational explorations of one thing or another. And in the past, I’d just store the notebooks I made in my filesystem (and, yes, over 30+ years I’ve built up a huge number). But now it’s incredibly fast to add some text to turn the notebooks into computational essays—that I can immediately publish to the cloud, so anyone can access them.

Sometimes I’ll put a link to the published notebook in a post like this; sometimes I’ll do something like tweet it. But the point is that I now have a very streamlined way to give people direct access to computational work I do, in a form that they can immediately interact with, and build on.

From a technical development point of view, the path to where we are today has been a long and complex one, involving many significant achievements in software engineering. But the result is something conceptually clear and simple, though extremely powerful—that I think is going to enable a major new level of computation-informed communication: a new world of notebook publishing.

*More about Wolfram Notebooks:*

Wolfram Notebooks Overview »

Wolfram Notebooks Interactive Course »

*Today my latest book is published: Adventures of a Computational Explorer.*

*From the preface:*

“You work so hard… but what do you do for fun?” people will ask me. Well, the fact is that I’ve tried to set up my life so that the things I work on are things I find fun. Most of those things are aligned with big initiatives of mine, and with products and companies and scientific theories that I’ve built over decades. But sometimes I work on things that just come up, and that for one reason or another I find interesting and fun.

This book is a collection of pieces I’ve written over the past dozen years on some of these things, and the adventures I’ve had around them. Most of the pieces I wrote in response to some particular situation or event. Their topics are diverse. But it’s remarkable how connected they end up being. And at some level all of them reflect the paradigm for thinking that has defined much of my life.

It all centers around the idea of computation, and the generality of abstraction to which it leads. Whether I’m thinking about science, or technology, or philosophy, or art, the computational paradigm provides both an overall framework and specific facts that inform my thinking. And in a sense this book reflects the breadth of applicability of this computational paradigm.

But I suppose it also reflects something else that I’ve long cultivated in myself: a willingness and an interest in applying my ways of thinking to pretty much any topic. I sometimes imagine that I will have nothing much to add to some particular topic. But it’s remarkable how often the computational paradigm—and my way of thinking about it—ends up providing a new and different insight, or an unexpected way forward.

I often urge people to “keep their thinking apparatus engaged” even when they’re faced with issues that don’t specifically seem to be in their domains of expertise. And I make a point of doing this myself. It helps that the computational paradigm is so broad. But even at a much more specific level I’m continually amazed by how much the things I’ve learned from science or language design or technology development or business actually do end up connecting to the issues that come up.

If there’s one thing that I hope comes through from the pieces in this book it’s how much fun it can be to figure things out, and to dive deep into understanding particular topics and questions. Sometimes there’s a simple, superficial answer. But for me what’s really exciting is the much more serious intellectual exploration that’s involved in giving a proper, foundational answer. I always find it particularly fun when there’s a very practical problem to solve, but to get to a good solution requires an adventure that takes one through deep, and often philosophical, issues.

Inevitably, this book reflects some of my personal journey. When I was young I thought my life would be all about making discoveries in specific areas of science. But what I’ve come to realize—particularly having embraced the computational paradigm—is that the same intellectual thought processes can be applied not just to what one thinks of as science, but to pretty much anything. And for me there’s tremendous satisfaction in seeing how this works out.

]]>How can something that simple produce something that complex? It’s been nearly 40 years since I first saw rule 30—but it still amazes me. Long ago it became my personal all-time favorite science discovery, and over the years it’s changed my whole worldview and led me to all sorts of science, technology, philosophy and more.

But even after all these years, there are still many basic things we don’t know about rule 30. And I’ve decided that it’s now time to do what I can to stimulate the process of finding more of them out. So as of today, I am offering $30,000 in prizes for the answers to three basic questions about rule 30.

The setup for rule 30 is extremely simple. One’s dealing with a sequence of lines of black and white cells. And given a particular line of black and white cells, the colors of the cells on the line below are determined by looking at each cell and its immediate neighbors and then applying the following simple rule:

✕
RulePlot[CellularAutomaton[30]] |

If you start with a single black cell, what will happen? One might assume—as I at first did—that the rule is simple enough that the pattern it produces must somehow be correspondingly simple. But if you actually do the experiment, here’s what you find happens over the first 50 steps:

✕
RulePlot[CellularAutomaton[30], {{1}, 0}, 50, Mesh -> All, ImageSize -> Full] |

But surely, one might think, this must eventually resolve into something much simpler. Yet here’s what happens over the first 300 steps:

And, yes, there’s some regularity over on the left. But many aspects of this pattern look for all practical purposes random. It’s amazing that a rule so simple can produce behavior that’s so complex. But I’ve discovered that in the computational universe of possible programs this kind of thing is common, even ubiquitous. And I’ve built a whole new kind of science—with all sorts of principles—based on this.

And gradually there’s been more and more evidence for these principles. But what specifically can rule 30 tell us? What concretely can we say about how it behaves? Even the most obvious questions turn out to be difficult. And after decades without answers, I’ve decided it’s time to define some specific questions about rule 30, and offer substantial prizes for their solutions.

I did something similar in 2007, putting a prize on a core question about a particular Turing machine. And at least in that case the outcome was excellent. In just a few months, the prize was won—establishing forever what the simplest possible universal Turing machine is, as well as providing strong further evidence for my general Principle of Computational Equivalence.

The Rule 30 Prize Problems again get at a core issue: just how complex really is the behavior of rule 30? Each of the problems asks this in a different, concrete way. Like rule 30 itself, they’re all deceptively simple to state. Yet to solve any of them will be a major achievement—that will help illuminate fundamental principles about the computational universe that go far beyond the specifics of rule 30.

I’ve wondered about every one of the problems for more than 35 years. And all that time I’ve been waiting for the right idea, or the right kind of mathematical or computational thinking, to finally be able to crack even one of them. But now I want to open this process up to the world. And I’m keen to see just what can be achieved, and what methods it will take.

For the Rule 30 Prize Problems, I’m concentrating on a particularly dramatic feature of rule 30: the apparent randomness of its center column of cells. Start from a single black cell, then just look down the sequence of values of this cell—and it seems random:

✕
ArrayPlot[ MapIndexed[If[#2[[2]] != 21, # /. {0 -> 0.2, 1 -> .6}, #] &, CellularAutomaton[30, {{1}, 0}, 20], {2}], Mesh -> All] |

But in what sense is it really random? And can one prove it? Each of the Prize Problems in effect uses a different criterion for randomness, then asks whether the sequence is random according to that criterion.

Here’s the beginning of the center column of rule 30:

✕
ArrayPlot[List@CellularAutomaton[30, {{1}, 0}, {80, {{0}}}], Mesh -> True, ImageSize -> Full] |

It’s easy to see that this doesn’t repeat—it doesn’t become periodic. But this problem is about whether the center column ever becomes periodic, even after an arbitrarily large number of steps. Just by running rule 30, we know the sequence doesn’t become periodic in the first billion steps. But what about ever? To establish that, we need a proof. (Here are the first million and first billion bits in the sequence, by the way, as entries in the Wolfram Data Repository.)

Here’s what one gets if one tallies the number of black and of white cells in successively more steps in the center column of rule 30:

✕
Dataset[{{1, 1, 0, ""}, {10, 7, 3, 2.3333333333333335}, {100, 52, 48, 1.0833333333333333}, {1000, 481, 519, 0.9267822736030829}, {10000, 5032, 4968, 1.0128824476650564}, {100000, 50098, 49902, 1.0039276982886458}, {1000000, 500768, 499232, 1.003076725850907}, {10000000, 5002220, 4997780, 1.0008883944471345}, {100000000, 50009976, 49990024, 1.000399119632349}, {1000000000, 500025038, 499974962, 1.0001001570154626}}] |

The results are certainly close to equal for black vs. white. But what this problem asks is whether the limit of the ratio after an arbitrarily large number of steps is exactly 1.

To find the *n*^{th} cell in the center column, one can always just run rule 30 for *n* steps, computing the values of all the cells in this diamond:

✕
With[{n = 100}, ArrayPlot[ MapIndexed[If[Total[Abs[#2 - n/2 - 1]] <= n/2, #, #/4] &, CellularAutomaton[30, CenterArray[{1}, n + 1], n], {2}]]] |

But if one does this directly, one’s doing *n*^{2} individual cell updates, so the computational effort required goes up like O(*n*^{2}). This problem asks if there’s a shortcut way to compute the value of the *n*^{th} cell, without all this intermediate computation—or, in particular, in less than O(*n*) computational effort.

Rule 30 is a creature of the computational universe: a system found by exploring possible simple programs with the new intellectual framework that the paradigm of computation provides. But the problems I’ve defined about rule 30 have analogs in mathematics that are centuries old.

Consider the digits of π. They’re a little like the center column of rule 30. There’s a definite algorithm for generating them. Yet once generated they seem for all practical purposes random:

✕
N[Pi, 85] |

Just to make the analog a little closer, here are the first few digits of π in base 2:

✕
BaseForm[N[Pi, 25], 2] |

And here are the first few bits in the center column of rule 30:

✕
Row[CellularAutomaton[30, {{1}, 0}, {90, {{0}}}]] |

Just for fun, one can convert these to base 10:

✕
N[FromDigits[{Flatten[CellularAutomaton[30, {{1}, 0}, {500, {0}}]], 0}, 2], 85] |

Of course, the known algorithms for generating the digits of π are considerably more complicated than the simple rule for generating the center column of rule 30. But, OK, so what’s known about the digits of π?

Well, we know they don’t repeat. That was proved in the 1760s when it was shown that π is an irrational number—because the only numbers whose digits repeat are rational numbers. (It was also shown in 1882 that π is transcendental, i.e. that it cannot be expressed in terms of roots of polynomials.)

How about the analog of problem 2? Do we know if in the digit sequence of π different digits occur with equal frequency? By now more than 100 trillion binary digits have been computed—and the measured frequencies of digits are very close (in the first 40 trillion binary digits the ratio of 1s to 0s is about 0.9999998064). But in the limit, are the frequencies exactly the same? People have been wondering about this for several centuries. But so far mathematics hasn’t succeeded in delivering any results.

For rational numbers, digit sequences are periodic, and it’s easy to work out relative frequencies of digits. But for the digit sequences of all other “naturally constructed” numbers, basically there’s nothing known about limiting frequencies of digits. It’s a reasonable guess that actually the digits of π (as well as the center column of rule 30) are “normal”, in the sense that not only every individual digit, but also every block of digits of any given length in the limit occur with equal frequency. And as was noted in the 1930s, it’s perfectly possible to “digit-construct” normal numbers. Champernowne’s number, formed by concatenating the digits of successive integers, is an example (and, yes, this works in any base, and one can also get normal numbers by concatenating values of functions of successive integers):

✕
N[ChampernowneNumber[10], 85] |

But the point is that for “naturally constructed” numbers formed by combinations of standard mathematical functions, there’s simply no example known where any regularity of digits has been found. Of course, it ultimately depends what one means by “regularity”—and at some level the problem devolves into a kind of number-digit analog of the search for extraterrestrial intelligence. But there’s absolutely no proof that one couldn’t, for example, find even some strange combination of square roots that would have a digit sequence with some very obvious regularity.

OK, so what about the analog of problem 3 for the digits of π? Unlike rule 30, where the obvious way to compute elements in the sequence is one step at a time, traditional ways of computing digits of π involve getting better approximations to π as a complete number. With the standard (bizarre-looking) series invented by Ramanujan in 1910 and improved by the Chudnovsky brothers in 1989, the first few terms in the series give the following approximations:

✕
Style[Table[N[(12*\!\( \*UnderoverscriptBox[\(\[Sum]\), \(k = 0\), \(n\)] \*FractionBox[\( \*SuperscriptBox[\((\(-1\))\), \(k\)]*\(\((6*k)\)!\)*\((13591409 + 545140134*k)\)\), \(\(\((3*k)\)!\) \*SuperscriptBox[\((\(k!\))\), \(3\)]* \*SuperscriptBox[\(640320\), \(3*k + 3/2\)]\)]\))^-1, 100], {n, 10}] // Column, 9] |

So how much computational effort is it to find the *n*^{th} digit? The number of terms required in the series is O(*n*). But each term needs to be computed to *n*-digit precision, which requires at least O(*n*) individual digit operations—implying that altogether the computational effort required is more than O(*n*).

Until the 1990s it was assumed that there wasn’t any way to compute the *n*^{th} digit of π without computing all previous ones. But in 1995 Simon Plouffe discovered that actually it’s possible to compute—albeit slightly probabilistically—the *n*^{th} digit without computing earlier ones. And while one might have thought that this would allow the *n*^{th} digit to be obtained with less than O(*n*) computational effort, the fact that one has to do computations at *n*-digit precision means that at least O(*n*) computational effort is still required.

Of the three Rule 30 Prize Problems, this is the one on which the most progress has already been made. Because while it’s not known if the center column in the rule 30 pattern ever becomes periodic, Erica Jen showed in 1986 that no two columns can both become periodic. And in fact, one can also give arguments that a single column plus scattered cells in another column can’t both be periodic.

The proof about a pair of columns uses a special feature of rule 30. Consider the structure of the rule:

✕
RulePlot[CellularAutomaton[30]] |

Normally one would just say that given each triple of cells, the rule determines the color of the center cell below. But for rule 30, one can effectively also run the rule sideways: given the cell to the right and above, one can also uniquely determine the color of the cell to the left. And what this means is that if one is given two adjacent columns, it’s possible to reconstruct the whole pattern to the left:

✕
GraphicsRow[ ArrayPlot[#, PlotRange -> 1, Mesh -> All, PlotRange -> 1, Background -> LightGray, ImageSize -> {Automatic, 80}] & /@ (PadLeft[#, {Length[#], 10}, 10] & /@ Module[{data = {{0, 1}, {1, 1}, {0, 0}, {0, 1}, {1, 1}, {1, 0}, {0, 1}, {1, 10}}}, Flatten[{{data}, Table[Join[ Table[Module[{p, q = data[[n, 1]], r = data[[n, 2]], s = data[[n + 1, 1]] }, p = Mod[-q - r - q r + s, 2]; PrependTo[data[[n]], p]], {n, 1, Length[data] - i}], PrependTo[data[[-#]], 10] & /@ Reverse[Range[i]]], {i, 7}]}, 1]])] |

But if the columns were periodic, it immediately follows that the reconstructed pattern would also have to be periodic. Yet by construction at least the initial condition is definitely not periodic, and hence the columns cannot both be periodic. The same argument works if the columns are not adjacent, and if one doesn’t know every cell in both columns. But there’s no known way to extend the argument to a single column—such as the center column—and thus it doesn’t resolve the first Rule 30 Prize Problem.

OK, so what would be involved in resolving it? Well, if it turns out that the center column is eventually periodic, one could just compute it, and show that. We know it’s not periodic for the first billion steps, but one could at least imagine that there could be a trillion-step transient, after which it’s periodic.

Is that plausible? Well, transients do happen—and theoretically (just like in the classic Turing machine halting problem) they can even be arbitrarily long. Here’s a somewhat funky example—found by a search—of a rule with 4 possible colors (totalistic code 150898). Run it for 200 steps, and the center column looks quite random:

✕
ArrayPlot[ CellularAutomaton[{150898, {4, 1}, 1}, {{1}, 0}, {200, 150 {-1, 1}}], ColorRules -> {0 -> Hue[0.12, 1, 1], 1 -> Hue[0, 0.73, 0.92], 2 -> Hue[0.13, 0.5, 1], 3 -> Hue[0.17, 0, 1]}, PixelConstrained -> 2, Frame -> False] |

After 500 steps, the whole pattern still looks quite random:

✕
ArrayPlot[ CellularAutomaton[{150898, {4, 1}, 1}, {{1}, 0}, {500, 300 {-1, 1}}], ColorRules -> {0 -> Hue[0.12, 1, 1], 1 -> Hue[0, 0.73, 0.92], 2 -> Hue[0.13, 0.5, 1], 3 -> Hue[0.17, 0, 1]}, Frame -> False, ImagePadding -> 0, PlotRangePadding -> 0, PixelConstrained -> 1] |

But if one zooms in around the center column, there’s something surprising: after 251 steps, the center column seems to evolve to a fixed value (or at least it’s fixed for more than a million steps):

✕
Grid[{ArrayPlot[#, Mesh -> True, ColorRules -> {0 -> Hue[0.12, 1, 1], 1 -> Hue[0, 0.73, 0.92], 2 -> Hue[0.13, 0.5, 1], 3 -> Hue[0.17, 0, 1]}, ImageSize -> 38, MeshStyle -> Lighter[GrayLevel[.5, .65], .45]] & /@ Partition[ CellularAutomaton[{150898, {4, 1}, 1}, {{1}, 0}, {1400, {-4, 4}}], 100]}, Spacings -> .35] |

Could some transient like this happen in rule 30? Well, take a look at the rule 30 pattern, now highlighting where the diagonals on the left are periodic:

✕
steps = 500; diagonalsofrule30 = Reverse /@ Transpose[ MapIndexed[RotateLeft[#1, (steps + 1) - #2[[1]]] &, CellularAutomaton[30, {{1}, 0}, steps]]]; diagonaldataofrule30 = Table[With[{split = Split[Partition[Drop[diagonalsofrule30[[k]], 1], 8]], ones = Flatten[ Position[Reverse[Drop[diagonalsofrule30[[k]], 1]], 1]]}, {Length[split[[1]]], split[[1, 1]], If[Length[split] > 1, split[[2, 1]], Length[diagonalsofrule30[[k]]] - Floor[k/2]]}], {k, 1, 2 steps + 1}]; transientdiagonalrule30 = %; transitionpointofrule30 = If[IntegerQ[#[[3]]], #[[3]], If[#[[1]] > 1, 8 #[[1]] + Count[Split[#[[2]] - #[[3]]][[1]], 0] + 1, 0] ] & /@ diagonaldataofrule30; decreasingtransitionpointofrule30 = Append[Min /@ Partition[transitionpointofrule30, 2, 1], 0]; transitioneddiagonalsofrule30 = Table[Join[ Take[diagonalsofrule30[[n]], decreasingtransitionpointofrule30[[n]]] + 2, Drop[diagonalsofrule30[[n]], decreasingtransitionpointofrule30[[n]]]], {n, 1, 2 steps + 1}]; transientdiagonalrule30 = MapIndexed[RotateRight[#1, (steps + 1) - #2[[1]]] &, Transpose[Reverse /@ transitioneddiagonalsofrule30]]; smallertransientdiagonalrule30 = Take[#, {225, 775}] & /@ Take[transientdiagonalrule30, 275]; Framed[ArrayPlot[smallertransientdiagonalrule30, ColorRules -> {0 -> White, 1 -> Gray, 2 -> Hue[0.14, 0.55, 1], 3 -> Hue[0.07, 1, 1]}, PixelConstrained -> 1, Frame -> None, ImagePadding -> 0, ImageMargins -> 0, PlotRangePadding -> 0, PlotRangePadding -> Full ], FrameMargins -> 0, FrameStyle -> GrayLevel[.75]] |

There seems to be a boundary that separates order on the left from disorder on the right. And at least over the first 100,000 or so steps, the boundary seems to move on average about 0.252 steps to the left at each step—with roughly random fluctuations:

✕
data = CloudGet[ CloudObject[ "https://www.wolframcloud.com/obj/bc470188-f629-4497-965d-\ a10fe057e2fd"]]; ListLinePlot[ MapIndexed[{First[#2], -# - .252 First[#2]} &, Module[{m = -1, w}, w = If[First[#] > m, m = First[#], m] & /@ data[[1]]; m = 1; Table[While[w[[m]] < i, m++]; m - i, {i, 100000}]]], Filling -> Axis, AspectRatio -> 1/4, MaxPlotPoints -> 10000, Frame -> True, PlotRangePadding -> 0, AxesOrigin -> {Automatic, 0}, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]]] |

But how do we know that there won’t at some point be a huge fluctuation, that makes the order on the left cross the center column, and perhaps even make the whole pattern periodic? From the data we have so far, it looks unlikely, but I don’t know any way to know for sure.

And it’s certainly the case that there are systems with exceptionally long “transients”. Consider the distribution of primes, and compute `LogIntegral[ n] - PrimePi[n]`:

✕
DiscretePlot[LogIntegral[n] - PrimePi[n], {n, 10000}, Filling -> Axis, Frame -> True, PlotRangePadding -> 0, AspectRatio -> 1/4, Joined -> True, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]]] |

Yes, there are fluctuations. But from this picture it certainly looks as if this difference is always going to be positive. And that’s, for example, what Ramanujan thought. But it turns out it isn’t true. At first the bound for where it would fail was astronomically large (Skewes’s number 10^10^10^964). And although still nobody has found an explicit value of *n* for which the difference is negative, it’s known that before *n* = 10^{317} there must be one (and eventually the difference will be negative at least nearly a millionth of the time).

I strongly suspect that nothing like this happens with the center column of rule 30. But until we have a proof that it can’t, who knows?

One might think, by the way, that while one might be able to prove periodicity by exposing regularity in the center column of rule 30, nothing like that would be possible for non-periodicity. But actually, there are patterns whose center columns one can readily see are non-periodic, even though they’re very regular. The main class of examples are nested patterns. Here’s a very simple example, from rule 161—in which the center column has white cells when *n* = 2^{k}:

✕
GraphicsRow[ ArrayPlot[CellularAutomaton[161, {{1}, 0}, #]] & /@ {40, 200}] |

Here’s a slightly more elaborate example (from the 2-neighbor 2-color rule 69540422), in which the center column is a Thue–Morse sequence `ThueMorse[ n]`:

✕
GraphicsRow[ ArrayPlot[ CellularAutomaton[{69540422, 2, 2}, {{1}, 0}, {#, {-#, #}}]] & /@ {40, 400}] |

One can think of the Thue–Morse sequence as being generated by successively applying the substitutions:

✕
RulePlot[SubstitutionSystem[{0 -> {0, 1}, 1 -> {1, 0}}], Appearance -> "Arrow"] |

And it turns out that the *n*^{th} term in this sequence is given by `Mod[DigitCount[ n, 2, 1], 2]`—which is never periodic.

Will it turn out that the center column of rule 30 can be generated by a substitution system? Again, I’d be amazed (although there are seemingly natural examples where very complex substitution systems do appear). But once again, until one has a proof, who knows?

Here’s something else, that may be confusing, or may be helpful. The Rule 30 Prize Problems all concern rule 30 running in an infinite array of cells. But what if one considers just *n* cells, say with the periodic boundary conditions (i.e. taking the right neighbor of the rightmost cell to be the leftmost cell, and vice versa)? There are 2^{n} possible total states of the system—and one can draw a state transition diagram that shows which state evolves to which other. Here’s the diagram for *n* = 5:

✕
Graph[# -> CellularAutomaton[30][#] & /@ Tuples[{1, 0}, 4], VertexLabels -> ((# -> ArrayPlot[{#}, ImageSize -> 30, Mesh -> True]) & /@ Tuples[{1, 0}, 4])] |

And here it is for *n* = 4 through *n* = 11:

✕
Row[Table[ Framed[Graph[# -> CellularAutomaton[30][#] & /@ Tuples[{1, 0}, n]]], {n, 4, 11}]] |

The structure is that there are a bunch of states that appear only as transients, together with other states that are on cycles. Inevitably, no cycle can be longer than 2^{n} (actually, symmetry considerations show that it always has to be somewhat less than this).

OK, so on a size-*n* array, rule 30 always has to show behavior that becomes periodic with a period that’s less than 2^{n}. Here are the actual periods starting from a single black cell initial condition, plotted on a log scale:

✕
ListLogPlot[ Normal[Values[ ResourceData[ "Repetition Periods for Elementary Cellular Automata"][ Select[#Rule == 30 &]][All, "RepetitionPeriods"]]], Joined -> True, Filling -> Bottom, Mesh -> All, MeshStyle -> PointSize[.008], AspectRatio -> 1/3, Frame -> True, PlotRange -> {{47, 2}, {0, 10^10}}, PlotRangePadding -> .1, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]]] |

And at least for these values of *n*, a decent fit is that the period is about 2^{0.63 n}. And, yes, at least in all these cases, the period of the center column is equal to the period of the whole evolution. But what do these finite-size results imply about the infinite-size case? I, at least, don’t immediately see.

Here’s a plot of the running excess of 1s over 0s in 10,000 steps of the center column of rule 30:

✕
ListLinePlot[ Accumulate[2 CellularAutomaton[30, {{1}, 0}, {10^4 - 1, {{0}}}] - 1], AspectRatio -> 1/4, Frame -> True, PlotRangePadding -> 0, AxesOrigin -> {Automatic, 0}, Filling -> Axis, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]]] |

Here it is for a million steps:

✕
ListLinePlot[ Accumulate[ 2 ResourceData[ "A Million Bits of the Center Column of the Rule 30 Cellular Automaton"] - 1], Filling -> Axis, Frame -> True, PlotRangePadding -> 0, AspectRatio -> 1/4, MaxPlotPoints -> 1000, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]]] |

And a billion steps:

✕
data=Flatten[IntegerDigits[#,2,8]&/@Normal[ResourceData["A Billion Bits of the Center Column of the Rule 30 Cellular Automaton"]]]; data=Accumulate[2 data-1]; sdata=Downsample[data,10^5]; ListLinePlot[Transpose[{Range[10000] 10^5,sdata}],Filling->Axis,Frame->True,PlotRangePadding->0,AspectRatio->1/4,MaxPlotPoints->1000,PlotStyle->Hue[0.07`,1,1],FillingStyle->Directive[Opacity[0.35`],Hue[0.12`,1,1]]] |

We can see that there are times when there’s an excess of 1s over 0s, and vice versa, though, yes, as we approach a billion steps 1 seems to be winning over 0, at least for now.

But let’s compute the ratio of the total number of 1s to the total number 0f 0s. Here’s what we get after 10,000 steps:

✕
Quiet[ListLinePlot[ MapIndexed[#/(First[#2] - #) &, Accumulate[CellularAutomaton[30, {{1}, 0}, {10^4 - 1, {{0}}}]]], AspectRatio -> 1/4, Filling -> Axis, AxesOrigin -> {Automatic, 1}, Frame -> True, PlotRangePadding -> 0, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]], PlotRange -> {Automatic, {.88, 1.04}}]] |

Is this approaching the value 1? It’s hard to tell. Go on a little longer, and this is what we see:

✕
Quiet[ListLinePlot[ MapIndexed[#/(First[#2] - #) &, Accumulate[CellularAutomaton[30, {{1}, 0}, {10^5 - 1, {{0}}}]]], AspectRatio -> 1/4, Filling -> Axis, AxesOrigin -> {Automatic, 1}, Frame -> True, PlotRangePadding -> 0, PlotStyle -> Hue[0.07`, 1, 1], FillingStyle -> Directive[Opacity[0.35`], Hue[0.12`, 1, 1]], PlotRange -> {Automatic, {.985, 1.038}}]] |

The scale is getting smaller, but it’s still hard to tell what will happen. Plotting the difference from 1 on a log-log plot up to a billion steps suggests it’s fairly systematically getting smaller:

✕
accdata=Accumulate[Flatten[IntegerDigits[#,2,8]&/@Normal[ResourceData["A Billion Bits of the Center Column of the Rule 30 Cellular Automaton"]]]]; diffratio=FunctionCompile[Function[Typed[arg,TypeSpecifier["PackedArray"]["MachineInteger",1]],MapIndexed[Abs[N[#]/(First[#2]-N[#])-1.]&,arg]]]; data=diffratio[accdata]; ListLogLogPlot[Join[Transpose[{Range[3,10^5],data[[3;;10^5]]}],Transpose[{Range[10^5+1000,10^9,1000],data[[10^5+1000;;10^9;;1000]]}]],Joined->True,AspectRatio->1/4,Frame->True,Filling->Axis,PlotRangePadding->0,PlotStyle->Hue[0.07`,1,1],FillingStyle->Directive[Opacity[0.35`],Hue[0.12`,1,1]]] |

But how do we know this trend will continue? Right now, we don’t. And, actually, things could get quite pathological. Maybe the fluctuations in 1s vs. 0s grow, so even though we’re averaging over longer and longer sequences, the overall ratio will never converge to a definite value.

Again, I doubt this is going to happen in the center column of rule 30. But without a proof, we don’t know for sure.

We’re asking here about the frequencies of black and white cells. But an obvious—and potentially illuminating—generalization is to ask instead about the frequencies for blocks of cells of length *k*. We can ask if all 2^{k} such blocks have equal limiting frequency. Or we can ask the more basic question of whether all the blocks even ever occur—or, in other words, whether if one goes far enough, the center column of rule 30 will contain any given sequence of length *k* (say a bitwise representation of some work of literature).

Again, we can get empirical evidence. For example, at least up to *k* = 22, all 2^{k} sequences do occur—and here’s how many steps it takes:

✕
ListLogPlot[{3, 7, 13, 63, 116, 417, 1223, 1584, 2864, 5640, 23653, 42749, 78553, 143591, 377556, 720327, 1569318, 3367130, 7309616, 14383312, 32139368, 58671803}, Joined -> True, AspectRatio -> 1/4, Frame -> True, Mesh -> True, MeshStyle -> Directive[{Hue[0.07, 0.9500000000000001, 0.99], PointSize[.01]}], PlotTheme -> "Detailed", PlotStyle -> Directive[{Thickness[.004], Hue[0.1, 1, 0.99]}]] |

It’s worth noticing that one can succeed perfectly for blocks of one length, but then fail for larger blocks. For example, the Thue–Morse sequence mentioned above has exactly equal frequencies of 0 and 1, but pairs don’t occur with equal frequencies, and triples of identical elements simply never occur.

In traditional mathematics—and particularly dynamical systems theory—one approach to take is to consider not just evolution from a single-cell initial condition, but evolution from all possible initial conditions. And in this case it’s straightforward to show that, yes, if one evolves with equal probability from all possible initial conditions, then columns of cells generated by rule 30 will indeed contain every block with equal frequency. But if one asks the same thing for different distributions of initial conditions, one gets different results, and it’s not clear what the implication of this kind of analysis is for the specific case of a single-cell initial condition.

If different blocks occurred with different frequencies in the center column of rule 30, then that would immediately show that the center column is “not random”, or in other words that it has statistical regularities that could be used to at least statistically predict it. Of course, at some level the center column is completely “predictable”: you just have to run rule 30 to find it. But the question is whether, given just the values in the center column on their own, there’s a way to predict or compress them, say with much less computational effort than generating an arbitrary number of steps in the whole rule 30 pattern.

One could imagine running various data compression or statistical analysis algorithms, and asking whether they would succeed in finding regularities in the sequence. And particularly when one starts thinking about the overall computational capabilities of rule 30, it’s conceivable that one could prove something about how across a spectrum of possible analysis algorithms, there’s a limit to how much they could “reduce” the computation associated with the evolution of rule 30. But even given this, it’d likely still be a major challenge to say anything about the specific case of relative frequencies of black and white cells.

It’s perhaps worth mentioning one additional mathematical analog. Consider treating the values in a row of the rule 30 pattern as digits in a real number, say with the first digit of the fractional part being on the center column. Now, so far as we know, the evolution of rule 30 has no relation to any standard operations (like multiplication or taking powers) that one does on real numbers. But we can still ask about the sequence of numbers formed by looking at the right-hand side of the rule 30 pattern. Here’s a plot for the first 200 steps:

✕
ListLinePlot[ FromDigits[{#, 0}, 2] & /@ CellularAutomaton[30, {{1}, 0}, {200, {0, 200}}], Mesh -> All, AspectRatio -> 1/4, Frame -> True, MeshStyle -> Directive[{Hue[0.07, 0.9500000000000001, 0.99], PointSize[.0085]}], PlotTheme -> "Detailed", PlotStyle -> Directive[{ Hue[0.1, 1, 0.99]}], ImageSize -> 575] |

And here’s a histogram of the values reached at successively more steps:

✕
Grid[{Table[ Histogram[ FromDigits[{#, 0}, 2] & /@ CellularAutomaton[30, {{1}, 0}, {10^n, {0, 20}}], {.01}, Frame -> True, FrameTicks -> {{None, None}, {{{0, "0"}, .2, .4, .6, .8, {1, "1"}}, None}}, PlotLabel -> (StringTemplate["`` steps"][10^n]), ChartStyle -> Directive[Opacity[.5], Hue[0.09, 1, 1]], ImageSize -> 208, PlotRangePadding -> {{0, 0}, {0, Scaled[.06]}}], {n, 4, 6}]}, Spacings -> .2] |

And, yes, it’s consistent with the limiting histogram being flat, or in other words, with these numbers being uniformly distributed in the interval 0 to 1.

Well, it turns out that in the early 1900s there were a bunch of mathematical results established about this kind of equidistribution. In particular, it’s known that `FractionalPart[ h n]` for successive

Consider the pattern made by rule 150:

✕
Row[{ArrayPlot[CellularAutomaton[150, {{1}, 0}, 30], Mesh -> All, ImageSize -> 315], ArrayPlot[CellularAutomaton[150, {{1}, 0}, 200], ImageSize -> 300]}] |

It’s a very regular, nested pattern. Its center column happens to be trivial (all cells are black). But if we look one column to the left or right, we find:

✕
ArrayPlot[{Table[Mod[IntegerExponent[t, 2], 2], {t, 80}]}, Mesh -> All, ImageSize -> Full] |

How do we work out the value of the *n*^{th} cell? Well, in this particular case, it turns out there’s essentially just a simple formula: the value is given by `Mod[IntegerExponent[ n, 2], 2]`. In other words, just look at the number

How much computational effort does it take to “evaluate this formula”? Well, even if we have to check every bit in *n*, there are only about `Log[2, n]` of those. So we can expect that the computational effort is O(log

But what about the rule 30 case? We know we can work out the value of the *n*^{th} cell in the center column just by explicitly applying the rule 30 update rule *n*^{2} times. But the question is whether there’s a way to reduce the computational work that’s needed. In the past, there’s tended to be an implicit assumption throughout the mathematical sciences that if one has the right model for something, then by just being clever enough one will always find a way to make predictions—or in other words, to work out what a system will do, using a lot less computational effort than the actual evolution of the system requires.

And, yes, there are plenty of examples of “exact solutions” (think 2-body problem, 2D Ising model, etc.) where we essentially just get a formula for what a system will do. But there are also other cases (think 3-body problem, 3D Ising model, etc.) where this has never successfully been done.

And as I first discussed in the early 1980s, I suspect that there are actually many systems (including these) that are computationally irreducible, in the sense that there’s no way to significantly reduce the amount of computational work needed to determine their behavior.

So in effect Problem 3 is asking about the computational irreducibility of rule 30—or at least a specific aspect of it. (The choice of O(*n*) computational effort is somewhat arbitrary; another version of this problem could ask for O(*n*^{α}) for any α<2, or, for that matter, O(log^{ β}(*n*))—or some criterion based on both time and memory resources.)

If the answer to Problem 3 is negative, then the obvious way to show this would just be to give an explicit program that successfully computes the *n*^{th} value in the center column with less than O(*n*) computational effort, as we did for rule 150 above.

We can ask what O(*n*) computational effort means. What kind of system are we supposed to use to do the computation? And how do we measure “computational effort”? The phenomenon of computational universality implies that—within some basic constraints—it ultimately doesn’t matter.

For definiteness we could say that we always want to do the computation on a Turing machine. And for example we can say that we’ll feed the digits of the number *n* in as the initial state of the Turing machine tape, then expect the Turing machine to grind for much less than *n* steps before generating the answer (and, if it’s really to be “formula like”, more like O(log *n*) steps).

We don’t need to base things on a Turing machine, of course. We could use any kind of system capable of universal computation, including a cellular automaton, and, for that matter, the whole Wolfram Language. It gets a little harder to measure “computational effort” in these systems. Presumably in a cellular automaton we’d want to count the total number of cell updates done. And in the Wolfram Language we might end up just actually measuring CPU time for executing whatever program we’ve set up.

I strongly suspect that rule 30 is computationally irreducible, and that Problem 3 has an affirmative answer. But if isn’t, my guess is that eventually there’ll turn out to be a program that rather obviously computes the *n*^{th} value in less than O(*n*) computational effort, and there won’t be a lot of argument about the details of whether the computational resources are counted correctly.

But proving that no such program exists is a much more difficult proposition. And even though I suspect computational irreducibility is quite ubiquitous, it’s always very hard to prove explicit lower bounds on the difficulty of doing particular computations. And in fact almost all explicit lower bounds currently known are quite weak, and essentially boil down just to arguments about information content—like that you need O(log *n*) steps to even read all the digits in the value of *n*.

Undoubtedly the most famous lower-bound problem is the P vs. NP question. I don’t think there’s a direct relation to our rule 30 problem (which is more like a P vs. LOGTIME question), but it’s perhaps worth understanding how things are connected. The basic point is that the forward evolution of a cellular automaton, say for *n* steps from an initial condition with *n* cells specified, is at most an O(*n*^{2}) computation, and is therefore in P (“polynomial time”). But the question of whether there exists an initial condition that evolves to produce some particular final result is in NP. If you happen (“non-deterministically”) to pick the correct initial condition, then it’s polynomial time to check that it’s correct. But there are potentially 2^{n} possible initial conditions to check.

Of course there are plenty of cellular automata where you don’t have to check all these 2^{n} initial conditions, and a polynomial-time computation clearly suffices. But it’s possible to construct a cellular automaton where finding the initial condition is an NP-complete problem, or in other words, where it’s possible to encode any problem in NP in this particular cellular automaton inversion problem. Is the rule 30 inversion problem NP-complete? We don’t know, though it seems conceivable that it could be proved to be (and if one did prove it then rule 30 could finally be a provably NP-complete cryptosystem).

But there doesn’t seem to be a direct connection between the inversion problem for rule 30, and the problem of predicting the center column. Still, there’s at least a more direct connection to another global question: whether rule 30 is computation universal, or, in other words, whether there exist initial conditions for rule 30 that allow it to be “programmed” to perform any computation that, for example, any Turing machine can perform.

We know that among the 256 simplest cellular automata, rule 110 is universal (as are three other rules that are simple transformations of it). But looking at a typical example of rule 110 evolution, it’s already clear that there are definite, modular structures one can identify. And indeed the proof proceeds by showing how one can “engineer” a known universal system out of rule 110 by appropriately assembling these structures.

✕
SeedRandom[23542345]; ArrayPlot[ CellularAutomaton[110, RandomInteger[1, 600], 400], PixelConstrained -> 1] |

Rule 30, however, shows no such obvious modularity—so it doesn’t seem plausible that one can establish universality in the “engineering” way it’s been established for all other known-to-be-universal systems. Still, my Principle of Computational Equivalence strongly suggests that rule 30 is indeed universal; we just don’t yet have an obvious direction to take in trying to prove it.

If one can show that a system is universal, however, then this does have implications that are closer to our rule 30 problem. In particular, if a system is universal, then there’ll be questions (like the halting problem) about its infinite-time behavior that will be undecidable, and which no guaranteed-finite-time computation can answer. But as such, universality is a statement about the existence of initial conditions that reproduce a given computation. It doesn’t say anything about the specifics of a particular initial condition—or about how long it will take to compute a particular result.

OK, but what about a different direction: what about getting empirical evidence about our Problem 3? Is there a way to use statistics, or cryptanalysis, or mathematics, or machine learning to even slightly reduce the computational effort needed to compute the *n*^{th} value in the center column?

Well, we know that the whole 2D pattern of rule 30 is far from random. In fact, of all 2^{m2} patches, only *m* × *m* can possibly occur—and in practice the number weighted by probability is much smaller. And I don’t doubt that facts like this can be used to reduce the effort to compute the center column to less than O(*n*^{2}) effort (and that would be a nice partial result). But can it be less than O(*n*) effort? That’s a much more difficult question.

Clearly if Problem 1 was answered in the negative then it could be. But in a sense asking for less than O(*n*) computation of the center column is precisely like asking whether there are “predictable regularities” in it. Of course, even if one could find small-scale statistical regularities in the sequence (as answering Problem 2 in the negative would imply), these wouldn’t on their own give one a way to do more than perhaps slightly improve a constant multiplier in the speed of computing the sequence.

Could there be some systematically reduced way to compute the sequence using a neural net—which is essentially a collection of nested real-number functions? I’ve tried to find such a neural net using our current deep-learning technology—and haven’t been able to get anywhere at all.

What about statistical methods? If we could find statistical non-randomness in the sequence, then that would imply an ability to compress the sequence, and thus some redundancy or predictability in the sequence. But I’ve tried all sorts of statistical randomness tests on the center column of rule 30—and never found any significant deviation from randomness. (And for many years—until we found a slightly more efficient rule—we used sequences from finite-size rule 30 systems as our source of random numbers in the Wolfram Language, and no legitimate “it’s not random!” bugs ever showed up.)

Statistical tests of randomness typically work by saying, “Take the supposedly random sequence and process it in some way, then see if the result is obviously non-random”. But what kind of processing should be done? One might see if blocks occur with equal frequency, or if correlations exist, or if some compression algorithm succeeds in doing compression. But typically batteries of tests end up seeming a bit haphazard and arbitrary. In principle one can imagine enumerating all possible tests—by enumerating all possible programs that can be applied to the sequence. But I’ve tried doing this, for example for classes of cellular automaton rules—and have never managed to detect any non-randomness in the rule 30 sequence.

So how about using ideas from mathematics to predict the rule 30 sequence? Well, as such, rule 30 doesn’t seem connected to any well-developed area of math. But of course it’s conceivable that some mapping could be found between rule 30 and ideas, say, in an area like number theory—and that these could either help in finding a shortcut for computing rule 30, or could show that computing it is equivalent to some problem like integer factoring that’s thought to be fundamentally difficult.

I know a few examples of interesting interplays between traditional mathematical structures and cellular automata. For example, consider the digits of successive powers of 3 in base 2 and in base 6:

✕
Row[Riffle[ ArrayPlot[#, ImageSize -> {Automatic, 275}] & /@ {Table[ IntegerDigits[3^t, 2, 159], {t, 100}], Table[IntegerDigits[3^t, 6, 62], {t, 100}]}, Spacer[10]]] |

It turns out that in the base 6 case, the rule for generating the pattern is exactly a cellular automaton. (For base 2, there are additional long-range carries.) But although both these patterns look complex, it turns out that their mathematical structure lets us speed up making certain predictions about them.

Consider the *s*^{th} digit from the right-hand edge of line *n* in each pattern. It’s just the *s*^{th} digit in 3^{n}, which is given by the “formula” (where *b* is the base, here 2 or 6) `Mod[Quotient[3 ^{n}, b^{s}], b]`. But how easy is it to evaluate this formula? One might think that to compute 3

Talking of mathematical structure, it’s worth mentioning that there are more formula-like ways to state the basic rule for rule 30. For example, taking the values of three adjacent cells to be *p*, *q*, *r* the basic rule is just ` p ⊻ (q ∨ r)` or

To work out *n* steps in the evolution of rule 30, one’s effectively got to repeatedly compose the basic rule. And so far as one can tell, the symbolic expressions that arise just get more and more complicated—and don’t show any sign of simplifying in such a way as to save computational work.

In Problem 3, we’re talking about the computational effort to compute the *n*^{th} value in the center column of rule 30—and asking if it can be less than O(*n*). But imagine that we have a definite algorithm for doing the computation. For any given *n*, we can see what computational resources it uses. Say the result is *r*[*n*]. Then what we’re asking is whether *r*[*n*] is less than “big O” of *n*, or whether `MaxLimit[ r[n]/n, n → ∞]<∞`.

But imagine that we have a particular Turing machine (or some other computational system) that’s implementing our algorithm. It could be that *r*[*n*] will at least asymptotically just be a smooth or otherwise regular function of *n* for which it’s easy to see what the limit is. But if one just starts enumerating Turing machines, one encounters examples where *r*[*n*] appears to have peaks of random heights in random places. It might even be that somewhere there’d be a value of *n* for which the Turing machine doesn’t halt (or whatever) at all, so that *r*[*n*] is infinite. And in general, as we’ll discuss in more detail later, it could even be undecidable just how *r*[*n*] grows relative to O(*n*).

So far, I’ve mostly described the Prize Problems in words. But we can also describe them in computational language (or effectively also in math).

In the Wolfram Language, the first *t* values in the center column of rule 30 are given by:

✕
c[t_] := CellularAutomaton[30, {{1}, 0}, {t, {{0}}}] |

And with this definition, the three problems can be stated as predicates about *c*[*t*].

✕
\!\( \*SubscriptBox[\(\[NotExists]\), \({p, i}\)]\( \*SubscriptBox[\(\[ForAll]\), \(t, t > i\)]c[t + p] == c[t]\)\) |

or

✕
NotExists[{p, i}, ForAll[t, t > i, c[t + p] == c[t]]] |

or “there does not exist a period *p* and an initial length *i* such that for all *t* with *t*>*i*, *c*[*t* + *p*] equals *c*[*t*]”.

✕
\!\(\*UnderscriptBox[\(\[Limit]\), \(t\* UnderscriptBox["\[Rule]", TemplateBox[{}, "Integers"]]\[Infinity]\)]\) Total[c[t]]/t == 1/2 |

or

✕
DiscreteLimit[Total[c[t]]/t, t -> Infinity] == 1/2 |

or “the discrete limit of the total of the values in *c*[*t*]/*t* as *t* → ∞ is 1/2”.

Define `machine[ m]` to be a machine parametrized by

✕
\!\( \*SubscriptBox[\(\[NotExists]\), \(m\)]\(( \*SubscriptBox[\(\[ForAll]\), \(n\)]\(\(machine[m]\)[n]\)[[1]] == Last[c[n]]\ \[And] \ \*UnderscriptBox[\(\[MaxLimit]\), \(n -> \[Infinity]\)] \*FractionBox[\(\(\(machine[m]\)[n]\)[[ 2]]\), \(n\)] < \[Infinity])\)\) |

or “there does not exist a machine *m* which for all *n* gives *c*[*n*], and for which the lim sup of the amount of computational effort spent, divided by *n*, is finite”. (Yes, one should also require that *m* be finite, so the machine’s rule can’t just store the answer.)

Before we discuss the individual problems, an obvious question to ask is what the interdependence of the problems might be. If the answer to Problem 3 is negative (which I very strongly doubt), then it holds the possibility for simple algorithms or formulas from which the answers to Problems 1 and 2 might become straightforward. If the answer to Problem 3 is affirmative (as I strongly suspect), then it implies that the answer to Problem 1 must also be affirmative. The contrapositive is also true: if the answer to Problem 1 is negative, then it implies that the answer to Problem 3 must also be negative.

If the answer to Problem 1 is negative, so that there is some periodic sequence that appears in the center column, then if one explicitly knows that sequence, one can immediately answer Problem 2. One might think that answering Problem 2 in the negative would imply something about Problem 3. And, yes, unequal probabilities for black and white implies compression by a constant factor in a Shannon-information way. But to compute value with less than O(*n*) resources—and therefore to answer Problem 3 in the negative—requires that one be able to identify in a sense infinitely more compression.

So what does it take to establish the answers to the problems?

If Problem 1 is answered in the negative, then one can imagine explicitly exhibiting the pattern generated by rule 30 at some known step—and being able to see the periodic sequence in the center. Of course, Problem 1 could still be answered in the negative, but less constructively. One might be able to show that eventually the sequence has to be periodic, but not know even any bound on where this might happen. If Problem 3 is answered in the negative, a way to do this is to explicitly give an algorithm (or, say, a Turing machine) that does the computation with less than O(*n*) computational resources.

But let’s say one has such an algorithm. One still has to prove that for all *n*, the algorithm will correctly reproduce the *n*^{th} value. This might be easy. Perhaps there would just be a proof by induction or some such. But it might be arbitrarily hard. For example, it could be that for most *n*, the running time of the algorithm is clearly less than *n*. But it might not be obvious that the running time will always even be finite. Indeed, the “halting problem” for the algorithm might simply be undecidable. But just showing that a particular algorithm doesn’t halt for a given *n* doesn’t really tell one anything about the answer to the problem. For that one would have to show that there’s no algorithm that exists that will successfully halt in less than O(*n*) time.

The mention of undecidability brings up an issue, however: just what axiom system is one supposed to use to answer the problems? For the purposes of the Prize, I’ll just say “the traditional axioms of standard mathematics”, which one can assume are Peano arithmetic and/or the axioms of set theory (with or without the continuum hypothesis).

Could it be that the answers to the problems depend on the choice of axioms—or even that they’re independent of the traditional axioms (in the sense of Gödel’s incompleteness theorem)? Historical experience in mathematics makes this seem extremely unlikely, because, to date, essentially all “natural” problems in mathematics seem to have turned out to be decidable in the (sometimes rather implicit) axiom system that’s used in doing the mathematics.

In the computational universe, though—freed from the bounds of historical math tradition—it’s vastly more common to run into undecidability. And, actually, my guess is that a fair fraction of long-unsolved problems even in traditional mathematics will also turn out to be undecidable. So that definitely raises the possibility that the problems here could be independent of at least some standard axiom systems.

OK, but assume there’s no undecidability around, and one’s not dealing with the few cases in which one can just answer a problem by saying “look at this explicitly constructed thing”. Well, then to answer the problem, we’re going to have to give a proof.

In essence what drives the need for proof is the presence of something infinite. We want to know something for any *n*, even infinitely large, etc. And the only way to handle this is then to represent things symbolically (“the symbol `Infinity` means infinity”, etc.), and apply formal rules to everything, defined by the axioms in the underlying axiom system one’s assuming.

In the best case, one might be able to just explicitly exhibit that series of rule applications—in such a way that a computer can immediately verify that they’re correct. Perhaps the series of rule applications could be found by automated theorem proving (as in `FindEquationalProof`). More likely, it might be constructed using a proof assistant system.

It would certainly be exciting to have a fully formalized proof of the answer to any of the problems. But my guess is that it’ll be vastly easier to construct a standard proof of the kind human mathematicians traditionally do. What is such a proof? Well, it’s basically an argument that will convince other humans that a result is correct.

There isn’t really a precise definition of that. In our step-by-step solutions in Wolfram|Alpha, we’re effectively proving results (say in calculus) in such a way that students can follow them. In an academic math journal, one’s giving proofs that successfully get past the peer review process for the journal.

My own guess would be that if one were to try to formalize essentially any nontrivial proof in the math literature, one would find little corners that require new results, though usually ones that wouldn’t be too hard to get.

How can we handle this in practice for our prizes? In essence, we have to define a computational contract for what constitutes success, and when prize money should be paid out. For a constructive proof, we can get Wolfram Language code that can explicitly be run on any sufficiently large computer to establish the result. For formalized proofs, we can get Wolfram Language code that can run through the proof, validating each step.

But what about for a “human proof”? Ultimately we have no choice but to rely on some kind of human review process. We can ask multiple people to verify the proof. We could have some blockchain-inspired scheme where people “stake” the correctness of the proof, then if one eventually gets consensus (whatever this means) one pays out to people some of the prize money, in proportion to their stake. But whatever is done, it’s going to be an imperfect, “societal” result—like almost all of the pure mathematics that’s so far been done in the world.

OK, so for people interested in working on the Problems, what skills are relevant? I don’t really know. It could be discrete and combinatorial mathematics. It could be number theory, if there’s a correspondence with number-based systems found. It could be some branch of algebraic mathematics, if there’s a correspondence with algebraic systems found. It could be dynamical systems theory. It could be something closer to mathematical logic or theoretical computer science, like the theory of term rewriting systems.

Of course, it could be that no existing towers of knowledge—say in branches of mathematics—will be relevant to the problems, and that to solve them will require building “from the ground up”. And indeed that’s effectively what ended up happening in the solution for my 2,3 Turing Machine Prize in 2007.

I’m a great believer in the power of computer experiments—and of course it’s on the basis of computer experiments that I’ve formulated the Rule 30 Prize Problems. But there are definitely more computer experiments that could be done. So far we know a billion elements in the center column sequence. And so far the sequence doesn’t seem to show any deviation from randomness (at least based on tests I’ve tried). But maybe at a trillion elements (which should be well within range of current computer systems) or a quadrillion elements, or more, it eventually will—and it’s definitely worth doing the computations to check.

The direct way to compute *n* elements in the center column is to run rule 30 for *n* steps, using at an intermediate stage up to *n* cells of memory. The actual computation is quite well optimized in the Wolfram Language. Running on my desktop computer, it takes less than 0.4 seconds to compute 100,000 elements:

✕
CellularAutomaton[30, {{1}, 0}, {100000, {{0}}}]; // Timing |

Internally, this is using the fact that rule 30 can be expressed as `Xor[ p, Or[q, r]]`, and implemented using bitwise operations on whole words of data at a time. Using explicit bitwise operations on long integers takes about twice as long as the built-in

✕
Module[{a = 1}, Table[BitGet[a, a = BitXor[a, BitOr[2 a, 4 a]]; i - 1], {i, 100000}]]; // Timing |

But these results are from single CPU processors. It’s perfectly possible to imagine parallelizing across many CPUs, or using GPUs. One might imagine that one could speed up the computation by effectively caching the results of many steps in rule 30 evolution, but the fact that across the rows of the rule 30 pattern all blocks appear to occur with at least roughly equal frequency makes it seem as though this would not lead to significant speedup.

Solving some types of math-like problems seem pretty certain to require deep knowledge of high-level existing mathematics. For example, it seems quite unlikely that there can be an “elementary” proof of Fermat’s last theorem, or even of the four-color theorem. But for the Rule 30 Prize Problems it’s not clear to me. Each of them might need sophisticated existing mathematics, or they might not. They might be accessible only to people professionally trained in mathematics, or they might be solvable by clever “programming-style” or “puzzle-style” work, without sophisticated mathematics.

Sometimes the best way to solve a specific problem is first to solve a related problem—often a more general one—and then come back to the specific problem. And there are certainly many problems related to the Rule 30 Prize Problems that one can consider.

For example, instead of looking at the vertical column of cells at the center of the rule 30 pattern, one could look at a column of cells in a different direction. At 45°, it’s easy to see that any sequence must be periodic. On the left the periods increase very slowly; on the right they increase rapidly. But what about other angles?

Or what about looking at rows of cells in the pattern? Do all possible blocks occur? How many steps is it before any given block appears? The empirical evidence doesn’t see any deviation from blocks occurring at random, but obviously, for example, successive rows are highly correlated.

What about different initial conditions? There are many dynamical systems–style results about the behavior of rule 30 starting with equal probability from all possible infinite initial conditions. In this case, for example, it’s easy to show that all possible blocks occur with equal frequency, both at a given row, and in a given vertical column. Things get more complicated if one asks for initial conditions that correspond, for example, to all possible sequences generated by a given finite state machine, and one could imagine that from a sequence of results about different sets of possible initial conditions, one would eventually be able to say something about the case of the single black cell initial condition.

Another straightforward generalization is just to look not at a single black cell initial condition, but at other “special” initial conditions. An infinite periodic initial condition will always give periodic behavior (that’s the same as one gets in a finite-size region with periodic boundary conditions). But one can, for example, study what happens if one puts a “single defect” in the periodic pattern:

✕
GraphicsRow[(ArrayPlot[ CellularAutomaton[30, MapAt[1 - #1 &, Flatten[Table[#1, Round[150/Length[#1]]]], 50], 100]] &) /@ {{1, 0}, {1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 0, 0}, {1, 0, 0, 0, 0, 0, 0}, {1, 1, 1, 0, 0}}] |

One can also ask what happens when one has not just a single black cell, but some longer sequence in the initial conditions. How does the center column change with different initial sequences? Are there finite initial sequences that lead to “simpler” center columns?

Or are there infinite initial conditions generated by other computational systems (say substitution systems) that aren’t periodic, but still give somehow simple rule 30 patterns?

Then one can imagine going “beyond” rule 30. What happens if one adds longer-range “exceptions” to the rules? When do extensions to rule 30 show behavior that can be analyzed in one way or another? And can one then see the effect of removing the “exceptions” in the rule?

Of course, one can consider rules quite different from rule 30 as well—and perhaps hope to develop intuition or methods relevant to rule 30 by looking at other rules. Even among the 256 two-color nearest-neighbor rules, there are others that show complex behavior starting from a simple initial condition:

✕
Row[Riffle[ Labeled[ArrayPlot[CellularAutomaton[#, {{1}, 0}, {150, All}], PixelConstrained -> 1, Frame -> False], Style[Text[StringTemplate["rule ``"][#]], 12], LabelStyle -> Opacity[.5]] & /@ {45, 73}, Spacer[8]]] |

And if one looks at larger numbers of colors and larger neighbors one can find an infinite number of examples. There’s all sorts of behavior that one sees. And, for example, given any particular sequence, one can search for rules that will generate it as their center column. One can also try to classify the center-column sequences that one sees, perhaps identifying a general class “like rule 30” about which global statements can be made.

But let’s discuss the specific Rule 30 Prize Problems. To investigate the possibility of periodicity in rule 30 (as in Problem 1), one could study lots of different rules, looking for examples with very long periods, or very long transients—and try to use these to develop an intuition for how and when these can occur.

To investigate the equal-frequency phenomenon of Problem 2, one can look at different statistical features, and see both in rule 30 and across different rules when it’s possible to detect regularity.

For Problem 3, one can start looking at different levels of computational effort. Can one find the *n*^{th} value with computational effort O(*n*^{γ}) for any γ<2 (I don't know any method to achieve this)? Can one show that one can’t find the *n*^{th} value with less than O(log(*n*)) computational effort? What about with less than O(log(*n*)) available memory? What about for different rules? Periodic and nested patterns are easy to compute quickly. But what other examples can one find?

As I’ve mentioned, a big achievement would be to show computation universality for rule 30. But even if one can’t do it for rule 30, finding additional examples (beyond, for example, rule 110) will help build intuition about what might be going on in rule 30.

Then there’s NP-completeness. Is there a way of setting up some question about the behavior of rule 30 for some family of initial conditions where it’s possible to prove that the question is NP-complete? If this worked, it would be an exciting result for cryptography. And perhaps, again, one can build up intuition by looking at other rules, even ones that are more “purposefully constructed” than rule 30.

When I set up my 2,3 Turing Machine Prize in 2007 I didn’t know if it’d be solved in a month, a year, a decade, a century, or more. As it turned out, it was actually solved in about four months. So what will happen with the Rule 30 Prize Problems? I don’t know. After nearly 40 years, I’d be surprised if any of them could now be solved in a month (but it’d be really exciting if that happened!). And of course some superficially similar problems (like features of the digits of π) have been out there for well over a century.

It’s not clear whether there’s any sophisticated math (or computer science) that exists today that will be helpful in solving the problems. But I’m confident that whatever is built to solve them will provide structure that will be important for solving other problems about the computational universe. And the longer it takes (think Fermat’s last theorem), the larger the amount of useful structure is likely to be built on the way to a solution.

I don’t know if solutions to the problems will be “obviously correct” (it’ll help if they’re constructive, or presented in computable form), or whether there’ll be a long period of verification to go through. I don’t know if proofs will be comparatively short, or outrageously long. I don’t know if the solutions will depend on details of axiom systems (“assuming the continuum hypothesis”, etc.), or if they’ll be robust for any reasonable choices of axioms. I don’t know if the three problems are somehow “comparably difficult”—or if one or two might be solved, with the others holding out for a very long time.

But what I am sure about is that solving any of the problems will be a significant achievement. I’ve picked the problems to be specific, definite and concrete. But the issues of randomness and computational irreducibility that they address are deep and general. And to know the solutions to these problems will provide important evidence and raw material for thinking about these issues wherever they occur.

Of course, having lived now with rule 30 and its implications for nearly 40 years, I will personally be thrilled to know for certain even a little more about its remarkable behavior.

]]>Wolfram|Alpha has been a huge hit with students. Whether in college or high school, Wolfram|Alpha has become a ubiquitous way for students to get answers. But it’s a one-shot process: a student enters the question they want to ask (say in math) and Wolfram|Alpha gives them the (usually richly contextualized) answer. It’s incredibly useful—especially when coupled with its step-by-step solution capabilities.

But what if one doesn’t want just a one-shot answer? What if one wants to build up (or work through) a whole computation? Well, that’s what we created Mathematica and its whole notebook interface to do. And for more than 30 years that’s how countless inventions and discoveries have been made around the world. It’s also how generations of higher-level students have been taught.

But what about students who aren’t ready to use Mathematica yet? What if we could take the power of Mathematica (and what’s now the Wolfram Language), but combine it with the ease of Wolfram|Alpha?

Well, that’s what we’ve done in Wolfram|Alpha Notebook Edition.

It’s built on a huge tower of technology, but what it does is to let any student—without learning any syntax or reading any documentation—immediately build up or work through computations. Just type input the way you would in Wolfram|Alpha. But now you’re not just getting a one-shot answer. Instead, everything is in a Wolfram Notebook, where you can save and use previous results, and build up or work through a whole computation:

Being able to use Wolfram|Alpha-style free-form input is what opens Wolfram|Alpha Notebook Edition up to the full range of students. But it’s the use of the notebook environment that makes it so uniquely valuable for education. Because by being able to work through things in a sequence of steps, students get to really engage with the computations they’re doing.

Try one step. See what happens. Change it if you want. Understand the output. See how it fits into the next step. And then—right there in the notebook—see how all your steps fit together to give your final results. And then save your work in the notebook, to continue—or review what you did—another time.

But notebooks aren’t just for storing computations. They can also contain text and structure. So students can use them not just to do their computations, but also to keep notes, and to explain the computations they’re doing, or the results they get:

And in fact, Wolfram Notebooks enable a whole new kind of student work: computational essays. A computational essay has both text and computation—combined to build up a narrative to which both human and computer contribute.

The process of creating a computational essay is a great way for students to engage with material they’re studying. Computational essays can also provide a great showcase of student achievement, as well as a means of assessing student understanding. And they’re not just something to produce for an assignment: they’re active computable documents that students can keep and use at any time in the future.

But students aren’t the only ones to produce notebooks. In Wolfram|Alpha Notebook Edition, notebooks are also a great medium for teachers to provide material to students. Describe a concept in a notebook, then let students explore by doing their own computations right there in the notebook. Or make a notebook defining an assignment or a test—then let the students fill in their work (and grade it right there in the notebook).

It’s very common to use Wolfram|Alpha Notebook Edition to create visualizations of concepts. Often students will just ask for the visualizations themselves. But teachers can also set up templates for visualizations, and let students fill in their own functions or data to explore for themselves.

Wolfram|Alpha Notebook Edition also supports dynamic interactive visualizations—for example using the Wolfram Language `Manipulate` function. And in Wolfram|Alpha Notebook Edition students (and teachers!) can build all sorts of dynamic visualizations just using natural language:

But what if you want some more sophisticated interactive demonstration, that might be hard to specify? Well, Wolfram|Alpha Notebook Edition has direct access to the Wolfram Demonstrations Project, which contains over 12,000 Demonstrations. You can ask for Demonstrations using natural language, or you can just browse the Demonstrations Project website, select a Demonstration, copy it into your Wolfram|Alpha Notebook Edition notebook, and then immediately use it there:

With Wolfram|Alpha Notebook Edition it’s very easy to create compelling content. The content can involve pure calculations or visualizations. But—using the capabilities of the Wolfram Knowledgebase—it can also involve a vast range of real-world data, whether about countries, chemicals, words or artworks. And you can access it using natural language, and work with it directly in a notebook:

Wolfram|Alpha Notebook Edition is a great tool for students to use on their own computers. But it’s also a great tool for lectures and class demonstrations (as well as for student presentations). Go to File > New > Presenter Notebook, and you’ll get a notebook that’s set up to create a Wolfram|Alpha Notebook Edition slide show:

Click Start Presentation and you can start presenting. But what you’ll have is not just a “PowerPoint-style” slide show. It’s a fully interactive, editable, computable slide show. The `Manipulate` interfaces work. Everything is immediately editable. And you can do computations right there during the presentation, exploring different cases, pulling in different data, and so on.

We invented notebooks more than 30 years ago, and they’ve been widely used in Mathematica ever since. But while in Mathematica (and Wolfram Desktop) notebooks you (by default) specify computations in the precise syntax and semantics of the Wolfram Language, in Wolfram|Alpha Notebook Edition notebooks you instead specify them just using free-form Wolfram|Alpha-style input.

And indeed one of the key technical achievements that’s made Wolfram|Alpha Notebook Edition possible is that we’ve now developed increasingly robust natural-language-to-code technology that’s able to go from the free-form natural language input you type to precise Wolfram Language code that can be used to build up computations:

By default, Wolfram|Alpha Notebook Edition is set up to show you the Wolfram Language code it generates. You don’t need to look at this code (and you can set it to always be hidden). But—satisfyingly for me as a language designer—students seem to find it very easy to read, often actually easier than math. And reading it gives them an extra opportunity to understand what’s going on—and to make sure the computation they’ve specified is actually the one they want.

And there’s a great side effect to the fact that Wolfram|Alpha Notebook Edition generates code: through routinely being exposed to code that represents natural language they’ve entered, students gradually absorb the idea of expressing things in computational language, and the concepts of computational thinking.

If a student wants to change a computation when they’re using Wolfram|Alpha Notebook Edition, they can always edit the free-form input they gave. But they can also directly edit the Wolfram Language that’s been generated, giving them real computational language experience.

A central goal of Wolfram|Alpha Notebook Edition is to be completely “self-service”—so that students at all levels can successfully use it without any outside instruction or assistance. Of course, free-form input is a key part of achieving this. But another part is the Wolfram|Alpha Notebook Edition Predictive Interface—that suggests what to do next based on what students have done.

Enter a computation and you’ll typically see some buttons pop up under the input field:

These buttons will suggest directions to take. Here step-by-step solution generates an enhanced interactive version of Wolfram|Alpha Pro step-by-step functionality—all right in the notebook:

Click related computations and you’ll see suggestions for different computations you might want to do:

It suggests plotting the integrand and the integral:

It also suggests you might like to see a series expansion:

Now notice that underneath the output there’s a bar of suggestions about possible follow-on computations to do on this output. Click, for example, coefficient list to find the list of coefficients:

Now there are new suggestions. Click, for example, total to find the total of the coefficients:

Wolfram|Alpha Notebook Edition has got lots of features to enhance the “math experience”. For example, click the button at the top of the notebook and you’ll get a “math keyboard” that you can use to directly enter math notation:

The Wolfram Language that underlies Wolfram|Alpha Notebook Edition routinely handles the math that’s needed by the world’s top mathematicians. But having all that sophisticated math can sometimes lead to confusions for students. So in Wolfram|Alpha Notebook Edition there are ways to say “keep the math simple”. For example, you can set it to minimize the use of complex numbers:

Wolfram|Alpha Notebook Edition also by default does things like adding constants of integration to indefinite integrals:

By the way, Wolfram|Alpha Notebook Edition by default automatically formats mathematical output in elegant “traditional textbook” form. But it always includes a little button next to each output, so you can toggle between “traditional form”, and standard Wolfram Language form.

It’s quite common in doing math to have a function, and just say “I want to plot that!” But what range should you use? In Mathematica (or the Wolfram Language), you’d have to specify it. But in Wolfram|Alpha Notebook Edition there’s always an automatic range that’s picked:

But since you can see the Wolfram Language code—including the range—it’s easy to change that, and specify whatever range you want.

What if you want to get an interactive control to change the range, or to change a parameter in the function? In Mathematica (or the Wolfram Language) you’d have to write a `Manipulate`. But in Wolfram|Alpha Notebook Edition, you can build a whole interactive interface just using natural language:

And because in Wolfram|Alpha Notebook Edition the `Manipulate` computations are all running directly on your local computer, nothing is being slowed down by network transmission—and so everything moves at full speed. (Also, if you have a long computation, you can just let it keep running on your computer; there’s no timeout like in Wolfram|Alpha on the web.)

One of the important features of Wolfram|Alpha Notebook Edition is that it doesn’t just do one-shot computations; it allows you to do multistep computations that in effect involve a back-and-forth conversation with the computer, in which you routinely refer to previous results:

Often it’s enough to just talk about the most recent result, and say things like “plot it as a function of x”. But it’s also quite common to want to refer back to results earlier in the notebook. One way to do this is to say things like “the result before last”—or to use the `Out[`*n*`]` labels for each result. But another thing that Wolfram|Alpha Notebook Edition allows you to do is to set values of variables, that you can then use throughout your session:

It’s also possible to define functions, all with natural language:

There are lots of complicated design and implementation issues that arise in dealing with multistep computations. For example, if you have a traditional result for an indefinite integral, with a constant of integration, what do you do with the constant when you want to plot the result? (Wolfram|Alpha Notebook Edition consistently handles arbitrary additive constants in plots by effectively setting them to zero.)

It can also be complicated to know what refers to what in the “conversation”. If you say “plot”, are you trying to plot your latest result, or are you asking for an interface to create a completely new plot? If you use a pronoun, as in “plot it”, then it’s potentially more obvious what you mean, and Wolfram|Alpha Notebook Edition has a better chance of being able to use its natural language understanding capabilities to figure it out.

It’s been very satisfying to see how extensively Wolfram|Alpha has been adopted by students. But mostly that adoption has been outside the classroom. Now, with Wolfram|Alpha Notebook Edition, we’ve got a tool that can immediately be put to use in the classroom, across the whole college and precollege spectrum. And I’m excited to see how it can streamline coursework, deepen understanding, enable new concepts to be taught, and effectively provide a course-based personal AI tutor for every student.

Starting today, Wolfram|Alpha Notebook Edition is available on all standard computer platforms (Mac, Windows, Linux). (A cloud version will also be available on the web soon.) Colleges and universities with full Wolfram Technology System site licenses can automatically start using Wolfram|Alpha Notebook Edition today; at schools with other site licenses, it can immediately be added. It’s available to K–12 schools and junior colleges in classroom packs, or as a site license. And, of course, it’s also available to individual teachers, students, hobbyists and others.

(Oh, and if you have Mathematica or Wolfram Desktop, it’ll also be possible in future versions to create “Wolfram|Alpha mode” notebooks that effectively integrate Wolfram|Alpha Notebook Edition capabilities. And in general there’s perfect compatibility among Wolfram|Alpha Notebook Edition, Mathematica, Wolfram Desktop, Wolfram Cloud, Wolfram Programming Lab, etc.—providing a seamless experience for people progressing across education and through professional careers.)

Like Wolfram|Alpha—and the Wolfram Language—Wolfram|Alpha Notebook Edition will continue to grow in capabilities far into the future. But what’s there today is already a remarkable achievement that I think will be transformative in many educational settings.

More than 31 years ago we introduced Mathematica (and what’s now the Wolfram Language). A decade ago we introduced Wolfram|Alpha. Now, today, with the release of Wolfram|Alpha Notebook Edition we’re giving a first taste—in the context of education—of a whole new approach to computing: a full computing environment that’s driven by natural language. It doesn’t supplant Wolfram Language, or Wolfram|Alpha—but it defines a new direction that in time will bring the power of computation to a whole massive new audience.

]]>In May 2017, I got an email from a former high-school teacher of mine named George Rutter: “I have a copy of Dirac’s big book in German (*Die Prinzipien der Quantenmechanik*) that was owned by Alan Turing, and following your book *Idea Makers* it seemed obvious that you were the right person to own this.” He explained that he’d got the book from another (by then deceased) former high-school teacher of mine, Norman Routledge, who I knew had been a friend of Alan Turing’s. George ended, “If you would like the book, I could give it to you the next time you are in England.”

A couple of years passed. But in March 2019 I was indeed in England, and arranged to meet George for breakfast at a small hotel in Oxford. We ate and chatted, and waited for the food to be cleared. Then the book moment arrived. George reached into his briefcase and pulled out a rather unassuming, typical mid-1900s academic volume.

I opened the front of the book, wondering if it might have a “Property of Alan Turing” sticker or something. It didn’t. But what it did have (in addition to an inscription saying “from Alan Turing’s books”) was a colorful four-page note from Norman Routledge to George Rutter, written in 2002.

I had known Norman Routledge when I was a high-school student at Eton in the early 1970s. He was a math teacher, nicknamed “Nutty Norman”. He was charmingly over the top in many ways, and told endless stories about math and other things. He’d also been responsible for the school getting a computer (programmed with paper tape, and the size of a desk)—that was the very first computer I ever used.

At the time, I didn’t know too much about Norman’s background (remember, this was long before the web). I knew he was “Dr. Routledge”. And he often told stories about people in Cambridge. But he never mentioned Alan Turing to me. Of course, Alan Turing wasn’t famous yet (although, as it happens, I’d already heard of him from someone who’d known him at Bletchley Park during the Second World War).

Alan Turing still wasn’t famous in 1981 when I started studying simple programs, albeit in the context of cellular automata rather than Turing machines. But looking through the card catalog at the Caltech library one day, I chanced upon a book called *Alan M. Turing* by Sara Turing, his mother. There was lots of information in the book—among other things, about Turing’s largely unpublished work on biology. But I didn’t learn anything about a connection to Norman Routledge, because the book didn’t mention him (although, as I’ve now found out, Sara Turing did correspond with Norman about the book, and Norman ended up writing a review of it).

A decade later, very curious about Turing and his (then still unpublished) work on biology, I arranged to visit the Turing Archive at King’s College, Cambridge. Soon I’d gone through what they had of Turing’s technical papers, and with some time to spare, I thought I might as well ask to see his personal correspondence too. And flipping through it, I suddenly saw a couple of letters from Alan Turing to Norman Routledge.

By that time, Andrew Hodges’s biography—which did so much to make Turing famous—had appeared, and it confirmed that, yes, Alan Turing and Norman Routledge had indeed been friends, and in fact Turing had been Norman’s PhD advisor. I wanted to ask Norman about Turing, but by then Norman was retired and something of a recluse. Still, when I finished *A New Kind of Science* in 2002 (after my own decade of reclusiveness) I tracked him down and sent him a copy of the book with an inscription describing him as “My last mathematics teacher”. Some correspondence ensued, and in 2005 I was finally in England again, and arranged to meet Norman for a quintessentially English tea at a fancy hotel in London.

We had a lovely chat about many things, including Alan Turing. Norman started by saying that he’d really known Turing mostly socially—and that that was 50 years ago. But still he had plenty to say about him. “He was a loner.” “He giggled a lot.” “He couldn’t really talk to non-mathematicians.” “He was always afraid of upsetting his mother.” “He would go off in the afternoon and run a marathon.” “He wasn’t very ambitious (though ‘one wasn’t’ at King’s in those days).” Eventually the conversation came back to Norman. He said that even though he’d been retired for 16 years, he still contributed items to the *Mathematical Gazette*, in order, he said, “to unload things before I pass to a better place”, where, he added, somewhat impishly, “all mathematical truths will surely be revealed”. When our tea was finished, Norman donned his signature leather jacket and headed for his moped, quite oblivious to the bombings that had so disrupted transportation in London on that particular day.

That was the last time I saw Norman, and he died in 2013. But now, six years later, as I sat at breakfast with George Rutter, here was this note from him, written in 2002 in his characteristically lively handwriting:

I read it quickly at first. It was colorful as always:

I got Alan Turing’s book from his friend & executor Robin Gandy (it was quite usual at King’s for friends to be offered books from a dead man’s library—I selected the collected poems of A. E. Housman from the books of Ivor Ramsay as a suitable memento: he was the Dean & jumped off the chapel [in 1956])…

Later in the note he said:

You ask about where, eventually, the book should go—I would prefer it to go to someone (or some where) wh. wd. appreciate the Turing connection, but really it is up to you.

Stephen Wolfram sent me his impressive book, but I’ve done no more than dip into it…

He ended by congratulating George Rutter for having the courage to move (as it turned out, temporarily) to Australia in his retirement, saying that he’d “toyed with moving to Sri Lanka, for a cheap, lotus-eating existence”, but added “events there mean I was wise not to do so” (presumably referring to the Sri Lankan Civil War).

OK, so here I was with a copy of a book in German written by Paul Dirac, that was at one time owned by Alan Turing. I don’t read German, and I’d had a copy of the same book in English (which was its original language) since the 1970s. Still, as I sat at breakfast, I thought it only proper that I should look through the book page by page. After all, that’s a standard thing one does with antiquarian books.

I have to say that I was struck by the elegance of Dirac’s presentation. The book was published in 1931, yet its clean formalism (and, yes, despite the language barrier, I could read the math) is pretty much as one would write it today. (I don’t want to digress too much about Dirac, but my friend Richard Feynman told me that at least to him, Dirac spoke only monosyllabically. Norman Routledge told me that he had been friends in Cambridge with Dirac’s stepson, who became a graph theorist. Norman quite often visited the Dirac household, and said the “great man” was sometimes in the background, always with lots of mathematical puzzles around. I myself unfortunately never met Dirac, though I’m told that after he finally retired from Cambridge and went to Florida, he lost much of his stiffness and became quite social.)

But back to Turing’s copy of Dirac’s book. On page 9 I started to see underlinings and little marginal notes, all written in light pencil. I kept on flipping pages. After a few chapters, the annotations disappeared. But then, suddenly, tucked into page 127, there was a note:

It was in German, with what looked like fairly typical older German handwriting. And it seemed to have something to do with Lagrangian mechanics. By this point I’d figured out that someone must have had the book before Turing, and this must be a note made by that person.

I kept flipping through the book. No more annotations. And I was thinking I wouldn’t find anything else. But then, on page 231, a bookmark—with a charmingly direct branding message:

Would there be anything more? I continued flipping. Then, near the end of the book, on page 259, in a section on the relativistic theory of electrons, I found this:

I opened the piece of paper:

I recognized it immediately: it’s lambda calculus, with a dash of combinators. But what on Earth was it doing here? Remember, the book is about quantum mechanics. But this is about mathematical logic, or what’s now considered theory of computation. Quintessential Turing stuff. So, I immediately wondered, did Turing write this page?

Even as we were sitting at breakfast, I was looking on the web for samples of Turing’s handwriting. But I couldn’t find many calculational ones, so couldn’t immediately conclude much. And soon I had to go, carefully packing the book away, ready to pursue the mystery of what this page was, and who wrote it.

Before anything else, let’s talk about the book itself. Dirac’s *The Principles of Quantum Mechanics* was published in English in 1930, and very quickly also appeared in German. (The preface by Dirac is dated May 29, 1930; the one from the translator—Werner Bloch—August 15, 1930.) The book was a landmark in the development of quantum mechanics, systematically setting up a clear formalism for doing calculations, and, among other things, explaining Dirac’s prediction of the positron, which would be discovered in 1932.

Why did Alan Turing get the book in German rather than English? I don’t know for sure. But in those days, German was the leading language of science, and we know Alan Turing knew how to read it. (After all, the title of his famous Turing machine paper “On Computable Numbers, with an Application to the Entscheidungsproblem” had a great big German word in it—and within the body of the paper he referred to the rather obscure Gothic characters he used as “German letters”, contrasting them, for example, with Greek letters.)

Did Alan Turing buy the book, or was he given it? I don’t know. On the inside front cover of Turing’s copy of the book is a pencil notation “20/-”, which was standard notation for “20 shillings”, equal to £1. On the right-hand page, there’s an erased “26.9.30”, presumably meaning 26 September, 1930—perhaps the date when the book was first in inventory. Then to the far right, there’s an erased “20-.”, perhaps again the price. (Could this have been a price in Reichsmarks, suggesting the book was sold in Germany? Even though at that time 1 RM was worth roughly 1 shilling, a German price would likely have been written as, for example, “20 RM”.) Finally, on the inside back cover there’s “c 5/-”—maybe the (highly discounted) price for the book used.

Let’s review the basic timeline. Alan Turing was born June 23, 1912 (coincidentally, exactly 76 years before Mathematica 1.0 was released). He went as an undergraduate to King’s College, Cambridge in the fall of 1931. He got his undergraduate degree after the usual three years, in 1934.

In the 1920s and early 1930s, quantum mechanics was hot, and Alan Turing was interested in it. From his archives, we know that in 1932—as soon as it was published—he got John von Neumann’s *Mathematical Foundations of Quantum Mechanics* (in its original German). We also know that in 1935, he asked the Cambridge physicist Ralph Fowler for a possible question to study in quantum mechanics. (Fowler suggested computing the dielectric constant of water—which actually turns out to be a very hard problem, basically requiring full-fledged interacting quantum field theory analysis, and still not completely solved.)

When and how did Turing get his copy of Dirac’s book? Given that there seems to be a used price in the book, Turing presumably bought it used. Who was its first owner? The annotations in the book seem to be concerned primarily with logical structure, noting what should be considered an axiom, what logically depends on what, and so on. What about the note tucked into page 127?

Well, perhaps coincidentally, page 127 isn’t just any page: it’s the page where Dirac talks about the quantum principle of least action, and sets the stage for the Feynman path integral—and basically all modern quantum formalism. But what does the note say? It’s expanding on equation 14, which is an equation for the time evolution of a quantum amplitude. The writer has converted Dirac’s *A* for amplitude into a ρ, possibly reflecting an earlier (fluid-density analogy) German notation. Then the writer attempts an expansion of the action in powers of ℏ (Planck’s constant over 2π, sometimes called Dirac’s constant).

But there doesn’t seem to be a lot to be gleaned from what’s on the page. Hold the page up to the light, though, and there’s a little surprise—a watermark reading “Z f. Physik. Chem. B”:

That’s a short form of *Zeitschrift für physikalische Chemie, Abteilung B*—a German journal of physical chemistry that began publication in 1928. Was the note perhaps written by an editor of the journal? Here’s the masthead of the journal for 1933. Conveniently, the editors are listed with their locations, and one stands out: Born · Cambridge.

That’s Max Born, of the Born interpretation, and many other things in quantum mechanics (and also the grandfather of the singer Olivia Newton-John). So, was this note written by Max Born? Unfortunately it doesn’t seem like it: the handwriting doesn’t match.

OK, so what about the bookmark at page 231? Here are the two sides of it:

The marketing copy is quaint and rather charming. But when is it from? Well, there’s still a Heffers Bookshop in Cambridge, though it’s now part of Blackwell’s. But for more than 70 years (ending in 1970) Heffers was located, as the bookmark indicates, at 3 and 4 Petty Cury.

But there’s an important clue on the bookmark: the phone number is listed as “Tel. 862”. Well, it turns out that in 1939, most of Cambridge (including Heffers) switched to 4-digit numbers, and certainly by 1940 bookmarks were being printed with “modern” phone numbers. (English phone numbers progressively got longer; when I was growing up in England in the 1960s, our phone numbers were “Oxford 56186” and “Kidmore End 2378”. Part of why I remember these numbers is the now-strange-seeming convention of always saying one’s number when answering the phone.)

But, OK, so the bookmark was from before 1939. But how much before? There are quite a few scans of old Heffers ads to be found on the web—and from at least 1912 (along with “We solicit the favour of your enquiries…”) they list “Telephone 862”, helpfully adding “(2 lines)”. And there are even some bookmarks with the same design to be found in copies of books from as long ago as 1904 (though it’s not clear they were original to the books). But for our purposes it seems as if we can reasonably conclude that our book came from Heffers (which was the main bookstore in Cambridge, by the way) sometime between 1930 and 1939.

OK, so we know something about when the book was bought. But what about the “lambda calculus page”? When was it written? Well, of course, lambda calculus had to have been invented. And that was done by Alonzo Church, a mathematician at Princeton, in an initial form in 1932, and in final form in 1935. (There had been precursors, but they hadn’t used the λ notation.)

There’s a complicated interaction between Alan Turing and lambda calculus. It was in 1935 that Turing had gotten interested in “mechanizing” the operations of mathematics, and had invented the idea of a Turing machine, and used it to solve a problem in the foundations of mathematics. Turing had sent a paper about it to a French journal (*Comptes rendus*), but initially it was lost in the mail; and then it turned out the person he’d sent it to wasn’t around anyway, because they’d gone to China.

But in May 1936, before Turing could send his paper anywhere else, Alonzo Church’s paper arrived from the US. Turing had been “scooped” once before, when in 1934 he created a proof of the central limit theorem, only to find that there was a Norwegian mathematician who’d already given a proof in 1922.

It wasn’t too hard to see that Turing machines and lambda calculus were actually equivalent in the kinds of computations they could represent (and that was the beginning of the Church–Turing thesis). But Turing (and his mentor Max Newman) got convinced that Turing’s approach was different enough to deserve separate publication. And so it was that in November 1936 (with a bug fix the following month), Turing’s famous paper “On Computable Numbers…” was published in the *Proceedings of the London Mathematical Society*.

To fill in a little more of the timeline: from September 1936 to July 1938 (with a break of three months in the summer of 1937), Turing was at Princeton, having gone there to be, at least nominally, a graduate student of Alonzo Church. While at Princeton, Turing seems to have concentrated pretty completely on mathematical logic—writing several difficult-to-read papers full of Church’s lambdas—and most likely wouldn’t have had a book about quantum mechanics with him.

Turing was back in Cambridge in July 1938, but already by September of that year he was working part-time for the Government Code and Cypher School—and a year later he moved to Bletchley Park to work full time on cryptanalysis. After the war ended in 1945, Turing moved to London to work at the National Physical Laboratory on producing a design for a computer. He spent the 1947–8 academic year back in Cambridge, but then moved to Manchester to work on building a computer there.

In 1951, he began working in earnest on theoretical biology. (To me it’s an interesting irony that he seems to have always implicitly assumed that biological systems have to be modeled by differential equations, rather than by something discrete like Turing machines or cellular automata.) He also seems to have gotten interested in physics again, and by 1954 even wrote to his friend and student Robin Gandy that “I’ve been trying to invent a new Quantum Mechanics” (though he added, “but it won’t really work”). But all this came to an end on June 7, 1954, when Turing suddenly died. (My own guess is that it was not suicide, but that’s a different story.)

OK, but back to the lambda calculus page. Hold it up to the light, and once again there’s a watermark:

So it’s a British-made piece of paper, which seems, for example, to make it unlikely to have been used in Princeton. But can we date the paper? Well, after some help from the British Association of Paper Historians, we know that the official manufacturer of the paper was Spalding & Hodge, Papermakers, Wholesale and Export Stationers of Drury House, Russell Street off Drury Lane, Covent Garden, London. But this doesn’t help as much as one might think—because their Excelsior brand of machine-made paper seems to have been listed in catalogs all the way from the 1890s to 1954.

OK, so let’s talk in more detail about what’s on the two sides of the page. Let’s start with the lambdas.

These are a way of defining “pure” or “anonymous” functions, and they’re a core concept in mathematical logic, and nowadays also in functional programming. They’re common in the Wolfram Language, and they’re pretty easy to explain there. One writes *f*[*x*] to mean a function *f* applied to an argument *x*. And there are lots of named functions that *f* can be—like `Abs` or `Sin` or `Blur`. But what if one wants *f*[*x*] to be 2*x*+1? There’s no immediate name for that function. But is there still something we can write for *f* that will make *f*[*x*] be this?

The answer is yes: in place of *f* we write `Function[a, 2a+1]`. And in the Wolfram Language, `Function[a, 2a+1][x]` is defined to give `2x+1`. The `Function[a, 2a+1]` is a “pure” or “anonymous” function, that represents the pure operation of doubling and adding 1.

Well, λ in lambda calculus is the exact analog of `Function` in the Wolfram Language—and so for example λ*a*.(2*a*+1) is equivalent to `Function[a, 2a+1]`. (It’s worth noting that `Function[b, 2b+1]` is equivalent; the “bound variable” `a` or `b` is just a placeholder—and in the Wolfram Language it can be avoided by using the alternative notation `(2#+1)&`.)

In traditional mathematics, functions tend to be thought of as things that map inputs (like, say, integers) to outputs (that are also, say, integers). But what kind of a thing is `Function` (or λ)? It’s basically a structural operator that takes expressions and turns them into functions. That’s a bit weird from the point of view of traditional mathematics and mathematical notation. But if one’s thinking about manipulating arbitrary symbols, it’s much more natural, even if at first it still seems a little abstract. (And, yes, when people learn the Wolfram Language, I can always tell they’ve passed a certain threshold of abstract understanding when they get the idea of `Function`.)

OK, but the lambdas are just part of what’s on the page. There’s also another, yet more abstract concept: combinators. See the rather obscure-looking line PI1IIx? What does it mean? Well, it’s a sequence of combinators, or effectively, a kind of abstract composition of symbolic functions.

Ordinary composition of functions is pretty familiar from mathematics. And in Wolfram Language one can write `f[g[x]]` to mean “apply `f` to the result of applying `g` to `x`”. But does one really need the brackets? In the Wolfram Language `f@g@x` is an alternative notation. But in this notation, we’re relying on a convention in the Wolfram Language: that the `@` operator associates to the right, so that `f@g@x` is equivalent to `f@(g@x)`.

But what would `(f@g)@x` mean? It’s equivalent to `f[g][x]`. And if `f` and `g` were ordinary functions in mathematics, this would basically be meaningless. But if `f` is a higher-order function, then `f[g]` can itself be a function, which can perfectly well be applied to `x`.

OK, there’s another piece of complexity here. In `f[x]` the `f` is a function of one argument. And `f[x]` is equivalent to `Function[a, f[a]][x]`. But what about a function of two arguments, say `f[x, y]`? This can be written `Function[{a,b}, f[a, b]][x, y]`. But what about `Function[{a}, f[a, b]]`? What would this be? It’s got a “free variable” `b` just hanging out. `Function[{b}, Function[{a}, f[a, b]]]` would “bind” that variable. And then `Function[{b}, Function[{a}, f[a, b]]][y][x]` gives `f[x, y]` again. (The process of unwinding functions so that they have single arguments is called “currying”, after a logician named Haskell Curry.)

If there are free variables, then there’s all sorts of complexity about how functions can be composed. But if we restrict ourselves to `Function` or λ objects that don’t have free variables, then these can basically be freely composed. And such objects are called combinators.

Combinators have a long history. So far as one knows, they were first invented in 1920 by a student of David Hilbert’s named Moses Schönfinkel. At the time, it had only recently been discovered that one didn’t need `And` and `Or` and `Not` to represent expressions in standard propositional logic: it was sufficient to use the single operator that we’d now call `Nand` (because, for example, writing `Nand` as ·, `Or[a, b]` is just `(a·a)·(b·b)`). Schönfinkel wanted to find the same kind of minimal representation of predicate logic, or in effect, logic including functions.

And what he came up with was the two “combinators” S and K. In Wolfram Language notation, `K[x_][y_] → x` and `S[x_][y_][z_] → x[z][y[z]]`. Now, here’s the remarkable thing: it turns out to be possible to use these two combinators to perform any computation. So, for example, `S[K[S]][S[K[S[K[S]]]][S[K[K]]]]` can be used as a function to add two integers.

It is, to put it mildly, quite abstract stuff. But now that one’s understood Turing machines and lambda calculus, it’s possible to see that Schönfinkel’s combinators actually anticipated the concept of universal computation. (And what’s more remarkable still, the definitions of S and K from 1920 are almost minimally simple, reminiscent of the very simplest universal Turing machine that I finally suggested in the 1990s, and was proved in 2007.)

But back to our page, and the line PI1IIx. The symbols here are combinators, and they’re all intended to be composed. But the convention was that function composition should be left-associative, so that fgx should be interpreted not like `f@g@x` as `f@(g@x)` or `f[g[x]]` but rather like `(f@g)@x` or `f[g][x]`. So, translating a bit for convenient Wolfram Language use, PI1IIx is `p[i][one][i][i][x]`.

Why would someone be writing something like this? To explain that, we have to talk about the concept of Church numerals (named after Alonzo Church). Let’s say we’re just working with symbols and with lambdas, or combinators. Is there a way we use these to represent integers?

Well, how about just saying that a number *n* corresponds to `Function[x, Nest[f, x, `*n*`]]`? Or, in other words, that (in shorter notation) 1 is `f[#]&`, 2 is `f[f[#]]&`, 3 is `f[f[f[#]]]&`, and so on. This might seem irreducibly obscure. But the reason it’s interesting is that it allows us to do everything completely symbolically and abstractly, without ever having to explicitly talk about something like integers.

With this setup, imagine, for example, adding two numbers: 3 can be represented as `f[f[f[#]]]&`, and 2 is `f[f[#]]&`. We can add them just by applying one of them to the other:

✕
f[f[f[#]]] & [f[f[#]] &] |

OK, but what is the `f` supposed to be? Well, just let it be anything! In a sense, “go lambda” all the way, and represent numbers by functions that take `f` as an argument. In other words, make 3 for example be `Function[f, f[f[f[#]]]&]` or `Function[f, Function[x, f[f[f[x]]]]`. (And, yes, exactly when and how you need to name variables is the bane of lambda calculus.)

Here’s a fragment from Turing’s 1937 paper “Computability and λ-Definability” that sets things up exactly as we just discussed:

The notation is a little confusing. Turing’s *x* is our `f`, while his *x*' (the typesetter did him no favor by inserting space) is our `x`. But it’s exactly the same setup.

OK, so let’s take a look at the line right after the fold on the front of the page. It’s I1IIYI1IIx. In Wolfram Language notation this would be `i[one][i][i][y][i][one][i][i][x]`. But here, `i` is the identity function, so `i[one]` is just `one`. Meanwhile, `one` is the Church numeral for 1, or `Function[f, f[#]&]`. But with this definition `one[a]` becomes `a[#]&` and `one[a][b]` becomes `a[b]`. (By the way, `i[a][b]`, or `Identity[a][b]`, is also `a[b]`.)

It keeps things cleaner to write the rules for `i` and `one` using pattern matching rather than explicit lambdas, but the result is the same. Apply these rules and one gets:

✕
i[one][i][i][y][i][one][i][i][x] //. {i[x_] -> x, one[x_][y_] -> x[y]} |

And that’s exactly the same as the first reduction shown:

OK, let’s look higher on the page again now:

There’s a rather confusing “E” and “D”, but underneath these say “P” and “Q”, so we can write out the expression, and evaluate it (note that here—after some confusion with the very last character—the writer makes both [ ... ] and ( … ) represent function application):

✕
Function[a, a[p]][q] |

OK, so this is the first reduction shown. To see more, let’s substitute in the form of Q:

✕
q[p] /. q -> Function[f, f[i][one][i][i][x]] |

We get exactly the next reduction shown. OK, so what about putting in the form for P?

Here’s the result:

✕
p[i][one][i][i][ x] /. {p -> Function[r, r[Function[s, s[one][i][i][y]]]]} |

And now using the fact that `i` is the identity, we get:

✕
i[Function[s, s[one][i][i][y]]][one][i][i][x] /. {i[x_] -> x} |

But oops. This isn’t the next line written. Is there a mistake? It’s not clear. Because, after all, unlike in most of the other cases, there isn’t an arrow indicating that the next line follows from the previous one.

OK, so there’s a mystery there. But let’s skip ahead to the bottom of the page:

The 2 here is a Church numeral, defined for example by the pattern `two[a_][b_] → a[a[b]]`. But notice that this is actually the form of the second line, with `a` being `Function[r, r[p]]` and `b` being `q`. So then we’d expect the reduction to be:

✕
two[Function[r, r[p]]][q] //. {two[x_][y_] -> x[x[y]]} |

Somehow, though, the innermost `a[b]` is being written as x (probably different from the x earlier on the page), making the final result instead:

✕
Function[r, r[p]][x] |

OK, so we can decode quite a bit of what’s happening on the page. But at least one mystery that remains is what Y is supposed to be.

There’s actually a standard “Y combinator” in combinatory logic: the so-called fixed-point combinator. Formally, this is defined by saying that Y[*f*] must be equal to *f*[Y[*f*]], or, in other words, that Y[*f*] doesn’t change when *f* is applied, so that it’s a fixed point of *f*. (The Y combinator is related to `#0` in the Wolfram Language.)

In modern times, the Y combinator has been made famous by the Y Combinator startup accelerator, named that way by Paul Graham (who had been a longtime enthusiast of functional programming and the LISP programming language—and had written an early web store using it) because (as he once told me) “nobody understands the Y combinator”. (Needless to say, Y Combinator is all about avoiding having companies go to fixed points…)

The Y combinator (in the sense of fixed-point combinator) was invented several times. Turing actually came up a version of it in 1937, that he called Θ. But is the “Y” on our page the famous fixed-point combinator? Probably not. So what is our “Y”? We see this reduction:

But that’s not enough information to uniquely determine what Y is. It’s clear Y isn’t operating just on a single argument; it seems to be dealing with at least two arguments. But it’s not clear (at least to me) how many arguments it’s taking, and what it’s doing.

OK, so even though we can interpret many parts of the page, we have to say that globally it’s not clear what’s been done. But even though it’s needed a lot of explanation here, what’s on the page is actually fairly elementary in the world of lambda calculus and combinators. Presumably it’s an attempt to construct a simple “program”—using lambda calculus and combinators—to do something. But as is typical in reverse engineering, it’s hard for us to tell what the “something”— the overall “explainable” goal—is supposed to be.

There’s one more feature of the page that’s worth commenting on, and that’s its use of brackets. In traditional mathematics one basically (if confusingly) uses parentheses for everything—both function application (as in *f*(*x*)) and grouping of terms (as in (1+*x*)(1-*x*), or, more ambiguously, *a*(1-*x*)). (In Wolfram Language, we separate different uses, with square brackets for function application—as in `f[x]`—and parentheses only for grouping.)

And in the early days of lambda calculus, there were lots of issues about brackets. Later, Alan Turing would write a whole (unpublished) paper entitled “The Reform of Mathematical Notation and Phraseology”, but already in 1937 he felt he needed to describe the (rather hacky) current conventions for lambda calculus (which were due to Church, by the way).

He said that *f* applied to *g* should be written {*f*}(*g*), unless *f* is just a single symbol, in which case it can be *f*(*g*). Then he said that a lambda (as in `Function[a, b]`) should be written λ *a*[*b*], or alternatively λ *a* . *b*. By perhaps 1940, however, the whole idea of using { … } and [ ... ] to mean different things had been dropped, basically in favor of standard-mathematical-style parentheses.

Look at what’s near the top of the page:

As written, this is a bit hard to understand. In Church’s convention, the square brackets would be for grouping, with the opening bracket replacing the dot. And with this convention, it’s clear that the Q (finally labeled D) enclosed in parentheses at the end is what the whole initial lambda is applied to. But actually, the square bracket doesn’t delimit the body of the lambda; instead, it’s actually representing another function application, and there’s no explicit specification of where the body of the lambda ends. At the very end, one can see that the writer changed a closing square bracket to a parenthesis, thereby effectively enforcing Church’s convention—and making the expression evaluate as the page shows.

So what does this little notational tangle imply? I think it strongly suggests that the page was written in the 1930s, or not too long thereafter—before conventions for brackets became clearer.

OK, so we’ve talked about what’s on the page. But what about who wrote it?

The most obvious candidate would be Alan Turing, since, after all, the page was inside a book he owned. And in terms of content there doesn’t seem to be anything inconsistent with Alan Turing having written it—perhaps even when he was first understanding lambda calculus after getting Church’s paper in early 1936.

But what about the handwriting? Is that consistent with Alan Turing’s? Here are a few surviving samples that we know were written by Alan Turing:

The running text definitely looks quite different. But what about the notation? At least to my eye, it didn’t look so obviously different—and one might think that any difference could just be a reflection of the fact that the extant samples are pieces of exposition, while our page shows “thinking in action”.

Conveniently, the Turing Archive contains a page where Turing wrote out a table of symbols to use for notation. And comparing this, the letter forms did look to me fairly similar (this was from Turing’s time of studying plant growth, hence the “leaf area” annotation):

But I wanted to check further. So I sent the samples to Sheila Lowe, a professional handwriting examiner (and handwriting-based mystery writer) I happen to know—just presenting our page as “sample A” and known Turing handwriting as “sample B”. Her response was definitive, and negative: “The writing style is entirely different. Personality-wise, the writer of sample B has a quicker, more intuitive thinking style than the one of sample A.” I wasn’t yet completely convinced, but decided it was time to start looking at other alternatives.

So if Turing didn’t write this, who did? Norman Routledge said he got the book from Robin Gandy, who was Turing’s executor. So I sent along a “Sample C”, from Gandy:

But Sheila’s initial conclusion was that the three samples were likely written by three different people, noting again that sample B came from “the quickest thinker and the one that is likely most willing to seek unusual solutions to problems”. (I find it a little charming that a modern handwriting expert would give this assessment of Turing’s handwriting, given how vociferously Turing’s school reports from the 1920s complained about his handwriting.)

Well, at this point it seemed as if both Turing and Gandy had been eliminated as writers of the page. So who might have written it? I started thinking about people Turing might have lent the book to. Of course, they’d have to be capable of doing calculations in lambda calculus.

I assumed that the person would have to be in Cambridge, or at least in England, given the watermark on the paper. And I took as a working hypothesis that 1936 or thereabouts was the relevant time. So who did Turing know then? We got a list of all math students and faculty at King’s College at the time. (There were 13 known students who started in 1930 through 1936.)

And from these, the most promising candidate seemed to be David Champernowne. He was the same age as Turing, a longtime friend, and also interested in the foundations of mathematics—in 1933 already publishing a paper on what’s now called Champernowne’s constant: 0.12345678910111213… (obtained by concatenating the digits of 1, 2, 3, 4, …, 8, 9, 10, 11, 12, …, and one of the very few numbers known to be “normal” in the sense that every possible block of digits occurs with equal frequency). In 1937, he even used Dirac gamma matrices, as mentioned in Dirac’s book, to solve a recreational math problem. (As it happens, years later, I became quite an aficionado of gamma matrix computations.)

After starting in mathematics, though, Champernowne came under the influence of John Maynard Keynes (also at King’s), and eventually became a distinguished economist, notably doing extensive work on income inequality. (Still, in 1948 he also worked with Turing to design Turbochamp: a chess-playing program that almost became the first ever to be implemented on a computer.)

But where could I find a sample of Champernowne’s handwriting? Soon I’d located his son Arthur Champernowne on LinkedIn, who, curiously, had a degree in mathematical logic, and had been working for Microsoft. He said his father had talked to him quite a lot about Turing’s work, though hadn’t mentioned combinators. He sent me a sample of his father’s handwriting (a piece about algorithmic music composition):

One could immediately tell it wasn’t a match (Champernowne’s *f*’s have loops, etc.)

So who else might it be? I wondered about Max Newman, in many ways Alan Turing’s mentor. Newman had first got Turing interested in “mechanizing mathematics”, was a longtime friend, and years later would be his boss at Manchester in the computer project there. (Despite his interest in computation, Newman always seems to have seen himself first and foremost as a topologist, though his cause wasn’t helped by a flawed proof he produced of the Poincaré conjecture.)

It wasn’t difficult to find a sample of Newman’s handwriting. And no, definitely not a match.

OK, so handwriting identification hadn’t worked. And I decided the next thing to do was to try to trace in a bit more detail what had actually happened to the book I had in my hands.

So, first, what was the more detailed story with Norman Routledge? He had gone to King’s College, Cambridge as an undergraduate in 1946, and had gotten to know Turing then (yes, they were both gay). He graduated in 1949, then started doing a PhD with Turing as his advisor. He got his PhD in 1954, working on mathematical logic and recursion theory. He got a fellowship at King’s College, and by 1957 was Director of Studies in Mathematics there. He could have stayed doing this his whole life, but he had broad interests (music, art, architecture, recreational math, genealogy, etc.) and in 1960 changed course, and became a teacher at Eton—where he entertained (and educated) many generations of students (including me) with his eclectic and sometimes outlandish knowledge.

Could Norman Routledge have written the mysterious page? He knew lambda calculus (though, coincidentally, he mentioned at our tea in 2005 that he always found it “confusing”). But his distinctive handwriting style immediately excludes him as a possible writer.

Could the page be somehow associated with a student of Norman’s, perhaps from when he was still in Cambridge? I don’t think so. Because I don’t think Norman ever taught about lambda calculus or anything like it. In writing this piece, I found that Norman wrote a paper in 1955 about doing logic on “electronic computers” (and creating conjunctive normal forms, as `BooleanMinimize` now does). And when I knew Norman he was quite keen on writing utilities for actual computers (his initials were “NAR”, and he named his programs “NAR…”, with, for example, “NARLAB” being a program for creating textual labels using hole patterns punched in paper tape). But he never talked about theoretical models of computation.

OK, but let’s read Norman’s note inside the book a bit more carefully. The first thing we notice is that he talks about being “offered books from a dead man’s library”. And from the wording, it sounds as if this happened quite quickly after a person died, suggesting that Norman got the book soon after Turing’s death in 1954, and that Gandy didn’t have it for very long. Norman goes on to say that actually he got four books in total, two on pure math, and two on theoretical physics.

Then he says that he gave “the other [physics] one (by Herman Weyl, I think)” to “Sebag Montefiore, a pleasant, clever boy whom you [George Rutter] may remember”. OK, so who is that? I searched for my rarely used Old Etonian Association List of Members. (I have to report that on opening it, I could not help but notice its rules from 1902, the first under “Rights of Members” charmingly being “To wear the Colours of the Association”. I should add that I would probably never have joined this association or got this book but for the insistence of a friend of mine at Eton named Nicholas Kermack, who from the age of 12 planned how he would one day become Prime Minister, but sadly died at the age of 21.)

But in any case, there were five Sebag-Montefiores listed, with quite a distribution of dates. It wasn’t hard to figure out that the appropriate one was probably Hugh Sebag-Montefiore. Small world that it is, it turned out that his family had owned Bletchley Park before selling it to the British Government in 1938. And in 2000, Sebag-Montefiore had written a book about the breaking of Enigma—which is presumably why in 2002 Norman thought to give him a book that had been owned by Turing.

OK, so what about the other books Norman got from Turing? Not having any other way to work out what happened to them, I ordered a copy of Norman’s will. The last clause in the will was classic Norman:

But what the will ultimately said was that Norman’s books should be left to King’s College. And although the complete collection of his books doesn’t seem to be anywhere to be found, the two Turing-owned pure math books that he mentioned in his note are now duly in the King’s College archive collection.

But, OK, so the next question is: what happened to Turing’s other books? I looked up Turing’s will, which seemed to leave them all to Robin Gandy.

Gandy was a math undergraduate at King’s College, Cambridge, who in his last year of college—in 1940—had become friends with Alan Turing. In the early part of the war, Gandy worked on radio and radar, but in 1944 he was assigned to the same unit as Turing, working on speech encipherment. And after the war, Gandy went back to Cambridge, soon starting a PhD, with Turing as his advisor.

Gandy’s war work apparently got him interested in physics, and his thesis, completed in 1952, was entitled “On Axiomatic Systems in Mathematics and Theories in Physics”. What Gandy seems to have been trying to do is to characterize what physical theories are in mathematical logic terms. He talks about type theory and rules of inference, but never about Turing machines. And from what we know now, I think he rather missed the point. And indeed my own work from the early 1980s argued that physical processes should be thought of as computations—like Turing machines or cellular automata—not as things like theorems to be deduced. (Gandy has a rather charming discussion of the order of types involved in physical theories, saying for example that “I reckon that the order of any computable binary decimal is less than eight”. He says that “one of the reasons why modern quantum field theory is so difficult is that it deals with objects of rather high type—functionals of functions…”, eventually suggesting that “we might well take the greatest type in common use as an index of mathematical progress”.)

Gandy mentions Turing a few times in the thesis, noting in the introduction that he owes a debt to A. M. Turing, who “first called my somewhat unwilling attention to the system of Church” (i.e. lambda calculus)—though in fact the thesis has very few lambdas in evidence.

After his thesis, Gandy turned to purer mathematical logic, and for more than three decades wrote papers at the rate of about one per year, and traveled the international mathematical logic circuit. In 1969 he moved to Oxford, and I have to believe that I must have met him in my youth, though I don’t have any recollection of it.

Gandy apparently quite idolized Turing, and in later years would often talk about him. But then there was the matter of the Turing collected works. Shortly after Turing died, Sara Turing and Max Newman had asked Gandy—as Turing’s executor—to organize the publication of Turing’s unpublished papers. Years went by. Letters in the archives record Sara Turing’s frustration. But somehow Gandy never seemed to get the papers together.

Gandy died in 1995, still without the collected works complete. Nick Furbank—a literary critic and biographer of E. M. Forster who Turing had gotten to know at King’s College—was Turing’s literary executor, and finally he swung into action on the collected works. The most contentious volume seemed to be the one on mathematical logic, and for this he enlisted Robin Gandy’s first serious PhD student, a certain Mike Yates—who found letters to Gandy about the collected works that had been unopened for 24 years. (The collected works finally appeared in 2001—45 years after they were started.)

But what about the books Turing owned? In continuing to try to track them down, my next stop was the Turing family, and specifically Turing’s brother’s youngest child, Dermot Turing (who is actually Sir Dermot Turing, as a result of a baronetcy which passed down the non-Alan branch of the Turing family). Dermot Turing (who recently wrote a biography of Alan Turing) told me about “granny Turing” (aka Sara Turing), whose house apparently shared a garden gate with his family’s, and many other things about Alan Turing. But he said the family never had any of Alan Turing’s books.

So I went back to reading wills, and found out that Gandy’s executor was his student Mike Yates. We found out that Mike Yates had retired from being a professor 30 years ago, but was now living in North Wales. He said that in the decades he was working in mathematical logic and theory of computation, he’d never really touched a computer—but finally did when he retired (and, as it happens, discovered Mathematica soon thereafter). He said how remarkable it was that Turing had become so famous—and that when he’d arrived at Manchester just three years after Turing died, nobody talked about Turing, not even Max Newman when he gave a course about logic. Though later on, Gandy would talk about how swamped he was in dealing with Turing’s collected works—eventually leaving the task to Mike.

What did Mike know about Turing’s books? Well, he’d found one handwritten notebook of Turing’s, that Gandy had not given to King’s College, because (bizarrely) Gandy had used it as camouflage for notes he kept about his dreams. (Turing kept dream notebooks too, that were destroyed when he died.) Mike said that notebook had recently been sold at auction for about $1M. And that otherwise he didn’t think there was any Turing material among Gandy’s things.

It seemed like all our leads had dried up. But Mike asked to see the mysterious piece of paper. And immediately he said, “That’s Robin Gandy’s handwriting!” He said he’d seen so much of it over the years. And he was sure. He said he didn’t know much about lambda calculus, and couldn’t really read the page. But he was sure it had been written by Robin Gandy.

We went back to our handwriting examiner with more samples, and she agreed that, yes, what was there was consistent with Gandy’s writing. So finally we had it: Robin Gandy had written our mysterious piece of paper. It wasn’t written by Alan Turing; it was written by his student Robin Gandy.

Of course, some mysteries remain. Presumably Turing lent Gandy the book. But when? The lambda calculus notation seems like it’s from the 1930s. But based on comments in Gandy’s thesis, Gandy probably wouldn’t have been doing anything with lambda calculus until the late 1940s. Then there’s the question of why Gandy wrote it. It doesn’t seem directly related to his thesis, so maybe it was when he was first trying to understand lambda calculus.

I doubt we’ll ever know. But it’s certainly been interesting trying to track it down. And I have to say that the whole process has done much to heighten my awareness of just how complex the stories may be of all those books from past centuries that I own. And it makes me think I’d better make sure I’ve gone through all their pages, just to find out what curious things might be in there…

*Thanks for additional help to Jonathan Gorard (local research in Cambridge), Dana Scott (mathematical logic) and Matthew Szudzik (mathematical logic).*

I’ve been reflecting recently on things I like to do. Of course I like creating things, figuring things out, and so on. But something else I like—that I don’t believe I’ve ever written about before—is mentoring. I’ve been doing it a shockingly long time: my first memories of it date from before I was 10 years old, 50 years ago. Somehow I always ended up being the one giving lots of advice—first to kids my own age, then also to ones somewhat younger, or older, and later to all sorts of people.

I was in England recently, and ran into someone I’d known as a kid nearly 50 years ago—and hadn’t seen since. He’s had a fascinating and successful career, but was kind enough to say that my interactions and advice to him nearly 50 years ago had really been important to him. Of course it’s nice to hear things like that—but as I reflect on it, I realize that mentoring is something I find fulfilling, whether or not I end up knowing that whatever seeds I’ve sown germinate (though, to be clear, I do find it fascinating to see what happens).

Mentoring is not like teaching. It’s something much more individual and personal. It’s about answering the specific “What should I do about X?” questions, and the general “What should I do given who I am?” questions. I’ve always been interested in people—which has been a great asset in identifying and leading people at my company all these years. It’s also what’s gotten me in recent years to write historical biography, and, sadly, to write a rather large number of obituaries.

But there’s something particularly fulfilling to me about mentoring, and about helping and changing outcomes, one person at a time. These days, there are two main populations I end up mentoring: CEOs, and kids. At some level, they’re totally different. But at some level, they’re surprisingly similar.

I like learning things, and I like solving problems. And in the mentoring I do, I’m always doing both these things. I’m hearing—often in quite a lot of detail—about different kinds of situations. And I’m trying to use my skills at problem solving to work out what to do. The constraint is always what is right for this particular person, and what is possible given the world as it is. But it’s so satisfying when one figures it out.

“Have you ever thought of X?” Sometimes, there’ll be an immediate “Oh, that’s a good idea” response. Sometimes one will be told a host of reasons why it can’t work—and then it’s a matter of picking through which objections are real, where all that’s needed is encouragement, and where there are other problems to be solved.

Sometimes my mentoring ends up being about things that have immediate effects on the world, like major strategy decisions for significant companies. Sometimes my mentoring is about things that are—for now—completely invisible to the world, like whether a kid should study this or that.

I tend to find mentoring the most interesting when it’s dealing with things I’ve never dealt with before. Maybe they’re things that are genuinely new in the world—like new situations in the technology industry. Or maybe they’re things that are just new to me, because I’ve never experienced or encountered that particular corner of human experience, or the world.

One thing that’s in common between CEOs and kids is that at some level they tend to be in “anything is possible” situations: they have a wide range of choices they can make about how to lead their companies, or their lives. And they also tend to want to think about the future—and about where they might go.

To be fair, there are both CEOs and kids where I wouldn’t be a particularly useful mentor. And most often that’s when they’re somehow already on some definite track, and where their next several years are largely determined. (Say just following a particular business plan, or a particular educational program.)

In the case of CEO mentoring, there’s a tendency for there to be quite long periods where not much happens, interspersed by the occasional urgent crises—deals to do or not, PR emergencies, personnel meltdowns, etc. (And, yes, those calls can come in at the most awkward times, making me glad that when I’m pushing other things aside, at least I can say to myself that I’m typically an official company advisor too, usually with a little equity in the company.)

With kids, things usually tend to be less urgent, and it’s more a matter of repeated interactions, gradually showing a direction, or working through issues. Sometimes—and this applies to CEOs as well—the issues are exogenous, and relate to situations in the world. Sometimes they’re endogenous, and they’re about how someone is motivated, or thinks about themselves or their place in the world.

I’ve found that the kids I find it most interesting to mentor fall into two categories. The first are the seriously precocious kids who are already starting to launch in high-flying directions. And the second are kids who aren’t connected to the high-flying world, and may be in difficult circumstances, but who somehow have some kind of spark that interactions with me can help nurture.

I’ve done a fair amount of traveling around the world in recent years (often with one or more of my own kids). And I always find it interesting to visit schools. (Research universities tend to seem similar all over the world, but as one gets to high schools and below, there are more and more obvious—and interesting—differences.) Usually I’ll give talks and have discussions with students. And there’s a pattern that’s repeated over and over again. At the end of an event, one or two students will come up to me and start an interesting conversation, and eventually I’ll hand them a business card and say: “If you ever want to chat more, send me mail”.

And, yes, the ones I hear from are a very self-selected set. Typically I’ll do an initial phone call to learn more about them. And if it seems like I can be useful, I’ll say, “Let me put you on my list of people I’ll call when I have time”.

I have a busy life, and I like to be as productive as possible. But there are always scraps of time when I’m not doing what I usually do. Maybe I’ll be driving from here to there at a time when there’s no useful meeting I can do. Maybe I’ll be procrastinating starting something because I’m not quite in the right frame of mind. And at those kinds of times it’s great to do a mentoring phone call. Because even if I’m hearing about all sorts of problems, I always find it energizing.

With CEOs, the problems can be big and sophisticated. With kids one might at first assume they’d be too familiar and low-level to be interesting. But at least for me, that’s not the case. Sometimes it’s that I started my career sufficiently early that I never personally encountered that kind of problem. Sometimes it’s that the problems are ones that newly exist only in recent years.

And particularly for kids in difficult circumstances, it’s often that with my particular trajectory in life I’ve just never been exposed to those kinds of problems. Sometimes I’m quite embarrassed at how clueless I am about some economic or social hardship a kid tells me about. But I’ll ask lots of questions—and often I’m quite proud of the solutions I’ll come up with.

I have to say that in modern times, it’s disappointing how difficult it tends to be for someone like me to reach kids who aren’t already connected to the rather high-flying parts of the world I usually deal with. There’s an example with our (very successful, I might add) Wolfram High School Summer Camp, which we’ve been putting on for the past seven years. We’ve always got great kids at the Summer Camp. But in the first few years, I noticed that almost all of them came from the most elite schools—usually on the East Coast or West Coast of the US, and generally had very sophisticated backgrounds.

I wanted to broaden things out, and so we put effort into advertising the Summer Camp on our Wolfram|Alpha website that (I’m happy to say) a very large number of kids use. The results were good in the sense that we immediately got a much broader geographic distribution, both within the US and outside. But though we advertised that scholarships and financial aid were available, few people applied for those, and in fact the fraction even seems to have recently been going down slightly.

It’s a frustrating situation, and perhaps it’s a reflection of broader societal issues. Of course, the Summer Camp is a somewhat different situation from mentoring, because to be successful at the Summer Camp, kids already have to have (or give themselves) a certain amount of preparation (learn at least the basics of the Wolfram Language, etc.). And in fact, it’s not uncommon for kids I’ve mentored to end up going to the Summer Camp. And from that point on (or, for example, when they go to some good college), they’re often basically “solved problems”, now connected to people and resources that will help take them forward.

When my company was young, I often found myself mentoring employees. But as the company grew, and developed a strong internal culture, that became less and less necessary because in a sense, the whole ambient environment provided mentoring. And, yes, as is typical in companies, my values as founder and CEO are (for better or worse) deeply imprinted on the organization. And part of what that means is that I don’t personally have to communicate them to everyone in the organization.

In a company it clearly makes sense to promote a certain coherent set of goals and values. But what about in the world at large, or, say, in kids one mentors? There’s always a great tendency to promote—often with missionary zeal—the kind of thing one does oneself. “Everyone should want to be a tech entrepreneur!” “Everyone should want to be a professor!” etc. And, yes, there will be people for whom those are terrific directions, and unless someone mentors them in those directions, they’ll never find them. But what about all the others?

I did some surveys of kids a couple of years ago, asking them about their goals. I asked them to say how interested they were in things like having their own reality TV show, making a billion dollars, making a big scientific discovery, having lots of friends, taking a one-way trip to Mars, etc. And, perhaps not surprisingly, there was great diversity in their answers. I asked some adults the same questions, and then asked them how they thought their answers would have been different when they were kids.

And my very anecdotal conclusion was that at least at this coarse level, the things people say they’d like to do or have done change fairly little over the course of their lives—at least after their early teenage years. Of course, an important goal of education should surely be to show people what’s out there in the world, and what it’s possible to do. In practice, though, much of modern formal education is deeply institutionalized in particular tracks that were defined a century ago. But still there are signals to be gleaned.

So you like math in school? The number of people who just do math for a living is pretty small. But what is the essence of what you like about math? Is it the definiteness of it? The problem solving? The abstract aesthetics? The measurable competitiveness? If you’re mentoring a kid you should be able to parse it out—and depending on the answer there’ll be all sorts of different possible directions and opportunities.

And in general, my point of view is that the goal should always be to try to find signals from people, and then to see how to help amplify them, and solve the problem of how to fit them into what’s possible in the world. I like to think that for every person there’s something out there that’s the best fit for what they should be doing. Of course, you may be lucky or unlucky in the time in history in which you live. You want to be an explorer, doing things like searching for the sources of rivers? Sorry, that’s been done. You want to be an asteroid miner or a genetic designer of animals? Sorry, you’re too early.

In a company, I view it as a major role—and responsibility—of management to take the skills and talents of the people one has, and solve the puzzle of fitting them into the projects that the company needs to do. Quite often one ends up suggesting quite new directions to people. (“I had no idea there was a thing like software quality assurance.” “Linguistic curation is something people do?” etc.) And over the years it’s been very satisfying to see how many successful careers I’ve been able to help launch by pointing people to new fields where it turns out their skills and interests are a match.

I don’t claim to be immune to the “encourage people to do what you do” phenomenon. And in a sense that informs the people—CEOs or kids—who I mentor. But I like to think that I’m unprejudiced about subject areas (and the more experience I get in the world, and with different kinds of people, the easier that gets). What does tend to be in common, though, is that I believe in just figuring out what to do, and doing it.

Too few people have had serious experience in going from “nothing to something”: of starting from some idea that just got invented, and then seeing it over the course of time turn into something real—and perhaps even important—in the world. But that’s the kind of thing I’ve spent my life doing, and that I try to do all the time.

And (at least given my worldview) I think it’s something that’s incredibly valuable and educational for people to see, and if possible experience for themselves. When people at the company have been involved in major “nothing-to-something” projects, I think there’s a certain glow of confidence they get that lasts a decade.

I can see that my own children have benefitted from watching so many projects of mine go from nothing to something—and being exposed to the process that’s been involved (and often giving their own input). And when I mentor kids (and often CEOs too) I like to mention projects I’ve got going on, so that over the course of time they too gradually get a sense of at least my version of the “nothing-to-something” process.

For the past several years, I’ve spent a couple of hours most Sundays doing “Computational Adventures” with groups of kids (mostly middle school, with some early high school, and some late elementary school). It’s been fascinating for me, especially as I try to understand more about teaching computational thinking. And of course it’s invigorating for me to be doing something so different from my typical “day job”.

Most of the time what I’ll actually do with the kids is try to figure out or build something with the Wolfram Language. It’s not the same kind of thing as mentoring individual kids, but there’s a little bit of “create something from nothing” when we develop ideas and implement them in the Wolfram Language.

I think to most kids, knowledge is something that just exists, not something that they know people create. And so it’s always fun when the kids bring up a topic, and I’m like “well, it so happens that the world expert on that is a friend of mine”, or, “well, actually, I was the one who discovered this or that!”. Like in mentoring, all this helps communicate the “you can do that too” message. And after a while, it’s something that kids just start to take for granted.

One of the features of having done mentoring for so long is that I’ve been able to see all sorts of long-term outcomes. Sometimes it’s a bit uncanny. I’ll be talking to some kid, and I’ll think to myself: “They’re just like that kid I knew 50 years ago!” And then I’ll start playing out in my mind what I think would naturally happen this time around, decades hence. And it’s the same with CEOs and their issues.

And, yes, it’s useful to have the experience, and to be able to make those predictions. But there’s still the problem solving about the present to do, and the human connection to make. And for me it all adds up to the fascinating and fulfilling experience I’ve had in doing all that mentoring over the past half-century or so.

Often it’s been some random coincidence that’s brought a particular mentoree to me. Sometimes it’s been their initiative in reaching out (or, very occasionally, someone reaching out on their behalf). I’m hoping that in the future (particularly when it comes to kids), it’ll be a still broader cross-section. And that in the years to come I’ll have the pleasure of successfully answering ever more of those “What should I do?” questions—that make me think about something I’ve never thought about before, and help someone follow the path they want.

]]>(

It’s called the Feigenbaum constant, and it’s about 4.6692016. And it shows up, quite universally, in certain kinds of mathematical—and physical—systems that can exhibit chaotic behavior.

Mitchell Feigenbaum, who died on June 30 at the age of 74, was the person who discovered it—back in 1975, by doing experimental mathematics on a pocket calculator.

It became a defining discovery in the history of chaos theory. But when it was first discovered, it was a surprising, almost bizarre result, that didn’t really connect with anything that had been studied before. Somehow, though, it’s fitting that it should have been Mitchell Feigenbaum—who I knew for nearly 40 years—who would discover it.

Trained in theoretical physics, and a connoisseur of its mathematical traditions, Mitchell always seemed to see himself as an outsider. He looked a bit like Beethoven—and projected a certain stylish sense of intellectual mystery. He would often make strong assertions, usually with a conspiratorial air, a twinkle in his eye, and a glass of wine or a cigarette in his hand.

He would talk in long, flowing sentences which exuded a certain erudite intelligence. But ideas would jump around. Sometimes detailed and technical. Sometimes leaps of intuition that I, for one, could not follow. He was always calculating, staying up until 5 or 6 am, filling yellow pads with formulas and stressing Mathematica with elaborate algebraic computations that might run for hours.

He published very little, and what he did publish he was often disappointed wasn’t widely understood. When he died, he had been working for years on the optics of perception, and on questions like why the Moon appears larger when it’s close to the horizon. But he never got to the point of publishing anything on any of this.

For more than 30 years, Mitchell’s official position (obtained essentially on the basis of his Feigenbaum constant result) was as a professor at the Rockefeller University in New York City. (To fit with Rockefeller’s biological research mission, he was themed as the Head of the “Laboratory of Mathematical Physics”.) But he dabbled elsewhere, lending his name to a financial computation startup, and becoming deeply involved in inventing new cartographic methods for the *Hammond World Atlas*.

The basic idea is quite simple. Take a value *x* between 0 and 1. Then iteratively replace *x* by *a x* (1 – *x*). Let’s say one starts from *x* = , and takes *a* = 3.2. Then here’s what one gets for the successive values of *x*:

✕
ListLinePlot[NestList[Compile[x, 3.2 x (1 - x)], N[1/3], 50], Mesh -> All, PlotRange -> {0, 1}, Frame -> True] |

After a little transient, the values of *x* are periodic, with period 2. But what happens with other values of *a*? Here are a few results for this so-called “logistic map”:

✕
GraphicsGrid[ Partition[ Table[Labeled[ ListLinePlot[NestList[Compile[x, a x (1 - x)], N[1/3], 50], Sequence[ Mesh -> All, PlotRange -> {0, 1}, Frame -> True, FrameTicks -> None]], StringTemplate["a = ``"][a]], {a, 2.75, 4, .25}], 3], Spacings -> {.1, -.1}] |

For small *a*, the values of *x* quickly go to a fixed point. For larger *a* they become periodic, first with period 2, then 4. And finally, for larger *a*, the values start bouncing around seemingly randomly.

One can summarize this by plotting the values of *x* (here, 300, after dropping the first 50 to avoid transients) reached as a function of the value of *a*:

✕
ListPlot[Flatten[ Table[{a, #} & /@ Drop[NestList[Compile[x, a x (1 - x)], N[1/3], 300], 50], {a, 0, 4, .01}], 1], Frame -> True, FrameLabel -> {"a", "x"}] |

As *a* increases, one sees a cascade of “period doublings”. In this case, they’re at *a* = 3, *a* ≃ 3.449, *a* ≃ 3.544090, *a* ≃ 3.5644072. What Mitchell noticed is that these successive values approach a limit (here *a*_{∞} ≃ 3.569946) in a geometric sequence, with *a*_{∞} – *a*_{n} ~ δ^{-n} and δ ≃ 4.669.

That’s a nice little result. But here’s what makes it much more significant: it isn’t just true about the specific iterated map *x* ⟶ *a x* (1 – *x*); it’s true about any map like that. Here, for example, is the “bifurcation diagram” for *x* ⟶ *a* sin(π ):

✕
ListPlot[Flatten[ Table[{a, #} & /@ Drop[NestList[Compile[x, a Sin[Pi Sqrt@x]], N[1/3], 300], 50], {a, 0, 1, .002}], 1], Frame -> True, FrameLabel -> {"a", "x"}] |

The details are different. But what Mitchell noticed is that the positions of the period doublings again form a geometric sequence, with the exact same base: δ ≃ 4.669.

It’s not just that different iterated maps give qualitatively similar results; when one measures the convergence rate this turns out be exactly and quantitatively the same—always δ ≃ 4.669. And this was Mitchell’s big discovery: a quantitatively universal feature of the approach to chaos in a class of systems.

The basic idea behind iterated maps has a long history, stretching all the way back to antiquity. Early versions arose in connection with finding successive approximations, say to square roots. For example, using Newton’s method from the late 1600s, can be obtained by iterating *x* ⟶ (here starting from *x* = 1):

✕
NestList[Function[x, 1/x + x/2], N[1, 8], 6] |

The notion of iterating an arbitrary function seems to have first been formalized in an 1870 paper by Ernst Schröder (who was notable for his work in formalizing things from powers to Boolean algebra), although most of the discussion that arose was around solving functional equations, not actually doing iterations. (An exception was the investigation of regions of convergence for Newton’s approximation by Arthur Cayley in 1879.) In 1918 Gaston Julia made a fairly extensive study of iterated rational functions in the complex plane—inventing, if not drawing, Julia sets. But until fractals in the late 1970s (which soon led to the Mandelbrot set), this area of mathematics basically languished.

But quite independent of any pure mathematical developments, iterated maps with forms similar to *x* ⟶ *a x* (1 – *x*) started appearing in the 1930s as possible practical models in fields like population biology and business cycle theory—usually arising as discrete annualized versions of continuous equations like the Verhulst logistic differential equation from the mid-1800s. Oscillatory behavior was often seen—and in 1954 William Ricker (one of the founders of fisheries science) also found more complex behavior when he iterated some empirical fish reproduction curves.

Back in pure mathematics, versions of iterated maps had also shown up from time to time in number theory. In 1799 Carl Friedrich Gauss effectively studied the map *x* → `FractionalPart`[] in connection with continued fractions. And starting in the late 1800s there was interest in studying maps like *x* ⟶ ` FractionalPart`[*a x*] and their connections to the properties of the number *a*.

Particularly following Henri Poincaré’s work on celestial mechanics around 1900, the idea of sensitive dependence on initial conditions arose, and it was eventually noted that iterated maps could effectively “excavate digits” in their initial conditions. For example, iterating *x* ⟶ `FractionalPart`[10 *x*], starting with the digits of π, gives (effectively just shifting the sequence of digits one place to the left at each step):

✕
N[NestList[Function[x, FractionalPart[10 x]], N[Pi, 100], 5], 10] |

✕
ListLinePlot[ Rest@N[NestList[Function[x, FractionalPart[10 x]], N[Pi, 100], 50], 40], Mesh -> All] |

(Confusingly enough, with typical “machine precision” computer arithmetic, this doesn’t work correctly, because even though one “runs out of precision”, the IEEE Floating Point standard says to keep on delivering digits, even though they are completely wrong. Arbitrary precision in the Wolfram Language gets it right.)

Maps like *x* ⟶ *a x*(1 – *x*) show similar kinds of “digit excavation” behavior (for example, replacing *x* by sin[π *u*]^{2}, *x* ⟶ 4 *x*(1 – *x*) becomes exactly *u* ⟶ `FractionalPart`[*u*, 2]—and this was already known by the 1940s, and, for example, commented on by John von Neumann in connection with his 1949 iterative “middle-square” method for generating pseudorandom numbers by computer.

But what about doing experimental math on iterated maps? There wasn’t too much experimental math at all on early digital computers (after all, most computer time was expensive). But in the aftermath of the Manhattan Project, Los Alamos had built its own computer (named MANIAC), that ended up being used for a whole series of experimental math studies. And in 1964 Paul Stein and Stan Ulam wrote a report entitled “Non-linear Transformation Studies on Electronic Computers” that included photographs of oscilloscope-like MANIAC screens displaying output from some fairly elaborate iterated maps. In 1971, another “just out of curiosity” report from Los Alamos (this time by Nick Metropolis [leader of the MANIAC project, and developer of the Monte Carlo method], Paul Stein and his brother Myron Stein) started to give more specific computer results for the behavior logistic maps, and noted the basic phenomenon of period doubling (which they called the “U-sequence”), as well as its qualitative robustness under changes in the underlying map.

But quite separately from all of this, there were other developments in physics and mathematics. In 1964 Ed Lorenz (a meteorologist at MIT) introduced and simulated his “naturally occurring” Lorenz differential equations, that showed sensitive dependence on initial conditions. Starting in the 1940s (but following on from Poincaré’s work around 1900) there’d been a steady stream of developments in mathematics in so-called dynamical systems theory—particularly investigating global properties of the solutions to differential equations. Usually there’d be simple fixed points observed; sometimes “limit cycles”. But by the 1970s, particularly after the arrival of early computer simulations (like Lorenz’s), it was clear that for nonlinear equations something else could happen: a so-called “strange attractor”. And in studying so-called “return maps” for strange attractors, iterated maps like the logistic map again appeared.

But it was in 1975 that various threads of development around iterated maps somehow converged. On the mathematical side, dynamical systems theorist Jim Yorke and his student Tien-Yien Li at the University of Maryland published their paper “Period Three Implies Chaos”, showing that in an iterated map with a particular parameter value, if there’s ever an initial condition that leads to a cycle of length 3, there must be other initial conditions that don’t lead to cycles at all—or, as they put it, show chaos. (As it turned out, Aleksandr Sarkovskii—who was part of a Ukrainian school of dynamical systems research—had already in 1962 proved the slightly weaker result that a cycle of period 3 implies cycles of all periods.)

But meanwhile there had also been growing interest in things like the logistic maps among mathematically oriented population biologists, leading to the rather readable review (published in mid-1976) entitled “Simple Mathematical Models with Very Complicated Dynamics” by physics-trained Australian Robert May, who was then a biology professor at Princeton (and would subsequently become science advisor to the UK government, and is now “Baron May of Oxford”).

But even though things like sketches of bifurcation diagrams existed, the discovery of their quantitatively universal properties had to await Mitchell Feigenbaum and his discovery.

Mitchell Feigenbaum grew up in Brooklyn, New York. His father was an analytical chemist, and his mother was a public-school teacher. Mitchell was unenthusiastic about school, though did well on math and science tests, and managed to teach himself calculus and piano. In 1960, at age 16, as something of a prodigy, he enrolled in the City College of New York, officially studying electrical engineering, but also taking physics and math classes. After graduating in 1964, he went to MIT. Initially he was going to do a PhD in electrical engineering, but he quickly switched to physics.

But although he was enamored of classic mathematical physics (as represented, for example, in the books of Landau and Lifshiftz), he ended up writing his thesis on a topic set by his advisor about particle physics, and specifically about evaluating a class of Feynman diagrams for the scattering of photons by scalar particles (with lots of integrals, if not special functions). It wasn’t a terribly exciting thesis, but in 1970 he was duly dispatched to Cornell for a postdoc position.

Mitchell struggled with motivation, preferring to hang out in coffee shops doing the *New York Times* crossword (at which he was apparently very fast) to doing physics. But at Cornell, Mitchell made several friends who were to be important to him. One was Predrag Cvitanović, a star graduate student from what is now Croatia, who was studying quantum electrodynamics, and with whom he shared an interest in German literature. Another was a young poet named Kathleen Doorish (later, Kathy Hammond), who was a friend of Predrag’s. And another was a rising-star physics professor named Pete Carruthers, with whom he shared an interest in classical music.

In the early 1970s quantum field theory was entering a golden age. But despite the topic of his thesis, Mitchell didn’t get involved, and in the end, during his two years at Cornell, he produced no visible output at all. Still, he had managed to impress Hans Bethe enough to be dispatched for another postdoc position, though now at a place lower in the pecking order of physics, Virginia Polytechnic Institute, in rural Virginia.

At Virginia Tech, Mitchell did even less well than at Cornell. He didn’t interact much with people, and he produced only one three-page paper: “The Relationship between the Normalization Coefficient and Dispersion Function for the Multigroup Transport Equation”. As its title might suggest, the paper was quite technical and quite unexciting.

As Mitchell’s two years at Virginia Tech drew to a close it wasn’t clear what was going to happen. But luck intervened. Mitchell’s friend from Cornell, Pete Carruthers, had just been hired to build up the theory division (“T Division”) at Los Alamos, and given *carte blanche* to hire several bright young physicists. Pete would later tell me with pride (as part of his advice to me about general scientific management) that he had a gut feeling that Mitchell could do something great, and that despite other people’s input—and the evidence—he decided to bet on Mitchell.

Having brought Mitchell to Los Alamos, Pete set about suggesting projects for him. At first, it was following up on some of Pete’s own work, and trying to compute bulk collective (“transport”) properties of quantum field theories as a way to understand high-energy particle collisions—a kind of foreshadowing of investigations of quark-gluon plasma.

But soon Pete suggested that Mitchell try looking at fluid turbulence, and in particular on seeing whether renormalization group methods might help in understanding it.

Whenever a fluid—like water—flows sufficiently rapidly it forms lots of little eddies and behaves in a complex and seemingly random way. But even though this qualitative phenomenon had been discussed for centuries (with, for example, Leonardo da Vinci making nice pictures of it), physics had had remarkably little to say about it—though in the 1940s Andrei Kolmogorov had given a simple argument that the eddies should form a cascade with a *k* distribution of energies. At Los Alamos, though, with its focus on nuclear weapons development (inevitably involving violent fluid phenomena), turbulence was a very important thing to understand—even if it wasn’t obvious how to approach it.

But in 1974, there was news that Ken Wilson from Cornell had just “solved the Kondo problem” using a technique called the renormalization group. And Pete Carruthers suggested that Mitchell should try to apply this technique to turbulence.

The renormalization group is about seeing how changes of scale (or other parameters) affect descriptions (and behavior) of systems. And as it happened, it was Mitchell’s thesis advisor at MIT, Francis Low, who, along with Murray Gell-Mann, had introduced it back in 1954 in the context of quantum electrodynamics. The idea had lain dormant for many years, but in the early 1970s it came back to life with dramatic—though quite different—applications in both particle physics (specifically, QCD) and condensed matter physics.

In a piece of iron at room temperature, you can basically get all electron spins associated with each atom lined up, so the iron is magnetized. But if you heat the iron up, there start to be fluctuations, and suddenly—above the so-called Curie temperature (770°C for iron)—there’s effectively so much randomness that the magnetization disappears. And in fact there are lots of situations (think, for example, melting or boiling—or, for that matter, the formation of traffic jams) where this kind of sudden so-called phase transition occurs.

But what is actually going on in a phase transition? I think the clearest way to see this is by looking at an analog in cellular automata. With the particular rule shown below, if there aren’t very many initial black cells, the whole system will soon be white. But if you increase the number of initial black cells (as a kind of analog of increasing the temperature in a magnetic system), then suddenly, in this case at 50% black, there’s a sharp transition, and now the whole system eventually becomes black. (For phase transition experts: yes, this is a phase transition in a 1D system; one only needs 2D if the system is required to be microscopically reversible.)

✕
GraphicsRow[SeedRandom[234316]; Table[ArrayPlot[ CellularAutomaton[<| "RuleNumber" -> 294869764523995749814890097794812493824, "Colors" -> 4|>, 3 Boole[Thread[RandomReal[{0, 1}, 2000] < rho]], {500, {-300, 300}}], FrameLabel -> {None, Row[{ Round[100 rho], "% black"}]}], {rho, {0.4, 0.45, 0.55, 0.6}}], -30] |

But what does the system do near 50% black? In effect, it can’t decide whether to finally become black or white. And so it ends up showing a whole hierarchy of “fluctuations” from the smallest scales to the largest. And what became clear by the 1960s is that the “critical exponents” characterizing the power laws describing these fluctuations are universal across many different systems.

But how can one compute these critical exponents? In a few toy cases, analytical methods were known. But mostly, something else was needed. And in the late 1960s Ken Wilson realized that one could use the renormalization group, and computers. One might have a model for how individual spins interact. But the renormalization group gives a procedure for “scaling up” to the interactions of larger and larger blocks of spins. And by studying that on a computer, Ken Wilson was able to start computing critical exponents.

At first, the physics world didn’t pay much attention, not least because they weren’t used to computers being so intimately in the loop in theoretical physics. But then there was the Kondo problem (and, yes, so far as I know, it has no relation to modern Kondoing—though it does relate to modern quantum dot cellular automata). In most materials, electrical resistivity decreases as the temperature decreases (going to zero for superconductors even above absolute zero). But back in the 1930s, measurements on gold had shown instead an increase of resistivity at low temperatures. By the 1960s, it was believed that this was due to the scattering of electrons from magnetic impurities—but calculations ran into trouble, generating infinite results.

But then, in 1975, Ken Wilson applied his renormalization group methods—and correctly managed to compute the effect. There was still a certain mystery about the whole thing (and it probably didn’t help that—at least when I knew him in the 1980s and beyond—I often found Ken Wilson’s explanations quite hard to understand). But the idea that the renormalization group could be important was established.

So how might it apply to fluid turbulence? Kolmogorov’s power law seemed suggestive. But could one take the Navier–Stokes equations which govern idealized fluid flow and actually derive something like this? This was the project on which Mitchell Feigenbaum embarked.

The Navier–Stokes equations are very hard to work with. In fact, to this day it’s still not clear how even the most obvious feature of turbulence—its apparent randomness—arises from these equations. (It could be that the equations aren’t a full or consistent mathematical description, and one’s actually seeing amplified microscopic molecular motions. It could be that—as in chaos theory and the Lorenz equations—it’s due to amplification of randomness in the initial conditions. But my own belief, based on work I did in the 1980s, is that it’s actually an intrinsic computational phenomenon—analogous to the randomness one sees in my rule 30 cellular automaton.)

So how did Mitchell approach the problem? He tried simplifying it—first by going from equations depending on both space and time to ones depending only on time, and then by effectively making time discrete, and looking at iterated maps. Through Paul Stein, Mitchell knew about the (not widely known) previous work at Los Alamos on iterated maps. But Mitchell didn’t quite know where to go with it, though having just got a swank new HP-65 programmable calculator, he decided to program iterated maps on it.

Then in July 1975, Mitchell went (as I also did a few times in the early 1980s) to the summer physics hang-out-together event in Aspen, CO. There he ran into Steve Smale—a well-known mathematician who’d been studying dynamical systems—and was surprised to find Smale talking about iterated maps. Smale mentioned that someone had asked him if the limit of the period-doubling cascade *a*_{∞} ≃ 3.56995 could be expressed in terms of standard constants like π and . Smale related that he’d said he didn’t know. But Mitchell’s interest was piqued, and he set about trying to figure it out.

He didn’t have his HP-65 with him, but he dove into the problem using the standard tools of a well-educated mathematical physicist, and had soon turned it into something about poles of functions in the complex plane—about which he couldn’t really say anything. Back at Los Alamos in August, though, he had his HP-65, and he set about programming it to find the bifurcation points *a*_{n}.

The iterative procedure ran pretty fast for small *n*. But by *n* = 5 it was taking 30 seconds. And for *n* = 6 it took minutes. While it was computing, however, Mitchell decided to look at the *a*_{n} values he had so far—and noticed something: they seemed to be converging geometrically to a final value.

At first, he just used this fact to estimate *a*_{∞}, which he tried—unsuccessfully—to express in terms of standard constants. But soon he began to think that actually the convergence exponent δ was more significant than *a*_{∞}—since its value stayed the same under simple changes of variables in the map. For perhaps a month Mitchell tried to express δ in terms of standard constants.

But then, in early October 1975, he remembered that Paul Stein had said period doubling seemed to look the same not just for logistic maps but for any iterated map with a single hump. Reunited with his HP-65 after a trip to Caltech, Mitchell immediately tried the map *x* ⟶ sin(*x*)—and discovered that, at least to 3-digit precision, the exponent δ was exactly the same.

He was immediately convinced that he’d discovered something great. But Stein told him he needed more digits to really conclude much. Los Alamos had plenty of powerful computers—so the next day Mitchell got someone to show him how to write a program in FORTRAN on one of them to go further—and by the end of the day he had managed to compute that in both cases δ was about 4.6692.

The computer he used was a typical workhorse US scientific computer of the day: a CDC 6000 series machine (of the same type I used when I first moved to the US in 1978). It had been designed by Seymour Cray, and by default it used 60-bit floating-point numbers. But at this precision (about 14 decimal digits), 4.6692 was as far as Mitchell could compute. Fortunately, however, Pete’s wife Lucy Carruthers was a programmer at Los Alamos, and she showed Mitchell how to use double precision—with the result that he was able to compute δ to 11-digit precision, and determine that the values for his two different iterated maps agreed.

Within a few weeks, Mitchell had found that δ seemed to be universal whenever the iterated map had a single quadratic maximum. But he didn’t know why this was, or have any particular framework for thinking about it. But still, finally, at the age of 30, Mitchell had discovered something that he thought was really interesting.

On Mitchell’s birthday, December 19, he saw his friend Predrag, and told him about his result. But at the time, Predrag was working hard on mainstream particle physics, and didn’t pay too much attention.

Mitchell continued working, and within a few months he was convinced that not only was the exponent δ universal—the appropriately scaled, limiting, infinitely wiggly, actual iteration of the map was too. In April 1976 Mitchell wrote a report announcing his results. Then on May 2, 1976, he gave a talk about them at the Institute for Advanced Study in Princeton. Predrag was there, and now he got interested in what Mitchell was doing.

As so often, however, it was hard to understand just what Mitchell was talking about. But by the next day, Predrag had successfully simplified things, and come up with a single, explicit, functional equation for the limiting form of the scaled iterated map: *g*(*g*(*x*)) = , with α ≃ 2.50290—implying that for any iterated map of the appropriate type, the limiting form would always look like an even wigglier version of:

✕
fUD[z_] = 1. - 1.5276329970363323 z^2 + 0.1048151947874277 z^4 + 0.026705670524930787 z^6 - 0.003527409660464297 z^8 + 0.00008160096594827505 z^10 + 0.000025285084886512315 z^12 - 2.5563177536625283*^-6 z^14 - 9.65122702290271*^-8 z^16 + 2.8193175723520713*^-8 z^18 - 2.771441260107602*^-10 z^20 - 3.0292086423142963*^-10 z^22 + 2.6739057855563045*^-11 z^24 + 9.838888060875235*^-13 z^26 - 3.5838769501333333*^-13 z^28 + 2.063994985307743*^-14 z^30; fCF = Compile[{z}, Module[{\[Alpha] = -2.5029078750959130867, n, \[Zeta]}, n = If[Abs[z] <= 1., 0, Ceiling[Log[-\[Alpha], Abs[z]]]]; \[Zeta] = z/\[Alpha]^n; Do[\[Zeta] = #, {2^n}]; \[Alpha]^n \[Zeta]]] &[fUD[\[Zeta]]]; Plot[fCF[x], {x, -100, 100}, MaxRecursion -> 5, PlotRange -> All] |

The whole area of iterated maps got a boost on June 10, 1976, with the publication in *Nature* of Robert May’s survey about them, written independent of Mitchell and (of course) not mentioning his results. But in the months that followed, Mitchell traveled around and gave talks about his results. The reactions were mixed. Physicists wondered how the results related to physics. Mathematicians wondered about their status, given that they came from experimental mathematics, without any formal mathematical proof. And—as always—people found Mitchell’s explanations hard to understand.

In the fall of 1976, Predrag went as a postdoc to Oxford—and on the very first day that I showed up as 17-year-old particle-physics-paper-writing undergraduate, I ran into him. We talked mostly about his elegant “bird tracks” method for doing group theory (about which he finally published a book 32 years later). But he also tried to explain iterated maps. And I still remember him talking about an idealized model for fish populations in the Adriatic Sea (only years later did I make the connection that Predrag was from what is now Croatia).

At the time I didn’t pay much attention, but somehow the idea of iterated maps lodged in my consciousness, soon mixed together with the notion of fractals that I learned from Benoit Mandelbrot’s book. And when I began to concentrate on issues of complexity a couple of years later, these ideas helped guide me towards systems like cellular automata.

But back in 1976, Mitchell (who I wouldn’t meet for several more years) was off giving lots of talks about his results. He also submitted a paper to the prestigious academic journal *Advances in Mathematics*. For 6 months he heard nothing. But eventually the paper was rejected. He tried again with another paper, now sending it to the *SIAM Journal of Applied Mathematics*. Same result.

I have to say I’m not surprised this happened. In my own experience of academic publishing (now long in the past), if one was reporting progress within an established area it wasn’t too hard to get a paper published. But anything genuinely new or original one could pretty much count on getting rejected by the peer review process, either through intellectual shortsightedness or through academic corruption. And for Mitchell there was the additional problem that his explanations weren’t easy to understand.

But finally, in late 1977, Joel Lebowitz, editor of the *Journal of Statistical Physics*, agreed to publish Mitchell’s paper—essentially on the basis of knowing Mitchell, even though he admitted he didn’t really understand the paper. And so it was that early in 1978 “Quantitative Universality for a Class of Nonlinear Transformations”—reporting Mitchell’s big result—officially appeared. (For purposes of academic priority, Mitchell would sometimes quote a summary of a talk he gave on August 26, 1976, that was published in the Los Alamos Theoretical Division Annual Report 1975–1976. Mitchell was quite affected by the rejection of his papers, and for years kept the rejection letters in his desk drawer.)

Mitchell continued to travel the world talking about his results. There was interest, but also confusion. But in the summer of 1979, something exciting happened: Albert Libchaber in Paris reported results on a physical experiment on the transition to turbulence in convection in liquid helium—where he saw period doubling, with exactly the exponent δ that Mitchell had calculated. Mitchell’s δ apparently wasn’t just universal to a class of mathematical systems—it also showed up in real, physical systems.

Pretty much immediately, Mitchell was famous. Connections to the renormalization group had been made, and his work was becoming fashionable among both physicists and mathematicians. Mitchell himself was still traveling around, but now he was regularly hobnobbing with the top physicists and mathematicians.

I remember him coming to Caltech, perhaps in the fall of 1979. There was a certain rock-star character to the whole thing. Mitchell showed up, gave a stylish but somewhat mysterious talk, and was then whisked away to talk privately with Richard Feynman and Murray Gell-Mann.

Soon Mitchell was being offered all sorts of high-level jobs, and in 1982 he triumphantly returned to Cornell as a full professor of physics. There was an air of Nobel Prize–worthiness, and by June 1984 he was appearing in the *New York Times* magazine, in full Beethoven mode, in front of a Cornell waterfall:

Still, the mathematicians weren’t satisfied. As with Benoit Mandelbrot’s work, they tended to see Mitchell’s results as mere “numerical conjectures”, not proven and not always even quite worth citing. But top mathematicians (who Mitchell had befriended) were soon working on the problem, and results began to appear—though it took a decade for there to be a full, final proof of the universality of δ.

So what happened to Mitchell’s big discovery? It was famous, for sure. And, yes, period-doubling cascades with his universal features were seen in a whole sequence of systems—in fluids, optics and more. But how general was it, really? And could it, for example, be extended to the full problem of fluid turbulence?

Mitchell and others studied systems other than iterated maps, and found some related phenomena. But none were quite as striking as Mitchell’s original discovery.

In a sense, my own efforts on cellular automata and the behavior of simple programs, beginning around 1981, have tried to address some of the same bigger questions as Mitchell’s work might have led to. But the methods and results have been very different. Mitchell always tried to stay close to the kinds of things that traditional mathematical physics can address, while I unabashedly struck out into the computational universe, investigating the phenomena that occur there.

I tried to see how Mitchell’s work might relate to mine—and even in my very first paper on cellular automata in 1981 I noted for example that the average density of black cells on successive steps of a cellular automaton’s evolution can be approximated (in “mean field theory”) by an iterated map.

I also noted that mathematically the whole evolution of a cellular automaton can be viewed as an iterated map—though on the Cantor set, rather than on ordinary real numbers. In my first paper, I even plotted the analog of Mitchell’s smooth mappings, but now they were wild and discontinuous:

✕
GraphicsRow[ Labeled[ListPlot[ Table[FromDigits[CellularAutomaton[#, IntegerDigits[n, 2, 12]], 2], {n, 0, 2^12 - 1}], Sequence[ AspectRatio -> 1, Frame -> True, FrameTicks -> None]], Text[StringTemplate["rule ``"][#]]] & /@ {22, 42, 90, 110}] |

But try as I might, I could never find any strong connection with Mitchell’s work. I looked for analogs of things like period doubling, and Sarkovskii’s theorem, but didn’t find much. In my computational framework, even thinking about real numbers, with their infinite sequence of digits, was a bit unnatural. Years later, in *A New Kind of Science*, I had a note entitled “Smooth iterated maps”. I showed their digit sequences, and observed, rather undramatically, that Mitchell’s discovery implied an unusual nested structure at the beginning of the sequences:

✕
FractionalDigits[x_, digs_Integer] := NestList[{Mod[2 First[#], 1], Floor[2 First[#]]} &, {x, 0}, digs][[ 2 ;;, -1]]; GraphicsRow[ Function[a, ArrayPlot[ FractionalDigits[#, 40] & /@ NestList[a # (1 - #) &, N[1/8, 80], 80]]] /@ {2.5, 3.3, 3.4, 3.5, 3.6, 4}] |

(*Photograph by Predrag Cvitanović*)

So what became of Mitchell? After four years at Cornell, he moved to the Rockefeller University in New York, and for the next 30 years settled into a somewhat Bohemian existence, spending most of his time at his apartment on the Upper East Side of Manhattan.

While he was still at Los Alamos, Mitchell had married a woman from Germany named Cornelia, who was the sister of the wife of physicist (and longtime friend of mine) David Campbell, who had started the Center for Nonlinear Studies at Los Alamos, and would later go on to be provost at Boston University. But after not too long, Cornelia left Mitchell, taking up instead with none other than Pete Carruthers. (Pete—who struggled with alcoholism and other issues—later reunited with Lucy, but died in 1997 at the age of 61.)

When he was back at Cornell, Mitchell met a woman named Gunilla, who had run away from her life as a pastor’s daughter in a small town in northern Sweden at the age of 14, had ended up as a model for Salvador Dalí, and then in 1966 had been brought to New York as a fashion model. Gunilla had been a journalist, video maker, playwright and painter. Mitchell and she married in 1986, and remained married for 26 years, during which time Gunilla developed quite a career as a figurative painter.

Mitchell’s last solo academic paper was published in 1987. He did publish a handful of other papers with various collaborators, though none were terribly remarkable. Most were extensions of his earlier work, or attempts to apply traditional methods of mathematical physics to various complex fluid-like phenomena.

Mitchell liked interacting with the upper echelons of academia. He received all sorts of honors and recognition (though never a Nobel Prize). But to the end he viewed himself as something of an outsider—a Renaissance man who happened to have focused on physics, but didn’t really buy into all its institutions or practices.

From the early 1980s on, I used to see Mitchell fairly regularly, in New York or elsewhere. He became a daily user of Mathematica, singing its praises and often telling me about elaborate calculations he had done with it. Like many mathematical physicists, Mitchell was a connoisseur of special functions, and would regularly talk to me about more and more exotic functions he thought we should add.

Mitchell had two major excursions outside of academia. By the mid-1980s, the young poetess—now named Kathy Hammond—that Mitchell had known at Cornell had been an advertising manager for the *New York Times* and had then married into the family that owned the *Hammond World Atlas*. And through this connection, Mitchell was pulled into a completely new field for him: cartography.

I talked to him about it many times. He was very proud of figuring out how to use the Riemann mapping theorem to produce custom local projections for maps. He described (though I never fully understood it) a very physics-based algorithm for placing labels on maps. And he was very pleased when finally an entirely new edition of the *Hammond World Atlas* (that he would refer to as “my atlas”) came out.

Starting in the 1980s, there’d been an increasing trend for physics ideas to be applied to quantitative finance, and for physicists to become Wall Street quants. And with people in finance continually looking for a unique edge, there was always an interest in new methods. I was certainly contacted a lot about this—but with the success of James Gleick’s 1987 book *Chaos* (for which I did a long interview, though was only mentioned, misspelled, in a list of scientists who’d been helpful), there was a whole new set of people looking to see how “chaos” could help them in finance.

One of those was a certain Michael Goodkin. When he was in college back in the early 1960s, Goodkin had started a company that marketed the legal research services of law students. A few years later, he enlisted several Nobel Prize–winning economists and started what may have been the first hedge fund to do computerized arbitrage trading. Goodkin had always been a high-rolling, globetrotting gambler and backgammon player, and he made and lost a lot of money. And, down on his luck, he was looking for the next big thing—and found chaos theory, and Mitchell Feigenbaum.

For a few years he cultivated various physicists, then in 1995 he found a team to start a company called Numerix to commercialize the use of physics-like methods in computations for increasingly exotic financial instruments. Mitchell Feigenbaum was the marquee name, though the heavy lifting was mostly done by my longtime friend Nigel Goldenfeld, and a younger colleague of his named Sasha Sokol.

At the beginning there was lots of mathematical-physics-like work, and Mitchell was quite involved. (He was an enthusiast of Itô calculus, gave lectures about it, and was proud of having found 1000 speed-ups of stochastic integrations.) But what the company actually did was to write C++ libraries for banks to integrate into their systems. It wasn’t something Mitchell wanted to do long term. And after a number of years, Mitchell’s active involvement in the company declined.

(I’d met Michael Goodkin back in 1998, and 14 years later—having recently written his autobiography *The Wrong Answer Faster: The Inside Story of Making the Machine That Trades Trillions*—he suddenly contacted me again, pitching my involvement in a rather undefined new venture. Mitchell still spoke highly of Michael, though when the discussion rather bizarrely pivoted to me basically starting and CEOing a new company, I quickly dropped it.)

I had many interactions with Mitchell over the years, though they’re not as well archived as they might be, because they tended to be verbal rather than written, since, as Mitchell told me (in email): “I dislike corresponding by email. I still prefer to hear an actual voice and interact…”

There are fragments in my archive, though. There’s correspondence, for example, about Mitchell’s 2004 60th-birthday event, that I couldn’t attend because it conflicted with a significant birthday for one of my children. In lieu of attending, I commissioned the creation of a “Feigenbaum–Cvitanović Crystal”—a 3D rendering in glass of the limiting function *g*(*z*) in the complex plane.

It was a little complex to solve the functional equation, and the laser manufacturing method initially shattered a few blocks of glass, but eventually the object was duly made, and sent—and I was pleased many years later to see it nicely displayed in Mitchell’s apartment:

Sometimes my archives record mentions of Mitchell by others, usually Predrag. In 2007, Predrag reported (with characteristic wit):

“Other news: just saw Mitchell, he is dating Odyssey.

No, no, it’s not a high-level Washington type escort service—he is dating Homer’s Odyssey, by computing the positions of low stars as function of the 26000 year precession—says Hiparcus [sic] had it all figured out, but Catholic church succeeded in destroying every single copy of his tables.”

Living up to the Renaissance man tradition, Mitchell always had a serious interest in history. In 2013, responding to a piece of mine about Leibniz, Mitchell said he’d been a Leibniz enthusiast since he was a teenager, then explained:

“The Newton hagiographer (literally) Voltaire had no idea of the substance of the Monadology, so could only spoof ‘the best of all possible worlds’. Long ago I’ve published this as a verbal means of explaining 2^n universality.

Leibniz’s second published paper at age 19, ‘On the Method of Inverse Tangents’, or something like that, is actually the invention of the method of isoclines to solve ODEs, quite contrary to the extant scholarly commentary. Both Leibniz and Newton start with differential equations, already having received the diff. calculus. This is quite an intriguing story.”

But the mainstay of Mitchell’s intellectual life was always mathematical physics, though done more as a personal matter than as part of institutional academic work. At some point he was asked by his then-young goddaughter (he never had children of his own) why the Moon looks larger when it’s close to the horizon. He wrote back an explanation (a bit in the style of Euler’s *Letters to a German Princess*), then realized he wasn’t sure of the answer, and got launched into many years of investigation of optics and image formation. (He’d actually been generally interested in the retina since he was at MIT, influenced by Jerry Lettvin of “What the Frog’s Eye Tells the Frog’s Brain” fame.)

He would tell me about it, explaining that the usual theory of image formation was wrong, and he had a better one. He always used the size of the Moon as an example, but I was never quite clear whether the issue was one of optics or perception. He never published anything about what he did, though with luck his manuscripts (rumored to have the makings of a book) will eventually see the light of day—assuming others can understand them.

When I would visit Mitchell (and Gunilla), their apartment had a distinctly Bohemian feel, with books, papers, paintings and various devices strewn around. And then there was The Bird. It was a cockatoo, and it was loud. I’m not sure who got it or why. But it was a handful. Mitchell and Gunilla nearly got ejected from their apartment because of noise complaints from neighbors, and they ended up having to take The Bird to therapy. (As I learned in a slightly bizarre—and never executed—plan to make videogames for “they-are-alien-intelligences-right-here-on-this-planet” pets, cockatoos are social and, as pets, arguably really need a “Twitter for Cockatoos”.)

*(Photograph by Predrag Cvitanović*)

In the end, though, it was Gunilla who left, with the rumor being that she’d been driven away by The Bird.

The last time I saw Mitchell in person was a few years ago. My son Christopher and I visited him at his apartment—and he was in full Mitchell form, with eyes bright, talking rapidly and just a little conspiratorially about the mathematical physics of image formation. “Bird eyes are overrated”, he said, even as his cockatoo squawked in the next room. “Eagles have very small foveas, you know. Their eyes are like telescopes.”

“Fish have the best eyes”, he said, explaining that all eyes evolved underwater—and that the architecture hadn’t really changed since. “Fish keep their entire field of view in focus, not like us”, he said. It was charming, eccentric, and very Mitchell.

For years, we had talked from time to time on the phone, usually late at night. I saw Predrag a few months ago, saying that I was surprised not to have heard from Mitchell. He explained that Mitchell was sick, but was being very private about it. Then, a few weeks ago, just after midnight, Predrag sent me an email with the subject line “Mitchell is dead”, explaining that Mitchell had died at around 8 pm, and attaching a quintessential Mitchell-in-New-York picture:

(*Photograph by Predrag Cvitanović*)

It’s kind of a ritual I’ve developed when I hear that someone I know has died: I immediately search my archives. And this time I was surprised to find that a few years ago Mitchell had successfully reached voicemail I didn’t know I had. So now we can give Mitchell the last word:

And, of course, the last number too: 4.66920160910299067185320382…

]]>Three and a half weeks ago I got an email asking me if I’d testify at a hearing of the US Senate Commerce Committee’s Subcommittee on Communications, Technology, Innovation and the Internet. Given that the title of the hearing was “Optimizing for Engagement: Understanding the Use of Persuasive Technology on Internet Platforms” I wasn’t sure why I’d be relevant.

But then the email went on: “The hearing is intended to examine, among other things, whether algorithmic transparency or algorithmic explanation are policy options Congress should be considering.” That piqued my interest, because, yes, I have thought about “algorithmic transparency” and “algorithmic explanation”, and their implications for the deployment of artificial intelligence.

Generally I stay far away from anything to do with politics. But figuring out how the world should interact with AI is really important. So I decided that—even though it was logistically a bit difficult—I should do my civic duty and go to Washington and testify.

Watch the Senate hearing:

*Optimizing for Engagement: Understanding the Use of Persuasive Technology on Internet Platforms* »

So what was the hearing really about? For me, it was in large measure an early example of reaction to the realization that, yes, AIs are starting to run the world. Billions of people are being fed content that is basically selected for them by AIs, and there are mounting concerns about this, as reported almost every day in the media.

Are the AIs cleverly hacking us humans to get us to behave in a certain way? What kind of biases do the AIs have, relative to what the world is like, or what we think the world should be like? What are the AIs optimizing for, anyway? And when are there actually “humans behind the curtain”, controlling in detail what the AIs are doing?

It doesn’t help that in some sense the AIs are getting much more free rein than they might because the people who use them aren’t really their customers. I have to say that back when the internet was young, I personally never thought it would work this way, but in today’s world many of the most successful businesses on the internet—including Google, Facebook, YouTube and Twitter—make their revenue not from their users, but instead from advertisers who are going through them to reach their users.

All these business also have in common that they are fundamentally what one can call “automated content selection businesses”: they work by getting large amounts of content that they didn’t themselves generate, then using what amounts to AI to automatically select what content to deliver or to suggest to any particular user at any given time—based on data that they’ve captured about that user. Part of what’s happening is presumably optimized to give a good experience to their users (whatever that might mean), but part of it is also optimized to get revenue from the actual customers, i.e. advertisers. And there’s also an increasing suspicion that somehow the AI is biased in what it’s doing—maybe because someone explicitly made it be, or because it somehow evolved that way.

So why not just “open up the AI” and see what it’s doing inside? Well, that’s what the algorithmic transparency idea mentioned in the invitation to the hearing is about.

And the problem is that, no, that can’t work. If we want to seriously use the power of computation—and AI—then inevitably there won’t be a “human-explainable” story about what’s happening inside.

So, OK, if you can’t check what’s happening inside the AI, what about putting constraints on what the AI does? Well, to do that, you have to say what you want. What rule for balance between opposing kinds of views do you want? How much do you allow people to be unsettled by what they see? And so on.

And there are two problems here: first, what to want, and, second, how to describe it. In the past, the only way we could imagine describing things like this was with traditional legal rules, written in legalese. But if we want AIs to automatically follow these rules, perhaps billions of times a second, that’s not good enough: instead, we need something that AIs can intrinsically understand.

And at least on this point I think we’re making good progress. Because—thanks to our 30+ years of work on Wolfram Language—we’re now beginning to have a computational language that has the scope to formulate “computational contracts” that can specify relevant kinds of constraints in computational terms, in a form that humans can write and understand, and that machines can automatically interpret.

But even though we’re beginning to have the tools, there’s still the huge question of what the “computational laws” for automatic content selection AIs will be.

A lot of the hearing ultimately revolved around Section 230 of the 1996 Communications Decency Act—which specifies what kinds of content companies can choose to block without losing their status as “neutral platforms”. There’s a list of fairly uncontroversially blockable kinds of content. But then the sentence ends with “or otherwise objectionable [content]”. What does this mean? Does it mean content that espouses objectionable points of view? Whose definition of “objectionable”? Etc.

Well, one day things like Section 230 will, of necessity, not be legalese laws, but computational laws. There’ll be some piece of computational language that specifies for example that this-or-that machine learning classifier trained on this-or-that sample of the internet will be used to define this or that.

We’re not there yet, however. We’re only just beginning to be able to set up computational contracts for much simpler things, like business situations. And—somewhat fueled by blockchain—I expect that this will accelerate in the years to come. But it’s going to be a while before the US Senate is routinely debating lines of code in computational laws.

So, OK, what can be done now?

A little more than a week ago, what I’d figured out was basically what I’ve already described here. But that meant I was looking at going to the hearing and basically saying only negative things. “Sorry, this won’t work. You can’t do that. The science says it’s impossible. The solution is years in the future.” Etc.

And, as someone who prides himself on turning the seemingly impossible into the possible, this didn’t sit well with me. So I decided I’d better try to figure out if I could actually see a pragmatic, near-term path forward. At first, I tried thinking about purely technological solutions. But soon I basically convinced myself that no such solution was going to work.

So, with some reticence, I decided I’d better start thinking about other kinds of solutions. Fortunately there are quite a few people at my company and in my circle who I could talk to about this—although I soon discovered they often had strongly conflicting views. But after a little while, a glimmer of an idea emerged.

Why does every aspect of automated content selection have to be done by a single business? Why not open up the pipeline, and create a market in which users can make choices for themselves?

One of the constraints I imposed on myself is that my solution couldn’t detract from the impressive engineering and monetization of current automated content selection businesses. But I came up with at least two potential ways to open things up that I think could still perfectly well satisfy this constraint.

One of my ideas involved introducing what I call “final ranking providers”: third parties who take pre-digested feature vectors from the underlying content platform, then use these to do the final ranking of items in whatever way they want. My other ideas involved introducing “constraint providers”: third parties who provide constraints in the form of computational contracts that are inserted into the machine learning loop of the automated content selection system.

The important feature of both these solutions is that users don’t have to trust the single AI of the automated content selection business. They can in effect pick their own brand of AI—provided by a third party they trust—to determine what content they’ll actually be given.

Who would these third-party providers be? They might be existing media organizations, or nonprofits, or startups. Or they might be something completely new. They’d have to have some technical sophistication. But fundamentally what they’d have to do is to define—or represent—brands that users would trust to decide what the final list of items in their news feed, or video recommendations, or search results, or whatever, might be.

Social networks get their usefulness by being monolithic: by having “everyone” connected into them. But the point is that the network can prosper as a monolithic thing, but there doesn’t need to be just one monolithic AI that selects content for all the users on the network. Instead, there can be a whole market of AIs, that users can freely pick between.

And here’s another important thing: right now there’s no consistent market pressure on the final details of how content is selected for users, not least because users aren’t the final customers. (Indeed, pretty much the only pressure right now comes from PR eruptions and incidents.) But if the ecosystem changes, and there are third parties whose sole purpose is to serve users, and to deliver the final content they want, then there’ll start to be real market forces that drive innovation—and potentially add more value.

AI provides powerful ways to automate the doing of things. But AIs on their own can’t ultimately decide what they want to do. That has to come from outside—from humans defining goals. But at a practical level, where should those goals be set? Should they just come—monolithically—from an automated content selection business? Or should users have more freedom, and more choice?

One might say: “Why not let every user set everything for themselves?”. Well, the problem with that is that automated content selection is a complicated matter. And—much as I hope that there’ll soon be very widespread computational language literacy—I don’t think it’s realistic that everyone will be able to set up everything in detail for themselves. So instead, I think the better idea is to have discrete third-party providers, who set things up in a way that appeals to some particular group of users.

Then standard market forces can come into play. No doubt the result would even be a greater level of overall success for the delivery of content to users who want it (and monetize it). But this market approach also solves some other problems associated with the “single point of failure” monolithic AI.

For example, with the monolithic AI, if someone figures out how to spread some kind of bad content, it’ll spread everywhere. With third-party providers, there’s a good chance it’ll only spread through some of them.

Right now there’s lots of unhappiness about people simply being “banned” from particular content platforms. But with the market of third-party providers, banning is not an all-or-nothing proposition anymore: some providers could ban someone, but others might not.

OK, but are there “fatal flaws” with my idea? People could object that it’s technically difficult to do. I don’t know the state of the codebases inside the major automated content selection businesses. But I’m certain that with manageable effort, appropriate APIs etc. could be set up. (And it might even help these businesses by forcing some code cleanup and modernization.)

Another issue might be: how will the third-party providers be incentivized? I can imagine some organizations just being third-party providers as a public service. But in other cases they’d have to be paid a commission by the underlying content platform. The theory, though, is that good work by third-party content providers would expand the whole market, and make them “worth their commission”. Plus, of course, the underlying content platforms could save a lot by not having to deal with all those complaints and issues they’re currently getting.

What if there’s a third-party provider that upranks content some people don’t like? That will undoubtedly happen. But the point is that this is a market—so market dynamics can operate.

Another objection is that my idea makes even worse the tendency with modern technology for people to live inside “content bubbles” where they never broaden their points of view. Well, of course, there can be providers who offer broader content. But people could choose “content bubbles” providers. The good thing, though, is that they’re choosing them, and they know they’re doing that, just like they know they’re choosing to watch one television channel and not another.

Of course it’s important for the operation of society that people have some level of shared values. But what should those shared values be, and who should decide them? In a totalitarian system, it’s basically the government. Right now, with the current monolithic state of automated content selection, one could argue it’s the automated content selection businesses.

If I were running one of those businesses, I’d certainly not want to get set up as the moral arbiter for the world; it seems like a no-win role. With the third-party providers idea, there’s a way out, without damaging the viability of the business. Yes, users get more control, as arguably they should have, given that they are the fuel that makes the business work. But the core business model is still perfectly intact. And there’s a new market that opens up, for third-party providers, potentially delivering all sorts of new economic value.

At the beginning of last weekend, what I just described was basically the state of my thinking. But what should I do with it? Was there some issue I hadn’t noticed? Was I falling into some political or business trap? I wasn’t sure. But it seemed as if some idea in this area was needed, and I had an idea, so I really should tell people about it.

So I quickly wrote up the written testimony for the hearing, and sent it in by the deadline on Sunday morning. (The full text of the testimony is included at the end of this piece.)

This morning was the hearing itself. It was in the same room as the hearing Mark Zuckerberg did last fall. The staffers were saying that they expected a good turnout of senators, and that of the 24 senators on the subcommittee (out of 100 total in the Senate), they expected about 15 to show up at some point or another.

At the beginning, staffers were putting out nameplates for the senators. I was trying to figure out what the arrangement was. And then I realized! It was a horseshoe configuration and Republican senators were on the right side of the horseshoe, Democrats were on the left. There really are right and left wings! (Yes, I obviously don’t watch C-SPAN enough, or I’d already know that.)

When the four of us on the panel were getting situated, one of the senators (Marsha Blackburn [R-TN]) wandered up, and started talking about computational irreducibility. Wow, I thought, this is going to be interesting. That’s a pretty abstruse science concept to be finding its way into the Senate.

Everyone had five minutes to give opening remarks, and everyone had a little countdown timer in front of them. I talked a bit about the science and technology of AI and explainability. I mentioned computational contracts and the concept of an AI Constitution. Then I said I didn’t want to just explain that everything was impossible—and gave a brief summary of my ideas for solutions. Rather uncharacteristically for me, I ended a full minute before my time was up.

The format for statements and questions was five minutes per senator. The issues raised were quite diverse. I quickly realized, though, that it was unfortunate that I really had three different things I was talking about (non-explainability, computational laws, and my ideas for a near-term solution). In retrospect perhaps I should have concentrated on the near-term solution, but it felt odd to be emphasizing something I just thought of last week, rather than something I’ve thought about for many years.

Still, it was fascinating—and a sign of things to come—to see serious issues about what amounts to the philosophy of computation being discussed in the Senate. To be fair, I had done a small hearing at the Senate back in 2003 (my only other such experience) about the ideas in *A New Kind of Science*. But then it had been very much on the “science track”; now the whole discussion was decidedly mainstream.

I couldn’t help thinking that I was witnessing the concept of computation beginning to come of age. What used to be esoteric issues in the theory of computation were now starting to be things that senators were discussing writing laws about. One of the senators mentioned atomic energy, and compared it to AI. But really, AI is going to be something much more central to the whole future of our species.

It enables us to do so much. But yet it forces us to confront what we want to do, and who we want to be. Today it’s rare and exotic for the Senate to be discussing issues of AI. In time I suspect AI and its many consequences will be a dominant theme in many Senate discussions. This is just the beginning.

I wish we were ready to really start creating an AI Constitution. But we’re not (and it doesn’t help that we don’t have an AI analog of the few thousand years of human political history that were available as a guide when the US Constitution was drafted). Still, issue by issue I suspect we’ll move closer to the point where having a coherent AI Constitution becomes a necessity. No doubt there’ll be different ones in different communities and different countries. But one day a group like the one I saw today—with all the diverse and sometimes colorful characters involved—will end up having to figure out just how we humans interact with AI and the computational world.

*Automated content selection by internet businesses has become progressively more contentious—leading to calls to make it more transparent or constrained. I explain some of the complex intellectual and scientific problems involved, then offer two possible technical and market suggestions for paths forward. Both are based on giving users a choice about who to trust for the final content they see—in one case introducing what I call “final ranking providers”, and in the other case what I call “constraint providers”. *

There are many kinds of businesses that operate on the internet, but some of the largest and most successful are what one can call *automated content selection businesses*. Facebook, Twitter, YouTube and Google are all examples. All of them deliver content that others have created, but a key part of their value is associated with their ability to (largely) automatically select what content they should serve to a given user at a given time—whether in news feeds, recommendations, web search results, or advertisements.

What criteria are used to determine content selection? Part of the story is certainly to provide good service to users. But the paying customers for these businesses are not the users, but advertisers, and necessarily a key objective of these businesses must be to maximize advertising income. Increasingly, there are concerns that this objective may have unacceptable consequences in terms of content selection for users. And in addition there are concerns that—through their content selection—the companies involved may be exerting unreasonable influence in other kinds of business (such as news delivery), or in areas such as politics.

Methods for content selection—using machine learning, artificial intelligence, etc.—have become increasingly sophisticated in recent years. A significant part of their effectiveness—and economic success—comes from their ability to use extensive data about users and their previous activities. But there has been increasing dissatisfaction and, in some cases, suspicion about just what is going on inside the content selection process.

This has led to a desire to make content selection more transparent, and perhaps to constrain aspects of how it works. As I will explain, these are not easy things to achieve in a useful way. And in fact, they run into deep intellectual and scientific issues, that are in some ways a foretaste of problems we will encounter ever more broadly as artificial intelligence becomes more central to the things we do. Satisfactory ultimate solutions will be difficult to develop, but I will suggest here two near-term practical approaches that I believe significantly address current concerns.

Whether one’s dealing with videos, posts, webpages, news items or, for that matter, ads, the underlying problem of automated content selection (ACS) is basically always the same. There are many content items available (perhaps even billions of them), and somehow one has to quickly decide which ones are “best” to show to a given user at a given time. There’s no fundamental principle to say what “best” means, but operationally it’s usually in the end defined in terms of what maximizes user clicks, or revenue from clicks.

The major innovation that has made modern ACS systems possible is the idea of automatically extrapolating from large numbers of examples. The techniques have evolved, but the basic idea is to effectively deduce a model of the examples and then to use this model to make predictions, for example about what ranking of items will be best for a given user.

Because it will be relevant for the suggestions I’m going to make later, let me explain here a little more about how most current ACS systems work in practice. The starting point is normally to extract a collection of perhaps hundreds or thousands of features (or “signals”) for each item. If a human were doing it, they might use features like: “How long is the video? Is it entertainment or education? Is it happy or sad?” But these days—with the volume of data that’s involved—it’s a machine doing it, and often it’s also a machine figuring out what features to extract. Typically the machine will optimize for features that make its ultimate task easiest—whether or not (and it’s almost always not) there’s a human-understandable interpretation of what the features represent.

As an example, here are the letters of the alphabet automatically laid out by a machine in a “feature space” in which letters that “look similar” appear nearby:

How does the machine know what features to extract to determine whether things will “look similar”? A typical approach is to give it millions of images that have been tagged with what they are of (“elephant”, “teacup”, etc.). And then from seeing which images are tagged the same (even though in detail they look different), the machine is able—using the methods of modern machine learning—to identify features that could be used to determine how similar images of anything should be considered to be.

OK, so let’s imagine that instead of letters of the alphabet laid out in a 2D feature space, we’ve got a million videos laid out in a 200-dimensional feature space. If we’ve got the features right, then videos that are somehow similar should be nearby in this feature space.

But given a particular person, what videos are they likely to want to watch? Well, we can do the same kind of thing with people as with videos: we can take the data we know about each person, and extract some set of features. “Similar people” would then be nearby in “people feature space”, and so on.

But now there’s a “final ranking” problem. Given features of videos, and features of people, which videos should be ranked “best” for which people? Often in practice, there’s an initial coarse ranking. But then, as soon as we have a specific definition of “best”—or enough examples of what we mean by “best”—we can use machine learning to learn a program that will look at the features of videos and people, and will effectively see how to use them to optimize the final ranking.

The setup is a bit different in different cases, and there are many details, most of which are proprietary to particular companies. However, modern ACS systems—dealing as they do with immense amounts of data at very high speed—are a triumph of engineering, and an outstanding example of the power of artificial intelligence techniques.

When one hears the term “algorithm” one tends to think of a procedure that will operate in a precise and logical way, always giving a correct answer, not influenced by human input. One also tends to think of something that consists of well-defined steps, that a human could, if needed, readily trace through.

But this is pretty far from how modern ACS systems work. They don’t deal with the same kind of precise questions (“What video should I watch next?” just isn’t something with a precise, well-defined answer). And the actual methods involved make fundamental use of machine learning, which doesn’t have the kind of well-defined structure or explainable step-by-step character that’s associated with what people traditionally think of as an “algorithm”. There’s another thing too: while traditional algorithms tend to be small and self-contained, machine learning inevitably requires large amounts of externally supplied data.

In the past, computer programs were almost exclusively written directly by humans (with some notable exceptions in my own scientific work). But the key idea of machine learning is instead to create programs automatically, by “learning the program” from large numbers of examples. The most common type of program on which to apply machine learning is a so-called neural network. Although originally inspired by the brain, neural networks are purely computational constructs that are typically defined by large arrays of numbers called weights.

Imagine you’re trying to build a program that recognizes pictures of cats versus dogs. You start with lots of specific pictures that have been identified—normally by humans—as being either of cats or dogs. Then you “train” a neural network by showing it these pictures and gradually adjusting its weights to make it give the correct identification for these pictures. But then the crucial point is that the neural network generalizes. Feed it another picture of a cat, and even if it’s never seen that picture before, it’ll still (almost certainly) say it’s a cat.

What will it do if you feed it a picture of a cat dressed as a dog? It’s not clear what the answer is supposed to be. But the neural network will still confidently give some result—that’s derived in some way from the training data it was given.

So in a case like this, how would one tell why the neural network did what it did? Well, it’s difficult. All those weights inside the network were learned automatically; no human explicitly set them up. It’s very much like the case of extracting features from images of letters above. One can use these features to tell which letters are similar, but there’s no “human explanation” (like “count the number of loops in the letter”) of what each of the features are.

Would it be possible to make an explainable cat vs. dog program? For 50 years most people thought that a problem like cat vs. dog just wasn’t the kind of thing computers would be able to do. But modern machine learning made it possible—by learning the program rather than having humans explicitly write it. And there are fundamental reasons to expect that there can’t in general be an explainable version—and that if one’s going to do the level of automated content selection that people have become used to, then one cannot expect it to be broadly explainable.

Sometimes one hears it said that automated content selection is just “being done by an algorithm”, with the implication that it’s somehow fair and unbiased, and not subject to human manipulation. As I’ve explained, what’s actually being used are machine learning methods that aren’t like traditional precise algorithms.

And a crucial point about machine learning methods is that by their nature they’re based on learning from examples. And inevitably the results they give depend on what examples were used.

And this is where things get tricky. Imagine we’re training the cat vs. dog program. But let’s say that, for whatever reason, among our examples there are spotted dogs but no spotted cats. What will the program do if it’s shown a spotted cat? It might successfully recognize the shape of the cat, but quite likely it will conclude—based on the spots—that it must be seeing a dog.

So is there any way to guarantee that there are no problems like this, that were introduced either knowingly or unknowingly? Ultimately the answer is no—because one can’t know everything about the world. Is the lack of spotted cats in the training set an error, or are there simply no spotted cats in the world?

One can do one’s best to find correct and complete training data. But one will never be able to prove that one has succeeded.

But let’s say that we want to ensure some property of our results. In almost all cases, that’ll be perfectly possible—either by modifying the training set, or the neural network. For example, if we want to make sure that spotted cats aren’t left out, we can just insist, say, that our training set has an equal number of spotted and unspotted cats. That might not be a correct representation of what’s actually true in the world, but we can still choose to train our neural network on that basis.

As a different example, let’s say we’re selecting pictures of pets. How many cats should be there, versus dogs? Should we base it on the number of cat vs. dog images on the web? Or how often people search for cats vs. dogs? Or how many cats and dogs are registered in America? There’s no ultimate “right answer”. But if we want to, we can give a constraint that says what should happen.

This isn’t really an “algorithm” in the traditional sense either—not least because it’s not about abstract things; it’s about real things in the world, like cats and dogs. But an important development (that I happen to have been personally much involved in for 30+ years) is the construction of a computational language that lets one talk about things in the world in a precise way that can immediately be run on a computer.

In the past, things like legal contracts had to be written in English (or “legalese”). Somewhat inspired by blockchain smart contracts, we are now getting to the point where we can write automatically executable computational contracts not in human language but in computational language. And if we want to define constraints on the training sets or results of automated content selection, this is how we can do it.

Why is it difficult to find solutions to problems associated with automated content selection? In addition to all the business, societal and political issues, there are also some deep issues of basic science involved. Here’s a list of some of those issues. The precursors of these issues date back nearly a century, though it’s only quite recently (in part through my own work) that they’ve become clarified. And although they’re not enunciated (or named) as I have here, I don’t believe any of them are at this point controversial—though to come to terms with them requires a significant shift in intuition from what exists without modern computational thinking.

*Even if you don’t explicitly know something (say about someone), it can almost always be statistically deduced if there’s enough other related data available*

What is a particular person’s gender identity, ethnicity, political persuasion, etc.? Even if one’s not allowed to explicitly ask these questions, it’s basically inevitable that with enough other data about the person, one will be able to deduce what the best answers must be.

Everyone is different in detail. But the point is that there are enough commonalities and correlations between people that it’s basically inevitable that with enough data, one can figure out almost any attribute of a person.

The basic mathematical methods for doing this were already known from classical statistics. But what’s made this now a reality is the availability of vastly more data about people in digital form—as well as the ability of modern machine learning to readily work not just with numerical data, but also with things like textual and image data.

What is the consequence of ubiquitous data deducibility? It means that it’s not useful to block particular pieces of data—say in an attempt to avoid bias—because it’ll essentially always be possible to deduce what that blocked data was. And it’s not just that this can be done intentionally; inside a machine learning system, it’ll often just happen automatically and invisibly.

*Even given every detail of a program, it can be arbitrarily hard to predict what it will or won’t do*

One might think that if one had the complete code for a program, one would readily be able to deduce everything about what the program would do. But it’s a fundamental fact that in general one can’t do this. Given a particular input, one can always just run the program and see what it does. But even if the program is simple, its behavior may be very complicated, and computational irreducibility implies that there won’t be a way to “jump ahead” and immediately find out what the program will do, without explicitly running it.

One consequence of this is that if one wants to know, for example, whether with any input a program can do such-and-such, then there may be no finite way to determine this—because one might have to check an infinite number of possible inputs. As a practical matter, this is why bugs in programs can be so hard to detect. But as a matter of principle, it means that it can ultimately be impossible to completely verify that a program is “correct”, or has some specific property.

Software engineering has in the past often tried to constrain the programs it deals with so as to minimize such effects. But with methods like machine learning, this is basically impossible to do. And the result is that even if it had a complete automated content selection program, one wouldn’t in general be able to verify that, for example, it could never show some particular bad behavior.

*For a well-optimized computation, there’s not likely to be a human-understandable narrative about how it works inside*

Should we expect to understand how our technological systems work inside? When things like donkeys were routinely part of such systems, people didn’t expect to. But once the systems began to be “completely engineered” with cogs and levers and so on, there developed an assumption that at least in principle one could explain what was going on inside. The same was true with at least simpler software systems. But with things like machine learning systems, it absolutely isn’t.

Yes, one can in principle trace what happens to every bit of data in the program. But can one create a human-understandable narrative about it? It’s a bit like imagining we could trace the firing of every neuron in a person’s brain. We might be able to predict what a person would do in a particular case, but it’s a different thing to get a high-level “psychological narrative” about why they did it.

Inside a machine learning system—say the cats vs. dogs program—one can think of it as extracting all sorts of features, and making all sorts of distinctions. And occasionally one of these features or distinctions might be something we have a word for (“pointedness”, say). But most of the time they’ll be things the machine learning system discovered, and they won’t have any connection to concepts we’re familiar with.

And in fact—as a consequence of computational irreducibility—it’s basically inevitable that with things like the finiteness of human language and human knowledge, in any well-optimized computation we’re not going to be able to give a high-level narrative to explain what it’s doing. And the result of this is that it’s impossible to expect any useful form of general “explainability” for automated content selection systems.

*There’s no finite set of principles that can completely define any reasonable, practical system of ethics*

Let’s say one’s trying to teach ethics to a computer, or an artificial intelligence. Is there some simple set of principles—like Asimov’s Laws of Robotics—that will capture a viable complete system of ethics? Looking at the complexity of human systems of laws one might suspect that the answer is no. And in fact this is presumably a fundamental result—essentially another consequence of computational irreducibility.

Imagine that we’re trying to define constraints (or “laws”) for an artificial intelligence, in order to ensure that the AI behaves in some particular “globally ethical” way. We set up a few constraints, and we find that many things the AI does follow our ethics. But computational irreducibility essentially guarantees that eventually there’ll always be something unexpected that’s possible. And the only way to deal with that is to add a “patch”—essentially to introduce another constraint for that new case. And the issue is that this will never end: there’ll be no way to give a finite set of constraints that will achieve our global objectives. (There’s a somewhat technical analogy of this in mathematics, in which Gödel’s theorem shows that no finite set of axiomatic constraints can give one only ordinary integers and nothing else.)

So for our purposes here, the main consequence of this is that we can’t expect to have some finite set of computational principles (or, for that matter, laws) that will constrain automated content selection systems to always behave according to some reasonable, global system of ethics—because they’ll always be generating unexpected new cases that we have to define a new principle to handle.

I’ve described some of the complexities of handling issues with automated content selection systems. But what in practice can be done?

One obvious idea would be just to somehow “look inside” the systems, auditing their internal operation and examining their construction. But for both fundamental and practical reasons, I don’t think this can usefully be done. As I’ve discussed, to achieve the kind of functionality that users have become accustomed to, modern automated content selection systems make use of methods such as machine learning that are not amenable to human-level explainability or systematic predictability.

What about checking whether a system is, for example, biased in some way? Again, this is a fundamentally difficult thing to determine. Given a particular definition of bias, one could look at the internal training data used for the system—but this won’t usually give more information than just studying how the system behaves.

What about seeing if the system has somehow intentionally been made to do this or that? It’s conceivable that the source code could have explicit “if” statements that would reveal intention. But the bulk of the system will tend to consist of trained neural networks and so on—and as in most other complex systems, it’ll typically be impossible to tell what features might have been inserted “on purpose” and what are just accidental or emergent properties.

So if it’s not going to work to “look inside” the system, what about restricting how the system can be set up? For example, one approach that’s been suggested is to limit the inputs that the system can have, in an extreme case preventing it from getting any personal information about the user and their history. The problem with this is that it negates what’s been achieved over the course of many years in content selection systems—both in terms of user experience and economic success. And for example, knowing nothing about a user, if one has to recommend a video, one’s just going to have to suggest whatever video is generically most popular—which is very unlikely to be what most users want most of the time.

As a variant of the idea of blocking all personal information, one can imagine blocking just some information—or, say, allowing a third party to broker what information is provided. But if one wants to get the advantages of modern content selection methods, one’s going to have to leave a significant amount of information—and then there’s no point in blocking anything, because it’ll almost certainly be reproducible through the phenomenon of data deducibility.

Here’s another approach: what about just defining rules (in the form of computational contracts) that specify constraints on the results content selection systems can produce? One day, we’re going to have to have such computational contracts to define what we want AIs in general to do. And because of ethical incompleteness—like with human laws—we’re going to have to have an expanding collection of such contracts.

But even though (particularly through my own efforts) we’re beginning to have the kind of computational language necessary to specify a broad range of computational contracts, we realistically have to get much more experience with computational contracts in standard business and other situations before it makes sense to try setting them up for something as complex as global constraints on content selection systems.

So, what can we do? I’ve not been able to see a viable, purely technical solution. But I have formulated two possible suggestions based on mixing technical ideas with what amount to market mechanisms.

The basic principle of both suggestions is to give users a choice about who to trust, and to let the final results they see not necessarily be completely determined by the underlying ACS business.

There’s been debate about whether ACS businesses are operating as “platforms” that more or less blindly deliver content, or whether they’re operating as “publishers” who take responsibility for content they deliver. Part of this debate can be seen as being about what responsibility should be taken for an AI. But my suggestions sidestep this issue, and in different ways tease apart the “platform” and “publisher” roles.

It’s worth saying that the whole content platform infrastructure that’s been built by the large ACS businesses is an impressive and very valuable piece of engineering—managing huge amounts of content, efficiently delivering ads against it, and so on. What’s really at issue is whether the fine details of the ACS systems need to be handled by the same businesses, or whether they can be opened up. (This is relevant only for ACS businesses whose network effects have allowed them to serve a large fraction of a population. Small ACS businesses don’t have the same kind of lock-in.)

As I discussed earlier, the rough (and oversimplified) outline of how a typical ACS system works is that first features are extracted for each content item and each user. Then, based on these features, there’s a final ranking done that determines what will actually be shown to the user, in what order, etc.

What I’m suggesting is that this final ranking doesn’t have to be done by the same entity that sets up the infrastructure and extracts the features. Instead, there could be a single content platform but a variety of “final ranking providers”, who take the features, and then use their own programs to actually deliver a final ranking.

Different final ranking providers might use different methods, and emphasize different kinds of content. But the point is to let users be free to choose among different providers. Some users might prefer (or trust more) some particular provider—that might or might not be associated with some existing brand. Other users might prefer another provider, or choose to see results from multiple providers.

How technically would all this be implemented? The underlying content platform (presumably associated with an existing ACS business) would take on the large-scale information-handling task of deriving extracted features. The content platform would provide sufficient examples of underlying content (and user information) and its extracted features to allow the final ranking provider’s systems to “learn the meaning” of the features.

When the system is running, the content platform would in real time deliver extracted features to the final ranking provider, which would then feed this into whatever system they have developed (which could use whatever automated or human selection methods they choose). This system would generate a ranking of content items, which would then be fed back to the content platform for final display to the user.

To avoid revealing private user information to lots of different providers, the final ranking provider’s system should probably run on the content platform’s infrastructure. The content platform would be responsible for the overall user experience, presumably providing some kind of selector to pick among final ranking providers. The content platform would also be responsible for delivering ads against the selected content.

Presumably the content platform would give a commission to the final ranking provider. If properly set up, competition among final ranking providers could actually increase total revenue to the whole ACS business, by achieving automated content selection that serves users and advertisers better.

One feature of Suggestion A is that it breaks up ACS businesses into a content platform component, and a final ranking component. (One could still imagine, however, that a quasi-independent part of an ACS business could be one of the competing final ranking providers.) An alternative suggestion is to keep ACS businesses intact, but to put constraints on the results that they generate, for example forcing certain kinds of balance, etc.

Much like final ranking providers, there would be constraint providers who define sets of constraints. For example, a constraint provider could require that there be on average an equal number of items delivered to a user that are classified (say, by a particular machine learning system) as politically left-leaning or politically right-leaning.

Constraint providers would effectively define computational contracts about properties they want results delivered to users to have. Different constraint providers would define different computational contracts. Some might want balance; others might want to promote particular types of content, and so on. But the idea is that users could decide what constraint provider they wish to use.

How would constraint providers interact with ACS businesses? It’s more complicated than for final ranking providers in Suggestion A, because effectively the constraints from constraint providers have to be woven deeply into the basic operation of the ACS system.

One possible approach is to use the machine learning character of ACS systems, and to insert the constraints as part of the “learning objectives” (or, technically, “loss functions”) for the system. Of course, there could be constraints that just can’t be successfully learned (for example, they might call for types of content that simply don’t exist). But there will be a wide range of acceptable constraints, and in effect, for each one, a different ACS system would be built.

All these ACS systems would then be operated by the underlying ACS business, with users selecting which constraint provider—and therefore which overall ACS system—they want to use.

As with Suggestion A, the underlying ACS business would be responsible for delivering advertising, and would pay a commission to the constraint provider.

Although their detailed mechanisms are different, both Suggestions A and B attempt to leverage the exceptional engineering and commercial achievements of the ACS businesses, while diffusing current trust issues about content selection, providing greater freedom for users, and inserting new opportunities for market growth.

The suggestions also help with some other issues. One example is the banning of content providers. At present, with ACS businesses feeling responsible for content on their platforms, there is considerable pressure, not least from within the ACS businesses themselves, to ban content providers that they feel are providing inappropriate content. The suggestions diffuse the responsibility for content, potentially allowing the underlying ACS businesses not to ban anything but explicitly illegal content.

It would then be up to the final ranking providers, or the constraint providers, to choose whether or not to deliver or allow content of a particular character, or from a particular content provider. In any given case, some might deliver or allow it, and some might not, removing the difficult all-or-none nature of the banning that’s currently done by ACS businesses.

One feature of my suggestions is that they allow fragmentation of users into groups with different preferences. At present, all users of a particular ACS business have content that is basically selected in the same way. With my suggestions, users of different persuasions could potentially receive completely different content, selected in different ways.

While fragmentation like this appears to be an almost universal tendency in human society, some might argue that having people routinely be exposed to other people’s points of view is important for the cohesiveness of society. And technically some version of this would not be difficult to achieve. For example, one could take the final ranking or constraint providers, and effectively generate a feature space plot of what they do.

Some would be clustered close together, because they lead to similar results. Others would be far apart in feature space—in effect representing very different points of view. Then if someone wanted to, say, see their typical content 80% of the time, but see different points of view 20% of the time, the system could combine different providers from different parts of feature space with a certain probability.

Of course, in all these matters, the full technical story is much more complex. But I am confident that if they are considered desirable, either of the suggestions I have made can be implemented in practice. (Suggestion A is likely to be somewhat easier to implement than Suggestion B.) The result, I believe, will be richer, more trusted, and even more widely used automated content selection. In effect both my suggestions mix the capabilities of humans and AIs—to help get the best of both of them—and to navigate through the complex practical and fundamental problems with the use of automated content selection.

]]>*The first workshop to define what is now the Santa Fe Institute took place on October 5–6, 1984. I was recently asked to give some reminiscences of the event, for a republication of a collection of papers derived from this and subsequent workshops.*

It was a slightly dark room, decorated with Native American artifacts. Around it were tables arranged in a large rectangle, at which sat a couple dozen men (yes, all men), mostly in their sixties. The afternoon was wearing on, with many different people giving their various views about how to organize what amounted to a putative great new interdisciplinary university.

*Here’s the original seating chart, together with a current view of the meeting room. (I’m only “Steve” to Americans currently over the age of 60…):*

I think I was less patient in those days. But eventually I could stand it no longer. I don’t remember my exact words, but they boiled down to: “What are you going to do if you only raise a few million dollars, not two billion?” It was a strange moment. After all, I was by far the youngest person there—at 25 years old—and yet it seemed to have fallen to me to play the “let’s get real” role. (To be fair, I had founded my first tech company a couple of years earlier, and wasn’t a complete stranger to the world of grandiose “what-if” discussions, even if I was surprised, though more than a little charmed, to be seeing them in the sixty-something-year-old set.)

*A fragment of my notes from the day record my feelings:*

George Cowan (Manhattan Project alum, Los Alamos administrator, and founder of the Los Alamos Bank) was running the meeting, and I sensed a mixture of frustration and relief at my question. I don’t remember precisely what he said, but it boiled down to: “Well, what do *you* think we should do?” “Well”, I said, “I do have a suggestion”. I summarized it a bit, but then it was agreed that later that day I should give a more formal presentation. And that’s basically how I came to suggest that what would become the Santa Fe Institute should focus on what I called “Complex Systems Theory”.

Of course, there was a whole backstory to this. It basically began in 1972, when I was 12 years old, and saw the cover of a college physics textbook that purported to show an arrangement of simulated colliding molecules progressively becoming more random. I was fascinated by this phenomenon, and quite soon started trying to use a computer to understand it. I didn’t get too far with this. But it was the golden age of particle physics, and I was soon swept up in publishing papers about a variety of topics in particle physics and cosmology.

Still, in all sorts of different ways I kept on coming back to my interest in how randomness—or complexity—gets produced. In 1978 I went to Caltech as a graduate student, with Murray Gell-Mann (inventor of quarks, and the first chairman of the Santa Fe Institute) doing his part to recruit me by successfully tracking down a phone number for me in England. Then in 1979, as a way to help get physics done, I set about building my first large-scale computer language. In 1981, the first version was finished, I was installed as a faculty member at Caltech—and I decided it was time for me to try something more ambitious, and really see what I could figure out about my old interest in randomness and complexity.

By then I had picked away at many examples of complexity. In self-gravitating gases. In dendritic crystal growth. In road traffic flow. In neural networks. But the reductionist physicist in me wanted to drill down and find out what was underneath all these. And meanwhile the computer language designer in me thought, “Let’s just invent something and see what can be done with it”. Well, pretty soon I invented what I later found out were called cellular automata.

I didn’t expect that simple cellular automata would do anything particularly interesting. But I decided to try computer experiments on them anyway. And to my great surprise I discovered that—despite the simplicity of their construction—cellular automata can in fact produce behavior of great complexity. It’s a major shock to traditional scientific intuition—and, as I came to realize in later years, a clue to a whole new kind of science.

But for me the period from 1981 to 1984 was an exciting one, as I began to explore the computational universe of simple programs like cellular automata, and saw just how rich and unexpected it was. David Pines, as the editor of *Reviews of Modern Physics*, had done me the favor of publishing my first big paper on cellular automata (John Maddox, editor of *Nature*, had published a short summary a little earlier). Through the Center for Nonlinear Studies, I had started making visits to Los Alamos in 1981, and I initiated and co-organized the first-ever conference devoted to cellular automata, held at Los Alamos in 1983.

In 1983 I had left Caltech (primarily as a result of an unhappy interaction about intellectual property rights) and gone to the Institute for Advanced Study in Princeton, and begun to build a group there concerned with studying the basic science of complex systems. I wasn’t sure until quite a few years later just how general the phenomena I’d seen in cellular automata were. But I was pretty certain that there were at least many examples of complexity across all sorts of fields that they’d finally let one explain in a fundamental, theoretical way.

I’m not sure when I first heard about plans for what was then called the Rio Grande Institute. But I remember not being very hopeful about it; it seemed too correlated with the retirement plans of a group of older physicists. But meanwhile, people like Pete Carruthers (director of T Division at Los Alamos) were encouraging me to think about starting my own institute to pursue the kind of science I thought could be done.

I didn’t know quite what to make of the letter I received in July 1984 from Nick Metropolis (long-time Los Alamos scientist, and inventor of the Metropolis method). It described the nascent Rio Grande Institute as “a teaching and research institution responsive to the challenge of emerging new syntheses in science”. Murray Gell-Mann had told me that it would bring together physics and archaeology, linguistics and cosmology, and more. But at least in the circulated documents, the word “complexity” appeared quite often.

The invitation described the workshop as being “to examine a concept for a fresh approach to research and teaching in rapidly developing fields of scientific activity dealing with highly complex, interactive systems”. Murray Gell-Mann, who had become a sort of *de facto* intellectual leader of the effort, was given to quite flowery descriptions, and declared that the institute would be involved with “simplicity and complexity”.

When I arrived at the workshop it was clear that everyone wanted their favorite field to get a piece of the potential action. Should I even bring up my favorite emerging field? Or should I just make a few comments about computers and let the older guys do their thing?

As I listened to the talks and discussions, I kept wondering how what I was studying might relate to them. Quite often I really didn’t know. At the time I still believed, for example, that adaptive systems might have fundamentally different characteristics. But still, the term “complexity” kept on coming up. And if the Rio Grande Institute needed an area to concentrate on, it seemed that a general study of complexity would be the closest to being central to everything they were talking about.

I’m not sure quite what the people in the room made of my speech about “complex systems theory”. But I think I did succeed in making the point that there really could be a general “science of complexity”—and that things like cellular automata could show one how it might work. People had been talking about the complexity of this, or the complexity of that. But it seemed like I’d at least started the process of getting people to talk about complexity as an abstract thing one could expect to have general theories about.

After that first workshop, I had a few more interactions with what was to be the Santa Fe Institute. I still wasn’t sure what was going to happen with it—but the “science of complexity” idea did seem to be sticking. Meanwhile, however, I was forging ahead with my own plans to start a complex systems institute (I avoided the term “complexity theory” out of deference to the rather different field of computational complexity theory). I was talking to all sorts of universities, and in fact David Pines was encouraging me to consider the University of Illinois.

George Cowan asked me if I’d be interested in running the research program for the Santa Fe Institute, but by that point I was committed to starting my own operation, and it wasn’t long afterwards that I decided to do it at the University of Illinois. My Center for Complex Systems Research—and my journal *Complex Systems*—began operations in the summer of 1986.

I’m not sure how things would have been different if I’d ended up working with the Santa Fe Institute. But as it was, I rather quickly tired of the effort to raise money for complex systems research, and I was soon off creating what became Mathematica (and now the Wolfram Language), and starting my company Wolfram Research.

By the early 1990s, probably in no small part through the efforts of the Santa Fe Institute, “complexity” had actually become a popular buzzword, and, partly through a rather circuitous connection to climate science, funding had started pouring in. But having launched Mathematica and my company, I’d personally pretty much vanished from the scene, working quietly on using the tools I’d created to pursue my interests in basic science. I thought it would only take a couple of years, but in the end it took more than a decade.

I discovered a lot—and realized that, yes, the phenomena I’d first seen with cellular automata and talked about at the Santa Fe workshop were indeed a clue to a whole new kind of science, with all sorts of implications for long-standing problems and for the future. I packaged up what I’d figured out—and in 2002 published my magnum opus *A New Kind of Science*.

It was strange to reemerge after a decade and a half away. The Santa Fe Institute had continued to pursue the science of complexity. As something of a hermit in those years, I hadn’t interacted with it—but there was curiosity about what I was doing (highlighted, if nothing else, by a bizarre incident in 1998 involving “leaks” about my research). When my book came out in 2002 I was pleased that I thought I’d actually done what I talked about doing back at that Santa Fe workshop in 1984—as well as much more.

But by then almost nobody who’d been there in 1984 was still involved with the Santa Fe Institute, and instead there was a “new guard” (now, I believe, again departed), who, far from being pleased with my progress and success in broadening the field, actually responded with rather unseemly hostility.

It’s been an interesting journey from those days in October 1984. Today complex systems research is very definitely “a thing”, and there are hundreds of “complex systems” institutes around the world. (Though I still don’t think the *basic* science of complexity, as opposed to its applications, has received the attention it should.) But the Santa Fe Institute remains the prototypical example—and it’s not uncommon when I talk about complexity research for people to ask, “Is that like what the Santa Fe Institute does?”

“Well actually”, I sometimes say, “there’s a little footnote to history about that”. And off I go, talking about that Saturday afternoon back in October 1984—when I could be reached (as the notes I distributed said) through that newfangled thing called email at **ias!swolf**

]]>