speaker-0: Hey folks, what if I told you that one of the most interesting barriers to Bayesian adoption in real world is not mathematical, it is the file format. Today's guest, Andreas Munch, has a PhD from UBC where he worked under Frank Wood and published at NeurIPS on probabilistic programming and amortized inference. And then... He co-founded Evara, a startup bringing Bayesian inference to enterprise inside Excel. Yes, Excel. We get into inference compilation in this episode, what it actually is, how it relates to amortized inference, which you may have heard about already on this show, and how PyProb, a Python package to do exactly just that, open source, makes all of these practical. We talk about probabilistic surrogate networks. And then we make the leap to the harder question. How do you take all of that beautiful research and explain it to a CFO who just wants a number? That last part, communicating uncertainty in enterprise settings, is honestly where I think this episode really shines. I hope you enjoy it as much as I did recording it. This is Learn Invasion Statistics, episode 155, recorded March 19, 2026. Welcome to Learning Basion Statistics, a podcast about Basion inference, the methods, the projects, and the people who make it possible. I'm your host, Alex Andorra. You can follow me on Twitter at alex-underscore-andorra. like the country. For any info about the show, LearnBasedStats.com is Laplace to be. Show notes, becoming a corporate sponsor, unlocking Beijing Merch, supporting the show on Patreon, everything is in there. That's LearnBasedStats.com. If you're interested in one-on-one mentorship, online courses, or statistical consulting, feel free to reach out and book a call at topmate.io slash Alex underscore and Dora. See you around, folks, and best Beijing wishes to you all. Hello, Mediabasians! Just a small update about my agent skill project, because a few weeks ago, I published my first agent skill, which was the patient workflow skill, and which scored 100 % on every valve I designed. And then, the brilliant Maximilian Goebel actually used the skill on real model, and it broke. You may remember from Max's appearance on the show that we're working together on something that's called the soccer factor model. This time, in this situation, we're working on a hierarchical order logistic model predicting match outcomes across five European football leagues. And Max ran the same prompt through two agents, one with the skill, one without, and a third agent compared them blind. The good thing is that the skill nails the fundamentals like prior predictive checks. non-centered parameterization, strict R-horse threshold, and a properly identified model structure. But interestingly, the unskilled agent did a few things better, especially reaching for the regularized horse shoe prior for high dimensional features, while the scale I designed did not even mention sparsity priors. And that made me laugh quite a bit, because that meant that one afternoon of real-world testing by Max revealed more gaps than three rounds of synthetic benchmarking I had done. So what I did is shipping V1.1 of the skill within the week. Now we have new critical rules, sparsity priors, classification evaluation matrix, identifiability checks, lots of new stuff also coming from some advice from Osvaldo Martin, friend of the show. So the big lesson here is evals are necessary, but not sufficient. Most importantly, get your tools into real hands early. If you want the full analysis, you'll get the blog post in the show notes of this episode because yeah, now we have a blog section on the LearnBasedAds.com website, so feel free to check it out. And on that note, let's continue with today's show. Andreas Munch, welcome to Learning Bayesian Statistics.

speaker-1: Thank you very much Alex, it's a pleasure to be here.

speaker-0: Yeah, same. Thank you for taking the time. It's going to be an interesting episode talking everything uncertainty and you certainly have experience with uncertainty. So this is great. ⁓ Let's start as usual with your origin story. Can you tell us how you transitioned into the world of statistics and eventually found yourself at the intersection of probabilistic programming and deep learning, is something you're really passionate about.

speaker-1: I most certainly am. Yes. It's a, it's a funny story actually. ⁓ well, I don't know if all the people find it funny, but, I sort of did do looking back at it. So I've always liked mathematics, physics growing up and they're going through high school. It's been, been the things that I enjoyed the most, the kind of logic possible puzzles and problem solving. I'm sure a lot of us sort of start off like that when you get into Bayes inference ultimately, but, ⁓ After I did a six month trip around the world right after high school, which is pretty normal in Denmark where I'm from, I got this weird idea that I was going to do business and I actually even applied for that for college. And I failed to recognize a certain requirement, which was there's a certain level of sort of English you need to have and all the sort of other subjects that are just prerequisite requirements. And I didn't have it at the right level and I didn't see that I applied for the one thing until I didn't get in. So I had to find some of the free spots, which obviously it was a pure spur of, of like almost high press at the time. But I ended up going into engineering because that was one of the few places that had any, any spots left. And it was earth and space, physics and engineering. was the program. So we still not quite a patient yet, but. My plan was to do that for a year and then switch back and upgrade my, my English level. But I ended up not surprising you maybe to just really enjoy that, that particular, that program. And so I stayed and stuck with it for the, ⁓ for the entirety of my, of my bachelor's. So it was sort of a weird segue into getting back into physics and engineering. And so Denmark doesn't have, you know, the Big is space programs, so we corroborate and collaborate with of course the ASAP program and NASA as well, I think for some programs. But mostly what we did was looking at satellite images of Greenland and sort of other analysis in that way. so doing that, I got into more programming because that was part of a lot of the analysis that we had to do. And I wanted to get more into that for my masters. And instead of starting over from computer science, I switched over to the sort of machine learning mathematical modeling program that we also had. And so that was my weird segue into it. It was also, I could do more programming without starting all over again. And it was in that program that we had this course, um, Bayesian, Bayesian analysis. And I had no idea what this was at the time, but it was much more theoretical than the sort of hardcore deep learning, sort of build some new networks and you should train it. I wanted to do sort of. more core statistics, which was crazy. I don't know why I thought I wanted to do that at the time, but that's what I wanted to do. And it was taught by Ula Vinta and Archie Vitari. I believe you've been chatting with him as well. He was visiting for six months. So he taught that whole course and we went through the the Bayesian analysis, data analysis book, which of course, probably a lot of us know it's a brilliant, brilliant book. we did all the... Stan programming and that's how I got into introduced to probabilistic programming. And I just fell in love with it. I thought it was incredible that you could sort of embed uncertainties and statistics into the languages themselves and then just run them and you do inference. It was the decoupling of what it's like to do the modeling and have inference sort of be separate. I thought was incredibly powerful and incredibly fun. to play around with. And so I decided I wanted to do research within this area. And that's basically how it all began. And so after my masters, I applied to various different schools and I got to in touch with Frank Wood, who was at Oxford at the time, who was moving to UBC in Vancouver, Canada, and setting up a totally new lab. And so I ended up joining him as he's, that was back in 2018, I think. That's a few years ago now, to do probabilistic programming. they had just, I think the year before, written a paper on inference compilation, which is amortized inference where you combine probabilistic programming and inference with new networks. And sort of that's how it all started.

speaker-0: Wow, okay, so you're one of the first students from Akivetary, if I understood correctly. Damn, this is pretty cool, pretty cool. Hello!

speaker-1: I really, really enjoy that course. was, ⁓ it was the beginning. it was, ⁓ yeah. And they did a wonderful job teaching. was so much fun.

speaker-0: Yeah. And I can definitely see also like the influence of entrepreneurial studies in your, in your background. And we'll get that later, but you've actually founded at least one company. like this is, yeah, this is not surprising to me. And also what you're trying to do with Evara is actually related to something you noted already in much of your work, which is a lack of real world based implications, despite it's universal applicability. And of course, it's something I resonate a lot with because this whole show is about making vision statistics more applicable, more widespread and just showing people it's not that hard. ⁓ And it's actually easier than the stats you're used to. It's just these stats you're used to seem easier just because they are more familiar, but not because they are intrinsically easier. ⁓ So in your experience, What are the biggest adoption barriers for people outside of academia?

speaker-1: Yeah, it's good question. And I want us to touch, you know, based on what you mentioned, which is, indeed going through my studies and trying to find, you know, applications of Bayes Infants. I think that's really sort of maybe a good starting point, which is of course something you do in academia all the time. You develop all your methods, your theories, et cetera. You've got to showcases and sort of benchmark it, et cetera. And I remember how peculiarly difficult it was. and sort of still is to come up with the sort of example use cases. And I think it's, for me at least, it seems harder to do in the Bayesian context than let's say the more of the frequencies context because of the model components. I think that's precisely part of the point and it's going to tie back into this adoption barrier, I think, in a bit. And indeed, as I've, after I graduated going into the entrepreneurial space was to... similar to, think a lot of us is that it's surprising that it's not more proliferate out there. It's incredibly powerful. And I think there are many, many instances where Bayesian inference is that it's a brilliant tool and a framework to use to solve lots of different problems. And I think we do it all the time, subconsciously as humans. I mean, it ties back into the, you know, the belief updates of what we expect and you get up like observations and you have to update your priors, which are your beliefs. And most of us probably don't think about it, but Most people don't formalize it, obviously, and you don't write these things down and there's no label for it really. But I think it ties into that particular problem, which is it is a different approach to the sort of statistical thinking. And so if you are a statistician, you're sort of already primed to think in this way and you question sort of everything and you're uncertain about everything. It's almost like your world now, you doubt everything in your life, which is sort of almost ironic. But you're also driven to, I think, look at the problem from different angles. But if you look out into most everyday life, you don't think about the sort of differences between the frequentist maybe way of thinking about a particular problem and then the Bayesian approach. There's no label for it and you don't formalize it. There's also no tools for it. That's the other thing. Right. And we all know statistics is hard. It's like the one thing everyone talks about in terms of, I mean, ask anyone who doesn't do statistics regularly. Even people that do statistics, it's just the masses, it gets to be crazy. Right. So, I mean, people are like scared of it almost, which is quite I think understandable. But when you bring Bayesian into it, it's like no one thinks about it. And now they have to change how we think about these different problems in a way that is almost counterintuitive, even though, like you said, it's intrinsically not necessarily harder, but it's a different way of thinking about the world and your problems, which I think most people just don't do. And it's very hard. Even I've tried this to talk to people who are, you know, scientists maybe in different fields who do statistics. And it can seem like the difference between Bayesian and frequentist methods is almost, it's subtle. Well, it isn't obviously, but... I think it can seem subtle because this prior that we have to define and think about with the model, it's still something we need to come up with ourselves. And so how is that really much different from maybe it's like a statistical test? And for someone who knows about it, it seems obvious. Of course it is. But it's not clear that I think it can seem like a detail. almost because it's not clear how much of a massive difference it does in terms of the yonder line theory and how you sort of deal with it and how it's not a, it's not a statistical test. In fact, it's quite the opposite. It's about specifying those prior beliefs rather than testing out a hypothesis. But there's overlaps and that's where I think it can get real difficult to sort of really find and grasp the nuances. Unless, you know, like you do and probably many of the listeners, you think about these things. all the time for years and you get bogged down on those details. So think that's part of that adoption barrier. It's just not, think statistics generally in many cases where you should use it, it's not used already. And everyone talks the frequentist, I think a lot of the times. So how do you then introduce this Bayesian method, which can, I think it's just difficult to sort of wrap your head around.

