Episode 0: Our Favorite Algorithms

If I'm going somewhere in those docs, I will stop what I'm doing to go and interact with the docs. When we talk about Transform Reduce, I'll be able to talk about how I match you. Oh, is this a PG-rated podcast? No, no, no, no, this is. We're allowed to say whatever we want. The most important thing, and you've got to leave this part in. The most important thing is that our podcast has to be better than JF and Chris' podcast. That'll be the opening clip. Have you listened to their podcast? No, I've not listened to their podcast. Welcome to episode zero of ABSB, the podcast recorded on November 14, 2020. My name is Connor, and with my co-host, Bryce, today we're going to be talking about what our favorite algorithm are. Hey, man. How's it going? It's pretty good. I just woke up, had myself a bagel that I napped in my couch for a half an hour. Was that on to talk to you? Was that intentional mentioning bagels in the first 30 seconds of our first inaugural episode of this podcast? I mean, it isn't mean with me, but yeah, but yeah, so what's this podcast about? It's going to be about algorithms, data structures, and anything and everything we want to talk about. So for those of you that don't know, this podcast is going to be modeled after one of my favorite podcasts called Magic Read Along, which is just two guys, you know, hopping on what sounds like a phone call, chatting about some things programming related, some things not, and hopefully it's entertaining for those that are listening. Yeah, it's funny. That term algorithms plus data structures equals programs. It was actually one of the first things that my mentor, Hartman Kaiser, told me about. And I don't think he ever mentioned the book to me, but he just said something to me in a moment of like programming is just algorithms plus data structures. And Hartman was this East German guy with this, he had a real character to him. So he just said it in such a way as if it was just this fundamental truth of the universe. And that's something I always wanted to talk to Hart. When did you learn that it was a book? So also for those that aren't aware, that what Bryce just said is the title of a Nicholas birth book that was published, I don't even know at year, probably in the 70s, which at some point both of us would read full disclosure. I don't think either of us have it ready yet. We just thought it was a great podcast name. Yeah, I think I first learned about it when you told me about it. And I think prior to that, my only exposure to that title was Hartman having mentioned it to me. And I think I had no idea that it was a book. I just thought it was a wise saying that he told me. Interesting. Yeah, that algorithms plus data structures equals programs. Yeah. So what are we going to be talking about today? We've got a question in a mind. What's that question? That question is what is your favorite algorithm? And I thought that the answer to this question was going to be really easy because I thought both of us were going to say the same algorithm, the algorithm in fact that brought us together, which is transform reduce or map reduce. And I should now I should give the story of how I met Kyle. So it was, God, what year was it? Was it 2018? Technically, the first time that we we talked was in 2018, yes. Was that when you gave the talk at the user group? The first time I spoke at the Bay Area C++ user group was in January of 2019. But I moved to the Silicon Valley in on August 5th of 2018. And then I believe it was like August 8th or 9th. I went to my first C++ Bay Area user group. And yeah, I don't going to say it was 2019 though, because that was when we really met. That was when we really got to know each other was when you gave that talk. So so for those who don't know, I live in the Bay Area and a few years ago I sort of became one of the main organizers of the Bay Area C++ user group although I've since stepped away from that role because I have no free time. But at the time I was still one of the main organizers and we're always looking for people from the community to give talks. And I don't remember if Connor approached me or I approached Connor. But Connor came to give this talk. And I still I still think it is the best talk that Connor's ever given. And he gave this talk about I think it was at the time it was still called algorithm intuition. And if you want to see a version of this talk, the best version I think would be to go watch the version at C++ now 2019, which one like best speaker and best talk and it won a bunch of awards. And essentially it's it's a talk about some of the C++ algorithms. I think primarily it's talk about a particular set of the C++ sequence algorithms that are near and dear to my heart, some of which are the known as the numeric algorithms. And during this talk, one of the things that Connor was particularly excited about and Connor is a very excited speaker. One of the things he was particularly excited about was Transform Reduce. Transform Reduce is an algorithm that if you're not a C++ person, you might know it better under the name of Map Reduce. So the idea is that it it's an algorithm where it takes an input sequence of items and then it takes two operations that it applies to them. One of those operations is a transformation which takes some function and applies it to each one of the elements and then the result of that transformation gets fed into a reduction operation. And a reduction operation is just an operation which takes two inputs and it produces a single output from it. So for example, plus is a reduction operation plus you take two inputs, you know, the two things that you're going to add together and it produces a single value as the output. And it's a very powerful, it's used a lot in data science. And so I had to say, you know, the thing about Connor's talk that really built our friendship was I just thought it was like the best talk ever and this was at a point in my career where the bar for a talk to impress me was really high. Like, you know, sometimes it talks and I just feel like, oh, this is good but not like great. But I'd come to have this intuition about like what was truly a great talk. And Connor was sitting there and giving this talk and I just thought, boy, this was great. And one of the reasons I thought it was great was he was talking about all the things that I would talk about when talking about these algorithms. And Connor didn't know it at the time, but I had been the person who had written the like specification in the language for a bunch of these algorithms. And Connor was talking about a bunch of the problems and the limitations with them. And I was like, oh my god, this dude gets it. And I was so excited. And he mentioned at some point in that talk that Transform Reduces his favorite algorithm. And I had given a talk a few years ago about how Transform Reduces my favorite algorithm because it's so powerful, so versatile. There's so much stuff that you can do about it. But I think that we determined that neither of us actually think Transform Reduces are favorite algorithms. That right? Well, I'm actually, I'm curious to hear what you're I know when we spoke about this topic a while back. That was your initial thought. And then I said, oh, well, at the time, inner product or Transform Reduces was my favorite algorithm. But I don't think it is anymore. And that's not because I don't love it. It's still, you know, it's amazing algorithm. It's still in my top, whatever N. But yeah, I think I have a new one now. And I guess maybe you have a new one too. So, yeah, well, no, no, no, you go first. You go first. I just said one short. I want to hear what you're your new favorite algorithm. Well, so first, I should say that even before, you know, so inner product for for those of you that, you know, are less familiar with C++ because I imagine we're going to have some non C++ developers listening in over time. Inner product is the C++ 11 name sort of the precursor. It's not identical because the constraints on the Transform Reduce, which is a parallel algorithm are slightly different. But I sort of first learned of Transform Reduce by the name inner product. And then I thought to myself, wow, this is a really bad name. And then like a couple weeks later, discovered the C++ 17 version was like, oh my gosh, this is way, way better name. And that's the case with most of the C++ 17 parallel algorithms. But before inner product, probably my favorite algorithm was stood partition, which I don't think I've ever said in a talk or anything. I just loved it because it was a linear runtime algorithm that had sort of the behavior of a sort. I think of partition as like a predicate sort. You pass a predicate and then you sort everything that adheres to it at the beginning and doesn't adhere to it at the end. But it's a linear runtime, which is super, super nice. So I went from partition to inner product to the renamed version Transform Reduce to then a new algorithm which exists. exists in very few languages called Outer Product. And in fact, the product, quote unquote, family of algorithms, I'm just a huge fan of. So in that family exists inner product, otherwise known as Transform Reduce, Cartesian product, which is sometimes just known as product in languages like Python and Ruby, and Outer Product. And I also wish that there was an algorithm that I have yet to discover called Triangle Product, which I mentioned in my CPP con 2020 talk, but we're not gonna talk about that here. So Outer Product, we're gonna talk about that. I wanna know what Triangle Product is. - Well, these things are supposed to be like 20 to 30 minutes. But yeah, so I'll explain Outer Product and then Triangle Product is just a slight variation of it. But so if you're familiar, so we've discussed inner product, aka Transform Reduce Cartesian product, for those of you that aren't familiar, is basically, in the simple case, you're taking two sequences or two ranges, but in the more complicated, you can take up to n. It's a variadic number of sequences. And basically, you create all possible combinations of each of the elements in that list. So if you have two lists, ABC, and then the second list is one, two, three, you create the pairs of elements, A1, A2, A3, B1, B2, B3, and C1, C2, C3. Pretty straight forward. So you end up with like, if you have two different length lists because they don't need to be the same length, you end up with n times n pairs or two pulls of elements if you have more than two lists. So a Cartesian product, if we think about it just in sort of the two list or sequence or range case, you can actually visualize that as a two-dimensional data structure, like a matrix. So in the case where I had ABC and one, two, three, instead of just a Cartesian product, gives you back all of the pairs in a single list, outer product gives you back a list of lists or a range of ranges. So you end up with basically a matrix that has each of these pairs, except instead of getting back pairs, similar to inner product or transform reduce, you specify a binary reduction operation that is applied to each of those pairs. So if you have an outer product, typically now the ABC, one, two, three case, doesn't make sense. If you have the numbers, one to five for each list, you can apply the multiplies binary operation and then your resulting table is a multiplication table. And this is extremely useful in the array oriented programming paradigm, which of course is where the first time on the ADSP, the podcast, I'll be mentioning APL. We can start potentially a drinking game for our listeners every time I mention APL, which is my favorite programming language, but outer product that exists in basically every array programming language, APL, J, Julia is probably the most popular array programming language that people have heard of. Haskell also has an outer product, but I think other than those, those are the only languages that I know that have outer product, but you can do very, very cool things. And just to add, if you have Cartesian product and you don't have outer product, you can do a Cartesian product and then call another algorithm called chunk, where you just pass the length of the first sequence and then chunk the resulting list from your Cartesian product to get basically the equivalent of an outer product. But that's my favorite algorithm. I absolutely love it. And maybe C++ 29 ranges will get it. We'll see. (laughs) What is your favorite algorithm now though, Bryce? - So my favorite algorithm, to understand it, my favorite algorithm actually tells the story of the start of my career. So it's actually like perfect for our first podcasts. And my favorite algorithm, I will say it's a specific implementation of the algorithm 'cause that leads into the story, which is boost algorithm split. And one of the reasons that this is my favorite is this was the first algorithm, the first time I was ever exposed to boost. So back in 2010, I was a fresh college dropout. Okay, technically speaking, I didn't drop out of college. Technically speaking, I flaunt out and they kicked me out for being correct about things. And it was 'cause I was bored in school. And I played a lot of text-based games called MUDs when I was a kid. And I started learning programming to create my own MUD engine. And I didn't know anything about programming before I started this. I was working with this guy who was a programmer. And we were doing it in C++, which was sort of novel 'cause a lot of MUDs were written in C. But he was like, yeah, I wish you had C++. It's more modern, it's better. And so I first got exposed to the standard library in this project. And then there was one place in this MUD engine where he was using boost. And it was, he was using boost algorithm split. And in what that split algorithm is, it's just a basic tokenization algorithm. So you give it an input sequence and then you give it a some set of tokens. And it takes the input sequence and it chops it up using those tokens. So like, you know, if you had an IP address and you wanted to split it out into the individual numerical components, your token would be a period. And then what, you know, if I had the IP address, one, two, seven, dot, o, dot, o, dot, one. And I fed it into this tokenization algorithm. It would give me back four components. The first component would be one, two, seven. Then second one would be zero. The third one would be zero. The last one would be one. And I don't remember exactly what we were using it for in this little mud engine. I think we were using it to perhaps we were using it to like separate out commands entered into the mud into their constituent components. But it's my first exposure to boost. And I seemed to recall, I found some sort of bug in the algorithm. And so I went to the boost people and I was like, hey, here's this bug, I had this fix for it. And then I very rapidly got completely sideline from my little game project into contributing to boost. And if I recall correctly, what happened was I was, my use case got more and more advanced and somebody was like, you should use boost spirit. And then I started talking with the boost spirit guys and I started contributing to boost spirit. And at the time, you know, one of the main contributors of boost spirit was one of its creators, Hartmet Kaiser. And so that's in a Hartmet and after some period of time, Hartmet and I got talking about why I basically approached them on IRC and was like, hey, I need a job because I was like an 18 year old college job. And he's like, why don't you buy a one way plane ticket to Louisiana, come down here and work for me. My parents, of course, absolutely loved this idea of me getting out of plane and going off to some stranger that they'd never met. My mother thought he was gonna be an ax murderer. And that was the start of my career. - Is your mom gonna listen to this podcast? - Oh, she'll probably listen to this podcast, yes. Yeah, but I think it's a very cool algorithm. And one of the reasons why it's very cool algorithm is it's a very common thing that comes up for a lot of programmers, even if you're not doing anything like that complex. I think tokenization is a fairly common thing to come up. I mean, even if you're just writing some command line scripts, it's a very common thing that you do where you're like, hey, I have this input sequence and I need to divide it up in some way. And it also, it sort of leads into some interesting discussions about efficiency. One of the reasons that we introduced string view into C++ 17 was to allow you to write an algorithm like this more efficiently. So let's go back to that example of parsing an IP address. Let's say that I've got a string that stores some IP address, a stud string specifically. And I want to split that stud string up into its constituent components. So a stud string is an owning string. It owns the memory for the string that it points to. So if my API for split is that it takes a stud string in and it returns a vector of stud strings, well boy, that is not efficient at all, is it? Because then what I'm doing is I'm taking this one initial input string and for each one of the constituent components, I have to make a copy of that piece of the string and stick it into the vector that I'm going to return. And so one of the canonical examples for why C++ 17 string view is useful is split. Because if I have a string view, what a string view is, is it's a non-owning view into some other string. So if I have one string that's my input string and I want to split it up into the constituent components, string view is perfect for this because the string view is non-owning, it can just refer to the piece of the string that it refers to. And the storage for that string is owned by the original input. And so instead of returning the string view, you can return a vector of string views or perhaps even something better than a vector. And it's actually even more interesting because, just coincidentally, this week, one of my other jobs is I'm the chair of the C++ Committee's library design group. And we got a paper this week talking about improving string splitting in C++. So C++20 introduced ranges, which is a more powerful idiom for composing algorithms than our previous idiom, which was iterator-based. And one of the things that's introduced in C++20 is a range of view called split view. But there's kind of a little bit of a problem with split view. And this paper tries to address it. The problem is split view in C++20. You give it some sequence, and it gives you back a sequence of sequences. The issue is what type of iterators that sequence of sequence gives you. So my understanding from the proposal is that today, the iterators that you get back from split view only provide the forward iterator guarantee. And this is problematic because almost all of the string APIs expect to contiguous iterator. So suppose that you're taking C++20 split. And you want to do something like parse an IP address. And then you want to call the C library function A2i or the more modern version from cars to convert each one of those IP constituent components to an actual integer type. But you can't do that because the iterators that split gives you are not the correct type of iterators to feed into from cars. And they're not the correct type of iterators to turn into A2i because A2i expects actual pointers. So there's this proposal. Oh God, I'm not going to remember the proposal number. I'm sure we can add a new-- We'll put it in the show notes. Yeah, we'll put it in the show notes. Superior string splitting is the name of the paper. Here, I'll see if I can find it. But this proposal essentially aims to fix this problem here. I got the paper number. It's P2210 by Barry Rebson. And that IP example was like the first example in the paper. So if you go in and look at that paper, you'll see immediately what I mean. And this proposal attempts to remedy that in C++ to make the split view a lot more useful when working with strings. And the other algorithm, which is I think sort of combined with this, is the algorithm for joining a set of string is with a delimiter. We've all probably written this at some point. You have a vector of strings and you want to insert a comma in between them. And I'm sure we've all written the naive form of this where he just got some for loop. And it just does like, you know, if I'm the first one, then don't insert it, et cetera. But you could probably tell me if there's like what the name of that algorithm is. I don't even actually know what the name of that algorithm is. And like, you know, all the cool kid algorithm languages. What's the variant that you just described? It's like where where it inserts a comma in between every every element. But like not, it doesn't insert one before the first element or after the last element. That depends on the language. But like typically that is called, it's doing the concatenation as well, right? Right, right. So typically that is like, there's several different names. But yeah, join concat or flatten typically don't take a delimiter. I know in Haskell there's an algorithm called interspers, which is the same thing as join. But like minus the concatenation. So like if you have a list of elements, it will just insert in between every element, the new element that you want there. But like doesn't join them. So you still end up with a list of elements. But I think typically what's it called? It's called interspers. Interspers. Yeah, there's there's two different inter algorithms. One is interspers and one is interleave and little C++ trivia fact. You've watched Eric Niebler, who is the author behind the Range V3 library, which was the work that was sort of done to show what C++ ranges could look like. In his calendar talk, I believe it was CPP gone 2015, but I plus or minus one. He shows an algorithm for transposing, which is just a composition of chunk and interleave. Interleave being where basically you have end different sequences. And then you take one element at a time from each one so that you reorder them that way. And then you go and take the second element from each algorithm, so on and so forth. But yeah, join I think is a classic name for it. Interestingly, the join that we got in range is C++20. Doesn't take a delimiter. So in the current C++23 proposal for sort of extending the range algorithms and adapters, I should say, and views we've had to propose join with because, unfortunately, the way we design join doesn't enable us to extend the interface such that it can take a delimiter. So we now need two different algorithms for that, which is this going to be another example that you're going to show in a talk where you're going to have a list of what every programming language calls it. And it's going to be the same for every programming language. And then you're going to have C++ and it's going to be different. And join is not as consistently named as some other ones. So like the classic example that Bryce Mayer may not be implicitly referring to is the fact that C++ calls what every language calls map stood transform because we accidentally already chose map for our ordered associative containers and ordered. And this is a real problem. Like people think that names might not matter. But I bet you, the first half of this talk, we talked about transform reduce. And I bet you that a lot of our audience would have not really known what transform reduce is. But if we said we did say map reduce, if you say map reduce, a lot more people know that because that's what it's called in every other language. And like it's not only that it's not only that transform is called map in every other language. It's that map reduces a specific paradigm. So our mistake of calling map transform within led to this other mistake of the common paradigm of map reduce not being called map reduce and C++. And the problem also exists in reverse. So I had heard of map reduce and the whole Hadoop at scale doing this kind of computation. And I think map reduce became very popular at Google for a while, or maybe still is. And I thought it was different than what transform reduce and never made the connection until I started learning functional programming. And so like yeah, it's both a problem for C++ developers relating things to, you know, in other languages or paradigms. And also for, you know, software developers coming to C++. But yeah, naming naming is hard. And that sort of gets to, you know, one of the reasons why I didn't explain really why I like transform reduce so much. But the reason is, you know, you're much more an algorithms guy than me. I'm more of a system software sort of guy, but really my expertise and specialty is in parallel programming and concurrent programming. And, you know, one of my jobs at Nvidia is I'm the team lead for thrust, which is our parallel algorithms library. Our implementation of C++ 17 parallel algorithms. And I think transform reduce is the most useful of the parallel algorithms. I'll maybe I'll temper that a little bit. Also the reduce is one of the most useful. And I say that because in our implementation, we implement many algorithms in terms of other algorithms. And the algorithm that the most number of algorithms are implemented in terms of is reduce and transform reduce. You know, there's things like the extreme of functions, you know, min element, max element, county, et cetera. All of those are implemented in terms of reductions in transform reduce in our parallel algorithms library. And in general, it's just a very useful parallel algorithm. Yeah, there was a talk given by, you know, moving outside the parallel world, talk that Ben Dean gave, I believe it was at 2016. CPP con called stood accumulate an algorithmic empire where he showed that of the 90 algorithms across a couple headers, 77 of them, with a little bit of sort of bending and twisting were implementable in terms of stood accumulate, which is what the C++ 11 standard calls basically stood reduced. Once again, slight differences on restrictions do the parallel nature of the reduced algorithm, but yeah, you start to see reductions everywhere. I remember when I listened to the first LambdaCast podcast where they were talking about sort of maps, reduces, and filters, and they were talking about how like there's catamorphic functions and anamorphic functions, catamorphic functions are the ones that do reductions. Anamorphic is exactly split, so it's when taking a list and you end up with a list of lists. So like chunk, split, group by, they're all versions of anamorphic ones, but like these categories are just everywhere, and that once you learn them, everything starts to look like a reduction. I think there's a paper called Beautiful Folds where they show that like basically everything is implementable in terms of a reduction. Yeah, I have this great diagram that I made that shows the dependencies between, you know, which algorithms are implemented in terms of other algorithms in our parallel algorithms layer. And I just shared it, I just shared it with you on my screen although it's not great for the podcast audience. I was going to say now we're now, you know, what this means. We're going to have to start screen capturing and putting these on YouTube as well because now our listeners are going to feel left out that we're staring at our screens and they're not. Plus, you need, you need, you need the pictures like the video evidence of how excitable we get. But yeah, it's really fascinating, some of the things that are implemented with reductions in thrust like, so find if is one whole family of algorithms that we implement in terms of reductions in parallel algorithms oftentimes short circling algorithms or algorithms where you can give up early. It doesn't make sense to do those in our implementation. Well, give up is a bit of a misnomer, like you've already found your results so you can stop iterating. Right, right. You can stop iterating, but in the case of like something that you're going to GPU accelerate, it's actually more expensive to make an algorithm that's going to stop, that's going to be efficient than an algorithm that's going to be fast. So yeah, so making an algorithm that's going to stop as soon as it finds the result is going to potentially be slower than an algorithm that just exhaustively searches the entire input sequence. So we implement find if in terms of reduce and then we implement find if not in terms of find if and interestingly we implement partition point in terms of find if not and we implement mismatch in terms of find if not. So essentially we implement mismatch and then equal in terms of reduce and mismatch is an interesting one because I know that's one of your, that's one that's an algorithm that's also near and dear to your hearts and maybe you can talk a little bit about mismatch. Well, so we're getting close to when we got to wrap this up, but definitely I'll say a little bit about mismatch, but first partition point I recently so in the follow up to the talk that Bryce mentioned at the beginning algorithm intuition was it another talk with a very similar title, but they're completely different talks, better algorithm intuition. I point out that there are five binary searches in the algorithm header. Most people are familiar with at least three and I would say at least one, the one is being binary search and then there's two other flavors lower bound and upper bound and then there's a fourth one called equal range which is basically a combination of lower bound and upper bound, but there's a fifth one that very few people have heard of or have heard of but don't realize that it's a binary search and that's partition point and this has come up recently twice in like code reviews of people asking, I need like a binary search, but that looks at two elements at a time so it takes a binary predicate and finds the place where the element on the left returns true and the element on the right returns false for like some unary predicate which you can then sort of fold into a binary predicate. I recently, the reason I'm going on this little tangent here is I recently discovered that we actually have a section in the C++ ISO standard for binary algorithms, binary search algorithms and partition point isn't in it. It's in the section next to partition because there's partition is partitioned and partition point so even in our standard we don't acknowledge that partition point is the fifth binary search algorithm, but anyways yes and mismatch is the generic version of adjacent find and adjacent find is the generic version of is sorted until and is sorted until can be used to program or to code is sorted. So that was like a relationship that I found and interestingly in the same talk that I just mentioned better algorithm intuition, I thought that this was amazing. I'm not sure actually Bryce if you recall we had none alcoholic beverages and what is that bar called Shannon's at the top of Nvidia and that was the time when I had made this discovery that adjacent find was implementable in terms of what I have then called the worst named or the most poorly named algorithm in the C++ algorithm header and I was scared to tell anybody because I wanted to be the first person in a talk to say oh my goodness look at what do you think and so I did this game where I said what is is sorted implementable in terms of and you said is sorted until and then I asked what's is sorted until implementable in terms of and then I think you got adjacent find and then I said and there's one more and you couldn't get it but no one got it and so then I told you stood mismatch and I was super excited. I asked Sean parent this and when I asked him what is is sorted until implementable in terms of he skipped over adjacent find and went straight to stood mismatch so in my talk I call it the Sean parent game because everyone should aspire to be as knowledgeable about your algorithms as he is because he just knew it off the back of his hand so one one one of these episodes we will talk about you and your fanboy love for Sean parent. That's that's fine we can do that I mean that's an appropriate topic everyone should be a bit fanboy of Sean parent I mean he he single-handedly can like him and Kate Gregory basically he started sort of the the road to my public speaking and then Kate Gregory I stole the title of my talk from from her CVP cast episode I think was 30 but yeah like when I when I see Sean's talks like they they are so inspiring and they just make they make me want to like inspire I hope that like someday I can inspire people like the way that like Sean inspired me yeah his C++ seasoning talk his generic programming talk when he talks about how reading Alexander Stepanov's code was just like mind blowing for him like that's that's just like so my favorite of his talks was I think his C++ match 2014 keynote where he talked about he talked about essentially porting porting some Adobe app to run on the iPad and talked about sort of the fundamentals of where you can get performance on modern processors and how you have to turn to parallelism and how you have to turn to accelerators to get performance and as somebody who's in that field I just thought it was it was just a super inspiring talk and I mean at the time I was really in the HPC world and Sean is Sean is not somebody who's an HPC programmer and I was really awestruck with how how many of the things that he was talking about like he was talking about getting performance on an iPad an iPad is not an HPC platform but the way in which he was talking about it was just as applicable to how you get performance on the world's largest super computers that I was just like wow this guy is this guy knows his stuff yep Sean is a Sean is an inspiration yeah and maybe with that maybe we should call it right there that's the final line of our our first episode is Sean is an inspiration and yeah I think with that we'll just say thanks to everyone that's listening and anything else you want to say Bryce no now I'm good if you if you have a favorite algorithm and you want to share it with us go follow us on Twitter at ADSP the podcast and let us know what's your favorite algorithm