 Hi everybody. Thanks Kevin. I'm Andrew. And this is my talk, Perspective in 3D. You guys must be really, really bored of financial stuff to show up at this talk. I appreciate it. A little bit about myself. Who am I? Like I said, I'm Andrew. I'm a contributor to Phinos' Perspective project. And I used to work at JPMorgan when we developed it as open source JPMorgan. And recently I've left and founded a company to attempt to commercialize technology called the Pro Perspective Company. Pause for applause? No. More importantly, 2021 Hogs for the Cause BBQ Grand Champion. Team Lardon Charge. Which, you know, has really nothing to do with this talk. Oh, how'd that get there? Weird. That's me. Grand champions. So let me ask a question. Most powerful programming language ever created. Just kidding. Got you. No. This, obviously. Everybody knows that, right? And this is something that's always really fascinating with me. Like, y'all are financial engineers, I'm assuming, or financial engineering related. Quick show of hands. How many people have worked on a project at a bank or a financial firm where the goal was to replace this with a web application? I was expecting more. But let's pretend like everybody raised their hands just to make my talk go later. How many of those products succeeded? Yeah. Okay. Why? It's because this is actually really complicated, right? It looks like a grid, and it is. But there's an enormous amount of complexity and power embedded in this application. And, you know, what, 30 plus years of engineering, hundreds or thousands of engineers have worked on this thing since when I was in high school or even earlier. Or like the original DNA of applications like this predates Excel by decades. And yet this application paradigm exists. And you know, I'm not decrying or in any way condemning like the pursuit of trying to replace these applications, but like we are in some sort of weird vicious cycle with financial application development where we hate this thing and we're constantly trying to place it, but we're also recoding it over and over again. And we're never actually kicking it off the desktop. And, you know, I don't particularly care about that from like a bank point of view necessarily, but as a programmer it really fascinates me. What is the appeal of this thing? What is that intrinsic power? Why does this really simple paradigm match up so well with computability and provide this really easy on-ramp for like non-technical people or non-programming people to really grasp and express computability like in a way that makes me as a programmer kind of plush? And I'll tell you, one of the most impressive, like when you see this and you see a grid in a financial application in a web page or something like that, that somebody kind of hand rolled, you know, you can look at the pixels and you can say there's numbers, there's colors, there's whatever, you can kind of get some sort of insight on what it does. But the thing that has always really struck me about Excel as a platform is stuff like this. So this is from a website called spreadsheetgaming.com. It is a 18-hole golf simulator with actual real-life courses. I believe they have three or four PGA tours also coded in there. And I'm sure this guy has been coding this. I'm assuming it's a guy. Sorry, I didn't mean to gender that comment. But I mean, this is just an enormous amount of work. And like for me as an engineer, when I see something like this, you know, like, I don't need to have a feature list in Excel to look at something like this and see where the boundaries are in terms of the power of the underlying programming paradigm. I know what I would do as an engineer if I wanted to code something like this, if I wanted to build an application with this amount of state, this amount of interactivity, this complexity of rendering. And without knowing anything about what Excel can do as a platform, I can look at this as an engineer and make a snap decision about what its boundaries are. Like it fills in my imagination immediately of knowing what the capabilities of the platform are. And that to me is like marketing magic. It's just this black magic trick where I didn't have to send a salesperson. I didn't have to write a prospectus. I didn't have to do a white paper or anything. This picture told me everything I needed to know about what the capabilities of the software were. And then I love this thing. I don't know if you've seen anything like this before, but this is an entire ray tracing engine written in Excel, which is just amazing. Now it's the performance is terrible, but that's not the point. The point is that such a complex model can be done in such a simplistic language that I don't expect people to understand the geometry of how something like this works necessarily for not familiar with mathematics, but just the fact that this is possible in this paradigm is just incredibly impressive to me. So when we wrote perspective for JPMorgan, our job was to make, I'm not going to go too much into why we bid it or what the background of it was, but the general point was to try to use bleeding edge technology to build desktop caliber user experiences in the browser, to take the technology that our firm at the time, JPMorgan, had been developing for decades to supercharge the physical machines that were sitting under Trader's desk and transition that whole business to the web and do so in a way where we could reuse a lot of the infrastructure and research and technology that I already put into this. And when I saw this, I knew exactly what I had to do for the next Fenos talk that I did in 2035, because we're not quite there yet. This is just like the first step in this is going to be 14 more talks over the next, you know, decade and a half. And then in 2035, we'll be playing a crisis on this machine embedded in perspective. So let me tell you a little bit about how this works. So Excel is like a lot of hand waving here. It's analogous to like assembly language. Those cells are basically memory cells. It's linear memory and you can make operations that cite various places the same way that like a pointer would work in a regular language and you could write expressions on them. It's really powerful. It is a complex computation model and it has performance implications. And in finance, we have certain shapes of data, highly structured data, highly tabular data and data that moves in real time. And when we open source perspective or we design perspective, the goal is to try to take that spreadsheet like interactive experience and that flexibility and power to kind of like start with your data and build out the kind of visualization you wanted on top of it without the integration of engineer. We were working under different constraints than a traditional spreadsheet. Specifically, perspective is a columnar data source. It's a lot more similar to something like access if you're familiar with it or traditional relational database. It has monotype columns. You can't put a string underneath a number. You can't really kind of put mixed data sets and build kind of, let me put it this way. You can't build golf in perspective yet. It is SQLite in some ways. It has a lot of kind of that same familiar relational algebra queries that you might be familiar with from SQL. And it's got some kind of OLEP like queries. It was never really designed to fit a specific paper in terms of like its implementation of a relational system. So it kind of picks and chooses little features from various types of database technologies in order to provide the user experience that we wanted. And specifically, it's specialized for real time or streaming data, which is something we had to deal with quite a lot. We really wanted this to be a platform that could scale with the kind of data sets that we had in our trading business, giant data sets that updated multiple times a second. And it's not that you can, as a trader, as a quant or something like that, consume that information to make decisions about it, but that you can issue queries against it and know that what you see as a result of these queries are up to the seconds when they're evaluated. After we open source, I think one of the really cool things about open sourcing is like once we've thrown the code over the wall and into the jungle, we didn't have the same kind of restrictions about how we could integrate and what other free stuff we could pull off the shelf and stick into our project. So when clients came to us with new needs and new ways that they wanted to extend it, it made it very natural for us to say, well, this stuff's already free, so what's the harm in just gluing it together with every other thing we can possibly find? We ended up kind of extending it with a bunch of things that we really couldn't have done internally, proprietary. For example, this language called Expert-TK, which is an Excel-like language written in C++ designed to be embedded in larger data computation systems to build Excel-like expression functionality into your platform. Guy who worked with my team at the time recommended it, or he knew the developer from a previous life, and we tried it out and it worked really, really well. It is, I refer to it as a stackless and heapless language in the sense that within the language itself, you can't define functions, there's no closures, you can't actually, like, inhabit a stack frame, you can't allocate anything on the heap, you can't do any sort of dynamic allocation whatsoever. When you write an Expert-TK expression, the size of the entire expression is compiled ahead of time, which is really great for a columnar engine, right, because we can take a really complicated expression, compile it ahead of time, know exactly how many bytes it's going to take to calculate each row, and then just blaze through the whole column without ever calling malloc, recalculating every row on the fly. And if, another quick show of hands, how many financial programmers, you see, man, how many other financial programmers in the room came from or once in a previous life wanted to be game programmers? Everybody, right? That was an obvious one, sorry, give me. There's actually a lot of parallels between, like, this and how a game engine works, or how GPU works. GPU is a parallel processor, right, with many, many cores that can do things in parallel, but it's not like, you know, the 12 cores, or whatever, four cores on this machine, it has a single instruction pointer and a lot of other constraints about how parallel those various cores can actually be. But it's really, really good for generating graphics if you're careful about how you program it. So, like, similar to a spreadsheet, this ray tracing is being done by calculating independently for every pixel in the image its color based on a math expression. So let me give you a quick demo just to show you what those things look like in perspective. So this is perspective. This is a really simple Tableau data set that we stole from their user forums. It's got about 10,000 rows on it, and it's just some data that kind of looks good in a pivot table. So there's a standard kind of stuff that you can do, you know, you can sort on columns, great, you can filter on columns. This is pretty standard SQL stuff. OK. But you can also do calculations that involve either expanding things horizontally or vertically. So for example, if I was to do a group by, take some value and group it, this went from 10,000 rows to 50, which means that each one of these physical rows in this query now represents multiple underlying rows in the original data set that I passed into the table. And there was some function that had to be applied in order to take the 42 rows in this table in Louisiana. And oh, what a coincidence. 42 rows in this Louisiana row, and come up with that number 42 and for all these other individual cells. It's a little more complicated than just being able to, so like right now, perspective does not allow you to customize operations in this direction vertically. The reason is because it's actually a lot more complicated than just writing an expression, because perspective supports kind of complicated multi-dimensional pivots, and is specifically designed to be real time. The internal functions that calculate these aggregations need to be able to incrementally update their leaves when the underlying data updates. So we haven't gotten to the point yet in the open source software where we have exposed the ability for you to customize these. We just have a bunch of hard-coded aggregates over here that allow you to choose basically how the aggregation works recursively at the multiple levels of roll up. But we also have an operation goes in the other direction that way. So Excel, you can go diagonal, you can go upways, sideways, left ways, around ways, all the other Willy Wonka stuff. But in a structured table like perspective, you can go up and down, you can go left and right. It's sort of, you can go kind of parallel to certain rows with some specialized operators, but I'm trying to simplify it. So let me give you an example. I'm just going to take two numeric columns, whatever, sales and profit done by. OK, these are two numeric columns. I'm going to click on button and make a new one. So I'm going to do that. I'm going to say, what did I say? Row ID. Pretty obvious what's going on here, right? Column A plus column B equals column C. Easy, right? And an interesting thing about this, if you remember from three minutes ago when I was talking about GPUs, these are all independently calculated. They're not done in parallel like they are in a GPU, but they're quite fast. And if you squint and ignore the parallelism part, it's operating a lot like a render. Now, sidebar. When we open source perspective, it was popular. A lot of people liked it. I think I fried a lot of value. But I think the best decision we ever made was when the bank came to us looking for an open source software project to kind of bring to market, I think they kind of looked at the engagement with the open source communities like we're going to take our dead code and we're going to throw it out in the community and hopefully somebody's going to pick it up and give us a bunch of free code back and we won't have to maintain it anymore. That's not how open source works. Open source is a plant or a pet. You've got to feed it. You've got to grow it. You've got to take care of it. You've got to maintain it. You've got to encourage it. It requires active work to own that thing. And we've been working on this for half a decade or more. And that was on top of the 10 plus years of development that happened privately before I was even involved in the project. When we open sourced it, it was popular. But what really happened over those intermediate five years was kind of working with the community, learning how they were using it, building new features on top of it, and engaging with the community to do that thing that I showed you earlier with the golf example, show people with their imaginations how they can use the technology to solve their problems without giving them a laundry list of features and a button that says contact or sales person so they can try to convince you to buy it. Over the years, the thing that I found absolutely by far the most effective thing in terms of like, and this doesn't just apply to open source because our open source strategy was also how we got the technology adopted within the bank and how we convinced traders and quants and analysts in a massively diverse organization to use our software to solve their problems in a way that I never had the access to do when I was developing proprietary software as a manager. The thing that really impacted that reach was the examples that we published. If you go to the, if you have ever been to the perspective website, not this one, that one. We have all these little examples down here and you know, JP Morgan does not endorse that you play Magic the Gathering. It does not care about NFTs whatsoever. It doesn't give a flying flip about all the bad things the NYPD has done over the years. None of this stuff has any relevance to banking. But all of these data examples are things that we did because we thought they were fun and because the data was free. And it was an ability for me to communicate to other bankers in an environment where, sorry, not other bankers, other financial programmers, that in an environment where I didn't have access to the kind of data that they were actually using on their desktop, what the power of the technology could do with data that was freely available that we could publish. There was actually an FTX example on here, but then they turned into a criminal enterprise and we took that down. Anyway, so this one specifically, the fractal example, is a really close analogy to what we're doing today. And actually, I should probably just show you this version because it's better. So this is a popular fractal, and I think you guys are probably familiar with called Mandelbrot Set. It looks like that. And okay, so what this is, is a, this is a expertise expression. And if you look at the actual underlying table, it looks like this. This is what the actual data is. It is 40,000 rows of the numbers, zero through 39,999. That's what the data is. You can see that if I refresh this to go back to the original setting. I have on the group by access the calculation, this one column index. I have this calculation index divided by 200. And on the y-axis, I have index mod 200, which is the, I'm basically just iterating through this linear data set, right? And just drawing things like a television one, left to right. In fact, if I go down here and I switch this column to plot index instead of color, you can see that, right? So this is the color range of values over here, right? And if I move the cursor over here, you can say that this is index one, and this is index 40,000, 39,999 behind me down here. And this guy is the Mandelbrot escape function. So that's a bug. Pay no attention to that. It is a really simple function that I stole from Wikipedia. Looks exactly like the Wikipedia version. I have no idea what this means. I haven't been to a math class in 25 years. All the mathematicians in the audience just told it, please. But basically what this is doing is it iterates, for every cell on the page, this is the complex plane, and it iterates through this escape function to see whether or not the function diverges. And you set up like, do it, I think this one's set to, how many iterations is set to? This is set to 100 iterations. So for every cell on this page is iterating 100 times and recalculating this convergence function and deciding how many iterations of that cell it takes to converge and plotting a color based on top of it. That sounds a lot like a GPU, right? So let's get back to the GPU part of this. Okay, so here's our task. This is what we're gonna be doing. This is a ray caster, a basic model of what a ray caster looks like, or it's a ray tracer. I'm not actually sure. Ray caster, ray tracer. Ray tracer, ray tracer, yes, perfect. Ray tracer, I was right the first time. So the way this works is there's a camera or a point in space where the camera is, and there's a plane, the image plane, and this is called the frustrum? Frustrum. Frustrum. Frustrum. And for every pixel on this, so this screen is my screen, right? This is where we're gonna render the image. And for every pixel that we wanna render, we're gonna calculate the color, independently from other pixels. And the way it works is we're gonna have a scene. The scene is gonna be some geometric objects that are defined in vectors, and we are going to iterate through all of them for every ray on the screen and calculate their intersections. We're then gonna sort them by depth, how far away they are from the camera, pick the closest one, and that's the color we're gonna plot on the screen. Sound simple? It was pretty simple, actually. Now this does like a lot more than what Perspective does, which is not super a lot. The, I also stole this algorithm from Wikipedia. So please don't ask me to totally explain it. And the key here is calculating the intersection between a vector and a triangle. So a really useful way to do that is this transformation, which allows you to map the coordinates of the vector points that define a triangle into very centric coordinates, which allows you to very cheaply determine whether or not a point or an intersection on the plane in which that triangle lies is within or outside of the triangle on various plane orientations. Specifically, it compounds those nine coordinates, those three vectors that determine the triangle in three dimensional space, into two coordinates, U and V. With the properties U and V must be greater than zero and U plus V is less than one. So you can calculate this intersection really easily by basically saying, given a origin point, it was gonna be our camera, a directional vector, the ray that we're casting into the pixel space and that, and the triangle we wanna intersect with, calculate its UV coordinates on the plane in which the triangle lies. And if those UV coordinates satisfy that equation, they're both greater than zero and added together a little less than one, then it intersects the triangle. And if not, it doesn't. And to show you what that looks like, I'm gonna do a little bit of live coding here because I think this is cool. Bear with me. Let's go up to here. We're gonna take all these guys and comment them out because I don't want you to see them yet. There we go. And I'm gonna go back over to this. How much time do I got? Five minutes, I can do this. Oops, that's too many. That was the big reveal, sorry. Okay, so this is a little tiny triangle. You can barely see it, it's real far away. But if I were to go down here in this code and replace all of this stuff with just, whoop, I screwed that up. Well, it's close though. So what you would have seen had I not screwed that up was you would see a nice little kind of rainbow color like this basically showing these values from zero to 30. How did that happen? Man, I really screwed this up. Nevermind, sorry guys. I really should have practiced this a little more, guys. Where did I turn that back to? That guy, that guy, that guy. Okay. Actually, you don't want to just undo this. Yeah, let's just skip that part. So. Anyway, so you saw this in the previous fractal example, right? We're just taking this one, the exact same data set that you saw in fractals, right? Zero to 39,000. And we're calculating the X and Y coordinates. And we're making up this value that is the, that's a typo, don't worry about that. We're picking a point that's gonna be the camera point exactly out of the Wikipedia article. We're then dropping in this giant vector, which is a little bit cheating, but this is a cube that I stole from Google. It's just the individual coordinates of the vector spaces that form up cube. 12 triangles, six faces on the cube, two triangles for face. And it's oriented around the origin 200 pixels per each side. That means that there are nine coordinates per face. So we're gonna iterate through that large vector in blocks of nine. We're gonna parse out the three individual vectors that form the corners of the triangle. And then we're gonna calculate those two coordinates by stealing the code directly from Wikipedia. This is literally like line for line exactly how the Wikipedia article about how the Thrunbor-Muller intersection algorithm is actually calculated. And you can see the exact parameter U that we talked about earlier and the exact parameter V that we talked about earlier that don't add up to one for some reason when I change the expression, but I'll figure that out later. And then we, once we found those coordinates and we validated that they were within the range, we assume and we know that we have an intersection. We calculate the depth by just taking the diff between the vector that points to the intersection point and the camera, calculating its magnitude. And as we're iterating through each of those triangles in the dataset, we just say is the depth that we calculate for this intersection closer to the camera than the previous one? And if it is, we set the color to be whatever that intersection is. And if not, we assume that it has been occluded by something else in the past or something else that we've already calculated. And what we end up with is something that looks like this. So this is a bunch of cubes. I just took that one really cube and just iterated it over a bunch of times at random. This is two and a half billion intersections being calculated in perspective. So it's the same, you know, 200 by 200 with the 12 triangles and 100 blocks. And it takes 15 or so seconds to render. Let's see if it makes me a liar. Come on, my man. I know you can do this. Yeah, there we go. Close. A lot of them are on this side of the camera because I'm bad at math. But yeah, look, this is not a talk for y'all to take this information home and build 3D charts for your financial clients, obviously. But I hope this gives you a little bit of an intuition about what the power of the underlying engine is and how you can use it to solve your own problems rather than having to go to an engineer to do those things. And I don't really have anything else. Any questions? Yeah, so I'll put the code on GitHub. Yeah, so ignore everything I just said. I'm gonna put the code on GitHub. Please download it and use it in financial applications to make financial visualizations for your companies. I'm sorry? How to do clients. Yeah, we're still working on the LOD parser, but you forgot this joke. So we're gonna start with doom and then we're going to crisis. 2035 is when you can expect that, although we're pretty good, so we might be able to do 2034. Yeah, thanks for coming to my talk.