speaker-0: Okay. Yeah. Yeah. Yeah. I can get what you're getting at here for sure. ⁓ I think the educational work that you and I are doing in the whole community I'm interviewing here is extremely important precisely for that reason. ⁓ And actually a major theme in your work is bridging the gap between deep learning and probabilistic programming. I think it's extremely important because here we're talking more about technical people than beginners. course, like if you're familiar with deep learning methods, by definition, you're a fairly technical person. But I think it's also important to address these two audiences. the more beginners that you mentioned that that show is also about, and also the more technical audience, which is also part of my audience. And first. Yeah, I tried to do that too in my own work bridging that gap between deep learning and probabilistic programming because I think there is a huge potential here for great models. But I'm curious in your case, why do you see this synergy as so important and what does deep learning provide that traditional probabilistic programming engines lack?

speaker-1: So I think it's a good question also. And I guess one of the core themes that, you know, always comes back also as almost like a counter argument to Bayesian inference is the computational requirements and then how fast does your inference engines and algorithms converge in the backend. And I think you've talked about this multiple times already as well on your podcast, Alex. And it's, I think there's many cases where you can speed up the inference task, potentially that's important thing to bear in mind, right? With using and leveraging neural networks. And I think one of the difficult things to consider is whether you're doing a one-off, let's say, inference problem where you have one observation. like set up observations and you have to do this in one go, but you don't want to necessarily redo the inference task for different sorts of observations. Then it's harder to imagine maybe in those cases where new networks can come into play in the way that's certainly original that I've been working within. But if let's say you wanted to do the sort of in the same model, do inference with many different kinds of observations, then you can think about these amortized inference methods where there's probably going to be certain, you know, underlying patterns in those posteriors. You could at least envision that. Where you can maybe train a new network to, for instance, be the proposal distribution for those proposal distribution based algorithms. And so you can imagine if you can build your model, can, for instance, you know, you could produce samples over a wide range of your priors. And now you can produce in your model all of your observations, right, from the likelihoods that you've also defined. And so you can use those sort of methods to train the neural networks to infer the posterior distribution across all of these different observations. And so now the underlying assumption is that you have a really good proposal distribution, for instance, for important sampling. not to say that you should just use important sampling, but that's a straightforward way that you can use these. and proposed distributions. So I think that's a very, very interesting, avenue. that's one of the things that I've been working on exactly. And I think one of the more interesting things that I've, that I started thinking about before I graduated is maybe similar to all these like LLMs, maybe you can amortize not just for a single, you know, inference problem, but maybe you can do it across different tasks as well. If you make these things big enough and you might be able to start sharing them across. you know, different industries and different inference problems, et cetera. So that it's not sort of, you don't, aren't limited to just using them whenever you do multiple inferences, but you can actually use them for different types of inference tasks. think that would be really interesting.

speaker-0: Yeah. Yeah. And I like how, like how you've set us up here is actually very reminiscent of a multi-spatial inference that we've talked about already on the show. That's something you work a lot on. And so I'll, I'll put these, episode, episode 107 and 151 in particular with, uh, Marvin Schmidt and, uh, Jonas Arruda, who are both working, both working on the base flow side. So if you guys, ⁓ mean, if you folks, you all listeners ⁓ want to have references about Amortized Patient in France, episode 107 with Marvin, and if you want to actually see live how to use diffusion models in Python with a live demo, episode 151 with Jonas is going to be extremely helpful to you. Here, we are going to talk about that with you too, Andreas, because you, well, You work a lot on that. ⁓ You've had a lot of work on that, especially your, I think your most cited paper is on what you call inference compilation, which is, looks a lot like amortized patient inference. So let's explain that like in simple terms, how, what is inference compilation? Is there any difference with amortized patient inference and how do we use? neural networks, which are a deep learning method, to amortize the cost of inference so that it becomes faster over time for our probabilistic models.

speaker-1: So I did just clarify, it's not, I didn't write the paper on the inference compilation. was sort of subsequent work. think the year before it was one of some of Frank's other students, Twannan ⁓ and others that actually wrote that paper. So the paper you're referring to is, that's just two, but it was part of this Italumus project, which is the inference problem there is the particle decays, inferences. given the sort of signals exactly. And there was a big simulator, but that was sort of a follow-up or extension of the work that was inference compilation. And just briefly for context, because I think, you know, one of the languages, programming, probably the programming languages that I've been working in is PyProp. It's a language that sort of was ⁓ created out of the inference compilation ⁓ theory ⁓ to sort of really be targeted to do inference compilation. So that is precisely the... The reason you say, I think you mentioned that it's similar to the amortized inference is because, that's exactly what it is. You're training neural networks to do amortized inference. And the neat thing about probabilistic programming, as you probably also talked about, is that you get these graphical models. And so you can sort of define the entire space of which you would have to sort of construct these neural networks, regardless of the inference. problem that you're looking at and you can sort of construct these similarly to how you can do, deploy the infant algorithms. You now also have this automated way of constructing and training the, amortizing for new networks that you can use, for example, with, ⁓ with the important sampling as I said, backend engine or others for that matter, of course, wherever it makes sense. So that's exactly what, what the, what that is all about. ⁓ one of the interesting aspects there though, when you think about probabilistic programming is that, ⁓ I don't know if you probably have talked about this also, but when you consider the difference between the low and high order probabilistic programming programs and languages and what they support, some of them are unbounded, right? So you don't know, you can't just compile the whole program sort of at a sort of compile time into the static graphical model. You have to do dynamically, you know, complete programs, during complete languages, you can't even guarantee that they will halt. And so part of the inference compilation aspect is how do you do this dynamically as you're just generating, right? You have to come up with a mechanism where these new networks can grow dynamically as you also generate samples over time. ⁓ Because you don't need to just generate a million, but if you want tomorrow to generate 10 million, like you don't want to start over necessarily. So that's a core part of that work is how do you construct and train your networks on the fly while making sure that you can maintain the conditional dependencies between all of your random variables without losing those dependencies. You can't constrain the neural network to sort of lose the dependencies because they can be arbitrary. The one millionth variable could depend on the number one, that's the inner radius. And that's part of that work. sort of some of the, I think the first paper wrote was about using attention mechanisms rather than the LSTM based mechanisms that was used in the original work. Because of the potential long-term dependencies and maybe you're forgetting ⁓ the sort of, especially if we have one to the million, are you actually able to remember that well throughout the LSTM? So that was some of that first work that I did.

speaker-0: Yeah, which is really fascinating. And so is this from this project that you started working on, on PyProp, which is an open source package that I put in the show notes. And I think that's how these work came to be. And I think this is a very interesting package. So I'd like just to ⁓ talk about that a bit right now, because... I already have a lot of questions about these papers, you know, and why you made some choices and not others. But I think it's going to be more concrete if we talk ⁓ through it with PyProb because it's actually, it's actual code that people can use in their own workflow. So for those who are not familiar with PyProb, what is the big picture goal of it?

speaker-1: So the big picture is to do amortized inference with inference compilation. That is the main and the core purpose of it. It's designed around how to construct these new networks. That is actually the long and short of that. So if someone wants to sort of explore how you can train the new network in a way that it's sort of embedded into the probabilistic programming language itself, Piperup is a great place to start with that. Now it's obviously maintained by the lab and I didn't, wasn't the original author that was Ganesh and Biden who was the main, you know, first author also of the paper you mentioned that I've been working on afterwards. What we call the Italumni's paper, but that's actually another paper, but it's the, two papers, there's two papers that came out of that same project. One was about how to scale these, like, pipe prop up into sort of multi-core, multi-CPU, multi-DPU, distributed compute, et cetera. Which was a whole, whole big effort on its own as well. But, ⁓ but that, think it's still maintained by, by the PlayLab out of UBC. yeah, I think if you have the link there, you can easily go there and you're always welcome to reach out to me as well. It's, I am intimately familiar with the language. I'm not so involved with it anymore, mind you, ⁓ I should say, but it's, it's very much still there.

speaker-0: Yeah. And so yeah, what can you give us the elevator pitch for it? When would it be useful? ⁓ When do you recommend using it? When not use it? And what are its current limits so that listeners can get a lay of the land?

speaker-1: mean, if you wanted to amortize base-in-influence in programs, especially where, well, even if you can map out the entire graphical model, it's a great language for that to play around with how to train your networks. And especially if you want to play around with how can you come up with different architectures or different designs for constructing these new networks. As it's open source, it's a great place to get started. I think that's the, mean, again, that it is the, the, the core mode. There's also the PPX plugin, I think where you can, I didn't play around with that too much, but I believe you can even plug it into, I won't say all, but many other languages as well. So there is a bridge essentially between, so it is written in Python. So that's the other, guess, neat thing. If you like Python, it's already in Python. that's nice. And uses PyTorch as well. I'm sure a lot of listeners out there probably use PyTorch. So if that's what you find interesting and want to play around with, think it's a great language and I quite enjoyed playing around with it. And I don't know if they've been pulled it in yet, but there's also automated surrogate modeling, is another use of neural networks. So it's not amortized in threads, but if you have programs... where certain bits of computation in the, let's say the simulator is very computationally expensive. You might want to train a surrogate neural network to speed up that computation if you're okay with the trade off of the approximations, of course, with the outputs. And so that was a follow-up work that I did afterwards where a similarity to doing automated inference, you can also do automated surrogate modeling for the entire program. That's also part of the, I don't remember which of it was in the four or something, but it should be there somewhere.

