We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Botany with Bytes

00:00

Formal Metadata

Title
Botany with Bytes
Title of Series
Number of Parts
66
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Producer
Production PlaceSan Antonio

Content Metadata

Subject Area
Genre
Abstract
Plants are tiny computers. As they grow, the sprouts are computing from first principles how to be a plant. We’ll see how they do it! This talk uses Ruby and the ‘graphics’ gem to build models of all kinds of plants, from algae blooms to juniper branches. We’ll touch on rewriting systems, formal grammars, and Alan Turing’s contributions to botany. We’ll look at the shapes of euphorbia, artichoke, and oregon grape, and how these come from plants’ love of sunlight and greedy desire for growth. By the end, we'll have a series of great visual metaphors for fundamental computer science concepts!
26
Thumbnail
44:21
Scheduling (computing)Public key certificateAdventure gameRight angleComputer animation
TwitterGame theoryCodeSystem callMathematical optimizationProcess (computing)Inheritance (object-oriented programming)Visualization (computer graphics)Installation artHeegaard splittingComputer simulationLibrary (computing)ECosTheory of everythingLecture/Conference
Rule of inferenceSystem programmingFibonacci numberElectric generatorForm (programming)LengthSound effectPhysical systemProcess (computing)Lindenmayer-SystemSet (mathematics)Rule of inferenceNeuroinformatikComputer animationLecture/Conference
String (computer science)Line (geometry)System programmingRewritingNeuroinformatikPhysical systemData structureComputer scienceCellular automatonGame theoryFraktalgeometrieLine (geometry)String (computer science)Price indexFormal grammarRule of inferenceForm (programming)GradientTriangleLevel (video gaming)Video gameComputer animation
String (computer science)Rule of inferenceLine (geometry)Heegaard splittingFormal grammarRule of inferenceString (computer science)Lindenmayer-SystemProgrammer (hardware)Cellular automatonDimensional analysisLevel (video gaming)Game theoryVideo gameComputer animation
String (computer science)Rule of inferenceDeterministic finite automatonComputerHierarchyRegular graphLindenmayer-SystemString (computer science)Regulärer Ausdruck <Textverarbeitung>Physical systemMoving averageRegular graphNeuroinformatikFormal grammarContext awarenessGroup actionFormal languageInfinitySemiconductor memoryProof theoryMemory managementTuring testHierarchyParsingState of matterContext-free grammarProgram slicingSet (mathematics)CuboidMultiplication signProgramming languageRule of inferenceData structureSubsetTrailCanonical ensembleRandom accessSocial classFunctional (mathematics)MereologyBitContext-sensitive languageRepeating decimalCodeProcess (computing)AreaInstance (computer science)Workstation <Musikinstrument>2 (number)Sensitivity analysisSimilarity (geometry)Cellular automatonComputer animationLecture/Conference
Computer multitaskingSystem programmingRegulärer Ausdruck <Textverarbeitung>Context awarenessMereologyStreaming mediaProgram slicingTrailFormal grammarPhysical systemLindenmayer-SystemMatching (graph theory)Data structureRule of inferenceChemical equationToken ringNumberMappingRegulärer Ausdruck <Textverarbeitung>IterationRAIDLecture/ConferenceComputer animation
Physical systemRule of inferencePhysical systemVideo game consoleRule of inferenceLogicWorkstation <Musikinstrument>State of matterImplementationElectronic mailing listEntire functionTrailLine (geometry)Hash functionRhombusLindenmayer-SystemComputer animation
Dimensional analysisRight anglePerformance appraisalTurtle graphicsRule of inferencePhysical systemElectric generatorTurtle graphicsSymbol tableElectronic mailing listDegree (graph theory)Right angleComputer programmingGame controllerOcean currentNumberRotationPosition operatorPoisson-KlammerSet (mathematics)ImplementationSoftware frameworkString (computer science)Lindenmayer-SystemAxiom of choiceData structureMedical imagingMatrix (mathematics)Connected spaceVideo gameProgrammer (hardware)Local ringDimensional analysisCASE <Informatik>Programming languageStatisticsLine (geometry)Positional notationDrop (liquid)Lecture/ConferenceComputer animation
State of matterRight angleState of matterQuicksortRule of inferenceRecursionData structurePosition operatorPoint (geometry)Physical systemStaff (military)Computer animationLecture/Conference
Right angleTurtle graphicsPhysical systemTurtle graphicsQuicksortSymbol tableRule of inferenceArithmetic meanState of matterLindenmayer-SystemElectric generatorPhysical systemComputer animation
Rule of inferenceBranch (computer science)Physical systemStatisticsPosition operatorTerm (mathematics)Process (computing)Lindenmayer-SystemBranch (computer science)Turtle graphicsNetwork topologyAngleDegree (graph theory)String (computer science)Data structureMultiplication signPerformance appraisalRight anglePresentation of a groupPlanningLecture/Conference
Branch (computer science)Right angleFormal grammarApproximationNeuroinformatikTurtle graphicsPhysical systemPoint (geometry)Branch (computer science)LengthComputer animationLecture/Conference
Lindenmayer-SystemNeuroinformatikFormal grammarPhysical systemMilitary baseLecture/Conference
Rule of inferencePhysical systemTetraederView (database)AreaPlanningComputer animationLecture/ConferenceDiagram
Kolmogorov complexityComputer simulationDifferent (Kate Ryan album)Direction (geometry)Multiplication signComplex (psychology)Particle systemAreaComputer simulationCodeQuicksortCharacteristic polynomialFluidSpiralReliefPattern languagePlanningDrop (liquid)Lecture/Conference
Drop (liquid)FluidPattern languageCharacteristic polynomialSpiralPhysical lawGraphics libraryApproximationParticle system
Kolmogorov complexityHypothesisTuring testParticle systemPhysical lawSpiralGraphics libraryCodeMathematical optimizationMultiplication signNeuroinformatikForm (programming)Computer simulationLaptopHypothesisTuring testQuadrilateralNetwork topologyCASE <Informatik>MathematicsComplex (psychology)Programming languageClosed setSystem callComputer animationLecture/Conference
Physical systemRotationRule of inferenceTuring testLaptopAngleCirclePoint (geometry)Degree (graph theory)Closed setForm (programming)RotationLindenmayer-SystemCASE <Informatik>Positional notation
Rule of inferenceRotationKolmogorov complexitySummierbarkeitCodeMultiplication signCodeComplex (psychology)LinearizationLine (geometry)Lindenmayer-SystemLecture/Conference
Dimensional analysisMultiplication signPlanningException handlingVideo gameFrequencyProcess (computing)Line (geometry)Cellular automatonMachine visionSingle-precision floating-point formatSpacetimeLecture/ConferenceComputer animation
Cellular automatonSpacetimeDot productPolygonBoundary value problemCellular automatonNumberQuicksortForm (programming)Computer animationLecture/Conference
Cellular automatonBoundary value problemCellular automatonConnected spaceInformationCASE <Informatik>Line (geometry)Disk read-and-write headPoint (geometry)Graph (mathematics)Computer scienceTrailLecture/ConferenceComputer animation
Demo (music)Line (geometry)Graph (mathematics)Computer scienceCellular automatonComputer animationDiagramLecture/Conference
Cellular automatonForm (programming)Data structureDimensional analysisPhysical systemTouchscreenShape (magazine)WaveStiff equationLine (geometry)Vertex (graph theory)Computer animationLecture/Conference
CurvatureSurfaceNegative numberSign (mathematics)SphereHyperbolischer RaumParallel portExistenceData structureLatent heatSurfaceTable (information)SpacetimeCategory of beingUniqueness quantificationSet (mathematics)Direction (geometry)MultiplicationDegree (graph theory)Pole (complex analysis)Parallel portLine (geometry)Hyperbolischer RaumGreat circleCurvePoint (geometry)Different (Kate Ryan album)Drop (liquid)Right angleNichtlineares GleichungssystemService (economics)Metropolitan area networkSphereComputer animationLecture/Conference
Software engineeringDistancePoint (geometry)Computer animationLecture/Conference
AreaPattern languageSolid geometryComputer simulationLatent heatComputer programmingReading (process)Video gameFormal grammarSurfaceMultiplication signCartesian coordinate systemFilm editingNeuroinformatikParsingTheoryField (computer science)Service (economics)Natural numberData structureTuring testRight angleMathematicsLecture/Conference
Transcript: English(auto-generated)
Thank you all for coming to Botany with Bytes. I realize this is one of the more obscure topics
on the Ruby Conference schedule, so I feel like you're absolutely the most adventurous crowd at RubyConf. Right on, get on ya. Welcome, this is Botany with Bytes. I'm Lino Nicolai. So this talk is very simulation and graphics focused. So this talk uses the graphics gem.
This is a very new gem, still in beta, authored by Ryan Davis, who just walked in here and left. He wrote this to be a very simple, very powerful graphics library. It's based on SDL. Instead of a game library, where everything is drawn upside down, and there's a lot of optimizations for game purposes,
this is a visualizations library. So even though it does run very fast, it conforms to usual mathematical conventions, like having your up access be up, and things like that. So if you're interested in how I did any of these simulations, all of the code is done with this library,
gem install dash dash pre for the beta graphics, and all of the code is on GitHub. I am Lido underscore Nico on Twitter. You can find all of my code on GitHub with the same name, Lido Nico. So imagine you are algae. Here's you, an alga.
We'll call you A, for alga, that makes sense. And you are going to do what algae do, which is make more algae, through a process called mitosis, which is a fancy way of saying cell division. Once you're done, you'll be the proud parent
of a baby, alga, which we'll call B, for baby. And this process will keep going. You'll keep splitting off, your little baby alga will grow up. So you have alga, baby, alga. And so on and so on and so on.
Each alga will split, each baby will grow up. And I'm just gonna start representing these things with letters so I don't have to keep drawing them. Alga, alga baby, alga baby, alga. It keeps going. Incidentally, this forms the Fibonacci sequence with the length of each generation for the same reason like breeding rabbits does.
You have that same exponentiation effect. So this process was first described by Aristid Lindenmayer, who was a human and not a plant. He was a botanist. And he called these systems of generation L-systems
after himself. They're very simple. They consist of a start, like a single alga, and a set of rules, like one alga becomes an alga and a baby. A baby grows up into a full-sized alga. So let's talk about computers for a minute.
You might recognize this as something that we come up across in our day-to-day computer science-y lives as a rewriting system. We know these from the Game of Life, which rewrites a grid. Each cell gets rewritten based on the structures around it. Or the famous Coke snowflake fractal. Each line gets rewritten with a line segment
with a triangle, and so on and so on. This is a string rewriting system. So this is a pretty solid indication. This is a grammar. But what is a grammar? A grammar is what strings or grids or lines or things, you know, you can do it in any dimension you please,
can you make with rules? Those rules can be of any form, whether it's kind of the geometric, these grid shapes map to these cells in the Game of Life. They can be like our L systems. You have an alga that is splitting and a baby alga that's growing up.
And that is the definition of a grammar. I know that seems absurdly broad. I'm gonna flip that around to something we're a little more familiar with as programmers. What strings can you match with rules? Like here is a regular expression. What strings does it match? Bet you guys didn't know you were getting a pop quiz, right?
Don't even worry about it. So when we talk about grammars, it'd be nice to be able to know where L systems fit in here and to organize grammars in a broader context. And to do that, we will use computers to organize our grammars. Now we know regular expressions fairly well.
And to implement regular expressions, the only computer you need is a deterministic finite automata. It's a fancy name for saying a bunch of states and a bunch of transitions. You don't need any memory. You don't need a stacker heap or any of that. Just leave that out.
Your computer only has to be the states and the transitions between them. Now with that computer, with all of the computers you can make in that structure, you get every regular expression ever. You get all of the sets of strings that can be matched with a regular expression. You call that the regular grammars.
So this little box indicates all of the strings that can be matched with regular expressions, with all of the grammars you can make. But we know from experience that there are grammars outside of those, like if you have, like me, totally naively tried to parse HTML with a regular expression. It doesn't happen.
Because there are structures that exist outside of this small area, there are also finite grammars, which are a subset of regular grammars. We're going to ignore them. So HTML, you need a stack to parse. You need to keep track of which tags you're inside, because you can have self-similar structures
inside those tags that you all parse in the same way. But you also have to remember how far down you've gone. And this is starting to look a little bit like a hierarchy here, right? We have the outsides and the insides. And this is called the Chomsky hierarchy, described by the linguist Noam Chomsky.
And as you might guess, there are things even beyond these context-free grammars that we use for HTML. You guys ever heard of a programming language called Ruby? No? Okay. So, beyond context-free grammars that you only need a stacked parse, we have context-sensitive grammars.
C++, for instance, is the canonical example where you can't tell, based on reading the code, if what you have is a class instantiation or a function call, because they look the same. And the only way to tell is to check your broader context to see what part of the language this is.
You need random access memory to do that. Now there's even more, like, beyond this, but what can we do to our computers, because we already have random access memory, and that's what, like, this computer has. How much farther can we go? And the answer is, recursively enumerable grammars
need a possibly infinite amount of memory to parse. Like, you might just keep going and going and going. You need the full Turing machine, with more memory than you could ever possibly enumerate. And Ruby exists, I'm not exactly sure where, somewhere between context-sensitive and recursively enumerable.
I suspect it's context-sensitive, but I don't really have a proof of that, because every time I open up parse.y, I just kind of look at it, and then close it again. And then there are things like Perl, which can't be parsed. That's not a joke, you really can't parse Perl.
So L-systems are a weird slice of a bunch of these layers. Like, you can match with an L-system, with these rules that I've been talking about, some finite grammars, some regular grammars, some context-free and some context-sensitive grammars, but not all of them.
And I'm gonna make that concrete in just a second. There are also context-sensitive L-systems, which are even stranger and beyond the scope of this talk. So L-systems are a strange slice of other grammars. So let's take the example of matching nested balanced parentheses. We know we can do this with a context-free parser,
same as HTML, you keep track of how deep you are, and you just keep recursing down. But an L-system can only match this structure if there's a token in the middle. As we saw earlier, we can make a rule saying, token X maps to X with parentheses around that,
and iterate on that process and get these nested balanced parentheses. But if there's no token in the middle, the L-system just can't conceive of that structure. You cannot match it with an L-system. And as we know, if there are an arbitrary number of balanced parentheses, you're gonna be absolutely out of luck with your regular expressions.
So here's an implementation of an L-system in Ruby. You'll notice it's dead simple. In fact, most of it is bookkeeping, like keeping track of what state we've passed in and what the rules are. So I'm just gonna highlight the actual logic of the L-systems, which is a one-liner that I've split up into three lines. You have the state, like an alga and a baby.
You split this up into a list, alga, baby. You apply the rules to each, the rules being a hash that you can map across the list, and then you join them back together. Have a nice little illustration of the diamond of how that works. That's all. That is the entire implementation of L-systems.
So you can throw this into a console, and it definitely works, I've tried it. You have your alga, all in a line. Alga, baby, alga, and so on. But what I really want, my goal for this talk, is more dimensions. So since we're talking about plants, how about a sprout?
Here we have a simple L-system describing a sprout. We can do this in two rules only. You have a leaf, and each leaf buds off into a stem, a left-facing leaf and a right-facing leaf. And each stem simply grows longer every generation.
Now, we've been drawing alga all in a line, representing that with a string, and now we need some kind of way to draw things in two dimensions, because we have left leaves and right leaves, and we're going to end up with a two-dimensional image. So to do that, we'll introduce turtle graphics. You guys ever played around with turtle graphics?
The logo programming language, maybe you were introduced to as a kid? The idea is you have a turtle, and you can command this turtle. You have control of this turtle, and you can tell the turtle to do things like move forward. And the turtle will move forward and draw as it goes. You can say, save our current position,
push that onto a stack. Turn left, any number of degrees, move forward, and then you can recall the previous position and zip back to that. So how a turtle evaluates a string, I'm just going to give a really quick example.
You provide the turtle with a string that's the S, left bracket S up at the top, and a set of rules for what the turtle can do in my implementation in Ruby. These are all symbols or a list with the turn and the number of degrees. So when you see a stem, in this case, move forward. When you see an L, move forward.
If you see a left bracket, turn left. So as the turtle evaluates, it'll simply go, I see an S, I will move forward. See a left bracket, I will turn left 60 degrees. I see another S, I'll move forward. Clear? Cool. So in talking about the Sprout, we need a way to break this structure down
so that the turtle can understand it. And I want to really emphasize that the turtle is an arbitrary choice of drawing framework. Like if you were a graphics programmer, you would do this by multiplying a bunch of rotation matrices as you go. There's no inherent connection between our turtles and our L systems, just that, you know,
turtles are cuter than rotation matrices, so that was the criteria I went by. So at the end of a stem, imagine this leaf, this branching structure. We're going to save the position at the end of the stem. We're going to turn left, draw a leaf, but to draw the right-facing leaf,
we'll restore the state. So we go back to the tip of the stem, turn right, draw another leaf. We always know that these will occur next to each other, in general, in a sort of recursively descending way. So we'll always be returning to the same point to draw these two stems.
So our sprout is an L system. We have a bunch of rules. This is just writing in a very terse sort of way, the rules I just described with the left leaf and the right leaf in the stem. And then we make a new turtle with the current state of the sprout, and we tell the turtle what each symbol in the L system means.
So the first generation is boring. It's a leaf and, you know, whatever. Second generation, also boring. It's the same thing we started out with, right? But the next generation is interesting. And I'm going to run through it just to make sure we're solid on how these L systems evaluate.
The stem, a stem, we're saving the position at the tip of the stem. Turn left, another stem, save the position again on the stack, turn left, finally draw a leaf, then recall back to where we were before. Turn right, draw a leaf. I think you guys get the idea, right?
So trees don't actually look like this, right? At least that's what I used to say when I gave this presentation. It turns out that there are plants that look like this. Here's a Drosera venata. This is a ancient carnivorous plant. It's still around today, you can find it, I think in the wilds of Washington State.
It really looks like that. It has that exact branching structure, like each angle is 60 degrees. It's crazy, but aside from these carnivorous plants that exist in a tiny region of the world, trees maybe don't look like that in general. So let's model an actual tree, like a juniper branch. Now this looks complicated, but it's the same thing we were talking about before.
You start with a twig, T, and you map that to a structure. Now that long string just really means this image, right? Each twig becomes this branch each time we evaluate it. And so here's the animation of the turtle executing.
And when we're done, we have something that looks like this, which is a pretty good approximation of what a juniper branch actually looks like. Now juniper branches are a little more complicated. Each twig has a different length depending on how long it's been growing. This is a really good approximation, especially with just a turtle, right?
So we've talked about how L-systems are grammars and that you need a computer to evaluate these grammars. So as the plant itself is growing and evaluating, this is the plant running in computation as it grows. I think that is super neato.
You can also do weirder non-organic stuff with L-systems, like here's a fun Sierpinski's triangle. You like really weird stuff, there be dragons. So now let's take a different view of the growing stem of a plant.
We're gonna go from top down, going to slice right across the tip of the plant's stem as the leaves bud off from the center. So in this area of the plant, which is called the meristem, we have a area filled with plant growth hormone and nutrients and all sorts of things that leaves really like.
Now as a leaf grows, it'll greedily suck up everything around that area and then head out from the center in search of more plant growth hormone. Now the next leaf budding off into the center will be budding into an area that doesn't have as much growth hormone. It will set off in a different direction in search of more growth hormone
and so will the next leaf. Now I want to model this. I want to have my plant sprouting leaves, but actually implementing this would kind of suck, right? I don't even want to think about the exact time complexity. And the time complexity doesn't really matter. I'm more using time complexity
as a way to describe code suck here, right? We really don't want to implement that. We can do better. So here's the very first model of how humans understood how plants grow. This was discovered at Cambridge in I think the 1950s or so. And that model was charged particles.
Now particles, little drops of fluid filled with iron shavings or something like that, all have the same electric charge and will repel from each other because of electromagnetism. And this happens in, like you can actually run this experiment and get, as you drop drops of charged fluid
onto an electric plate, they will spread out in the same pattern that leaves grow on the tip of a plant, these kind of characteristic spirals. That's really neat. Like that's a pretty good approximation, we know. And we can implement that with some drawings here
with the graphics library I've been talking about where each particle moves away according to the laws of electric repulsion. And you'll see after a while it starts to vaguely form these spirals. Now the time complexity is O of N squared, codes suck about the same, we're not gonna worry about optimizations there,
like no quad trees for this, don't even worry about it. By the way, that was Alan Turing's model. He was the first person to describe this. In the general case he called this the hypothesis of general phyllotaxis, which means my idea of how leaves grow. And then he later refined that
to be an even more accurate model. It's interesting that it's Turing that made this first model because the mathematics is very similar to the mathematics of actually parsing computer languages, right? And Turing devised a closed form solution. Like he didn't run the simulation like I just did and measure things.
He figured it out drawing in his notebook. Like here's his drawing in his own notebook of how plants grow around the meristem. And we can notice, as Turing noticed, that each leaf sets off at a very specific angle to the previous leaf. Like that holds all the way around the circle.
This is about 137.5 degrees. And if you're Turing, you derive the closed form solution of that, which is the golden angle, 360 degrees over phi, but the opposite side of the circle from that.
So now that we know this closed form solution, now that we know the exact angle that each leaf sets off from the previous one, we can build an L system out of it, right? In this case, the rotation, you have a stem, you rotate it and grow a new leaf, the rotation is going to be 137.5-ish degrees. So we can implement that and boom, artichokes.
So the time complexity of this is fine. It's like, you know, you simulate it once, right? It's O of one or whatever L systems are, the linear. So that's great. And the code is, as you've seen, a few lines of Ruby,
so the code suck has dramatically decreased. So let's go back to algae, but this time we'll do it in more dimensions. Here's you again. And this time there are many of you, all in a line. And we're going to do the cell division thing again, this time not worrying about single alga and babies,
just all algae. And each alga is going to divide downward, down on the plane. That, except life is really complicated and some of them have divided more than once in that time period. And this process will keep going where some of them are going to be
a little more enthusiastic and divide multiple times. And it keeps going on and on. It's not actually getting smaller as it goes down, that's just me running out of space to draw it. And as an aside, we're going to represent these cells, I've been representing them as dots with little smiley faces inside them.
But actually as they grow, they push up against one another in this sort of form where we end up with a whole bunch of polygons at the boundaries between cells. I'm going to flip that around. So the red lines are the cell boundaries.
We can make that much simpler by just connecting the centers of the cells. We put a point in the middle of each cell and connect across each edge with a line. This is called taking the dual of a graph. And it's the same information, it's just fewer vertices, fewer edges to keep track of, much simpler.
Now in this case, I can draw that. We'll draw each line connecting the center of each alga. And then we take away the illustrations, and we're just left with this graph. It's much easier for us to deal with as computer scientists. So as we simulate this, I mentioned that
things are not actually getting smaller as they go down, but they are, you'll notice, getting more packed tightly. But we know that the cells are all about the same size and squished up against each other. So I want to simulate what happens when these cells all squish together in that way, using the well-known Unix command jellyfish.
This is what happens. You can see from the top of the screen down, all of these vertices all connected with the line, which means there's an edge between the cells. This ruffles out into three dimensions in this kind of jellyfish-tentacle-like shape.
It's the same structure as jellyfish tentacles, that's why I call it that. And as it ruffles, it moves into three dimensions. We have kind of bending stiffness here to make sure it just doesn't go all wibbly. But notice this form of this. You'll notice this everywhere. Like, you can probably go outside and see some plants
that have this wavy structure at the edge of their leaves. Like, that's an instant identification of like, yeah, I know what the cells are doing here. This happens in jellyfish. Up where I'm from in Seattle, we have Oregon grape and holly, which does exactly the same things with the wavy lines. If you're from the desert, you've seen succulents that do the same thing. You've seen euphorbia all over the world
that all have the same structure. Now, this structure is a specific kind of surface. The world we live in, things like this table are all flat, they're not curved in any way. As we move through space,
we're not like warping as we go, we're just kind of existing. But we live on the Earth, which is a sphere. We're small enough that as we walk around, things curve away from us as we go. If we walk in a straight line, two people at the equator, 90 degrees apart, walk in a straight line, they'll hit each other at the North Pole.
This is an example of hyperbolic space, which is in many ways the opposite of a sphere. It has some strange properties. It's the one with plants. How many unique parallel lines, if you have two lines through a point and draw one line parallel to one of them, it'll always intersect the second line.
In our world, sure, you have one set of parallel lines all pointing the same direction. On a sphere, if we're talking about the lines that exist as the great circles all the way around the equator or through the North and South Pole, there are no parallel lines. You can't draw two things that never touch. But this one, you can have multiple parallel lines to any point.
They're pointing different directions, but they also never touch. These surfaces have other different properties that are really interesting, and I'd love to talk about them more, but the moral of this story, what I'm getting at, is that plants don't care about any of that. We can verify this, right? We can go outside and ask an Oregon grape,
like, man, what beautiful hyperbolic leaves you have? What's the relationship of the distance of any given point on those? And I guarantee you, it will not answer. Thank you, that's all I got.
We have a bunch of time for questions. Yes, in the back. The question is, can I think, off the top, I guess, about any kind of application for these surfaces, given that we use nature a lot in inspiring our designs? One of the reasons that this hyperbolic structure occurs a lot in nature is that it's surface area maximizing, so that's a pretty solid example
of something you might conceive of it being used for. To my knowledge, it's never actually been used, but it occurs not randomly, but because it serves a specific purpose, and nature selects for things that do things like that. This is how I started programming. I was an illustrator, I was trying to draw,
or trying to sculpt in a 3D modeling program a model of a jellyfish, and I couldn't, for the life of me, get all the tentacles right, because they're really complicated, and I thought to myself, I bet I could get a computer to do that. Turns out, you can't, right? Well, we had a talk earlier this RubyConf by Sing Wei, Wave, maybe, about parsing Ruby.
If you haven't seen that, go back and watch it on Confreaks, and you'll get a better understanding of formal parsing theory. There's a lot of things you can look up from there. This is a huge field. The question was, how do I get a formal background in this? I don't even know where to begin.
There's so many aspects of what I've talked about, like, what are you interested in specifically? Anything, all right. You can read Turing's papers, they're all available. A lot of the papers that Turing wrote in the last few years of his life dealt with stuff like this. There's one really interesting one about the patterns
that appear on the faces of fish from a similar, like, biologically motivated example. There's all of his papers on the growth of leaves, that kind of stuff, if you're comfortable with the very formal math side of things, that's where I would start. No, all right, thank you very much. Thank you very much.