0:00:00Welcome to Under the Radar, a show about independent iOS app development.
0:00:03I'm Mark O'Arment.
0:00:04And I'm David Smith.
0:00:06Under the Radar is never longer than 30 minutes, so let's get started.
0:00:10So this past weekend I had the privilege of attending a friend of mine's PhD dissertation
0:00:17defense.
0:00:18And congratulations, Carl, he passed.
0:00:20Oh, nice.
0:00:21And this was computer science, right?
0:00:23This is computer science, and specifically he was – he did his PhD in machine learning.
0:00:29So his dissertation was something that I understood maybe half of, but the half that I didn't
0:00:35understand prompted a few interesting conversations that I had with him over the weekend, just
0:00:40about the way in which we used computers to solve problems, and the ways that his dissertation
0:00:47and what he was doing is solving these really complicated, deep problems in this really
0:00:54interesting way that uses lots of computation and all these types of things.
0:00:58And for certain kinds of problems, that's what you have to do.
0:01:01But more fundamentally, I think what he and I were talking a lot about was just about
0:01:06sort of algorithms.
0:01:07And it's interesting, I find, that I think any introduction to computer science, like
0:01:12one of the first courses you have to take is almost certainly going to be some variant
0:01:17on introduction to algorithms.
0:01:22There's going to be this sort of this fundamental thing, and they walk you through the set of
0:01:26problems usually, like the classic ones are things like sorting.
0:01:30You have a list of numbers and you need to put them in order.
0:01:33How do you do that?
0:01:34And you kind of start with the maybe what you would call "naive" solutions, things
0:01:38like bubble sort and insertion sort, and then you start to get into the way more complicated
0:01:43ones where you start using quicksort or merge sort and radix sorting and all these really
0:01:49kind of clever, esoteric things.
0:01:53And usually I think that's presented as the algorithm that you start with, those naive
0:01:59solutions are like the, you know, it's like, well, they're the ones for the babies that
0:02:04when you're starting out, you use those solutions.
0:02:07And then you graduate to these really cool special ones.
0:02:10And in practice, obviously, like for sorting things, the reality is you don't actually
0:02:14ever use these algorithms ever again, because almost any collection framework just has a
0:02:20sort option on it and it'll sort it for you.
0:02:23But I think most of what they're trying to teach you when you're doing that is that,
0:02:28you know, understand that to solve an algorithm, which is probably worth defining, is an algorithm
0:02:34is probably best thought of just as a series of steps to solve a problem.
0:02:39And you define ahead of time what those steps are.
0:02:42So it's sort of like if you have a recipe for baking a cake, you know, like the goal
0:02:46is to bake a cake, and you have a series of steps that you have to do.
0:02:50And when you define a computer algorithm, that's really all you're doing is saying,
0:02:54you know, here's this series of steps of operations that you have to do in order to complete and
0:03:00do that task.
0:03:02I think it differs also from like, you know, like you can have like a lot of computer code
0:03:07that just does things that's basically like moving data around or doing simple things.
0:03:11I think when like, you know, if you're like, you know, populating a web page with like
0:03:15the results of the rows in a database, like I don't think most of the things you're
0:03:19going to do there are going to be what most people consider an algorithm.
0:03:23Whereas an algorithm, like I consider it, and the way I think most people consider it
0:03:25is like a method of solving some kind of interesting or non-trivial computing task of, you know,
0:03:33not just like moving data from one place to another or not just like basic math, like,
0:03:37you know, addition of things, but some kind of like slightly more complicated problem,
0:03:43like you know, as you said, sorting a list or something more complicated like detecting
0:03:46what's in an image, you know, like there's all sorts of things you can do.
0:03:49But like I think it has to kind of be like above just, you know, moving things from place
0:03:53A to place B to display them.
0:03:56It's something, some kind of method to solve a more complicated problem or accomplish a
0:04:00more complicated task.
0:04:01Yeah, I think that's fair.
0:04:02And I think, and certainly like when you're early, like the complexity of the problem
0:04:07that you're solving is, you know, will typically increase the more advanced of a developer
0:04:13you become.
0:04:14You know, I think there are some problems that were hard for me to solve when I was
0:04:17young and like the, you know, like I try to take some algorithms for granted now that
0:04:21I just, I know how to do something and so I do it.
0:04:25But it's, yeah, there's usually some sense of solving a novel or interesting problem,
0:04:30you know, by creating a series of steps that you apply to do that.
0:04:36And sometimes algorithms are very prescriptive, you know, like that it's this very straightforward,
0:04:40like do step A, step B, step C.
0:04:43And sometimes they can become very non prescriptive.
0:04:45And this is where you start to get into things like machine learning and neural networks
0:04:49and probabilistic things or heuristics where it's much more squishy.
0:04:55And like, you don't really know what's going on.
0:04:56Like a lot of what it seems like machine learning is, is like you are trying to train this magic
0:05:01black box to do magic black box stuff.
0:05:04But it's not an algorithm in the sense that you have like a specific set of things that
0:05:09that box is doing.
0:05:11It's much more you have to train and orient that box to do some task.
0:05:16But it's, you know, it's still used to solve a problem in that way.
0:05:22So in practice, though, I think what is interesting is what I find in the day to day work of being
0:05:27a software engineer is that usually most of the work I do, probably 80% of the work I
0:05:33do is the kind of work you were describing that isn't an algorithm that is these this
0:05:36kind of basic moving data around just sort of just shuffling things back and forth.
0:05:43It's making a web request, getting back a JSON object, parsing it, displaying that in
0:05:48a table view like that's like 50% of iOS is used for that.
0:05:53And then maybe another 30% is the like saving stuff to disk or doing kind of basic operations
0:05:58with that data.
0:05:59But what is interesting, I find is that we still, though, have situations where we have
0:06:06to invent a new algorithm to do something and maybe invent is the wrong word.
0:06:11Like sometimes these exist in the world, and we're kind of adapting them to our own use.
0:06:16But honestly, there are some times that I've had to invent something that I'm kind of making
0:06:20it up.
0:06:21And maybe the solution to this exists in a more concrete and authoritative way in the
0:06:26universe, but I typically don't spend my time when I have a problem I need to solve like,
0:06:31okay, let me go to the journals and research all of the past work that people have done
0:06:37in this area.
0:06:38Like, more often than not, for better or worse, I tend to just not, you know, I start with
0:06:43a straightforward solution.
0:06:45And if I hit a wall, like I hit a place that I can't do something, or I'm trying to solve
0:06:49a problem that's too sophisticated, maybe I'll go and try and kind of research something.
0:06:53But typically, I kind of just start doing the basic, what I think my computer science
0:06:58professor would always call the naive solution.
0:07:01And I start there, and then I expand out from there.
0:07:05And what's interesting, I found is that in practice, the naive solution is often good
0:07:09enough.
0:07:10The naive solution is often what I end up keeping with.
0:07:15Not necessarily because I like, usually the naive solution isn't as performant for whatever
0:07:20that means for what you're doing.
0:07:23But often, the nice thing about a naive solution is that it's often really clear and understandable.
0:07:29And the clever solution is often really complicated.
0:07:32Like if you look at sorting a list, like this canonical example of an algorithm, I can explain
0:07:39to someone how insertion cert works, which is essentially, you take an item off the list,
0:07:45and then you move along the list and see where it needs to go.
0:07:49And you look, take the next one, and you move your way along.
0:07:51And you kind of, you can very straightforward, like the actual code for an insertion sort
0:07:56is very straightforward.
0:07:58Trying to explain to someone how quicksort works, which I understand like myself, where
0:08:03it's like you're partitioning the data into log n partitions, and in each of those you
0:08:09sort and then you combine them back together in a clever way.
0:08:12Like it's clever, and it's more performant, and I'm glad that my collection framework
0:08:17uses it.
0:08:18But in practice, it's not very maintainable or easy to understand.
0:08:22And the analog of those and things that I actually use in my day to day life, I often
0:08:26find that the naive solution can actually sometimes be better.
0:08:29And I have a few examples that we'll get into in a bit of places where I've run into
0:08:32this recently.
0:08:33But it's just kind of an interesting thing to think about where sometimes you don't
0:08:37have to have a clever algorithm, you can just need to have an effective algorithm and either
0:08:42your performance will be fine, or even if it's a bit slow, it might be easier to maintain
0:08:49and overall be more reliable.
0:08:51- Oh yeah, and that's ultimately more important.
0:08:54Hardware these days is really, really fast.
0:08:58And so it's always, this is like the kind of the root of all evil being premature optimization
0:09:03kind of thing.
0:09:04It's always good to try the naive solution first, because chances are it'll probably
0:09:10be fine.
0:09:12There's been very few cases where I've had to get really clever.
0:09:15Like normally I just try to do something in a straightforward way, because as you said,
0:09:18it is better for things like maintainability and especially code readability.
0:09:23If you write something really clever and you come back to it in two months, are you going
0:09:27to understand what it's doing and be able to debug it or expand it or maintain it?
0:09:32Whereas if something is very straightforwardly done in a naive looking way, it's actually
0:09:38really easy to read and really easy to understand.
0:09:39So that's better long term for maintainability.
0:09:42But also just like, the hardware is just so fast, don't underestimate it.
0:09:48Don't assume until you've actually tried the naive solution first, don't assume that
0:09:51it will be too slow.
0:09:53That being said, one of the most valuable things I learned in my computer science algorithms
0:09:58class is the concept of algorithmic complexity.
0:10:02This is basically the rate at which the performance or memory usage gets affected as the size
0:10:11of the input grows.
0:10:13So this is the big O notation in computer science stuff and stuff like that.
0:10:17And so the idea basically is if you have two nested loops, first iterate over all the things
0:10:23on the outside, and then for each iteration of all the things, iterate over all the things
0:10:27again and do something with whatever you find.
0:10:30That grows exponentially with the size of the input because for every value in the input,
0:10:36it has to do that value or the number of values squared number of operations.
0:10:41Whereas if you can do something in one pass, that's only doing number of values type of
0:10:46operations.
0:10:47And so the idea of designing algorithms to say only do something in a single pass or
0:10:54to only do something in place instead of needing a whole bunch of memory or things like that,
0:10:59that does have value to me more frequently than I think because there's simple things.
0:11:06I can design my app in Overcast.
0:11:10I only usually have about 10 to 30 unplayed podcast episodes.
0:11:16And so I can design the app such that it works fine for people who have 10 to 30 unplayed
0:11:20episodes because that's what I'm living with and that's kind of what I can test as being
0:11:23fast in my own day-to-day usage of it.
0:11:26But there are some people who have 500 unplayed episodes or 10,000 unplayed episodes.
0:11:31Yes, I know it sounds crazy, but we've done episodes on this before about like extreme
0:11:36users or extreme conditions.
0:11:38And so I actually had to make a test account that subscribed to like a thousand podcasts
0:11:43and didn't listen to any episodes for a year.
0:11:45So it has this massive back catalog and I have to test things on that because sometimes
0:11:49like the assumptions I make when I'm dealing with a really small input size like 20 or
0:11:5430 simply are not performance enough or not even usable or might crash if you have like
0:12:01a couple hundred or a couple thousand of something.
0:12:04And so it is like the algorithmic complexity does end up mattering in those extreme cases.
0:12:11If you have something that grows very quickly, some kind of very complicated method like
0:12:15my playlist sorting method is exponential and it doesn't matter when you have 30, but
0:12:20it does matter when you have a thousand.
0:12:23And that makes the whole app basically unusable.
0:12:26So I had to do things to fix that and I had to measure it with instruments and figure
0:12:31out what was slow and then I found this one method.
0:12:33It was again, it was like a nested loop and it was like, "Oh boy, that's going to be real
0:12:36bad."
0:12:37And like you don't notice it when it's a small amount of input, but it becomes a problem
0:12:41when it's a big amount.
0:12:42- Yeah, and I think that's a good example where it's the, like sometimes you have to
0:12:48be clever and sometimes you have to go to literature or have to go to places to find
0:12:53the clever solution that someone has invented a method for doing this in a more performant
0:12:58way.
0:12:59But it's a lovely, I love the approach though of just not starting there and not trying
0:13:04to be too clever.
0:13:05And I recently, and this is, I think actually a good concrete example to kind of make this
0:13:09point.
0:13:10So I've been, as we'd mentioned a few episodes ago, I've been making watch faces recently.
0:13:14And one of the things that's always bugged me about the Apple Watch is that if you look
0:13:18at the time, or you're trying to look at the date, at certain times of the day you won't
0:13:24be able to see it because the date is covered by the hour hand or the minute hand, which
0:13:30is silly because this isn't a physical object.
0:13:33This is something that can move things around.
0:13:36And so--
0:13:37- By the way, for the record, physical objects that have this problem usually have hands
0:13:41shaped such that it's not a problem.
0:13:44And also because they're three dimensional, you can usually just tilt the object to the
0:13:48side slightly and see under the hand.
0:13:50- An excellent point.
0:13:51So the digital version is worse than the physical version, which just annoys me at so many levels.
0:13:58And so in all my watch faces, what I wanted to do is if I show the date, I want to make
0:14:02sure that it's never hidden by the hands.
0:14:05And so I needed to come up with a method for moving the date around.
0:14:09So essentially, and I'll have a link in the show notes to a kind of a video of showing
0:14:13this in action.
0:14:14But so what I want to do is as the hands sweep along, if either of the hands is going to
0:14:21cover the date, I want to move the date out of the way so that it is still visible.
0:14:28And the reality is you don't have to actually move the date very much in order to accomplish
0:14:32this because in practice, it's very, very subtle arcs that you're having to move it
0:14:38down.
0:14:39So it doesn't actually even look really weird because it'll snap back into place.
0:14:43But that was my goal.
0:14:44And so I need to kind of in this context, I need to make an algorithm to reposition
0:14:48this and work out where the date should be displayed at any given time.
0:14:52And I started down the road and this is like, this is why this topic came into my head was
0:14:56I forgot the lesson of starting simple, instead complicated, because I've been doing so much
0:15:01trigonometry and math and all these kind of clever things to for some of my layouts in
0:15:06watch design, you have to do a tremendous amount of trigonometry, like it's just it's
0:15:09all trig.
0:15:11But the I started down this road of like, okay, can I kind of come up with this system
0:15:15of equations and constraints that I'm opting to kind of optimize over to work out when
0:15:20I'm going to be over something and then it was easy to handle the case of one hand because
0:15:25I can easily detect if the date areas, you know, being overlapped by one thing, but then
0:15:30the tricky thing is, well, if I move it, then it may intersect the other thing.
0:15:35And then do I move where do I move it from there, because I could then potentially move
0:15:38it back if I didn't add me if I didn't have a clever equation for that.
0:15:43So I have all this complexity, and I can't get anywhere.
0:15:46And so I'm like, what is there a simple way to do this.
0:15:48And what I came up with was this like, pointlessly simple version of this algorithm that turned
0:15:54out in practice to work really well.
0:15:57And so all I do is I had the so you look at you look at the situation and say, the date
0:16:03is going to be in one of five places.
0:16:05It's either going to be in its normal, like the three o'clock position, like its home
0:16:10position, it's going to be just above or just below the minute hand or just above or just
0:16:16below the hour hand.
0:16:17Like necessarily, those are the five places that it can be, because it'll either be shifted
0:16:23just past or just above either of those hands.
0:16:26But those are the five places it can be like that.
0:16:30That's like my overall assumption.
0:16:32And I think that works.
0:16:33And then all I need to do is say of those five positions, are any of them covered by
0:16:40one of the hands?
0:16:41So that obviously, the is the home position or are one of the other hands covering the
0:16:47other hand essentially.
0:16:48So if you imagine like 315, where both hands are kind of over on the slide, then certain
0:16:53some of those positions are going to be a little complicated.
0:16:55If they are, ignore them.
0:16:57So I start with five, if any of them are have to be discounted, I discount them, you know,
0:17:02so maybe I'll end up with four or three possible locations.
0:17:05And for each of the locations, I just say which one is closest to the three o'clock position,
0:17:09whichever one it is, use that one.
0:17:12And that algorithm works.
0:17:14It's exact, it does exactly what you mean.
0:17:17It's super simple, though, like, and it's like the code for it is incredibly clear,
0:17:21because it's just like, here's five positions.
0:17:24You know, do any of them need to be excluded, which is a very easy, like straightforward
0:17:29operation to do, because I can just look at where it is and look at where the hand is
0:17:32based on the time and say, do they do the are these two things the same, you know, modulo,
0:17:37like the, the width of the hand.
0:17:39And then from that, just like do a quick, you know, distance, like linear, like literal
0:17:44distance between the between the the home position and those things, and which everyone
0:17:50is closest to us.
0:17:51And it works.
0:17:52And I loved that it was one of these things like that solution is a super simple algorithm,
0:17:58very understandable.
0:17:59Anybody could, you know, it's like I could, it took trivial to code up is very, very clear.
0:18:05And it works.
0:18:06And like, is it the most efficient?
0:18:07Is it the most optimal?
0:18:08Like, I don't know.
0:18:09But in this particular case, it works fine.
0:18:11And I love anytime I can find these solutions where it's like this really straightforward,
0:18:16simple algorithm for solving a clever problem, but not in a way that is going to hurt my
0:18:21head or in you know, in six months, if something good saying doesn't work quite right, or
0:18:25I change the shape of my watch or like something changes, and I have to debug something and
0:18:29it's like a complete nightmare because it's a big series of linear equations that I barely
0:18:33understand.
0:18:34Like, there's always that thing where people say, you know, the problem with writing the
0:18:37cleverest code is that it's like debugging is twice as hard as coding.
0:18:42And so if you code at your limit of intellect, debugging is going to be impossible, but you
0:18:48have to code at half your intellect, so that when later when you're debugging it, you
0:18:52can use your full intellect and still solve the problem.
0:18:55I like that.
0:18:56That's a good one.
0:18:57We are brought to you this week by Linode.
0:19:00With Linode, you have access to a suite of powerful hosting options with prices starting
0:19:04at just $5 a month.
0:19:06You can be up and running with your own virtual server in the Linode cloud in under a minute.
0:19:10Whether you're just getting started with your first server or deploying a more complex system,
0:19:14like I mean, I host a bunch of stuff at Linode.
0:19:15I host all of my all of my web stuff there, including all of Overcast.
0:19:19And that is something like 25 servers at this point.
0:19:23And whether you have just one or whether you have 25, whether you have 100 Linode is a
0:19:27great choice.
0:19:28They have the fastest hardware and network.
0:19:31They have fantastic customer support behind it all if you need any help with anything.
0:19:35And it has just never been easier to launch Linode cloud server.
0:19:37They make it super easy.
0:19:38They have great documentation, great support, great help.
0:19:41And they guarantee 99.9% uptime for your server.
0:19:44Once your server is up, they intend to keep it that way.
0:19:47They also now offer additional storage, block storage is now out of beta.
0:19:51So Linode has fantastic pricing options available.
0:19:55Plans start at one gig of RAM for just $5 a month.
0:19:59And they offer high memory plans as well, starting at 16 gigs of RAM and lots of stuff
0:20:03in between.
0:20:04As a listener of the show, you can get a $20 credit if you sign up at linode.com/radar.
0:20:09So that will support us.
0:20:10That will show your support for the show and Relay FM and you'll get $20 towards any Linode
0:20:15plan.
0:20:16So if you get $5 a month, one gig plan, that could be four months for free.
0:20:19And with a seven day money back guarantee, there is nothing to lose.
0:20:22I love Linode.
0:20:23I highly suggest you check it out.
0:20:25It is the nicest web host I've ever used, bar none.
0:20:29And one of the nicest web apps I've ever used.
0:20:31It's really, really nice.
0:20:33So go to linode.com/radar to learn more and sign up and take advantage of that $20 credit
0:20:39or use promo code radar2018 at checkout.
0:20:42Thank you so much to Linode for supporting this show and Relay FM.
0:20:47So one thing I found, I love coming up with a clever algorithm, not in the sense that
0:20:52it's super complicated, but I love when I find something stupid that works.
0:20:56Something that's just like, I can't believe, when you can literally just say, I can't believe
0:21:01that works.
0:21:02It's such an incredible pleasure as a programmer when you find some really dumb solution or
0:21:07work around that's like, you feel like you're getting away with something.
0:21:10This shouldn't be this easy.
0:21:12It shouldn't work.
0:21:14But yet it does.
0:21:16And that is one of the most satisfying things you do as a programmer.
0:21:20Yeah, no, absolutely.
0:21:21And I think there is something just so, and I think in many ways, those are my favorite
0:21:26moments of where you have these moments of insight where you're like, huh.
0:21:29Yeah, no, the super simple basic version actually works.
0:21:32I had another one that comes to mind for me of, I had, so in Sleepless Plus, I do automatic
0:21:37sleep tracking now, which at first I thought was gonna be this ridiculously complicated
0:21:42machine learning or have it to get into crazy algorithms problem to solve.
0:21:49And I sort of go in, but to start with, I was just like, well, it's just like, I've
0:21:53been collecting all this manual data.
0:21:54And so my manual sleep analysis where you use the actual accelerometer movements of
0:21:59your wrist during the night and use that to approximate your sleep.
0:22:02And I had all this data and I was like, well, let me just plot of all the data that's being
0:22:07collected currently by the system against the data that I already have and kind of see
0:22:14if there's vague correlations.
0:22:16And the, of course, the, there's this moment where I look at the data, I'm like, active
0:22:20calorie data aligns exactly with what I was calling restlessness previously.
0:22:28That's interesting.
0:22:29So instead of having to do, which makes sense, like intuitively for what they're measuring
0:22:34with active calories, that they're looking for movement as well as like heart rate data.
0:22:37But it was this funny thought of like, huh, so all that complicated stuff I was thinking
0:22:41I was going to have to do with like looking at your heart rate and doing all this analysis,
0:22:45you know, it probably is pretty much just like some kind of heuristics over active calories.
0:22:50And then it's, and then like magic, it works.
0:22:53And basically, that was what I did.
0:22:55And that's what happens.
0:22:56And it's like, I just remember, I still have a screenshot of it, of this, like, doing
0:22:59this little plot of like my data versus active calorie data, you know, because I tried with
0:23:04heart rate data, and that didn't really align very correctly.
0:23:06I do that.
0:23:07And it's just like, huh, these align perfectly.
0:23:09Like it's like 98% of exactly the same data.
0:23:12And all I have to do is solve that 2%.
0:23:14But it seems like I'm getting away with something because it's super simple and super
0:23:17straightforward.
0:23:18I didn't have to do like this crazy, like, okay, I need to encode all this data into
0:23:22some method.
0:23:23And I can throw it into core ML, whatever that means, I don't even know.
0:23:25And then like, do some magic.
0:23:26It's like, no, I can just take the data and just process it in a reasonable way using
0:23:31some clever heuristics.
0:23:32And, you know, I validate this against a lot of data and as long as it still works, then
0:23:37it's fine.
0:23:38Yeah, my favorite hack algorithm is the fast inverse square root, which I've never had
0:23:44a need for.
0:23:45But I came across this and, you know, reading about it a long time ago, and it was something
0:23:49in Quake 3 Arena.
0:23:51And it was, it basically approximates the inverse square root by not doing any division
0:23:58at all and only by like doing this weird bit shift with this one special number.
0:24:03And like in the code, like in the Quake 3 source code, it even says like, you know,
0:24:08the spelled out version of WTF after this one line with this magic number.
0:24:11Like why does this even work?
0:24:13But it totally does.
0:24:15And so, yeah, that's like, I just love that feeling of like, either I can't believe this
0:24:19works and/or I don't understand why this works, but it does.
0:24:24Also like one area of algorithms that I find very satisfying is when you can make a jump
0:24:30in performance that is ridiculous.
0:24:32Like that feels like you're getting away with something there too.
0:24:35It's like not only in simplicity, but like if like a new tool becomes available to you
0:24:40or a new technique or new hardware becomes available to you, that takes something that
0:24:44used to be a very slow thing or a very complicated thing and makes it very, very fast.
0:24:48Like not getting like a 2x performance, but getting like a thousand x performance.
0:24:52And that kind of thing happens a lot of times, you know, as hardware advances, we get things
0:24:56like GPU acceleration, which I've never really had a use for directly, but like, you know,
0:25:02if you can, if you're doing something complicated on the CPU that the GPU could be doing for
0:25:07you, you can get like, you know, 10x, 100x, 1000x kind of improvements with GPU acceleration
0:25:12if it's the right kind of work.
0:25:14Where I find value in this is in vector operations.
0:25:17Like I've talked about this before, like the accelerate framework on iOS and Mac OS is
0:25:21just fantastic.
0:25:23And it doesn't apply to everything, but if you find yourself like frequently going through
0:25:28large arrays of numbers to do big batch operations on them, whether it's like, you know, multiplying
0:25:33them against each other or taking the absolute value of a big batch of numbers or doing any
0:25:38kind of like, you know, comparisons or merging or other like applying the same math operation
0:25:44to a big array of numbers.
0:25:46If you can find a way to either use the vector tools directly against your big batch of numbers
0:25:52or if you can find a way to restructure your need to use vector operations.
0:25:59So like even if you need to do a little bit of setup to like, okay, I was doing this big
0:26:03strip operation.
0:26:04If I can just put these numbers into an array of floats, then I can call this one function
0:26:09call on it that can do the entire job in way less time and therefore also using way less
0:26:15code.
0:26:17But like, you know, it's using vector units on the processor to also do it in way less
0:26:20time and that kind of thing.
0:26:23Like there a lot of times there's there's opportunity like that where like if you can
0:26:26just work your data a little bit to fit something that's a little bit different from what you
0:26:31were doing before, you can use a different kind of tool that might be orders of magnitude
0:26:36faster.
0:26:37And I always find there I'm so satisfied using vector stuff because you know, I do a lot
0:26:42of audio processing and a lot of you know, you know, processing of large amounts of numbers
0:26:46and the vector stuff makes it so easy and so fast.
0:26:50Yeah, I think too it's what you're describing there is something that I've run into many
0:26:53times where sometimes a simple data transformation can radically change your performance or change
0:27:00the way that you can structure an algorithm to reason about data.
0:27:04And like one that I find myself doing a lot is sometimes you take an array and turn it
0:27:08into a dictionary where you if you if you're doing any kind of operation that requires
0:27:14you to kind of keep referencing elements in the array, but you have to go and find them
0:27:21essentially to do that operation.
0:27:24Like the number I can like in most so many of my apps, there's always so there's something
0:27:27where I take an array, I turned it into a dictionary, and then I can go and then reason
0:27:32about it much more performantly later.
0:27:34And sometimes this even comes into cases where you're trying to do some kind of database
0:27:41query.
0:27:42This is something where this is just a little performance optimization, I suppose, but like,
0:27:45I'm going to, you know, I'm rather than making five or 10 or 20 select queries, you make
0:27:50one that is the union of those, and then put them in a dictionary and kind of you can look
0:27:55look them up later.
0:27:57I often find that's way, way faster.
0:27:58But I think the key thing that you're describing there is that sense that it's so it's so often
0:28:03if you can, there's if there's some data transform you can do with what you're out what you're
0:28:07working on, that's somehow radically changes it and looking for those and being aware that
0:28:12this is a possible solution that you don't have to, you don't have to keep data in the
0:28:16form that you get it in can often just be a powerful tool to find a kind of a quick
0:28:21or clever or you know, like foolishly simple algorithm for processing it.
0:28:26Oh, yeah.
0:28:27And by the way, don't forget about wonderful unused foundation classes set and ordered
0:28:32yet.
0:28:33And of course, they're mutable equivalents.
0:28:34Those are really helpful and things like that.
0:28:37But anyway, that's about all we have time for today.
0:28:39But I wish everyone the best with their algorithm finding and their the satisfaction and finding
0:28:44something really dumb that works.
0:28:46Yes.
0:28:47No, it is an absolutely delight.
0:28:48And I think it's one of the one of the funnest parts of computer science.
0:28:50And like, when it when you have those moments, like, relish them, enjoy them, because they
0:28:56don't come all that often.
0:28:57But you know, remember your what you learned in your first CS 101 class and it'll serve
0:29:01you well.
0:29:02Thanks for listening and we'll talk to you next week.
0:29:04- Bye.