speaker-0: Yeah, and I'm actually curious, know, in your experience, how, yeah, which kind of models do you recommend, do you recommend using for, with, with amortized inference? You know, which, which kind of situations and models are most appropriate for these kinds of methods in your experience?

speaker-1: Yeah, I think that ties back to what we talked about earlier, which is the repeated inference tasks. Right. So one of the examples that I've been, I worked on myself is the appearing of composite materials. So one of the things that you usually do when you are trying to figure out how to construct the plane, part of that is to ensure that you can simulate what it's like to create these, materials that it makes the the wing, for instance, you want to make sure that it's produced and it's created properly. And so you can simulate, you know, the thermodynamic mechanisms as you basically, if you put it in a big oven, that's what you do with these composite materials. And one of the things you might want to make sure of is that the internal temperature reaches the right, how should I say that? It can't be too hot or it can't be too cold. There's a pretty sort of narrow window. of the internal temperatures so that it's constructed properly. Now you could of course drill into it while it's inside the oven, but then you might break the materials. So the idea is, can you infer the internal temperatures by just observing the surface temperature, for example? ⁓ And you can use a simulator for that. So if you simulate the process properly, you still end up with a latent inference problem because you don't observe directly the actual temperatures internally. But you can infer them. And so that was the first, one of those first ⁓ sort of examples that I used. And here it's an obvious sort of maybe use case where every time you need to do another measurement with players, a different plane wing or something like that. Well, that's a different, that's a new inference problem. But the simulator you're doing inference in is the same. So it's the same model. So here is a perfect example of where you can train these neural networks so can reuse them over and over and over again. and speed up the inference task by orders of magnitude.

speaker-0: Well, yeah. Yeah. Okay. So that definitely pairs with what Marvin and Jonas told us, which is basically if you have ideally big data and fixed model in a way, so something like a physics model or something like that, a model that doesn't change a lot, but you do have data and the changes a lot because you have a lot of it, then a multi-spatial inference is going to be one of your best bet.

speaker-1: I should actually emphasize, you need real data even. is what's so amazing about simulators. You generate it. Right. You just run the simulator because if the simulator is good, which, know, in this case, it's a highly, you know, high fidelity physics simulator, it's using the right differential equations, et cetera. So you just run, you can just keep running the simulators and it generates all of the possible outputs that you might want to condition on. And so. You can construct your own data set, which is the amazing part.

speaker-0: Yeah. Yeah. Yeah. This is, that's always, that's always really amazing. think for most people using the Bayesian framework, this won't be something really different from what they're used to. You know, prior, prior predictive samples, posterior predictive samples, they're always in the framework already, even if you don't use amortized inference. But if you come from a frequency's framework, this will definitely be something that, that's going to be quite weird and very empowering, I think, because it's much more intuitive when you think about your models that way. And I think it's also very useful to, you know, select features, for instance, when you're working on a model, because then one of the bars that each feature has to pass is, well, does that feature has actually a clear generative story in your model? You know, like does it explain something about the outcome that other features don't yet? And that's a good bar to try and pass because if it doesn't then why is it your model? Probably it's creating problems more than solving things. So it's a good, more intuitive way of thinking about feature selection and just thinking about it from a statistical perspective. know, it's like, if it's passing that threshold, then it's in there. Okay. Why? that's harder to explain to a business stakeholder.

speaker-1: Definitely. Which is why I like, I always thought liked Bayesian Infant for that reason, it sort of forces you to think about those sort of things, right? You're building the model. you have to be quite, it's almost baked into the process that you need to think about these sort of things.

speaker-0: Mm-hmm. Yeah, no exactly. And so maybe to close up on PyProb, how can interested listeners get started with PyProb?

speaker-1: Go to the website. That's the, basically the best starting point. I guess you can always reach out, you can reach out to the current maintainers. don't know, it's a while ago, I looked at it last time. So I guess you have to just double check that the, what the, what the contacts are. But that will be the best way to do it is to go there and look at some of the examples. There are examples in inside the repository as well for how to build models. That's the, that's the, that's the easiest. It's the real problem is of course, and that's, guess you asked about the constraint earlier. It is the PlayLab that maintains it. So it's not as a, as big repository with the, such a big community as well. So when you use it, it's similar. gotta, you have to appreciate that it's not like there's a million people that keep sort of updating it all the time. And so that's the, that's, that's, that's the only caveat. ⁓ yeah, but otherwise that's the, that's the way to do it.

speaker-0: Yeah. Yeah. Yeah. ⁓ yeah. And I can confirm that there is, there is quite enough resources on PyPro on the website to, ⁓ to get started with that. So I think it's a, good starting point. And now listeners, you know, more or less the use case where it's going to be helpful. if it's one of yours right now, definitely check that out. and actually you mentioned that already Andreas, ⁓ but you, you've also worked on probabilistic surrogate networks for simulators with something that's called unbounded randomness. didn't know about that. ⁓ yeah, can you explain that? are these? How do these surrogates manage to stay fast while retaining the interpretable structure of the original simulator?

speaker-1: Yeah, that's a, that's a good question. It's also the main, that was the main difficulty of the work. So it was inspired by the way of that same curing problem because that simulator is quite expensive to run. And so it was actually, and it was also from even the interlumous project as well. It's the same problem. You've got some big simulations with some big computational blocks in there and You just don't always know exactly where they are. And if you've got millions of lines of code, how do you sort of extract out the exact pieces that you want to surrogate over? It can be a huge endeavor. And so the first pass is of course, can we just build a surrogate model for the entire program? Right. That certainly covers those cases. And the... problem there you immediately run into, hence why unbound or randomness is because, if you're in a probabilistic programming setting and it's true and complete, well, you don't know when the program halts or if it halts or how many latent variables are being produced. And you don't know the order of the latent variables. And essentially, if you think about it, it's like you have to infer the branching structure as well. If you've got if-stigma, while-loops, et cetera, when do you exit the loops, cetera, and so on and so forth. And that was the real... sort of underlying sort of theoretical part of the work, both technically, but also a little bit from the theoretical side. So that work primarily was a matter of how do you construct these sort of neural networks that can similar to the inference network grow. But the difference here is that, and I don't know how much you've talked about this before on the podcast, but one of the ways that you reason about the, you know, the sort of stochastic structure of your programs is we need to be able to identify all your random variables for one. And so you use these adversities, which are these unique identifiers that you construct. If it's dynamic, you construct them dynamically. For instance, this is the way you can do it. If it's a bounded program, you can again compile it. And so it becomes a little bit easier. You can sort of have a little bit more control, I suppose, depending on how you decide to do it. But in this case, when you do it dynamically, You can't guarantee either that this is the same order every time. And in the inference compilation case, it's much easier because, well, you infer given the variables that you produce during your trace and the program itself still runs concurrently with the inference program. So again, if you think, let's say, ⁓ let's just use report and sampling as the example, right? So because you need to calculate, you know, the joint probability at the top. to calculate the weight for the inference algorithm and divide by the proposed distributions, PDF that you place on the samples that you have proposed. Well, to calculate the joint distribution of the program, you actually need to run the program. So we can imagine if you start the program execution from the beginning, whenever you hit a random statement, like a sample statement, instead of sampling from the prior This is called the prior, because it's obviously not always in the prior sense, because they're all conditionals, right? But whenever you hit such a point, you will then instead of sampling from those conditional priors, let's call them, you instead query this, the proposal distribution, right? So the neural networks that you've trained. But then you can continue executing in the original program. And so every step of the way, you can compute the joint probability. and divide by the proposal probability as well and construct this dynamic. You can sort of, maybe you can imagine this is hard to visualize maybe, but that's, that's the way you do it. The surrogate problem is different because there is usually replacing the program. So, so you can't use the program to sort of guide the, the, the structure and produce the variables that would sort of follow from a given sample. So that is the main problem that we have to figure out how to solve. And well, it's not maybe too surprising the sort of way to maybe do it, a way to do it is to do a classifier. So you can imagine given in an address and everything that came before it, because you need to consider that, let's say a branching structure, an if-else statement could be some arbitrary computation of all of the previous sample values, whether explicitly or implicitly. And so the neural network needs to... come like try to predict which of these branches, let's say the FL statements that you need to then like enter in quotation marks, of course. Now there is no FL statement in the way that certainly we did it, but you're mimicking it by then predicting those addresses that might come from either of those two branches. Of course, the immediate criticism would be, it's the program is deterministic in terms of choosing the branch, but the philosophy, I suppose, that you would have to accept is because you don't observe everything and you don't know all of the, you haven't mapped out all of the cases in your program and know from the sort of enumeration, all the values, which you can't do because if you sample from a Gaussian, it's continuous. So you can't figure out exactly the cutoff point by just testing it. So maybe a stochastic approach to predicting these practices is not unreasonable. And that's how we did it. Now the real... The is also you don't know necessarily how many branches you might insert. You can imagine a while loop where the value determines when you exit. So you could sample initially, let's say, from a Poisson distribution and then given the value that determines the number of iterations of the while loop when you break it out again. And so you need to come up with a way where, let's say, a previous random sample put produce an unbounded set of transitions to other random variables. And we don't know about this number beforehand. So it really was a matter of how do you sort of expand the space of classifiers, values that you don't know beforehand. And so one of the things we did is we thought about, although it's not, you know, maybe measure theoretically equivalent, because it isn't, but You can imagine that you have a classifier that predicts the transition to known transition up to any given point in time during training. And then you always have a holdout probability mass on other yet unseen transitions. But it's like the collection of all of those that you may or may not have seen yet. And every time you see a new, let's say transition, that would be like a new class, like a new type of image, for example, if you think images. would break off almost like a stick breaking process, some of that holdout probability mass and begin training on those transitions as you see them. And it's sort of probability measure preserving at the time of splitting, but it's not quite the same as if you had known the transition existed beforehand and trained from the beginning. So it's not entirely unbiased in that sense, but it otherwise is quite neat and it works quite well actually.

