Often when we learn about or work with math, it's done so in a very detached style.
You might learn the rules or techniques of differentiation, for example,
but how often do you get to apply them to meaningful and interesting problems?
In this episode, we have Vincent Knight and Grant Palmer on to discuss a wide variety of
applied and approachable math problems using Python. Whether you're deeply into math or
not so much, I think there's a lot to enjoy from this episode.
This is Talk Python to Me, episode 372, recorded June 29th, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes
talkpython.fm and follow the show on Twitter via at Talk Python. We've started streaming most of our
episodes live on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube to get
notified about upcoming shows and be part of that episode. This episode of Talk Python is brought to
you by Compiler from Red Hat. Listen to an episode of their podcast to demystify the tech industry over
talkpython.fm/compiler. And we'll see you next time on Twitter. And we'll see you next time on Twitter.
A quick announcement before we jump into the show. You probably know about our video courses. I'm super
super proud of them and they're a fantastic educational resource for many people. But sometimes you can
benefit from a more hands-on, group-based approach. That's why I'm running another online cohort course.
This one will cover FastAPI, Async Python programming, and MongoDB. However, the structure is different this
time around. This course will be taught 100% live in person. You'll attend over Zoom and all the sessions will
include myself as an instructor and your fellow students. It runs from August 8th to August 19th.
If that sounds interesting, please check out the link in your podcast player show notes or on the episode
page. And if your company offers educational credits or training reimbursements, you should be able to
expense this course as well as our regular Talk Python courses. I'll put some links to templates that you can
use to help with that in the show notes as well. Vince Grant, welcome to Talk Python to me.
Thanks, Michael. Thank you very much for having us. Thank you.
Yeah, thanks. Nice to be here.
Yeah, it's good to have you. Vince, I guess it's welcome back for you, right?
Yeah, I was on the show a while ago. Big listener, love the show. Yeah, I came here a long time ago to
discuss one of the game theoretic libraries I work on. So yeah, thanks for having me again.
Yeah, you bet. I love game theory. It's amazing. We'll touch on that a little bit. We're going to
do kind of a survey of a bunch of different areas of applied math and how Python and compare that with
how R might solve those problems, some of the libraries involved, some of the techniques involved.
So lots of fun things. I'm looking forward to diving into them with you.
Awesome. Awesome.
Yeah. Awesome.
But before we do, maybe we'll kick it off with Grant. You're new. Tell people quickly
about how you got into programming, Python, math. How do you end up here on this show?
So I'm a lecturer at Cardiff University in the School of Mathematics. So I learned to program
when I was doing my PhD. Vince here was actually my PhD supervisor. So I essentially learned
programming from Vince during that time. Nice.
Yeah. And during my PhD, I sort of realized or I learned that everything that we'd been able
to learn during my like master's and stuff, it was all completely doable in open source software.
And that's kind of where I focused my PhD on then. I sort of, one of my main projects during my PhD
was building a library to be able to do some of this stuff. And then, yeah, I passed then my PhD.
What general area was your PhD in? I know, Matt, but what specifically?
Discretive end simulation was where I specialized during my PhD. But like in conjunction with
that, some of the other techniques, stuff like Markov chains and curing theory, which are sort
of different ways of solving the same sort of problem. And that's where I sort of specialized
in.
Fun.
Yeah. Very, very cool.
We have a running, running joke with Garrett that one of his sub topics in his PhD that he became
hyper specialized in as PhDs go was, is deadlock. And so it's, there's a tweet came up about a
question about deadlock and all these jokes that come up. We got very excited. Well, I got very
excited. Like Garrett, someone's joking about your work.
That's fantastic. Vince, you've already told your story. Maybe just a quick update. What
have you been up to in the last couple of years?
Yes. In the last couple of years, having the pleasure of working with Garrett now,
now that he's a colleague of mine, but otherwise continuing my work on the actual library, which
is the library we were chatting about just now. And yeah, I'm still a mathematician at Cardiff,
where the best part of my job is getting to teach people how to program. And that's something.
Mathematics is such a cool subject, but in a way you're only ever a theoretical mathematician
until you can program the stuff you're doing. Even the applied stuff is quite theoretic. And then
it's once you can code these things that are so powerful, it really kind of releases the magic
of mathematics for want of a less cringy type of way of saying it. So that's kind of what I really
enjoy doing and what I keep doing. Kind of what we're going to be talking about today.
Fantastic. Yeah, absolutely. We're going to touch on a bunch of different manifestations of that.
Cool. I want to put out a quick disclaimer. We're going to be talking about math things,
obviously Python things as well on the Python show here. The disclaimer is I have some degrees in math,
but I have not done anything with them for 20 years. And therefore I know just enough to ask
bad questions and make poor assumptions. So you all are going to have to keep me on track and just tell
me, no, no, no, Michael, you were totally misremembering that from your courses 20 years ago.
The real problem is we might just be on just the other side of that boundary where we could
confidently give you bad answers. That's the...
Perfect.
Asking bad questions is fine.
If you say it confidently, I'm sure it's going to be...
Yeah, exactly. Confidently giving bad answers is the problem.
Yeah, sure. All right, cool. Well, let's kick this off by just talking about what is applied mathematics.
Because one of the final courses I took, it very much confused me, both in the content and just purely in its title.
This was a course at UCSD in the PhD program there. The course was titled Applied Abstract Algebra.
Right.
I'm like, well, is it abstract or is it applied? Because I really don't... I just... So let's just start out with...
We're going to be talking about solving applied math problems. Like what the heck is applied math versus
like what I might do in a calculus class where I'm solving a bunch of like formulaic type of problems
versus real analysis where I'm chaining theories to derive new ideas or maybe it's numerical analysis
or stats. Like what... Where are we in the math world?
Yeah. I think applied mathematics is an interesting kind of like term because in a way it's become a...
It's become destroyed from its meaning in a lot of cases in that there's a whole area of applied
mathematics as a subfield of mathematics. That's not necessarily applied in any realistic sense.
I don't know what you think, Gerd.
Yeah, yeah. So I think traditionally what applied mathematics was when I was doing my undergrad
was these sort of physics models where they assume no gravity and they assume no friction
and stuff like that, which doesn't seem very realistic to me at all.
Yeah.
Whereas when me and Vince have been talking about applied mathematics, sometimes that goes
under another name called operational research or operations research. But we call it applied
mathematics because we're applying various techniques in mathematics to a situation, a real situation.
Right.
I do think not necessarily by definition, but just in general, different techniques that apply
to the more physics-y problems to the more management-style problems maybe that is there.
But not by definition. It doesn't have to be like that. It's just that's what people find useful.
Yeah. In a way, a lot of these labels in terms of the mathematical subfields and things are not terribly
helpful because they create barriers between these fields. This problem I studied in my PhD where
it's in pure enumerative combinatorics trying to count these types of matrices. Really a problem
actually because of all other series of conversations. And the most elegant proof that came for this
conjecture came from statistical mechanics, whatever that means, but it's a field of mathematical
physics. And it's where all these boundaries from fields not always are helpful, whereas really the
techniques are the helpful ones and knowing when to apply them. The definition that we would use for
the purpose of what we're talking about today in terms of applied mathematics are just without
necessarily going to an incredibly high level of mathematics where you're talking about the stuff
that they do at CERN that is certainly applied. There's some very low hanging fruit. I don't know
if that's the right word. Low hanging fruit of where mathematics can very much-
Like day to day problems.
Yeah.
Exactly. Day to day. And it's where you take these ideas of, you know, in high school where you're told,
oh, matrices are important because computers can do mathematics really quickly with them, but you
don't do it with a computer. So, you know, who cares, right? But actually with a matrix, you can really apply these things.
Yeah. They tell you it's important for computers and then you, yeah, then you proceed to do it by hand for the next two weeks. Yeah.
Exactly. Exactly. Two weeks if you're lucky. Yeah.
I wish there was some value to that, but yeah, exactly. You're like, well, I could tell you whether this matrix is singular or not, but I have no idea why I would do that. Right? So this is sort of the next step. Like, well, what would you, if you had that knowledge, that kind of knowledge, what would you do with it? Like what kind of problems could you answer? And some of the examples that you all cover in this book that we're going to highlight a little bit are things.
Like if you have two businesses that are competing, what choices might they make? Or if no, I know this is extremely theoretical and it's never going to happen, but what if there was like a pandemic and there were people who were sick?
Probably not that funny, but yes.
We needed to make weird trade-offs about society. Like, should we shut everybody in a basement? Should we make them behave in different ways? What's the cost versus benefit analysis? And those kinds of things, right?
These things that without needing too much high-level mathematics, you can describe them mathematically relatively simply. And then just with a little bit of code, you can really do cool stuff with it. Just doesn't take much code, you know, and that's, that's where Python really comes in.
Yeah, for sure. One of the things that we'll see throughout here is there's a bunch of different examples across these different areas of math and these different types of problems in different libraries that apply to solving them.
But the thing that's cool is every one of those solutions fits within a couple of pages on the long ones, right?
For Jupyter Notebooks that have the solutions, plus have some of the output of the answer, right?
Yeah, yeah, yeah.
It's not a ton of code, is it?
No, no, exactly. And that's, this kind of touches on something else that we were going to talk about is the idea that a lot of the time when these things are taught, they're taught with specific pieces of software, mostly commercial pieces of software.
Yeah, yeah.
Yeah.
It's, I also think it demystifies things a little bit because if what you do is you go to some expensive, polished piece of software like Maple or something, and you can say, you say, well, I could ask this expensive, complex, huge piece of software a question and it can magically give me the answer.
Yeah.
It's great that you get the answer. And it's great that you know you have this very fancy tool, but it doesn't necessarily reveal a ton of understanding because of it, right?
An idea that's beginning to form in my head. I was just saying this to Gary and I just haven't fully formed. I think there's a blog post that no one's going to read that I want to write one day about, you know, the ethics of it, about teaching these fancy commercial software. It's why these great companies give out these educational software is that they immediately have lots of users of the software that don't know how to use anything else. And I wonder if ethically as educators, if that's okay.
I think we should make more of an effort to separate the concept from the software. And I was kind of like saying, like, I don't think we should teach any commercial software. And Darren, you made a good point when we were chatting.
I don't really have a problem with teaching a particular topic through commercial software, as long as we teach it in a separated way so that you know, once you've formulated the concepts and the ideas mathematically, you can use whatever software you want. In the classroom, we happen to have this expensive license.
So we're going to have this. But outside of the classroom, there are other things you can use.
Yeah. Well, I think there's a couple aspects here. One, Vince, you spoke about the ethics of it. Is it the right thing to do to basically reinforce this loop?
Exactly. Exactly.
Exactly.
That entrenches some of these. The other part is, if you're in the UK, or if you're in the US, and you say to your student, probably especially if you're in the US, they're used to getting paid so much. I just paid for both my daughters to go through college. So I'm aware that here you pay a lot for the actual tuition. But many places you'll say to students, what is it in the UK? Is there, how is college, what's the affordability? I know in Germany and other places, but don't know it that well there.
It's a touchy subject in that tuition fees have just come in.
And so costs of universities here are equivalent, not far off to in-state tuition in public universities in the United States.
I think they're not far off.
But then we get to charge, I'm saying we, very, very not talking about me, but we get to charge whatever we want to a certain extent to people from the European Union.
And then even more to people from outside of that.
Actually, I don't even know if that's true about the European Union because of recent events anymore.
Yeah.
But yeah.
So yeah, there's a cost.
Sure.
Okay.
So going back though, my point about the ethics was it's one thing to be in the US or places in Europe where we have a decent amount of money.
It's another to say to somebody, you have to pay $500 for this software to learn the subject, right?
Where $500 US might be the yearly income.
For an employed person and their student.
It seems like there's a lot of good would be done by building up maybe the missing gaps that force or encourage people to go to this commercial software.
Building that up rather in the form of SciPy libraries and the Python data science stack in general.
Absolutely.
So that it's free, open source and all those things.
I think that would apply for all subjects.
I think really close to what we're talking about here is with mathematics, I think it's really frustrating because maybe I'm thinking too purely now.
And I mean pure of heart, not pure mathematics.
In terms of like mathematics is just such a clean and minimalistic subject.
You know, you need a pen and a paper to do it.
And if all of a sudden we're teaching people to use a pen and paper to do mathematics and saying like, oh, but you can only do it with a pen made by a BIC.
And don't worry, BIC has given us all this free pen.
The Mongron pen is the only one.
Exactly.
Right.
And then once you graduate, if you want to write down this idea again, you have to use a BIC pen, but you have to pay for it yourself.
And I really do think mathematics, the evolution of mathematics and a lot of science, I would argue, is into computing, right, is into getting computers to do it.
And that extension of using the pen now is to use code.
And yeah, it's...
For me, at least, I think one of the important things is that separation of mathematical concepts to software.
Because it's a lot less of a problem, but there's still a problem going.
The only way you can do this is by using free open software.
There are some places, unfortunately, that are not allowed to use open software because they think there's security problems and stuff.
So if you've only taught open software, then certain, like the NHS, for example, I know they discourage using open software.
So maybe you then think, oh, I can't do this maths thing anymore.
But if you've separated the concept from the software, at least you know the concept and you know you've got choices.
Yeah, absolutely.
Yeah.
I think that's very true.
Separating the concept from the software is key where possible.
And I think perhaps we don't always do a good job of that.
And here I am speaking as an industry.
I think sometimes we often...
I've been to conversations where people have said, I need to use MATLAB.
Can you help me with MATLAB?
But it turned out they wanted to know how to numerically solve a differential equation.
They didn't want to do MATLAB.
They just wanted to solve a numeric equation.
They just did not know that that's what they were doing.
This portion of Talk Python to me is brought to you by the Compiler Podcast from Red Hat.
Just like you, I'm a big fan of podcasts.
And I'm happy to share a new one from a highly respected and open source company.
Compiler, an original podcast from Red Hat.
With more and more of us working from home, it's important to keep our human connection with technology.
With Compiler, you'll do just that.
The Compiler Podcast unravels industry topics, trends, and things you've always wanted to know about tech
through interviews with people who know it best.
These conversations include answering big questions like, what is technical debt?
What are hiring managers actually looking for?
And do you have to know how to code to get started in open source?
I was a guest on Red Hat's previous podcast, Command Line Heroes,
and Compiler follows along in that excellent and polished style we came to expect from that show.
I just listened to episode 12 of Compiler.
How should we handle failure?
I really valued their conversation about making space for developers to fail
so that they can learn and grow without fear of making mistakes or taking down the production website.
It's a conversation we can all relate to, I'm sure.
Listen to an episode of Compiler by visiting talkpython.fm/compiler.
The link is in your podcast player's show notes.
You can listen to Compiler on Apple Podcasts, Overcast, Spotify, Pocket Cast,
or anywhere you listen to your podcasts.
And yes, of course, you could subscribe by just searching for it in your podcast player,
but do so by following talkpython.fm/compiler so that they know that you came from Talk Python to me.
My thanks to the Compiler Podcast for keeping this podcast going strong.
We can dive into the applied math aspects, but I think one other final thing on this is I feel like professors,
especially as they get older, they've taught a certain way with a certain set of tools for 20 years.
And you know what?
That course they wrote, they already have the materials and exercises and all of that.
And the idea of saying, well, we're going to now throw out this and like grab some new open source library.
I mean, there's 350,000 libraries on PyPI and they're always changing and turning and something new is coming along.
And it's maybe a lot to ask, but also maybe not too much to ask to say, look, you should keep up with these things.
And if there's a new way to present it to your students, not because even some of the ethics stuff,
but you might be doing a disservice to your student to say, look, the only way that you can solve these problems is with say Fortran,
or the only way you can do it is with a $2,000 toolbox extension to MATLAB.
That's the way that you have to go to solve this.
And here's this, you know, super well-respected professor telling you that's how you do it.
Well, that's not actually how you do it.
That's how they've done it for 20 years.
And so there's a lot of inertia there, right?
I'm really near what being a lecturer, so maybe I'm being really naive here, but it is an effort to keep up with all this stuff.
But that's our job.
Our job is to keep up with the latest maths.
Anyway, if I was still using, if in 30 years time, I was still using the same maths as I'm using today,
I wouldn't be doing my job properly.
So why would, why is the same true with software?
I think it actually frankly comes back to ethics in that, you know, it's, it's unethical to not make the effort to update your training.
And if we were talking about doctors and surgeons, they do need to learn new things as the science evolves.
And I think probably with, with lecturers, professors, higher education, it, it comes back to that dichotomy between research and teaching and how teaching is viewed.
So, but yes, absolutely.
I think, you know, in a way I would be disappointed if at the end of my career I'm still teaching Python.
In a way I'll say, oh, by that.
Not 2020 Python, but, you know, 2050 Python or whatever it is, right?
Absolutely.
Yeah, exactly.
Oh, Pythons are, you know, I started teaching Python 2.
Or Python Plus Plus.
And then I had to figure out how to teach both.
Yeah.
And he's having it.
Exactly.
Yeah, yeah.
So you, sorry, I cut you off.
So you started teaching Python 2 and then now you've moved on.
And then I had to figure out how to deal with Python 2 and 3 and now I just keep 3 and yeah.
Yeah, that's, I can't believe that transition took so long, but well, there it is.
Let's dive into some of the problems and we're going to, more specifically, I'm going to take
this book that you all created and use it to sort of guide our exploration of both some of
these problems, how we might solve them with Python and some of the libraries that make it
possible.
I guess one of the things that struck me about that journey is that there's not that
many external packages that are required.
It's not like, well, this one takes 10 to solve this problem.
This one takes these complex, these five, if you put them together just right, you get the
answer.
So that'll be fun.
But, you know, tell us a bit about this book, Applied Mathematics with Open Source Software.
So publisher, this is an academic publisher, which amongst other things means the book is really
too expensive, but they often just send out emails to people saying, you know, hey, could
you write a book?
It's not necessarily a source of flattery, but, you know, got one of these emails and
Geraint actually had just given a talk at Tycon UK.
I don't know if you want to say a little bit about the talk you gave.
Yeah.
It was very much a precursor to this book where I had given an introduction to the field of
operational research, which is how we label this certain type of applied mathematics and
all the different problems that could occur.
And I think the title of the talk was, there's a library for that because every sort of problem
that we could come up with, you could pip install a library and in a function or two solve the
problem, which was a neat little...
Yeah.
Oh, there it is.
There's a neat little...
That's it.
Is it?
Yeah.
I'll link to it.
Yeah.
If I can just interrupt, the call for proposals for Tycon UK closes on Saturday.
So if you're thinking of talking, please submit a talk.
So yeah.
And it was just really neat that we had these, like, what we call standard problems.
It was essentially our postgraduate MSC course that we teach.
But instead of teaching the maths, there was one or two Python functions that solved it for
you.
And then, yeah, that eventually evolved into this book where instead of each little topic
being a couple of functions, we filled out chapters on some of the theory and, again, tried to
separate the maths and the programming, emphasizing that by introducing another language, which was
R, to show that you can do it in two different ways and that the software is independent of the
problem.
I think you and I have described it because every now and then, as we were writing the
book, we kind of stop and go, wait, who's the book for?
You know, and as we were like making decisions about how exactly to do something, we're like,
wait, who's the book for?
And I won't necessarily, well, maybe we should talk about that.
But I think we've kind of written a book that's meant to be useful to people wanting to get started
either with the mathematical field problem or with how to actually do it with the code.
And so every chapter has got the same kind of structure that describes a problem,
then it describes the basics ideas behind the theory of the problem or the mathematical tools,
the theory behind the mathematical tools.
But again, not going into too much depth, kind of what I said before about you don't need to
understand all of Newton and Leibniz's calculus to be able to kind of predict the outcome of a
pandemic.
And then it just solves the problem.
The original problem, it solves it in two separate ways, using R and Python.
And the final kind of section in every chapter is pointing at a bunch of literature on it,
which we thought would be useful.
Yeah.
And we're more broadly, you might be able to, these types of problems appear and what you
might be able to do with it.
Yeah.
But the really cool stuff with the publisher is that we had an ongoing kind of conversation
before the start.
Garrett and I were both like, well, the book has to be open.
They've agreed like, oh, there's not a PDF floating around online of the book,
but all the source files are there.
So all the late deck files are there.
There's all the Jupyter notebooks are there with the code.
We haven't quite gotten all the R markdown files up yet, but they are theoretically all
there.
And so the book is very open, which we're happy about.
Yeah.
That's great.
It is very shiny new.
It still has that new book smell.
It was released just almost exactly a month ago, right?
That's right.
Yeah.
Keep on saying I've got to have Garant over to celebrate, but we don't get around to doing
that.
I had to sign a copy for my nun.
Oh, nice.
That's very sweet.
That's so nice.
All right.
Now, before we dive into the various problems in the Python side, while we're still kind of
talking a little bit high level, this is one of the interesting aspects here is the Python
and R aspect.
So when you go through each chapter, which is, I think I agree with you that it's pretty approachable,
even if you don't have a, you don't have to have like a master's in math or specialize
in that area for it to make sense.
It doesn't have, if you don't really want to see a ton of formulas.
Yeah.
It's not super intense.
I think that's our first official review, Michael.
Pretty approachable.
It's fantastic to share.
Yeah.
Well, like I said, my math, while I said a ton of it is highly rusted, it was pretty approachable
for me.
So there's that.
But maybe just talk about putting R and Python side by side for solving a set of different
problems.
What are some of the takeaways either of you got from that?
One thing we wanted to do here, because we would, well, I would certainly.
describe myself as a, as a Python person, non-R person.
I know R, I write R, I've written a book in R, but I would certainly describe myself as
a Python person in that.
If you're going to sit down and write something, you would pick Python first.
I would pick Python.
Exactly.
But also, you know, I'm embedded in the Python community.
I listen to some good Python podcasts.
I'm a Python person and I can look at some Python code and the joy is that looks very Pythonic,
right?
I can, I can, I can tell you that.
And so we were kind of aware that we didn't want to translate the Python to R when we were
writing this.
We wanted to, you know, write this as close to our people as, as we could.
I don't know if we managed that, but that was something as well that we were aware of.
It's not just translating languages.
In Python, yeah, in Python, we have the word Pythonic for idiomatic Python.
Do you all know, is there a word for that in R or is it just idiomatic R?
I don't know.
Yeah.
I don't either.
Yeah.
I think you're right.
You were going to say something.
Jump in here.
So I was going to say, like, as we were writing the book, we noticed that there were certain
problems, which the R and the Python lined up exactly, not from design, just from, if we
were going to approach these independently, it is pretty much exactly the same.
way to solve it.
There were some problems where we had to reformulate the mathematics because the way
to do it in R was so different to the way you do it in Python.
That doesn't mean the math's changed.
We just had to reformulate it, re-communicate it so that we could write it down in R.
And then there were some problems, again, where we had to use different mathematics to
solve it in Python and R because of the availability of libraries and stuff.
I thought that was really, really neat.
And I think that emphasizes, again, the separation of concept to software because sometimes you
did have to do very different things in different softwares.
My favorite chapter on this is the one that is your specialty, Darren, the discrete event simulation
chapter, where I forget the name of the two theoretic ideas about discrete event simulation.
Process-based and what's the other one?
Yeah, so there's process-based and there's the event scheduling approach.
There's two different ways of approaching discrete event simulation.
And the standard library in R to do it is process-based.
And I don't want to call it the way to do it in Python, but the way we've said in Python
to do it is by using the Q library, CIW library.
The only reason Gerard doesn't want to say it's the way to do it in Python is because it's
using his library, the library that he's maintained around.
Yeah, nice.
Both those libraries, I'm pretty sure that underneath, well, I know how Q works underneath, but the
Simmer, which is the R version, I'm pretty sure underneath they work very, very similarly.
There's not many ways you could do different ways of discrete event simulation, but the way
you formulate the problem is very different.
And going through that in the book and going in Python, you have to take like an overhead
worldview where you look at the system, whereas in R, you have to take a sort of, you have to
put yourself in the mind of the customer and go, what is the customer doing right now, rather
than from a systems point of view, in order to formulate the problem before you could just
then go and solve it.
I just thought it was very, very interesting that the way to do it in each language was
so different.
And yet probably underneath, it's doing exactly the same thing.
You get the same answers out.
You just got to formulate it in a different way.
Yeah.
I think that's such a nice example where diversity, and I'm using diversity from the way that languages
do things.
I think that's the best chapter in the book, frankly.
I think that's the best chapter in the book because you not only do things differently
from a programming point of view, but because you do things differently from a programming
point of view, the theoretic discussion allows you to kind of, yeah, give a really good
understanding of these two ways of doing it.
Yeah.
Something else that's kind of worth mentioning about the Python in our bit.
I don't know if this is a terrible address, but I like tests.
I don't like trusting in any code.
I like writing tests all the time.
And we came to this media thing that we wanted the book to be tested.
We wanted to know the code was correct in the book, but we wanted to have these two different
languages.
And we didn't want to kind of use the standard doc test notation for the Python.
And then we wanted to find something that would work for the R, et cetera.
So we actually wrote a little language agnostic doc tester that basically runs through and tests
all the code in the book for us.
And theoretically, when we write the second edition and we add Julia as well, it will be up
to handle it.
Yeah, I guess Julia is another option that could have possibly shown up in here.
Pretty interesting.
I guess it's worth pulling this up.
It's probably worth pulling up the Stack Overflow friends and putting those in there.
Yeah.
Right.
So we have R.
We've got, I don't know where these all lie right now, but I would imagine that the graph
looks a little bit different across these.
Just for people listening, I would say R is certainly growing.
It's actually growing pretty healthily compared to many, many programming languages.
And it's not going crazy, but it's going across.
And you've got Python, which if anyone's looked in the last couple of years, it's just done
insane stuff in terms of popularity over there.
So there's that.
And then Julia is, it's, I don't know, I can't really read it.
It's, you know, like point.
Not quite the same scale.
0, 1% versus say like 2% for Julia, for R, excuse me.
And then for 16% for Python.
There is something to be considered about choosing not just a language because the language has
a cool way of doing async or its generators are beautiful, but choosing a language for its
ecosystem as well.
Yeah.
And that's where it touches on this here, right?
But also for the community that's already there, I think.
Yeah.
At least in the area of mathematics that me and Vincent are in, I think R and Python are quite
prevalent, but they're also used in different.
Maybe their peers there, right?
Yeah.
A little closer than this would show.
I think they're also used in different ways.
Would you agree, Vince?
I would say Python's very, because of PyPy, things like out of the box, there's one library
to do this and it's their way to do it.
Whereas with R, people tend to write their own stuff and then upload it to Cran.
Yeah.
So you might get lots and lots of different ways of doing the same thing, but each one might
specialize slightly in a different way.
Whereas with Python, I feel like there's one library that does it really, really well.
I think people just use the ecosystems in different ways.
This portion of Talk Python to Me is brought to you by the Python at Scale Summit.
The Python at Scale Summit is a conference to highlight innovative big data solutions for
Python developers and enterprises.
You'll learn about trends in the Python big data ecosystem, share stories about implementing
solutions, find out about new innovations, and connect with other data scientists using
Python.
The Python at Scale Summit will be a hybrid conference with talks, workshops, and training.
Of course, there will be networking and social events to connect with other Python professionals
too.
Come hear speakers like Matt Rockland from Coiled, Brian Granger from AWS, and many others from
amazing organizations such as NASA, Capital One, and BCG.
Get back together with your peers and learn how they're scaling their computation and data analysis
using Python and the data science stack.
Register at talkpython.fm/python dash at dash scale.
When you visit the link, be sure to use the code TALKPYTHON, all caps, to get 15% off your
tickets.
That's code TALKPYTHON at talkpython.fm/python at scale.
The links in your podcast player's show notes.
Thanks to the Summit for supporting the podcast.
Yeah, both those two things are often talked as strengths of either library, right?
The fact that Python has that one way to do things and the set of different ways to do
string formatting conversation comes up.
But then the fact that R is kind of like closer to the science.
I don't know if that's even accurate, but that's the feeling, I guess, is also a strength, right?
Yeah.
The reason there's lots and lots of libraries to do the same thing is because they've each
specialized in something which a new academic has just written a paper on.
And that's why there's lots of different ways of doing it.
Yeah.
All right.
Sure.
And maybe, you know, like out in the audience, the ninja says R is really powerful when it
comes to things like analytics and so on.
Right.
So maybe there's certain areas where, you know, there's the libraries you can pick that
are definitely better.
Okay.
Now we talked about the book.
The book also, as you pointed out, has an open version where you can find it on GitHub,
which obviously we'll link to.
And in here for each one of these, you've got some examples, which are basically the, at least
for the Python side, the Jupyter Notebook examples here.
So I thought maybe we could sort of talk through a little bit.
What is the problem?
And then maybe really first quick, quickly introduce what this area is.
Cool.
And then what we can then talk about the problem, the example problem you put out there and some
of the libraries and techniques there.
Sure.
So the chapter two, which you're looking at right there, you say is about a mathematical
idea called, a mathematical concept called the Markov chain.
So it's this probability model that you loosely go that you're, as the system go,
model changes over time.
The system is in a particular state.
And then you go with a given probability of being in that state to another state.
You can go around like that.
That's not the best explanation I've ever given.
I've explained that many times.
That's probably one of my worst explanations.
But market change can be used to model queues.
And there's a whole field of mathematics called queuing theory.
And that is often used as a very applied problem.
And so the problem we got here is imagine you've got a barber.
The barber has kind of two decisions, how many chairs they have to cut hair in and how many
chairs they have to keep people waiting for a chair.
And obviously that has an impact on the queue, right?
Of how long people have to wait to get their hair cut.
And you can use Markov chains to build up a model and find the probability of having to wait
relatively simply.
I know, Garen, if you want to clean up what I just said.
No, yeah.
So I think the model then would be the second state and the probabilities of going between
each state from the state unit.
And that can be written as a matrix.
And the neat thing then is there's loads and loads of linear algebra techniques, which at
this point you don't really need to know about.
But there are linear algebra techniques, which stuff like number can just do for you, which
if you know which techniques to use, you know how to interpret that as a real life
interpretation.
So for example, there's one certain set of equations you can solve using our Markov chain,
sorry, using our matrix, which will give you the long run probabilities of being in each
state.
There's another certain linear algebraic technique, which will give you something else.
And that's what this is.
Yeah, nice.
Yeah, the problem is essentially comes down to solving a matrix equation, which you could
write down and understand with basic mathematical knowledge.
And then that can be solved.
This goes back to what you told in high school, that matrices are great because computers can do
them fast.
But then you never actually get to do that.
You just write down equations.
But it's just a call to NumPies, the knowledge library.
You can just solve it immediately for you.
It's amazing.
Yeah.
So the problem here to make this applied or more operational, I guess, that you all put
out there says you have a barbershop and the shop notices that there's a lot of customers
who are, they come and the shop is full and the waiting room is full and people just leave.
And I, you know, since COVID, I've just decided I'm cutting my own hair.
I can't, it took too long to find a barber or anything that worked.
And then after that, I kind of figured it out.
But there used to be this place I would go to and boy, did it need this problem.
It would be, you would go there and be like an hour and a half wait.
And, you know, you just, all the time and you never knew.
But so they would solve it by giving away free beer to people while they wait, which was nice.
But this one wants to solve it more in a more formal business way where they want to have
people just wait less.
So it says you have two barber chairs, there's room for four people in the waiting room.
There's about 10 customers an hour and it takes about 15 minutes to serve a customer.
How can we minimize or how do we change things so that we don't have customers leaving because
they come in, see a full waiting room and take off, right?
Instead of knocking down a wall and building a bigger waiting room and, or spending a lot
of money on an extra barber chair and just seeing the effect and maybe five years later trying
the other way, you can just mathematically model this.
And this is a good example of, I think what we described as applied mathematics is that you
can answer these cool questions.
So you could say, well, maybe we need a bigger waiting room.
Or maybe we need more barber chairs or something like that.
Right.
And then you can make that trade off.
Yeah.
So let me find the, this is the numpy, numpy dot lin alg magic.
And so basically you set it up so that you set up all these scenarios in these constraints
and then you just say numpy solve it, right?
That's pretty much it.
Yeah.
And mathematically you're, you write down this matrix a and another vector b and you're solving
the equation ax equals b.
Most of the code is just getting the matrix set up and the b set up.
Actually, most of the code is the doc strings.
And then, and then, yeah, you just use the lin alg dot least squares.
That's one of many ways you can do it.
Least squares is actually getting an approximate solution to the linear, linear algebraic equation.
And there's various reasons why that's a better idea than solving it directly.
And yeah, it's just, it's basically one line.
I think one of the neat things about this then is all that maths you sort of learn in school
or even first year university where you're doing sort of row operations and stuff.
That's not the mathematics that matters here.
The mathematics that matters is what is the matrix you need to do that to?
And once you've done it, how do you interpret the result?
That is the mathematics.
It's not the actual operations that you spent so long doing in first year university.
Yeah, that is a bit ironic.
That's such a good point, Darren, because I think what is mathematics is an interesting question, right?
And like, is it being able to differentiate a whole bunch of quadratics really fast?
Or is it knowing which quadratic you need to differentiate, right?
And I would argue that it is that, you know, it's knowing what, really knowing what the problem is.
So that, okay, then the actual specific mathematical technique, well, who cares, right?
Sure.
Well, events people so often say, oh, I'm never going to use that.
I'm never going to do these things.
I could do that with a calculator or I could do that.
I think a lot of that might be slightly misplaced.
I'm not going to say misplaced, but somewhat misplaced focus on some of these things, right?
Like if you could say, well, spend a little time showing you how to differentiate,
then we'll show you how to actually solve problems with that instead of just getting,
you know, more and more complicated techniques that you can apply.
Yeah.
Integration's more of a pick and choose, right?
I like to find which thing applies.
But still, you know, instead of going deep, deep, deep, deep, deep into that on the first
year stuff.
Yeah.
You had someone on the show a little while ago called Allen Downey.
Yeah.
He writes a lot of really great books.
And I remember what he said on your show was about, he likes to think of teaching these
things in the other way that code allows you to do these things immediately.
So instead of waiting through and waiting and having to have faith that there's going to
be used to it.
You can just flip that around, you know, and understand what it is.
I think there's also a lot of that and what we should be doing.
Yeah.
That's a very good point.
I totally agree.
All right.
Wrap this one up.
You were able to find that it would be better to increase the number of barbers by one than
increase the waiting room capacity by two.
Because I think the chance of the shop being full is like 23% if you had something like
that.
Yeah.
Versus like 8%.
Those kinds of things.
And those are really concrete numbers that you could go to a business and say, you know,
you hired us to analyze these things.
We gathered all the necessary information, like average time, you know, how much that might
vary and those kinds of things.
And here are your choices and here are what are the rough expected outcomes.
Like that's really, really valuable information.
And I am very sure that most barbershops, even chains, don't do this kind of analysis.
Not necessarily in your algebra going on in barbershops.
That's an interest.
That's a bold claim.
I know.
And this question, so a lot of the research, Darren, that I do is within healthcare.
So we work with hospitals solving essentially very similar problems to the one that we've
just discussed.
We were keen to avoid too much healthcare because that's what we do so much of.
But yeah, this, this, if you get rid of the idea of a barbershop, you talk about a ward,
how many beds are on the ward, how big's the, the party out for ambulances to wait in, et cetera,
et cetera.
That, that becomes very important and very powerful and not, not something you need to spend thousands
of pounds or dollars on licenses for.
Not, you know, the, the, not necessarily even have a huge understanding of, of the learning
mathematics.
It's all right there.
It's all right there available to anyone.
Yeah.
But there's way more at stake in a hospital and healthcare than there is for a, of course,
yeah.
A haircut.
Yeah.
Okay.
Let's go on to the next one.
So the next topic is discrete events.
So I'll find my way over to that one.
And y'all introduce this one to discrete event simulation.
This sounds like this might be somewhat in your wheelhouse, right?
Yeah.
So I think discrete event simulations probably, if you're used to programming, this is probably
the one that probably makes the most sense because it's moving virtual things from the
place essentially.
So the question we're answering, we're asking here is very similar to the question we just
answered with Markov chains.
But sometimes things are too complicated to be able to formulate that correct matrix or
the matrix doesn't quite work because the situation is a bit too complicated.
But what we can do is build a virtual representation of our system.
And by sampling random numbers, we can move virtual people around our barbershop and look at what
would happen, right?
And just observe, collect data, crunch that data.
And this is what discrete event simulation is.
It's building a virtual representation of the system, using random numbers to play that
virtual representation system, and then collect some data about what just happened virtually.
Okay, excellent.
So this one, let me set the problem that you all laid out here.
This is a bicycle repair shop.
And there's a set of gates or actions or I guess events you might say that it flows through.
So a bike arrives randomly at a rate of 15 bikes per hour.
They show up and they say, hey, there's something wrong with my bike.
And the staff member looks at it and helps them.
That takes about three minutes.
But it turns out about 20% of the time, the bikes don't need repair.
There's like, did you know that there's a thing to just twist here and tighten it?
All right, go away.
You're fixed.
You're cured.
But 80% of the time, there's something wrong, flat tire, broken chain, whatever.
And that gets put into a place where they're waiting to work on it.
And that takes about six minutes, right?
And then you've got to collect it back.
The question is, I guess the difference that I see here is there's not an uncertainty of whether or not you want a haircut when you show up at a barbershop.
There's just the amount of time and where the people are and the actions they might take if it's too full.
But here you may show up and you may need help or you may not need help and so on, right?
So there's, is that the difference?
I suppose that is the difference between these two problems.
But that's not the reason we would use simulation over Markov chains.
In fact, the situation we're looking at here could be formulated as a Markov chain.
The difference I see is that in this situation, you could have an infinite amount of bicycles in your bicycle shop.
So if we were to formulate that as a Markov chain, we'd have an infinite matrix, which is not terrible to deal with, but you wouldn't be able to deal with it in the way we just did.
Got it. Okay.
Talking about the states that I did kind of awkwardly in the previous chapter, it's just how many people are in the shop.
So there's three people in the shop.
Well, there's a probability that the next thing that happens is four or the probability that the next thing that happens is two.
So it's a very straightforward set of states that is finite, as Garen said.
Here, there's two things to keep track of.
There's the number of bikes being seen by, waiting to be seen by an inspector, the number of bikes waiting to be seen by the repair shop.
And that just immediately, the fact that now you've got these two dimensions that can change, just again adds to the complexity and the fact that it's an infinite amount of them.
Yeah.
So the reason we would use simulation for this is because it's a more complicated situation for a variety of reasons than what we had before.
And it would take a really, really big, if not infinite matrix to be able to solve this.
So why would we go to that effort when we can get quick, easy answers just by virtually playing this?
These two chapters are paired.
And actually, there's this, all the chapters are paired in the book for the reason that they are kind of the two similar types of problems from opposite angles.
And correct me, Garen, if you don't agree, but I think that the two opposite angles about numerical tractability, how much you can do with an exact method, which is what the previous chapter was, versus a more approximative method.
And it's not always easy to say exactly what you should use one or the other.
Sometimes it's absolutely clear, but sometimes it's not.
But there's these pairs of chapters that kind of reflect that, you know, the size of the problem, for want of a better word.
Very interesting.
Okay, the fundamental Python bit here is the CIW, or you pronounce that Q?
Yeah, I call that Q.
C-I-W, Q.
It's the Welsh word for Q.
Q-U-E-U-E.
It's the Welsh word for that.
And that's why I call it the library though.
Fantastic.
All right.
And so the idea is basically you state the problem in terms of the arrival rate of events, the inspection or the service distributions in terms of how those flow through there.
The number of things that can be servicing it and the routing and so on.
You create a network with the Q library.
And then you could just ask it questions, right?
You can tell it to run a simulation.
You can run it for some amount of time, like eight seconds or so on.
And it's interesting that it simulates it, that it doesn't exactly solve it, right?
That's the point of simulation.
Well, not the point, but like one of the uses of simulation is that we can quite easily simulate something that's too complicated to solve exactly or would take too long to solve exactly.
But we can quite easily simulate it.
The trade-off then is because assimilation is essentially streams of random numbers that we do things to, you could get extreme values.
You could get flukes.
So you lose accuracy, but you gain efficiency.
Yeah.
So the idea is you run it over and over and over again with the randomness playing out there.
And then you just say, well, what is the most common set of outcomes look like?
Yes, actually, I guess.
Yeah.
Very cool.
So what did we learn from this one?
That we could add an extra inspector at the front or we could add an extra repairer.
And what was the better outcome here?
So we were measuring was the maximum amount of time a bicycle spends in the shop.
We wanted to get bicycles out as quick as possible.
So if we added an extra bicycle inspector, we would reduce our time, maximum time in the shop by quite a lot.
But if we added an extra repairer, we'd reduce it, but not quite so much.
So we essentially found that the bottleneck was the inspection desk and not the repairing.
How interesting.
And I suspect, maybe this is not true, but I feel like if I was a business, knowing that would not just help me hire the right person, but I think having an inspector type of person would be easier to get.
Right.
You don't have to have as great of a skill set to actually be the mechanic that does the repairs.
So that's really valuable as somebody who runs a bike shop.
I will also throw out another statement here.
It's probably true.
I also suspect bike shops don't employ these techniques, but should.
They can now.
They can.
Well, they can now, honestly.
I think.
I believe larger companies probably would.
Stuff like supermarkets and airports probably would have a team of people behind them doing this, but smaller shops, probably not.
Yeah.
Gosh, I'm trying to remember the name.
Not always, right?
Would be a little caveat I'd say to Gary.
We certainly know of lots of examples of big entities, companies, things that make very expensive decisions without doing these sorts of investigations.
Yeah.
Well, you mentioned grocery stores and stuff.
I had the folks from Kroger, which I think, if not, is the largest, one of the largest chains in the US.
They have basically an analytics and data science subsidiary called 8451.
They employ 200 data scientists who do R and Python.
That's awesome.
That's not joking around in terms of, you know, where do the bananas go and those types of things, right?
So you're right.
The larger companies definitely, definitely invest in that.
It's the interesting thing about what is data science, right?
Talking about data scientists in that, are they looking at historic data and identifying things?
And I suspect that there's no answer to my question here.
I suspect different data scientists do different things.
But when you share a data science department, that doesn't necessarily mean they're doing this type of work.
It might be.
Absolutely.
It might be.
But it might also be diving into the data and understanding and observing as opposed to necessarily modeling possible.
It could be AI.
It could be AI and ML.
It could be a data ETL, just bringing in data and just getting into system.
Yeah, there's all these different aspects.
I wonder more about the data science on when do I go from being somebody that uses, say, Python for computation to becoming a data science, right?
When do I, would you cross the boundary from being a mathematician or a biologist to becoming a data scientist that has some understanding of biology, for example?
I would argue it kind of goes back to what we were saying earlier about what is an applied mathematician and, you know, at what point are these labels helpful and at what point are they not, right?
Yeah, exactly.
Out in the audience, Fritam says, yeah, data science is such a catch-all phrase right now.
I would agree.
Also a buzzword.
So if you're looking for a job, it's a good one.
All right.
Let's go on to another one.
We'll get through as many of these as we can.
And then we have time for anyway.
So those two problem areas were paired together.
Yeah.
The next area that you focused on is fairly different with differential equations.
So those two areas that we were just in is the book's got parts and it's two chapters in every part.
And that was in the probabilistic modeling is what we'd call it.
It's modeling these probabilistic type situations.
And here we're in the dynamical systems section.
And so specifically here, we're looking at a problem where differential equations can be used.
And we wrote, we started writing this book before the world changed, before COVID happened.
And I remember coming into our writing sessions.
I have to say, I really enjoyed writing the book.
Very glad to have it finished, but I enjoyed writing the book.
And I said to Gary, Gary, do we need to change this chapter?
Because this chapter, there's a disease going around.
I think we call it a cold.
Yeah.
Everyone's caught a cold in a small community.
There's a cost to not being able to work.
So coined that to have a cold.
Right?
And there's a cost, a financial cost to not be able to work.
Financial cost with a possible cure that would double the rate at which you get better from the cure.
Is it worth, from the cold, pardon me, is it worth financially to get this cure was the problem.
And yeah, we were like, should we make this about COVID?
You know, should we just essentially all the graphs we spent so long looking at that was on the news all the time.
You know, this is it.
This is essentially the same thing.
Yeah.
Should we make it about COVID?
And we decided not to, didn't we, Gary?
We decided to just keep it somewhat abstract.
But yeah, that's the problem here.
And yeah, the model is, is a textbook for want of a better word, a textbook model that's often taught when you start learning about systems of differential equations called the SIR model.
And the SIR model has a population in three groups, susceptible people.
Sorry, Vince, I think you're talking about a different chapter.
I am talking about the right chapter.
Thank you, Gary.
Sorry, I went off on one.
Thank you.
That's the next chapter.
No, no, brilliant, Gary.
They're similar.
Yeah, they're similar.
Very similar.
This one we wrote, you can write down a differential equation that dictates not a system, but just the number of people that are infected over time.
And so you can write that down, that differential equation.
You can get a solution for it.
Sorry.
Thank you, Gary.
Thank you.
Yeah, no worries.
This one actually uses an interesting library that I am just fascinated with.
It's an awesome library.
Called SimPy, right?
Yeah.
I just had the folks on back in May, not too long ago for this one, Andre and Aaron for this.
And I did not expect this from Python because it's, I expected NumPy and the linear algebra type things, but not, you know, here is the integral of this solution of this differential equation.
And here are the steps that I took to get there.
It is so neat.
SimPy is an incredible library that just gives you so much of what mathematics is thought to have to be commercial in that you can have all your symbolic stuff.
So, you know, if you want to know what is X plus X, you don't need to tell the computer what value X has.
With SimPy, the computer can just understand the concept that X is this mathematical idea.
And it's incredible.
And it's a fantastic, fantastic library.
I think it was when I started teaching programming to our first year cohort, I actually taught SageMath and SageMath is built on top of SimPy.
But at some point I decided to just teach with SimPy.
And so that's what we use here.
That's what we use here.
We build up the actual numeric solution for the differential equations.
We find the expression that if you put it into this differential equation, that would be the solution.
We get an exact solution here.
It's pretty wild.
You say the way you set it up.
I mean, everything about SimPy is wild.
But the way you set it up here is you say, I'm going to create some symbols like time T or constant alpha or so on or initial conditions.
And then you say, I'm going to have a function.
You don't say what the function is.
You say there is a function called I.
And then what you define for the thing you're going to work with is you say, sim.equation.
And you say, the equation is going to be given the derivative of this function of T and T.
And then it has this expression in there.
Negative.
I guess that's probably the, what you're specifying here is this is the derivative, not the equation itself, which is negative alpha times I of T, right?
This is one of those parts of SimPy that when we teach this to our first years, it allows us to help identify misunderstandings about the mathematics.
I think programming can often help you understand mathematics better and likewise and vice versa.
But people often come to study mathematics and don't know the difference between a formula and an equation.
And an equation has two sides.
An equation has an equal side in the middle.
And so what you're creating here is sim.equation.
Sim.equ takes two variables, a left-hand side and a right-hand side.
That's actually the name of the parameters.
So the left-hand side is the derivative of I.
So it's saying that the speed at which the number of infected people changes over time, that's the left-hand side of your equation, is equal to, and then the right-hand side of your equation, some constant alpha minus some constant alpha, sorry, times the number.
So the speed is related to the number, and that's really the relationship that defines differential equations.
Right.
And in this scenario, you can change the alpha, the rate of recovery, by providing medicine or just letting people do their thing, you know?
Naturally recovery, absolutely.
Yeah, yeah, exactly.
So in here, you say, you know, given these constants, we're going to, you know, get the equation and then you solve it.
You come up with the actual symbolic solution.
Symbolic solution.
Always blows my mind.
You say sim.dsolve, like, does that solve the differential equation?
I'm guessing.
You give it the equation and the initial conditions and stuff, and you're like, where the initial condition is, we defined a function I.
We didn't say what it is, really.
But we said at zero, it's the initial condition of like how many people are sick or whatever that turned out to be, which is just...
All of which are symbols.
Amazing.
Everything here is just an idea.
Nothing's a number.
Everything is just an idea or a concept.
Yeah, yeah.
We don't know anything about it.
We just know that these are the constraints of the equation.
And now it gives you, you get the solution and it's, it's an equation.
Let's see.
I got to go further down.
So that's it there.
It says that...
It gives you the actual solution and then you start plugging in like the numbers, the different conditions, and it gives you the answers, right?
Sorry.
Exactly.
Yeah.
You plug in the numbers at the end.
So we get the cost if you were to purchase the cure would be 700 and the cost without purchasing the cure would be 500.
It's just the overall costing into account productivity, offsetting all the impacts of similar type of decisions that governments all over the world will be making.
And in this particular case, for this cold, Jadier is no, it is not worth getting.
But good care.
Don't tell that to the people who are suffering with a fever.
It's a cold.
This is not like the common cold.
This is a cold.
Yeah.
We found this chapter really, really neat because when we started doing exactly the same thing going, how do we solve this in R?
We realized we had to use a completely different approach.
How do is a bad phrase.
We went looking at R for an equivalent symbolic mathematics package in R.
And there is one.
But really, it's a wrapper for Python's SymPy.
And so we found ourselves writing strings of Python that you pass to R that R passes to SymPy.
And yeah.
Sorry.
Yeah.
I think this is your point now.
That doesn't sound like really like solving it in R.
Exactly.
So then, so we decided, well, no, if we were just to solve this in R, how would you do it?
And as there is no symbolic library, a library for doing symbolic mathematics in R, we solved it numerically.
And that just shows like exactly the same problem.
We get exactly the same answers out.
But the bit in the middle, the solution steps were completely different in both Python and R for those reasons, which I think is really neat.
I think that shows that you're concentrating on the problem.
Rather than the solution steps.
Absolutely.
And what you've learned here is that this function that expresses the cost of people being sick, I of T that we talked about is 100 for 100 people sick.
E to the negative alpha of T, which is, it's pretty awesome.
I mean, there's never, there's almost always a reason to marvel at the number E. Have you all read the book E, the story of a number? Have I mentioned this before?
I don't think I have. No.
This, this book is so good. It just goes back to the history.
Is it good?
Literally of just, oh yeah, yeah. It's, I totally can recommend it. So people can check that out if they're...
E is a ridiculously cool number, right? In terms of, I know Pi gets all the press, but E is a ridiculously cool number.
It's way cooler than Pi. It's way cooler than Pi.
I mean, Pi is cool, but it's, if you are into the change of anything, differential equations, integrations, like it's, there's nothing like it.
I had not heard about that.
We are going pretty long on time here. So I don't, I want to be respectful of your all time and everything.
So maybe, is there any other, the problems or areas or libraries that you've made? Actually, let me, let me pick one here.
Which chapter is the game theory one? Seven or nine? Let's see.
Wait for it. No, it's not.
Just one before that. Yeah.
Or yeah, no, it wasn't before that. Yeah. Got it. Yep.
The missing one is the linear programming one. All right. Game theory.
And the reason I want to pull this up is we talked about you, Brent's library and his application.
How about some Nash pie? I mean, there was a John Nash won the Nobel prize in economics for coming up with, basically proving every, in every game, there was an equilibrium position, which is insane that that's true.
In a 17 page PhD thesis. Yeah. Incredible.
And not bad. Not bad. so quick game theory. What is it? People maybe have heard of it, but they don't really know, or maybe they do know.
I fumbled through the previous one, Gary, but it would make sense for me to take this one.
Yeah. She should.
Right.
So game theory is the study of emergent interactions of if you can kind of make some decisions, describe a system at the lower level, how individuals interact, what happens at, at the higher level. That that's the study of game theory. It's, it's interactive decision-making. A lot of the time you can think of decision-making.
For example, with that barbershop problem.
I've discussed at the first stage of, well, if I had this many chairs or this much waiting room, what's the best thing for me? But there you're the only thing that your decision gets hit back with. If you think of a game of tennis, it's playing against the wall. It's playing against that probability. Game theory is just taking it to a slightly different dimension where you have two barbershops. What if you had two barbershops? And if one does this and the other does that, where are the customers going to go? Is the kind of idea.
Right. Both barbershops could say, expand their waiting room. Both barbershops could hire more barbers or one could say, you know what, if you hire barbers, I'm getting a bigger waiting room. It's like that trade-off. Yeah.
Exactly. A very famous problem in game theory is the prisoner's dilemma. Two criminals are convicted and are separated and are questioned and they can give evidence about the other prisoner. If they both stay quiet, they both give no evidence. The police won't have enough evidence to send them to prison for a very long time. They'll have to stay for a very short amount of time. So that's in their interest. But the police offer me a deal. And if I give evidence about Geraint, then I'll go free and Geraint will go to prison for far longer.
Geraint gets offered the same deal and that immediately creates a dilemma that we will both end up getting for a long time. We will both give evidence one about the other. And so that's a very simple model. And that's actually what I came on the show a long time ago to talk about was that actual model and all the interesting stuff you could do with that.
But this game theoretic chapter is paired with another chapter called agent-based modeling. It's again, one of those points where labeling is interesting because for some agent-based modeling is a subset of game theory. No way it doesn't really matter. And so this chapter is all about emergent behavior. If we can define how decision makers in our system interact, what happens based on what they do, and they being plural, then what is the emergent behavior that you can measure?
The game that we model in this chapter is there are two taxi firms that serve a community, again, a small town, and they get to decide how many taxis they're going to have.
The town wants to incentivize these two taxi firms, essentially not to collude.
They want to incentivize the taxi firms to give better service to the population.
And so we create the game that allows the tax firms to decide how many taxis they're going to have, one, two, or three.
And we build a little model that describes what happens if each tax firm has one taxi, what happens if one has one, the other has two, what happens if one has one, the other has three, et cetera, et cetera.
And then we obtain what is called the Nash equilibrium, which is a measure of if both tax firms know all this and act rationally, what would we expect to happen?
It's just amazing how these outcomes, it's just so clear, you know, if what's the likelihood of the other person doing or the other player participant taking this particular choice.
And if or if I take this choice, what are they most likely to do?
And where are things going to settle in?
It's really neat how this all sets up here.
And let me find the section.
Yeah.
So what you do is you create a NumPy array or that represents one of the participants outcomes and choices.
And this one, I guess it's a what is this a zero sum game?
Because you know, quite not quite.
It's not zero sum.
It's symmetric.
That's symmetric.
OK.
So you pass in the transpose of that, which says here's the other player.
They get basically the opposite of that.
And then you just say Nash.game and off you go, right?
Yeah.
Nash.game creates this game.
It creates the game object.
And in the game object, the Nash.py library has all sorts of different algorithms that could be used.
And the one where we use is something called support enumeration, which is essentially the basic by definition idea.
And the thing that we do do here is we say, OK, if we are the town hall trying to decide how to let these two tax firms compete, is we essentially are deciding not how we regulate them, but how we incentivize them.
So what game should we make the two taxi firms play?
And we do that by essentially say, I guess we will tax you slightly less if you put on this amount of taxis or give you an extra bonus if not.
And the idea is to what is the smallest amount that the city hall has to kind of guarantee to taxi firms to ensure that their rational behavior would be to give that service to the population.
So, yeah, then it's just that those three lines you go on the screen right there.
So while loop where it just increments that offset.
Yeah.
And you just say, get the equilibrium from it and off it goes.
Yeah.
Very nice.
OK.
This is really great.
And I guess it's worth pointing out.
I heard of the guy.
Yeah, that's me.
I should say that.
Work on this project.
So the Nash By Library is myself and former undergraduate.
Actually, they went on to start their PhD at the School of Mathematics.
We started this library.
It's grown quite nicely now.
To be honest, probably the part of the library I'm the most proud of is the documentation.
There's arguably a game theory textbook in there if anyone's interested, as well as all the functionality for two-pack games.
Yeah, fantastic.
Yeah, it looks really great.
I'm a big fan of game theory.
I think it's very simple.
And yet it reveals pretty amazing answers and behaviors.
You know, as opposed to something like partial differential equation, which can also reveal amazing answers.
But the journey to get through it is extremely long versus this.
You could sit down in the afternoon and explain it to somebody, you know, like that prisoner's dilemma and so on.
We could all kind of relate to a lot of what's happening there.
You realize that you're aging.
But I remember when I first started teaching game theory, everyone had seen the movie A Beautiful Mind.
But if people listening and are slightly interested in game theory and haven't seen A Beautiful Mind, I'd definitely recommend it.
It's a Hollywood movie, so have the correct level of expectations.
It's a really nice movie.
Russell Crowe plays John Knapp.
And it's more about, not necessarily about the mathematics, but more about his life, which is incredibly interesting.
And there's a couple of scenes in that movie that arguably, if you just spend a little bit of time talking about a couple of seats in that movie, you can explain most of the game theory.
Absolutely.
All right.
Well, I get the sense we're a tad bit over time, which is fine.
But maybe we should wrap it up here.
There's a bunch of other areas that we haven't covered that are lots of fun that you go into.
So, yeah, very, very neat.
But let's kind of wrap it up.
Maybe we'll ask you the final two questions.
I want to thank you for having us.
But I know that you got these two questions coming.
So, like, oh, do I thank you now?
Do I thank you later?
But no, I just really do appreciate you having us on.
I really do appreciate you as a guest.
Yeah, you're very welcome.
It's been great to talk about it.
All right.
Now, maybe a lightning round.
Vince, if you're going to write some Python code, what editor are you using these days?
I use them.
Right on.
Brent?
I use Sublime.
I really like having no features.
I just like typing.
I don't want features.
Right on.
Perfect.
And then a notable PyPI package that you've come across that you're thinking is worth giving a shout out to?
I was thinking about this before.
And the one I'm going to suggest is one called Python Ternary.
You've got it on the screen there.
Yeah.
Python Ternary is a library for plotting on simplexes.
So for plotting on triangles, want a better word.
It's the type of plots you draw a lot in evolutionary game theory, as well as other things.
It's actually a collaborator on a product of mine that maintains this.
And it's a very nice library for plotting different looking plots.
I'm sure people think about, well, you could have these different plots on triangle surfaces or, you know, like how much are you at?
How close are each three different states or something like that?
Yeah.
Some of these are really amazing, like this M Cherry one on there where it's got kind of crawling graphs through these triangle different states and so on.
Yeah, I haven't seen anyone like that before.
It's very cool.
And it's built on top of Matplotlib.
So it's essentially the layer to do all the correct scaling and things like that is there for you.
So yeah, Python Ternary is really cool.
Yeah.
Fantastic.
Grant?
I think the library I would choose is, it's called Traces.
It's a small library that, I don't know if you've heard of it before.
I've got the link here.
Oh, that one.
Yeah.
It does one thing and one thing good.
It takes moving averages over irregular time intervals.
And it was a problem which I thought I had until I found this.
And then it just made life easier.
I liked it.
Yeah.
Very cool.
Okay.
I think it's the next link.
I think it's one just below that.
This one right here?
Not that one.
This one?
There it is.
Yeah.
Yes.
The Uneven Time Series.
Yeah.
Perfect.
Okay.
Yeah.
Oh, yeah.
That looks great.
It does one thing and one thing good.
Fantastic.
All right.
Well, yeah.
And yeah, that's often just what you need.
Put a link to both of those in the show notes.
Thank you so much.
So people are interested in your book or maybe exploring some of these problems.
What do you tell them?
Where do they go?
If you're interested in the book, that's great.
I think I'd more kind of emphasize just mathematics is so incredibly powerful.
And it really, really is.
And it's kind of like I feel that code, open source code, Python, kind of an order of how important each other is.
And so I think I'd encourage people to investigate those things and you can do amazing things with mathematics and a bit of code.
That'd be mine.
I don't know what you think.
Absolutely.
No, no.
Yeah.
I second that.
I think my main message is the maths and the software are separate things and they complement each other really well, but they are separate things.
They are separate things.
Yeah.
That's it.
Fantastic.
All right.
And like I said, your book is on GitHub.
So people can go poke around some of the examples and some of the notebooks and see what we're talking about.
Make it a little more concrete.
Make it a little more applied, maybe.
Yes.
All right, guys.
Thanks for being here.
Thanks for sharing your work.
It's been a lot of fun.
No, thank you so much, Michael.
Thank you.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Listen to an episode of Compiler, an original podcast from Red Hat.
Compiler unravels industry topics, trends, and things you've always wanted to know about tech through interviews with the people who know it best.
Subscribe today by following talkpython.fm/compiler.
Sign up for the Python at Scale conference to connect with your data science colleagues and learn about trends in the Python big data ecosystem.
Share stories about implementing solutions and find out about innovations in our space.
Visit talkpython.fm/Python dash at dash scale.
That's talkpython.fm/Python at scale.
And use code Talk Python to get 15% off your ticket.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.