speaker-0: Yeah, this is super interesting. I don't think we covered that least that deeply yet on the show. So thanks a lot for these details. think it's... Yeah, this, of course, is not something that you're going to apply all the time, but it can really serve you when you're in the cases where it's actually most needed. So actually, you mind? Anomalizing and summarizing these cases where you think these kind of methods are going to be most helpful too for people.

speaker-1: Yes. The answer is I'm not entirely sure. I mean, at this point, it became a theoretical science, know, we needed it for a simulator. And so we developed it. And of course it's a form of programming. So we have to be general and agnostic in how we construct these methods. We had the use case originally, but I mean, to be honest, it's not, I think there's many cases where you would need to do it, especially again, if you need to surrogate over programs where you don't know the execution paths. But maybe you want to actually split out, instead of thinking about it probabilistically and simulating all of the, let's say, random samples, if you wanted to speed up a computation where you just care about the branching structure, that might be more interesting application. But to be honest, it's not something I've been thinking too much about since it was, I like the theoretical aspect more at the time of figuring out how to do it in the first place, which is, but so I it's a very good question. And I'll be, if anyone thinks of something, I would love to hear it as well. think that would be lots of fun.

speaker-0: Yeah, for sure. So please, do that. Do reach out if you end up working on that, for sure. And Andres, any reference that you can add to the show notes about that will be super interesting. And of course, put ⁓ the link about the proceedings of machine learning ⁓ research that you worked on. in the show notes, but if you think there is anything that I missed and that would be helpful for people who want to dig deeper on that topic, please feel free to add that to the show notes. something you've actually also written about is the mental shift that's required to move from single number predictors to belief updating frameworks, like the patient framework. So in your...

speaker-1: Cool.

speaker-0: In your experience, a Y is accuracy, often the wrong metric for a Bayesian practitioner.

speaker-1: ⁓ yes. guess that actually also goes back to sort of maybe the adoption barrier. So I guess if you think maybe enterprise, and now this relates a bit to sort of maybe my experience from sort of the entrepreneurial space that came after the studies of trying to, mean, guess maybe Alba has the same goal. want to democratize base inference. mean, I think it's underutilized. should be used basically everywhere when, when it obviously makes sense. But if you think about what enterprise does today, I'm sure you can attest to that also. They all want to hear about accuracy and it's a rational thing to think about is if you have a predictor, if you want to predict the future of your enterprise, let's say financially speaking, you predicted the sales or your budgets or your P and L, or if you're considering your loans or your interest rates and all that kind of good stuff, you want to have a thing that's perfect. That's fair enough. But on the other hand, it's also a weird thing because we don't observe everything, in which case there's uncertainties just almost inherently. And so I think in many cases, what we really want in fact, is obviously this distribution of what we think could actually happen, which is also really, I think the only proper way to even consider risk, right? Unless you know your uncertainties about your predictions, how are you going to assess whether or not there is a risk involved? Because if your model is perfect, there's effectively zero risk, right? That's almost obvious. So if there is uncertainty, Well, that's what you would want. So what does accuracy then really mean? Because now it's about if you have a distribution, that's what you would want. Well, then the accuracy is a question about how accurate is your distribution given some true distribution, which usually we don't know. But people don't think about that sort of accuracy. They want to know how good is my sales single number predictor, which fits well into, you know, the, the frequentist methods. And it's also maybe why they can sometimes be more appealing. It's also an easier, I think, often narrative, even if you want to, let's say, sell a product in this regard, right? It's, it's, it's, you know, we've got a predictor and you can also measure some R-squared value or some accuracy, but funnily enough can also be gamed in themselves, which is funny because of how do you measure that? It's like, well, R-squared, absolute values, whatever, but no one talks about that. It's just better than the others. Which, which is also a funny thing, but... But if you talk about like creating something or inferring a distribution, I mean, what does, no one knows what accuracy means in that case. I mean, for most people. That's why I think it's a very interesting and a funny, it's almost like a paradox in some way that we think about these accuracies, but we're not talking about the accuracies that I think oftentimes are more important to be honest. And I think Bayesian inference is great for that, but it's a, you have this barrier of it's like, if you don't think about distributions. But we think about accuracy for seeing the number. Now you have this, if you try to convince or persuade or proliferate these ideas, it's like, well, I want a number and now you don't even give me a number. And then I'm unhappy. Like why would I even care about this now? Because it's like, now I need to understand why distributions are important. know, it's a, it's it's not, I think it's a tall order in many cases, which I think is also understandable. It's a, there's a lot of thinking that you would have to do and shift that mindset. which is not about whether you could do it. think many, everyone can, but it is, there's an effort in trying to change the way you think about your problems in everyday life.

speaker-0: Yeah, yeah, no, for sure. And I think that's where also your background, you know, where you're preaching academia and industry is extremely interesting to ⁓ talk about here. How do you recommend doing that then in an enterprise setting? How do you explain the value of modeling uncertainty to stakeholders who are used to goal targetings? and point estimates rather than simulation and probability distributions.

speaker-1: It's a good question. think that's honestly the biggest problem that as a community, need to figure out how to solve. mean, I'm curious what you think about this too, Alice, which is, whenever we talk to ourselves in the community, these things are obvious, right? It's, it's, it's, we all think about this all the time. It's, it's part of the reason that we love it. I mean, I guess you'll probably think the same. Once you start thinking Beijing, you can't stop. It's like the only thing you think about everything this way, which is. almost also annoying. You doubt everything in some weird way, which is, and you also doubt because we know humans can't do basic inference mentally at all very well. It's really bad at it. And so anything I think about and my predictions, and now I see some piece of evidence, I adopt my own immediate update because like, I don't think I could do this. Right. But exactly is how do you do that to everyone? else out there without sounding like that they're doing things wrong. Cause that's the other thing. It's not like you can't say that, you know, basement is not necessarily right. Again, it's, it's a, it's an approach to certain sets of problems. I think in many cases, the right tool and it's the best tool we have to reason about many of these things. But you can't say that frequent is methods for instance is wrong. It isn't, it's a, it's a different framework and it's totally fine to use it. But when you're trying to, you know, Let's say either sell a product or convince people or persuade people to use this. If they're using frequentist methods, you're also asking them to be like, well, maybe you should try something else, which can sometimes be, but why would I bother? And if you try to convince them almost it's a, you, in some cases you might need to try to tell them that maybe it's not the right way that they're currently doing it, but that can be, think, difficult to acknowledge on the other side as well. And you can come across as a bit of a, I don't know. you know better sort of thing, which is not, I think that quite the right way to it. I haven't quite figured it out yet. I think it's one of the hardest things that we face as true Bayesianists is how do we sort of proliferate these ideas without sounding both arrogant. And it ties back to the use case problem, I think, honestly, which is it's also very, very hard to exemplify the value because you're also in a space where you can't quote unquote prove it, there's uncertainty no matter what you do. So if you predict, optimize this and you're going to get more sales, but here's your, you know, the error bars. And then it doesn't perform as well as you maybe did last year, but then it's probably going to be, you're going to be false it for your method, not because it's inherent to the prediction. It's all well within the error bars. What actually happened is it's, it's baked into the system. It's supposed to be that way. So it's also hard to think, to prove the value. Because there is no accuracy number. If there was an accuracy number, that's part of the way you could sort of initially get people on board much more easily. Cause you can, if you say you have a low error prediction on your sales, well that sounds nice. I'll believe you. If I believe you, I might want to use it. So that's, I don't know how to do that. Honestly, it's part of the things I do. That's the thing I think the most about all the time is this.

speaker-0: Yeah. No, I mean, this is definitely a hard question and that's why I ask it. ⁓ I've definitely seen a lot of scenarios throughout my career ⁓ because I've done a lot of consulting before working full time for different companies. So yeah, I've seen a lot of different scenarios and stakeholders. So I can say that there is one. recipe that's going to work all the time because it depends a lot on the people you have in front of you. ⁓ Unfortunately, sometimes you have dishonest or insecure stakeholders. This is the hardest cases because like you have to take into account much more than just the technical aspect of the job. So it also becomes much more of a politics job than a technical job. ⁓ and it's definitely depends on who you're talking to and what the actual situation is. ⁓ the hardest is when you, like, you definitely need to not make this stakeholder look bad. This is, this is the hardest situation to, to navigate. if you're, let's say you're in a, like most of the time you're in a situation that's pretty. normal right where you have in front of you someone who wants to learn, who is pretty scientific. Like when you do consulting, most of the time you are in front of technical people and some business people. And when it's the same, like if you're one of the data scientists in a team, you talk to your boss who is fairly technical and you also often talk to other people who are not product managers or I don't know, like whatever you have in whoever you have in front of you. Most of the time, people are just, you know, well-intentioned. They want to learn and they want to solve a problem. That's just what they want to do. And if they are not technical, even if they are technical, what usually my arc for doing that is, you know, acknowledging the tension, but then offering the resolution. Because it's true that that the tension is real, have some business stakeholders who want certainty. Not all of them. I've had a lot of business stakeholders who actually love when you're talking about uncertainty and you're estimating it. These are the easiest ones because they are like, ⁓ yeah, I love that patient stuff. I don't know how to do it, but that's great that you do. So please, you know, lay it all over, lay it all over the analysis. ⁓ But when you have people who really want just one number in certainty, Then I think also trying to acknowledge that false certainty is worse than acknowledge uncertainty is something that's important. then reframe it. Don't give them a distribution. Give them a decision-relevant summary. Like there is an 80 % chance that this player outperforms the threshold. Like this player or this product or whatever. practical tools I use a lot of the time is use scenarios instead of intervals. So usually I love having an optimistic base and pessimistic case and what drives each of the scenarios. This is much more useful than giving non-technical people intervals. And then visualizations, of course, on top of these scenarios for each scenario that make the uncertainty feel like information, not like noise and something that's, um, that's, that's giving you paralysis analysis. yeah, in a way, think the deeper point is that uncertainty quantification builds trust over time. So that that's, I think this point is more real when you're embedded in a science team inside a company, much more than when you're doing consulting where things go much faster and on shorter timelines. But when you are part of the science team in a company, Then also, when, people know that when you say you're 70 % confident and you're right 70 % of the time, then people start listening to the 40 % cases too, let's say. Of course you need time for that. Like it's not building trust takes time. ⁓ it can be compacted if the company moves very fast, but still it's not something you can have from day one.

speaker-1: Yeah.

speaker-0: Um, so yeah, like, and, most of the time from what I've seen is that a lot of the stakeholders will respect honest uncertainty more than false position, especially after being burned by overconfident models. in a way having overconfident models is also something that's serving you as, the modeler because like if people have been burned by death and they know you cannot go too far either in the direction of certainty.

speaker-1: Yeah. And that makes that, mean, of course that, makes a lot of sense. And that's exactly, I mean, it resonates a lot with, sort of what, what we've experienced as well. The, the, not the caveat, that's not the right phrase. What I find is the real, for me, so I should maybe start from the sort of the, current goals that I have now and sort of why we're doing Evara now, which is the, this, business that I'm, that we, have started after I graduated. It all comes from that sort of my passion for obviously Bayes inference, which we all share. And the goal that I thought was going to be achieved years ago, which is why is probabilistic programming not used everywhere? It's in the languages, we all use this language anyway, but it's usually not used ⁓ either, which is perhaps not too surprising because you need to be a programmer for one. And two, they're still very statistical. Right. You still need to know about statistics. So you have this weird Venn diagram of like statisticians that also know and cares about Bayesian inference and then, you know, pretty good programmers. And then that sort of intersection there is not a particularly big one, think across the world, certainly. So it's not, I think, too surprising on one side and yet... I think it's so important to have this as almost like a probabilistic like calculator. If you want to call it that, we should all have this. It's almost like if I'm using my estimating it sort of really anything, I would like to know my uncertainties about that. Like if I'm looking at my monthly budget, why not have my, my, my error bars. for myself throughout the entire accumulation of all of my uncertainties, which is about how much heat do I use, how much electricity do I spend, how much gas, how much do I drive and all that kind of stuff. And it says uncertainties in all of these different components and they all add up to this monthly expenses, including potential income uncertainties about my job and so on and so forth. And that seems to be something that I would just, if I do a budget like that, I would just want that inherently. Like we all do it now, we write it in some sort of program somewhere on our computer and we get some number out, but that's not, we all know that that's not going to be the real number. It's some sort of weird gauge, but progressive programming promises that essentially that you can just, even if you don't do inference, know, just Monte Carlo simulation, the sort of base, no observations. You just create and see what is my expected sort of plus or minus. expenses every month. And then you do inference once you start to actually observing your total, you know, expense every month, right? It's just the other thing. You don't even need to really do much updates. Once you build the model, unless there's something fundamental into your behavior that changes the way that you might want to update certain mechanisms, you can just put in your expenses every month and then it will adjust those uncertainties for you. And it's a perfect almost example also, because one of the big problems as we've talked about is the computational scale and how fast you like, you know, converge. But it's like, if the baseline is no uncertainty, I would rather have something that might have converged somewhat, but still give me some level of estimations of my budgets. And it still seems better to me. So it's like the bar almost is very low because you're not competing against some other very technical. solutions here, it's nothing or something. So, and you can just run it longer. And if you do this month, a month, once a month, even who cares if I need to run it for 20 minutes. mean, obviously most people wouldn't, but it's just the, hopefully the example kind of makes sense of like why not have it. It's, and so that's what I'm really want to do. And it's the, problem there is that if you were thinking about, let's say selling to an organization, now you have to hand over that process entirely. So if you do, let's say, the consultancy bit can solve a lot of those maybe friction points, because at least they can offload it in some sense. They can sort of get on board with the ideas. And as long as you produce the of the results and the outcome, and they just need to sort of take that in, it's... You know, it seems logically also sort of more, more easy and, it's, you won't be as opposed to it, but if you're asked them to do it, it's not that they don't maybe like the ideas of it, but it's more like you ask them to do work, which, which might itself be sort of part of the, not only do you need to try to understand, but you need to understand it enough that you sort of trust what's happening. It's a new tool that you have to use. And yet that's also, that's on, that's what I find the most interesting. That's really what I want to solve. That's everything I think about these days is how do we get people to use it and find it interesting and enjoy it and see the value of it without just offloading the sort of that intellectual bit to another entity.

speaker-0: Yeah, no, that makes total sense. And actually thanks for the segue. That's perfect because I think it's a good time now to start looking at your insurance pricing demo that you have with Evara, which is the company you founded. But before we jump into the Excel shit that you have for us, can you set the stage? What are the latent variables we're going to look at? We're trying to account for when setting In your example, a car insurance premium.

speaker-1: Yes, yes, exactly. So take an interest like this more enterprise-like stage rather than maybe a personal monthly budget. You can imagine if I were to offer, let's say you Alex, like an insurance policy, just to make it slightly more personal. One of the things that you own a company and you want to ensure all of your cars and your fleet of vehicles, so your fairly big business. I want to figure out and ascertain how many claims would you do every year? Right. And how much is it going to cost every year? And so a simple example like model will be to indeed have those latent variables, which is how many claims and how many vehicles are going to, you know, are you going to make claims on in a given year out of the total amount of vehicles that you have. And on top of that, you might have a change in vehicles. So if you have a deal where I need to get an estimate of even historically, What's going to, how is your claim history going to change over time as well? And if your fleet grows, how should I expect that in the future? And should that change how much I charge you today? Because I need to predict, you know, the potential insurance premiums into the future. And as an insurance company, the important thing is of course that there's always risk involved because how much money do I need to hold in reserve to make sure that I can pay out your insurance claims? That is really the of almost the game. like in insurance, the uncertainty is like very much an inherent problem, right? Because I don't know how much, how many damages there's going to be. And I need to make sure I have enough money, but I can't have all my money said I need to reinvest my money as well. So this is a very much a, you know, a problem of what is my risk tolerance? Like do I want to make sure that there's a 99 % chance that I will be able to pay everything out, but that might be a very long tailed distribution where I can't make any of the money that I've charged all the customers work for me. So that's really the underlying problem. the latent variables are the metrics about your business that I can't observe. Like the changes in the number of vehicles, right? There's no, I can't observe that. the, you how many... how many of your, if you say, if you give this up to your employees and they drive around, like how, how, how risky are they in their behavior of driving and so on. And that's, that's some of those latent variables that you would need to, that you would need to infer. And that's the example that we've been sort of looking at. So it's a simplified version of that, where we will be inferring the expected number of claims that you make per vehicle. And then obviously you have this unknown maybe number of vehicles. So you have these risk parameters and the exposure parameters. So these are just insurance metrics that have been used that you can infer as latent variables.

speaker-0: Yeah, something obviously listeners and actually people who are watching on YouTube are gonna notice is that you build this model in Excel and that's really what is about actually. So yeah, if you're free to give the elevator pitch for Evara and also tell us why you build it in Excel rather than a complex coding environment for instance.

speaker-1: Well, it's all in the, for the, for the, towards the mission of making this system democratic and democratizing based inference as possible. Right. So if we can, I'm just going to, if we assume the base inference is valuable, I'll just start with that. The reason we're in Excel is because everyone is in Excel. Right. It's about a billion people roughly estimated that has Excel. That doesn't mean everyone's going to do base inference, but there's estimates that maybe about a hundred million people are in a website, call them super users or power users. that does actually analysis and can do like fairly complicated functions, et cetera, within Excel. And you can do, you mount the buckets and you do P and L and all of that kind of good stuff within Excel. part of that mission to make it as simple as possible is to make the interface to the probability programming language much, simpler. So we've basically made Excel into a probability programming language, but we've tried the main goal is to make it so that you don't have to think so much about the statistical bits of it. So it functions much more like you used to. trying to make the, let's say you select uncertainties and you visualize the uncertainties and you call them, you know, maybe you call it around rather than gaussian to sort of fit the language that you also use sort of every day that matches these uncertainty like concepts, as opposed to make it super statistical and you call it a sample statement and you call it an observed statement. And so taking it out of that more traditional programming paradigm to make it not obvious. mean, the interesting thing is Excel is a German complete programming language, but no one thinks about Excel like a programming language. mean, who does that? No one thinks about it that way. But can write anything in it. You've got Lambda functions and everything. It would be crazy to write all of that stuff, but some people against you, but it's not pleasant. But Excel does a lot of good things. Like I use it, I've actually come to appreciate it since really working in it for monthly budgeting. I rather use it for that because it has that visual aspect. But I think it's a great medium, these spreadsheet type programs to make it more accessible and sort of easy to use without having to be a super detailed technical person in programming languages. So that's the reason why we're simply, we're in Excel. It's to sort of leverage that and embed it into existing workflows. ⁓ But that does have a reason.

speaker-0: Yeah, yeah, yeah. That's the answer I had guessed from ⁓ hearing from you from the past hour, so I'm not surprised. And that's honestly really great that you're doing that. So actually now let's dive into the demo. You want to share your screen and then walking us through the demo live?

speaker-1: Yes, let's do that one. Make sure I get the right one here. So you this one. All right. Perfect. That pops up correctly. Perfect. Wonderful.

speaker-0: Awesome. Yeah. Yes, yeah, it's in there so folks if you're listening I encourage you to switch to the YouTube video and if you're already on YouTube well I hope you enjoy looking at Andreas and myself in very close framing for more than one hour and your reward is actually to watch these two

speaker-1: You know, the spreadsheets, how amazing. It's like, I guess what you've been waiting for is to look at a spreadsheet. Exactly. Yeah. Good luck on the, if you're listening, good luck on visualizing spreadsheets. that's a, that's going to be quite the challenge.

speaker-0: We're all nerds here, Andreas, so we're all happy that the rigworld

speaker-1: Awesome. That's, that's what we were hoping for. So let's just call this Acme Corp, right? So this is what I mentioned that say this is your business Alex. And like I mentioned, we've got these risk parameters. We've got the annual fleet change. We've got loss per claim and sort of, might have uncertainties about these sorts of numbers when I need to figure out and predict how many claims and how much is it going to cost me? How much coming in, how much claim in total dollar value are you going to be making every year? That is the sort of predictive. task that we're looking at. And we have the years here. Let's just do this as an annual example to sort of illustrate the sort of time varying aspect of this and how you can lay this out in Excel. So you've got the, say the first five years onto 24. This is a year old. I should have probably added 25 here, whatever. And then you might predict sort of into the future, what are the claims going to look like for the next, let's say handful of years. And We have these different, different other columns here. You've got the claims and the number of vehicles. So it's because the number of claims you will making is a function of the number of vehicles. So if you have a fleet of so many vehicles, the risk and the rate here that is derived from these two numbers is going to tell us how many claims you will be predicted to make every year. And of course, multiplying the claims by the loss dollar value per claim is going to make the prediction of the total loss for that year. And of course we can add the total loss up for the entire year and then the prediction for the subsequent years, which will give us the total predicted cost. So this is all just, you know, regular Excel that you just sort of type them into the different cells and you can reference them just like you normally do. It works all that same way. Now, if we then ask, let's say I'm going to charge a certain premium, let's say for the next X years, what is the profit from an insurance perspective going to look like? How much money am I going to make or lose? Right. I can just look at the differences between the total predicted loss to the premium. And that's going to give me the total profit that I'll be making or a loss, right? If it's the opposite, if it, if your claims might be greater than what I'm asking for, you know, that's my risk as an insurance company. I make a certain promise today about what I will be covering for you. And that's going to be some uncertainty about how much you'll actually claim at the end. And one of us is going to make more money from this. That's basically the premise, right? For an insurance company. Now, if you just look at some of these values, instead look at the uncertainty, you'll notice that it's not, and this is hard to assume that one in more than this, but it's not a traditional this number. We've got this eval.decline and this is your priors, right? This is your sample statements that we've created. Right. And you'll find these everywhere. You've got an occurrence here as well. So this is a Poisson distribution. So this is an occurrence. This is how you might think of that. And the fleet change, which is like the growth that goes on every year is another occurrence. It's another certainty that we have. And you notice, look at the number of claims here. The first one is the starting point. So let's say the first year when we talk, we had 50 vehicles. So there's no uncertainty in that at all. There's no prediction, you just have 50. Now the next year is just a function of our assumptions in the growth. And you can see it references those numbers as you would expect them to. You have another around here, so now it's just sort of the likelihood, right? Cause I'm also uncertain about my model. That's the way you might think about these likelihoods. So I might predict that it's going to grow by two and there's a 10%. So this is a thing about Excel. I can just write this as a 10 % variation in my prediction. And that's going to give me my predicted number of vehicles. And from that, we can calculate number of claims as a function of the two risk parameters and the exposures. This is a fraction of the total vehicle feed I can number because you have, and we can then calculate of course, the total loss that comes from that. And you can accumulate those. So that's just the, this is the model, right? I've just described the model. So that's basically what we do. This is the neat thing about Excel, every budget or P and L or anything you have that has uncertainties and assumption, ask anyone that does spreadsheet model analysis today, they have uncertainties in their assumptions. Well, that's a model. That's basically what we're trying to sort of make explicit here. Now, when you have Evara here installed as we have, we can just launch it. So I'll launch it here first. That's going to set up the backend and everything internally so that we can actually start to do inference. This is just for the backend that pops up there. So you can see that it actually starts up stuff there that we can communicate with. So it does, it can do inference and everything. Now. You can see we've got a bunch of options up here, but let's just sort of show the, you actually just like sample and show individual scenarios in the entire spreadsheet. So right now what we're watching here is sort of like the mean or the median number across all of our assumptions, our distributions. If we make them more dynamic and we click next and previous, you can see that all the numbers sort of just change across the entire thing. So this is just one sample for the entire model that shows up here. Everywhere. So you can sort of see a result we can plot also, and it automatically obviously relates to each other. It's just Excel numbers. So you can see that these are, you know, we have a real set of numbers. So this is going to be our real data. It's going to be the blue. So I might have done a little too pretty here, but we want to see what happens when you have actuals. So you can sort of observe a due inference. So, but the orange line here are just random samples from our, predictions about my claims, the claims and the number of vehicles and my losses. What we will have now is that the blue line is going to represent our real data. So some of that we'll be observing and some of it will be a future prediction. So let's start off with doing the multi-color simulation. Let's not do any observations just quite yet. So we can just look at from the beginning, what is my total predicted loss? So we can run the system to basically just do random sampling and it will be generating In this case, can see up here, have a thousand scenarios that we just generated. So you can change this number and we get a nice plot that looks like this. I'll zoom in here so we can actually see them. So you get this sort of histogram of our scenarios and how they're binned in the total loss that I would expect from my model. Just a priori from the beginning. And we can slide through the different scenarios that we've generated, which... would of course also reflect back into the original sheet. So you can sort of tie the scenarios to where it is on your plots like this. And so if this is my predictive loss, I would use this, for example, to decide what my policy should be. Because this is really where it me sort of fits into the, I think your talk with Daniel, which is the sort of what about the decision-making aspect of this. Where once I have my predictive losses, the question is where do I put my sort of line of, how should I say that? You know, what am I comfortable with? Like given these are my losses, how much should I charge you so that I'm comfortable with having a certain probability that I'm not losing more money than more than 5 % chance, et cetera. And so that's the game that I would have to do as an insurance company. If you did the same model, you would have to do the same for yourself to sort of negotiate with me. And we'd have to come up with some sort of sub-optics, some sort of min-max position where we're both comfortable. Okay. So that's fine. But let's say we want to revisit after a few years. And now you've made claims after the first, let's say the first five years. And now from my side, I want to update my model. That's obviously the problem. So now we have inference. So let's say we have our actuals here. So these are the actuals. Let's hypothetically afterwards compare to our predictions for the future. So let's imagine now I've generated a full scenario for the entire years, according to the model. So that's a bit of a mock-up set of data. But I can only infer given the observations of the first five. So we can obviously, what we'll do is we'll add them as actuals. That's just what we call them. It's just observed statements. And we'll note them. And you can mark them like this. There's many ways you can add them as actuals, but this is just one way to do this interactively. And we can record them. And what we see here is how these numbers have changed. And if you look at it up here, you've got the Varo actual and it references those numbers on that other sheet. And we should do that the same way here for our number of vehicles. There we go. So now we've also observed the number of vehicles. You can do this for all of your actuals. You can do for some, for all, whichever. It's just a model with observations. And so now you have this like, at this point, it's like this pseudo state where you have like actuals. So it's not inference yet. You still need to run the inference, but it has this sort of pseudo conditional predictions. So, but now we can rerun it, of course, and do the, the inference, this is probably the program. Now we run it, now we do inference. And you get the updated posterior, estimated posterior, of course. Right. So before you have this sort of long tail exponential kind of looking distribution. And now after my observation for those first five years, you get this much more centered posterior distribution. It looked more like a Gaussian, seems roughly, right? Obviously it's an approximator. But it has sort of contracted much more round, know, one point, maybe two. You can look at here at the top, we've got some summary statistics, the mean standard deviation that follows from our scenarios. You can also look at confidence intervals and other stuff, but I'll sort of leave those details for later, but there's other things you can explore. After those five years, my expected loss is $1.2 million. And this is roughly 50-50 even down the middle. So a fair bit, quote unquote, might be to... offer a new policy where if it's even, it will be about this $1.26 million that would be the price for this policy. But I would obviously try to make it so that I get a better deal out of this because you don't see this plot naturally. But the point is without such a plot, can't really make such an offer. I can't deduce what is a reasonable risk reward policy offer that I would give you. Of course, if you want to look at the results, so now we go back to sort of this accuracy, but visually we can sort of imagine an accuracy assessment here. So remember, in our actuals, we had those first five years, we condition on those, and we have five future years. And so in this plot, what we have is the first five up to 24, because we have actuals there, they're fixed in time. So our ORINT prediction is exact. It's just right on top. So it's the next five we need to consider. how good we are. And before, if you remember, it was going all over the place because it's just general samples. But now you'll see that it's nicely hooked and tied to that beginning. So if you sample through and look at different scenarios, you can see that it fluctuates nicely around those future predictions in that kind of fight. Actually, you can imagine like an aero-bars around that in a posterior sense. And you can visualize each individual scenario here. If I wanted to, let's say for reporting purposes, choose a scenario that lies, let's say way out here in the bottom, let's say a few losses, and I wanted to report that, further down, let's say here, right? So now we have chosen scenario right here. Well, we can now look at this is what that scenario looks like in this case. And it reflects again, this posterior sense where it's like the blue is... what might actually have happened in this case, but we predicted or assumed it was this, you know, the orange one at the bottom. It all fits within that posterior notion is that in 2024, we don't know what's going to happen. So we have all these possible scenarios and we might make a decision based off of we think it's going to be this lower bottom one, but we have accepted at that point in time, the fairly large risk that is going to be greater. Cause we go back to the plot here, it's sort of down here in the lower end. There's a big chance it's going to be greater, but that's where the risk reward, you know, question really comes into play. And it's all about your risk profile as a, you know, individual or business or a corporation, et cetera. So that's, that's, that's what we're doing is that we make this available.

speaker-0: Yeah, yeah, this is awesome. Thanks. Thanks, interest for these, these demo and yeah, for everybody listening, this is actual Bayesian sampling in an Excel spreadsheet. So this is like, I know a lot of people have been dreaming of that for a long time. Well, this is actually what you're getting here. So that's, that's amazing. Well done on that. Andreas and I'm just like under the hood. How do you do that? Like have you had to code all of that in... I don't remember the Excel language. ⁓

speaker-1: There's a lot of languages and things going on under ⁓ the hood. That's lot. That's the best thing I can say. There's anything from VBA to some TypeScript, C-sharp and you name it. There's a lot of stuff that needs to go into that to make it work nicely. mean, part of the sort of, I can say that certainly the technical interesting things to think about is How do you make it also sort of efficient to use proper resources because you don't, the reason we have an engine that runs in the backend is because you don't want to be constrained by the Excel computation resources themselves. But you also need to make sure that you're not messing up with how Excel functions otherwise naturally. So it's a, it's a non non-trivial, it's non-trivial task.

speaker-0: ⁓ yeah, I can guess that. How do you do for, like do you support already net sampling and things like that? And if yes, do you do that? Like do you plug to any probabilistic languages that already exist like PIMC and...

speaker-1: We've got some of the traditional, typical algorithms put in place. So far it's not been the main focus actually quite yet. But firstly of all, there's a lot of the sort of more straightforward ones that you could think about SMC, et cetera, that is obviously also running there. You can choose that. It's just the thing about Excel is in many cases, it's not necessarily the biggest, massive, millions of lines of code. So the real work so far has actually been to just make sure that it actually integrates properly. It's very much in the future, future set of decisions to, and on our roadmap to add more infant algorithms, but also we want to make it so that you can plug in different even languages and, you know, make a universal set of, let's say, cross-compiled sort of languages, maybe where you can add your favorite, like other language, maybe, as well as having like an intermediate layer. So you can plug in and have some open source capabilities, which we just don't, we won't have that yet. Right now it's just about, make it, sure that it actually works properly and that we can, we can support the sort of the proprietary bits first and then we can expand from there. But that is, that's the goal. I mean, we want to make it so this is much more of a platform like system that you can also plug things into and, you know, add your own infant algorithms if you want.

speaker-0: Yeah, exactly. So for sure, you're going to handle mostly, let's say, building your level models here and probably like conjugate priors models. This is a perfect use case.

speaker-1: cool things you can do. I'm quite excited about the things you can do exactly. There's a lot of really cool, both science, but also just the technical stuff as well. It's really, it's actually not fun. It's a weird thing. It's like Excel is fun again, in some real way. I actually enjoy writing these models because it's quite fun actually.

speaker-0: Yeah, yeah. Yeah. Yeah. I mean, even for the hard models, like, you know, I can definitely imagine that being offloaded to Evara basically and Evara being able to basically parse a prompt from the user directly in Excel. then basically sampling, like defining and sampling, let's say a structural time series model, sampling that with PIMC under the hood. And then in a few minutes giving user back ⁓ plots and analysis if everything went well and then yeah basically the user not needing at all to know what went on

speaker-1: That is exactly, that's what we're doing here also, right? It's exactly that. We want to make it. What we're trying to do with this is just deliver on that promise that it's supposed to be something that you can have in your everyday tools where you don't need to be is that decision that you don't even know what property programming is. The idea is to make this look like set of macros that sort of fits nicely into Excel, but take away even the complexities of the tool itself and what it does. Which sometimes can actually be sort of both a benefit and not, because it can also look too pedantic a little bit. It's like, is this just like a simple like add-in that does whatever? And it's like, no, no, there's a lot actually also going on. But we want to hide that, but it can also be like, well, you then, is there anything interesting really going on then other than just something like that? So, which is a funny place to be. like, and like I said, the, the, the barrier of adoption is the biggest problem that I am trying to figure out. If anyone has great ideas of listeners, yourself, Alex, this is the thing I want to figure out. It's to get people to use these sets of tools. it's what we're doing or something else is actually, that doesn't matter. I'm on this because of the years, like I think most of both yourself and your listeners, it's about these new things.

speaker-0: No exactly, well I mean, so how people listening to us right now, if they're interested in trying that out, ⁓ how can they do that? How can people start using FRI?

speaker-1: Use yourself. We've got a website, but send us an email and we'll figure something out.

speaker-0: Awesome. What's the email?

speaker-1: It is either contact at evaro.ai.

speaker-0: Perfect. So.

speaker-1: I'll give you the context also for the notes as well.

speaker-0: Yeah, the website and the LinkedIn of Evara are in the show notes for this episode, folks. feel free to focus on that. And actually to start playing us out here on Drafts because you've already been very generous with your time, but I'm curious about, you know, I've been part of the team who's created and founded the company. I'm always the entrepreneur. is always interested in this. Like where are you in the company's life cycle right now? What are your... priorities for the next month and what are you focusing on right now in your next step?

speaker-1: ⁓ it's been, there's a bit of restructuring that we've had to do. it's, like I said, it's the struggle is to figuring out how to convey the ideas of what we're sort of offering, which has been difficult. So we've been focusing a lot before on big enterprises, which has proved both difficult because it turns out enterprise sales are very hard. That's the one you're really like, it's very difficult. There's a lot of sales cycles and everything. So we've now got some sales help involved as well, but we might want to try to scale things around and sort of target maybe more medium to small businesses. But otherwise, analysts just get people to use it. I think that might also be one of the important factors to sort of get back to the, maybe it also has to be an internal, know, not pressure is not the right word, but it's... If analysts can use it, we can maybe better and more easily convey it because it can sort of generate the value and interest from sort of an internal asset rather than trying to like to sell directly to very busy executives, right? Because they certainly don't have the bandwidth, which is, know, why would they? It's like, all know when we're busy. It's not like I'm going to drop everything. Like imagine I'm sitting here on a, like the analogy might be a Windows machine and now someone convinced me that Linux is better, but it's like, yeah, but I don't have the time to figure out Linux. It doesn't matter how good it is. Right. It's a, I don't have the bandwidth necessarily to make that decision at the point in time. So yeah, it's figuring out how to really get into the market with something like this. That's everything that I'm really to figure out these days. Actually just today, it finished a new update, which is wonderful before we got on the call. that's ⁓ that's awesome. Wow.

speaker-0: Get it? Yeah, congrats, well done. I know it's hard and I know it's a lot of stress and work to do that. Especially the sales funnel is always obviously something that you need to pay a lot of attention to. But I think you guys are doing a very good job on that and I think it's a great initiative. from the show that a lot of people have been asking for this kind of product. Well, now it's here, folks. if you want to try it out, go to the the Evara website. And actually, just before asking you the last question, Andreas, you are someone who is curious and always learning. So, yeah, is there anything you personally are focused on for the coming month, things you want to learn? things you are curious about or you wanna see in particular?

speaker-1: I'm getting more more interested in the not to open another can of worms because you I'm going to say LLMs, which is, you know, you can't not say that. feel like, even though I will say I feel trying, trying really hard not to.

speaker-0: That's good because that way the... and then this... The... Show goes up and more people listen to it.

speaker-1: Fuck you, bitch. Brilliant. That's right. That's right. That's fine. Yeah, no, and I've always been a bit of an anti-hype person just sort of generally. I like to be somewhat skeptical, I guess for better or worse, it's one of those things. I've been coming, I like to believe that I approach these things somewhat conservatively and yet still with an open mindset. And I've been more more intrigued with, I think ways that we might be able to leverage these language models to sort of really succeed in our mission as well as sort of like a part of a way to communicate maybe the kind of inference stuff that you might be doing. I think there is some potential there and we've done a lot of exploration and that's the next thing also we're going to be working on is to figure out a way to do that. But I want to make clear it's like one of those things where we don't want, right now we don't have any other limbs, right? mean, it's not like that it's it's processing programming. And there's no, you're not going to replace that ever. ⁓ But I think there are opportunities where you can have, know, again, it goes back to that interface aspect where I think there's some interesting things there that we're exploring if we can make sense of this in a way that that is actually useful. But we always try to do, and what I'm always wary of is the, you know, where are the shortcomings with these systems and... Are you going to run up against a wall where it's going to introduce errors and bugs into, to, you know, your, like the way you think about your problems and et cetera. So I think it's one of those things that we need to be very careful of in how you integrate these systems, in a way that it makes sense. But that's one of the things I'm really excited about. Actually, I think that will be a lot of fun to look at.

speaker-0: Yeah, definitely sounds like it. ⁓ Well, Andreas, I'm gonna call it a show because you've been, again, super generous with your time. Thank you so much for these. Of course, as usual, before letting you go, I'm gonna ask you the last two questions. I ask every guest at the end of the show. First one, if you had unlimited time and resources, which problem would you try to solve?

speaker-1: Well, I this is one of those that I think they've already been set before. would just do better, better inference. no.

speaker-0: No, no, I don't think so, no. ⁓

speaker-1: I think, I think Daniel said something not, maybe not exactly the same, but I will agree being, I'm envious of, of, you know, those people working on, on, you know, good inference algorithms. think it's a, the, the, feeling of, of generating new methods or algorithms and seeing it working is a, I mean, there's nothing quite like it. But I guess why we do also science, but at least you end up like, it's just so enjoyable. I mean, The sugar model is that example also is like what you use it for. That one was also just because it was super neat ⁓ as a science. But there is a problem to resolve with inference and better inference and faster inference, ⁓ which is one of those things that I think we should really, I would love to try and solve that. ⁓ Obviously figuring out how to maybe do mass scale, I don't know, research and questionnaires and figure out why inference and...

speaker-0: Mm-hmm.

speaker-1: based on inference and statistics, it's so difficult to conceptualize for people. I think there's another one you got to figure out. But I think I would say this, so you know, I think what you're doing here is amazing. I think this is indeed one of the ways to do it. And I think I wish more people, they should start listening to your podcast. This is brilliant.

speaker-0: Mm-hmm. Yeah. Thanks, thanks Andreas. Definitely appreciate that. Feel free to spread the love. That's how the show gets going. Actually, don't do any paid marketing at all. Just like only organic growth. This ⁓ is a purely organic product. Could be sold at Whole Foods, if I understand correctly. ⁓

speaker-1: Perfect. You're doing some really good work. think this is brilliant. I really, I love this. This thing is great.

speaker-0: Great. Thank you, Andreas. appreciate it. well, second question, you know, we can't, I'm French, so I have to talk about food all the time. So if you could have dinner about, if you could have dinner, sorry, with any great scientific mind, dead alive or fictional, who would it be?

speaker-1: All right. thought you just didn't genuinely. It's like, would love dinner. just, yeah, it's a struggle. I think, ⁓ I think that's like, it's between two different people. One is Newton. I mean that, that is just what he managed to accomplish is just ridiculous. It's like, I can't figure out how that meant. Like you just don't invent categories because you want to try to solve all the problems. Like who does that? That's just, that's, that's just insane. Well, it's even before 30 or whatever. It's like, wow, talk about. feeling like you got to work harder. I think he just showed up everyone. So I think that would be pretty interesting conversation. was a, how to like figure out how that man thought that's it. Yeah, that's quite something. But the other one would be, think Niels Bohr. Well, he's a Dane, so I can't help it. And in fact, was, his grandchildren were teaching at my university. he taught his, Thomas Bohr was my, taught me electromagnetism. Very difficult subject, but fascinating. mean, to figure out how you think about quantum mechanics, talk about uncertainties. It's like here you have nature's own uncertainty in quantum mechanics. I want to talk to that man and figure out how do you, what's going on there? Like how do you start to reconcile the world with being quantum fluctuations and random? I think in physics, quantum mechanics is one of the most enjoyable subjects that I worked on. I really like that. Maybe that's why I end up in base difference.

speaker-0: Mm-hmm. Mm-hmm. Yeah. Yeah, that's ⁓ that makes sense for sure. ⁓ that'd be, that'd be a fun dinner. Yeah.

speaker-1: I need to ask you then Alex, maybe you've already answered, what about you?

speaker-0: Oh yeah, I've already answered that. I twice at least. Really? So that would have been episode 0. But that's great, that means I can answer multiple times. I think episode 0 I answered and then episode 57 I was actually interviewed by Remy Louvre who was on the show.

speaker-1: That's impeccable. You just know the exact numbers. That's pretty wild.

speaker-0: Yeah, I know, know. mean, you know, each episode is a substantial amount of work. at some point, like each episode you ship is a bit like its own product. So it stays with you. So I often remember the numbers of the episodes. that's a weird way my brain works. So that's for sure. yeah, I mean, so that's what I answered. I don't even remember what I answered in episode 57. I'm pretty sure I answered... ⁓ Condorcet for Episode 0. So French mathematician, also ⁓ part of the Enlightenment, extremely brilliant person. Yeah, from aristocracy, but who actually also ⁓ was an extremely adept thinker of democracy and republic and his ideas for the time were extremely advanced, especially from someone coming from aristocracy. So I was definitely someone who knew how to think outside the box because that is definitely his idea were definitely not how he was raised. ⁓ but at the same time, he also proved mathematically the problem of majority voting. When you vote. the way we do. so, yeah, basically he was already advocating at the very, very ⁓ beginning of democracy that we shouldn't have simple majority votes like that, because this is not the actual way of actually getting to the majority vote. And so we should have much more ⁓ ranked voting. So this is one way. The one he was mathematically proving would be the optimal one would be basically to select your preferred candidates in some duels. you know, like, and so just two by two, but each candidate would be in duels. And then the candidates who wins the most duels is the candidate that is actually chosen by the majority. And

speaker-1: What time period was in? What are the nature of these duels?

speaker-0: Yeah, exactly. They still had actual duals. I'm pretty sure it influenced his thinking. But mathematically, he basically shows that it's the optimal way of actually getting to the majority vote. Because otherwise there is dilution of votes and there is strategic voting. You can see that in France, for instance, I mean, even in the US, but the Electoral College ⁓ adds a layer of complexity. But in France and in most of Europe, you know, like there is strategic voting because basically If there is more parties from, let's say the number of right parties stay the same, but you have more propositions on the left. So if you have more leftist parties, then actually it's going to dilute the vote for the left. Even though actually the fact that there is more propositions from the left probably is because people are most ⁓ interested in the left's propositions. But the fact that you have more parties. means that the left actually has less chance of getting to power, even though it may represent more than 50 % of the population. so that's a big problem. And I hear him saying left, but it could be right. It's like it, math is...

speaker-1: I understand. It very well illustrates the...

speaker-0: Yeah. And that's also why like in the US you cannot really have more than two parties because then it's it's diluting votes and so on. And Condorsi's whole point is that, it shouldn't be the case. Like if you, we don't know if the majority vote is the best one, but if you actually won the majority vote, then do it properly. And the proper way to do that is Condorsi voting. it's just like preferred for each duel. And then the winner of the duels wins the election. There is one paradox though of these is that for instance if you have three candidates and A is preferred to B who is preferred to C who is preferred to A then you have a paradox condense a paradox and then there is no winner and the way this is solved is a random solution so just draw randomly the winner and This is a fun way to do that. So I think that's why it will never be implemented because we hate randomness and it would be like No way the president is chosen randomly, but it's actually the fairest way to do it when there is the Condorcet paradox. It's just between the ones who've got the most jewels, you just draw randomly between them, which I could only appreciate.

speaker-1: Fascinating. think I would say Alex there in the end, I think it's a marketing problem. You just have to call it gambling. I people like some sort of randomness. I'm pretty sure. Yeah. It depends on how you frame it. Yeah, yeah, yeah. I know about can of worms, anyway, don't want to.

speaker-0: Yeah, yeah. This is another can of worms. So, mean, and so since you asked me, think I don't remember who I said for episode 57. maybe I said it already, but of course I would really have really like to have dinner with Piers Simon Laplace, who is actually the one who developed patient statistics and understood the potential and who has actually someone very interesting, like from very, very like a very small family from the west of France. So he didn't have a lot of money coming. I think they were peasants. So you can imagine at that time the living conditions and he just managed to go to Paris because he was a brilliant mathematician. and it's just his math teacher who, you know, like spotted him and was like, dude, you could apply for, I'm sure they were saying dude already at the time. Dude, you're gonna go to Paris. Take the train. ⁓

speaker-1: Even though it doesn't

speaker-0: Yeah. It'd be like Frère. Frère, you need to go to Paris ⁓ and study math at university. then ⁓ he studied math with d'Alembert, who was one of the brilliant minds of the time. Actually found out about ⁓ Bayes' role, but he didn't read about it. He just discovered it again. and was super happy and thought he would make his dog trait thesis about that. And then D'Alembert was like, ⁓ yeah, yeah, well done. But actually already exists. Yeah. You cannot write your PhD thesis about that. ⁓ so actually Laplace was a bit depressed about that, if I remember correctly. He was quite down and was like, damn, I don't know what I'm going to do with that PhD. And then that's when, you know.

speaker-1: But you're a little late.

speaker-0: the obstacle is the way so that's when he understood the whole framework about that and developed all of that. So I think that'd be a great dinner because extremely brilliant person from modest roots. So I would be actually super interested in how you lived at that time in these conditions and who was also able to raise himself up just because he was extremely brilliant intellectually. And like then the dinner would be in French too I'm sure I would understand him even though sometimes you know he would use weird weird words in French that ⁓ yeah like dude and stuff yeah

speaker-1: That sounds amazing. can... I'll just... If you have room for another, I wouldn't mind joining in on that. mean, no one understands French, I'll just sit there. I guess.

speaker-0: So yeah, bless with people. Yeah, well, happy to, happy to. I'll translate, I'll translate. That'd be great.

speaker-1: Wonderful! That would be fascinating, that was a good choice, yeah.

speaker-0: Yeah, I mean, bring Newton. I'm pretty sure he'll be happy to meet Laplace and conversely.

speaker-1: Yes, it would be. would be. We'll have a ball. Just yeah, I love it. I think it's

speaker-0: Also, Andreas, this is definitely running long and I need you to let you go. So thank you so much again for taking the time. ⁓ Good luck on Evara. Thanks for doing that. I think it's a great service to the community and I hope you guys will be successful. I definitely wish you the best. All the links are in the show notes, folks, for those of you who want to dig deeper. And Andreas. Thanks again for taking the time and being on this show.

speaker-1: Thank you so much, Alex. It's been an absolute pleasure. And I think what you're doing is just brilliant for the community and everything that we're all trying to do. So keep this up. This is great. Thank you.

speaker-0: Thank you, I'll stop the episode on that for people who just watched the end. That makes me look very good, awesome. Thank you, Andreas, for doing exactly what I asked you before the show.

speaker-1: Yes, yes, yes. was lots of emails and lots of documents that I instructed very carefully.

speaker-0: Don't spill the secrets. See you soon folks! This has been another episode of Learning Bayesian Statistics. Be sure to rate, review and follow the show on your favorite podcatcher and visit learnbayestats.com for more resources about today's topics as well as access to more episodes to help you reach true Bayesian state of mind. That's learnbayestats.com. Our theme music is Good Bayesian by Baba Brinkman, fit MC Lars and Meghiraam. Check out his awesome work at bababrinkman.com. I'm your host. Alex and Dora. can follow me on Twitter at Alex underscore and Dora like the country. You can support the show and unlock exclusive benefits by visiting Patreon.com slash LearnBasedDance. Thank you so much for listening and for your support. You're truly a good Bayesian. Change your predictions after taking information in and if you're thinking I'll be less than amazing. Let's adjust those expectations. Let me show you how. Let's get them on a solid foundation