Good morning everyone. So, as described earlier like I will walk you through the hot star journey from EC2 to Kubernetes specifically from IPL 18 to IPL 19 ok. Myself Rakhar Joshi I am a software development engineer at hot star I do most of the infrastructure work there ok. So, a bit about context about hot star we are like number one OTT platform in India. We have content in more than 15 languages, we have live on demand content, we have sports, we have retail content and lot of other things I guess everyone has been to the website ok. So, let us deep dive into like what is the number we are facing and at what scale we are operating. So, during the World Cup semifinals between India and New Zealand we have seen like 25 million plus concurrency on our platform. We have seen like more than around 1 million, 1.1 million RPS on specific services not all, but specific services. We have seen like the clickstream messages that we provide the data team that works on that. We have seen like more than 10 million clickstreams during that specific time and we have like video encoding, a video trans coding for more than like 100 hours and like the content is more than 100 hours and we transcode that like every day we do these things. So, this is just scale and the like the scale at which we operate day to day life. So, just to set context like we what we will do we will go through the journey of hot star from how it started in IPL 18 and how we operated what we did and then what challenges we faced and like because of these challenges what actions we have taken and what is the state of hot star during World Cup and currently. So, I will just give you a context like what hot star was at IPL 18. I will discuss more of the infrastructure platform things on which hot star was running. So, we were running on EC2 stack. We were having ELBs which are sort of ingress for our applications. We have those ELBs attached to our auto scaling groups which scales the application as per the requirements and then we used AMIs to deploy our applications. Those AMIs were pre-backed. We were using packer to deploy these create these AMIs and deploy these applications on the EC2 machines and we were using Jenkins for CI CD pipelines and for infrastructure deployment we were using Terraform infrastructure as a code. We were not doing anything manual. We were trying to like we have stopped at that time also but again we like never ask anyone to do any manual changes because whenever the automation scripts or whenever the deployment goes on it will overwrite. So, we believe in like you should like always make changes in code. You can trace them because it is difficult to debug issues and something breaks in production because of the manual changes you have done at one place and it can affect you at other places. So, yeah that was the state of hot star at IPL 18 and we have seen like around 10.3 million concurrency that time. We might have seen more but there were challenges and there were issues that even we faced but yeah. So, those were the issues that we I have like mentioned here. We will discuss them also like what are the issues we have seen and why like we were not able to handle more than that or even if we are handling them then there was a bit of issue in user experience and all this. So, the first issue we have seen is like handling search. So, you know like when a cricket match is going on and the peak of the traffic that comes on our platform is during the IPL or World Cup like cricket matches. So, what we have seen is like it is something interesting going on within a match or something happens then what happens like you see a surge of requests coming, surge of new users coming to your platform and you have to handle them seamlessly.  We have seen like we were not able to scale as much as we want to scale during the scale during the surge that we get but so EC2 takes some time to boot up like if you have an application which is running on your EC2 machines you have to let's say you have to scale from just an example 22 and you need 30 machines. So, if you spin up 10 machines at a time it takes some time and it is just one service. We have like around I don't know the count but more than 40 repair services which are running and you have to scale everything you can't just scale one service and it will be done. So, that was one issue the first issue leads to the other one because we know like there can be surge at any time of the live event or any time. So, what we used to do we used to keep like the buffer of the resources like okay like if this much surge comes and we will handle it. We have these resources there. So, what we used to keep is like we used to keep some extra buffer with our infrastructure which is not good like at the scale that you are running like if you are running serving 21 million and currency and still you are keeping some buffer okay okay it can reach higher then it's difficult as it can reach to the hardware problems also you might see we have seen like capacity issues at AWS also specific instance that in that region in that is not available. So, these type of issues we have seen another thing we have seen is like when you scale up these much EC2 machines the EC2 itself calls the AWS API internally. We have seen like throttling of those APIs which is EC2 internally calls to AWS and we have seen like we were getting throttled on that which lead to which lead us to not scale at a time but we have to do the step scaling. We can't scale like let's say the let's say we decided okay we are running on a 20 million concurrency platform and we want to go to 25 million and we have to do like scale up 50 instances at a time. So, for one service if it's 50 then it can be more than 200 300 instances at a time across the platform. So, there are account level rate limiting and all this internal things that AWS does. So, those issues also we have faced. So, these were the challenges that we were facing and we were trying to like overcome these things during the live events. So, that was one part then we decided like okay whatever patch or whatever logic we are putting behind it there is something we are missing and if we go if you want to like break more records if you want to like double the concurrency or if you want to like make our platform more faster we have to think something else. So, we started exploring like how what other platforms we can use for Hotstar. So, we started exploring containers we started exploring how to orchestrate those containers and how to run those containers and manage them. So, like couple of things we have like found plus points in that and those are like containers you can run anywhere like for easy to like if your application is there then you need a local setup and everything container like if you create a just an example let's say we are using Docker. So, if you create like your 10 applications your 10 Docker file you create one Docker compose and you can spin up the whole infrastructure anywhere. So, these type of things local deployment become fast you can you don't have to like depend on one cloud provider all these things were positive there to boot up containers it's quite easy like as compared to EC2. So, as compared to EC2 it's quite easy to spin up a new container let's say you are running with 10 containers you 115 it's quite easy as compared to EC2. The resources are optimized because what happened earlier we used to have the whole EC2 machine for one application. Let's say my JVM is running it requires 2.5 cores and it requires let's say some amount of memory and lowest CPU that I am getting as a hardware is 3 core or 4 core I have to take 4 core I can't deal with 2 core machine. So, these some so these type of things we have realized like at scale it bites you like you can't just throw away like 1.5 core or 2 cores of instance because you can't take the last one because this is not available. So, with Docker you can or with containers you can specify whatever the resource your application wants what memory they want. So, as the boot up is easy for the container it becomes seamless for like we can scale it to any number whatever you want. There are challenges it's not like you can just keep the throw the number and it will scale to that but it's as compared to EC2 it's like seamless for us. Let's go to production time because what we have seen like we have created base container on top of that their application gets deployed. So, the whole deployment procedure has been extended. Earlier it was like some applications are deploying on their own way. Some are using different instance book some are performing some different instance book differently. So, these type of like mismatching across the organization has been reduced. And now as a devolved guy I know as infrastructure guy I know like what's the platform for any application if I have to debug any production thing of any application earlier I used to switch context. Okay, this application these type of setup are there in their production then I have to debug. So, these type of things have been improved. So, as I talk like Docker we have decided we will go to the container but how to orchestrate them. So, Kubernetes is the best fit for us we have found in present like what we can use to use we can use for handling our infrastructure. We have this because of Kubernetes we have like standardized deployments across what stuff because the way now application deploys is like you just give me the your application name some context about their application what resource you want what you want what's your image Docker image is all these things you just give me I'll deploy everything on the cloud for you. So, it's standardized nothing is manual there like some tags are required some tags are missing some parameters are not there some parameters are there. So, these type of things have like gone away from what's one clip deployment because we as we have standardized the deployment. So, now we have a separate flow for deploying your applications you can just write we use Casan net for creating the your JSON JSON objects to Kubernetes object to convert into ML and then apply it on the cluster. So, these type of things are helped us and also the developers like they don't have to think much about like how these things will gonna happen like how my alerts will be set how where my logs will go all these things are like out of the box provided to them because we have basic measures which do all these things logging and alerting has been improved because earlier what used to happen some applications are debug logging debug log some are just logging error log some are logging some different log it has been standardized every application can give their own information like what type of logging you want and why it like if I'm an infrastructure guy I should know like why some some guy is logging debug logs if it's not required because at the end of the day I have to manage the logs. So, these type of things were there. So, we can like at a single place I know like what's going on across the organization for and we use go CD for CI CD go CD is again deployed on Kubernetes cluster itself and it's a like this is the best fit for we have found for us but all of apart from all of this the best thing we have found is like request best scaling for our application. So, in EC2 world what used to happen is like we used to get the concurrency okay our platform is running on some x amount of concurrency. So, we have to scale for 2x or 1.5x. So, there is some manual things we have to do we have written scripts and everything but again like you never know when you will have to go to 1.5x or 2x. So, these type of things we used to do manually we have to manually trigger the scripts and perform the scaling and we have to manually check all these things.  The application spin up the containers on its own based on the horizontal part scaling that Kubernetes provide and we are using the metrics that we get from Prometheus for request that an application is getting. So, these type of combinations we have done and this request basis just made our life easier for us because now during the live event like earlier there used to be some person or someone is responsible for scaling the Hotstar. Now, it's like it will scale on its own. So, you don't have to worry about okay something interesting going on we have to scale the platform otherwise latencies will increase some errors will so on. So, all these things have been reduced. So far so good but again like if you talk at the level of Hotstar where you have more than 50 services, 40 references just thinking of migration and doing the migration is another different story. So, like introducing a new thing in an organization like for a team is okay but if you are have to introduce it for an organization level there are a lot of challenges you have to face like we have to dockerize the application. So, there are a couple of ways to dockerize the application tell the developers okay we will give you a sample docker file you can use this and create your own docker files that is one way. Another way is like we give them the base docker images they can on top of that they can build their applications and they can process again like what image which we should give like at organization when you have like more than 40 50 teams then you have to cover all the edge cases and you don't want to make your single docker image that huge k at the time of scale. It has to download that image in a node and it is taking like GBs to download that does the base image and then it will do this. So, these type of issues we have faced we have improved those things. So, these are the this is one issue we have faced another issue is earlier applications are running on single EC2 machine whatever CPU they want whatever memory they want they were getting now we have reduced it because we have seen like we were giving more than what is required for an application let's say a JVM is running we were providing four cores and four GP but we have realized like it can work on 2.5 cores or 3 cores and 2.5 or 3 GB something like that. So, why waste one core and one extra GB at scale when you are running like thousand containers for an application you are like just wasting the hardware that CPU. So, again when we reduce it we have to make sure like everything is working as well and it should have improved. So, these application performance we have to check for all the application from scratch. So, it was like your application is the first time it is going to production it is as same as the first time it is going to production again the third thing was cost optimization like we have reduced this is not like we have reduced like crazy amount of cost but the features that we are getting against the cost that we are paying is really like improved for us and the way we scale our applications now the way we do the performance tuning for our application has become good for us. The fourth thing was like I as I said like the autopilot mode or the request based scaling like or at what number each application has to scale you have to give that number to the Kubernetes or HP object like at some amount like if you are getting 10,000 request then scale if you are getting 5,000 request then scale. So, finding that number is difficult for us because right now it looks easy ok scale for 10,000 but why 10,000 why not some other number why can't it handle more request or why it is handling 10k why it was running on 5k earlier. So, all these findings are like the challenges we have to face and we have like worked on those things the other thing was like the cluster management we manage our own cluster in of cluster management we do. So, as we said like when we scale these things right.  So, whatever extra infra components that you are running the DNS that we are running in that cluster all these things we have to make sure like they are running properly. So, after that like once we started migrating these things we made sure like the how we are making the platform ready for the live events or the big day where we see a lot of crazy traffic on our platform. So, we did the load testing of the applications we have like load generator and all these things I think Gaurav will be talking about how we test our applications for and make our applications prepare for live events. We have like during the game day preparation we have realized like whatever the scaling parameters we have given like either they are not tuned up we have to like we can tune them more properly so that at load or at peak we are not just throwing resources to them. The other thing was capacity allocation like even though you are moving away from EC2 but your nodes are again like some hardware. So, that you have to scale. If you are running to 200 or 500 nodes then you need 500 EC2 instances there or 500 hardware there which can provide you the CPUs and memory and handle the your containers. So, that allocation we have to we have also worked on that. Again, as I mentioned like the horizontal scaling of input resources because and if your application is not scaling then it will affect your one part of the application or one part of hot star or one part of platform but if your intra context are not intra resources are not scaling then it can affect at a cluster level or an organization level. Let us say your Prometheus is not scaling then you will not get any metric. You are not if you are not getting any metric your applications are not able to scale because they do not know what is the current request your applications are getting. So, these type of things we kept in mind and we prepare and we focus on these elements as we move towards the IPL and that was the state of hot star at IPL. We were using OCD for CICD pipelines we were using Balton control for secret management like on runtime at runtime we inject those secrets for the Docker containers for the applications inside the containers when they spill off. We were using Terraform earlier we used Terraform we love Terraform. So, we use Terraform for infra deployments. We are doing in-house cluster management as I mentioned like all the core components of infra like the networking inside the cluster Prometheus logging, alerting monitoring everything we do in-house like the cluster management we do on our own. The major thing we have achieved is like the autopilot mode for scaling our applications and that was like a huge win for us because as an infrastructure guy or as a DevOps person you know like when you have to be there during some events and you have you are responsible for scaling your applications and it becomes difficult like one time job is okay twice it's okay but IPL runs for 60 days and then World Cup comes it will run for another 45 days. So, it's not possible at human level K you can do these things at one point of time you will get frustrated and things go away. So, that is the big thing we have achieved during the migration. So, this is a bit of comparison that we think like we have done for migrating to EC2 to KITS. One more thing is like it's not like EC2s were bad or KITS is some next level thing there are issues in Kubernetes also there were issues in EC2 also but whatever the requirements and whatever the use cases we had EC2s were not getting fit for us it was more easier for us to move our applications and run our applications on Kubernetes as compared to EC2. So, one main thing you know like earlier the patching of infra components were difficult like let's say logging there is some let's say we were using some component in logging and there is a security issue in that component. Now each application has its own way of logging like the component they are using is same but they install on each EC2 machine. So, every packer thing you have to go and you have to change. So, that was the setup idea but what happens now everything is in our based Docker images whenever we have to patch anything we can just patch the Docker image we can update the tag and we can use those tags in the application when the application gets deployed. So, devs doesn't have to care much about that like why we are changing this or we are telling them we are creating tickets for them okay update this version because these are security issues. So, these type of things have reduced a lot and it's really speeds up the deployment and functioning of an at an organization level. So, another thing was like I'm again focusing on the autopilot mode because we know the pain that we have faced in high pill 18 during Asia Cup all these things like how difficult it is to be there and because it's a manual thing right you miss for two minutes or one minute or even seconds if you miss K you have to give a scale up call or you have to run the script to scale it up if you don't do this your user experience will become bad. So, it can impact at a global level. So, those are like critical components but we were doing it. So, yeah, those were like differences major differences we have seen another thing was like scaling for for the traffic and the for the pattern that we receive scaling containers is quite easy for us as compared to easy to the challenges we have already discussed. So, this is like a summary for whatever we have done in the last one and a half year like we are scaling applications based on the request base model whatever request each application is getting they are scaling on its own. You don't have to like people that are all these things like how many back ends you need for that concurrency how many back ends you need for that concurrency all these things have been gone away scaling is better in k it is as compared to easy to as we have to keep the buffer of resources we were wasting a lot of resources there the cost issue was there the hardware problem was there even we have to talk to AWS before right now also we have to talk to cloud providers before this but again like it has reduced a lot earlier we were like if we don't get a resource the application scale or we have to compromise with the node type or something like that. So, these were there then again like we have standardized the deployments and it's really like it looks like it's a okay thing it should be there but believe me like when you start your organization and like you have like 50 60 teams growing together it's difficult to keep the track of all the team. So making this standardized after the way it was earlier it was a huge success for us and again like once the deployment and everything is standardized it was easier for us to bring any application to production it takes less than a day now to set up all the applications from scratch once they have their application ready we can create Docker and yeah, thank you. Yeah, I think that's all from my side my you guys can follow me or catch up me on Twitter this is my Twitter handler and you can also connect on the email the official email address and you guys should visit to tech dot dot star dot com and see the blogs that we are writing. Thanks, Parker. Questions? Yeah, I have a question. So you spoke about your moving from EC2 to K it's that's Kubernetes open source containers. Was this like you know moving away from Amazon because Amazon also has ECS where it has you know container service and it also has really good integration with Terraform where it's I think much simpler than using k it's with Terraform. Yeah, so first of all it was not regarding any cloud provider or anything it was just the pain that we were getting because of the requirements we are getting the easiest thing that you have mentioned we have tried ECS also but the use cases and customization that we need at cluster level were not available at the time when we started migrating to ECS. So it was like you don't have that much control on the cluster level the way we want to tune our application the way we want to tune our things the way we want to tune our master nodes to give us some value or some things that were not available at ECS like you can't handle that much on its own. So then we decided like let's move away from like the service that is providing the master and coupon ECS for us but let's do it in-house. So yeah, that was the major reason for us to migrate to in-house cluster management as compared to the cloud providers that we are still on like AWS only. It's not like we are moved away because our nodes are still there. It's just that the management of the nodes management of the master node, the DNS of the cluster these things we handle. So instead of getting it from some third party things we are handle. Yeah, thank you. Hello. Yeah. So I think he partly covered what I wanted to ask whether you really moved from AWS to something else or so which way your talk was clearly about EC2 versus Kubernetes. You compared EC2 and Kubernetes in a way it is kind of confusing because you are ultimately using EC2 only at the back. You're just managing EC2 by using Kubernetes. No, no. So let me make this clear like I'm not comparing any two products here. I was saying like the way we faced issues in one platform and how the other platform helped us fighting those issues and making our life easier as a infrastructure guy or at an organization level how the other platform helped us more as compared to it. I'm not saying like everyone or like EC2 should be EC2 is bad or something is good or you should migrate to that. It's not like that. The use cases that we had we were facing issues and we have seen like in live events like we are not able to do it as per the expectations that we had. So that's why we moved again in K it is also we use nodes, right? The nodes that are running on EC2 itself, but the way just give an instance. I'll give an instance. So let's say you have 10 you have 10 applications, right? So earlier each application each process of your application is running on a single EC2 machine. That was the architecture or infrastructure that we had. So each application is using in situ instances. So we were wasting a lot of resources and everything. So scaling and all these things become difficult. I'm not saying that Kubernetes is just but click and over the night you can scale to whatever even at 25 million we had our own challenges. We had issues. We have to scale nodes also. So all these things were there, but they have reduced a lot so that we can focus more on our core intra components as compared to these issues like okay, we are not able to scale our platform. Instead of that we should work on making our Prometheus more better, making our logging more better, making other products more better. So we get time now to work on these so that's what like I think that's what I want to continue. Quick question. We have half a minute. Is it working here in the meantime? Okay. Sorry. My question is you mentioned Prometheus, but what do you guys use for centralized logging, alerting, monitoring and stuff like that? What tools do you use and you haven't even mentioned CDNs.   We'll start with the next session and yeah, we can take it off. Thank you very much. Thanks, Prakar.


Hi, I'm Zor. Welcome to Unizor Education. Continue talking about theory of probabilities and in particular it's a little bit more formal description using the set theory and the theory of measure. I would like to remind just very, very briefly the analogy which we have established before. What we have done, we have made the comparison between the sample space of the random experiment, which is basically all the results, all the outcomes of this experiment, all the elementary events basically, with certain set, with every elementary event being an element of this set. Now, every random event, which is basically a combination of certain elementary events, in this case would be a subset of this set and we are considering a situation when all the elementary events are, they have equal chance to occur, which means that the concept of a probability can be actually interpreted as a measure, an additive measure, established on every element. So if we have n elements, then each element has a measure of 1 over n and it's additive in the sense that whenever we have any subset which contains certain number of elements, the measure of that subset is basically a sum of these elements and if there are m elements which are in the subset, then the probability or a measure allocated to this subset is m over n. So the probability is an additive measure and this is basically our model. We are using this language actually to translate something which is a little bit intuitive, like probability and events, random events, etc. We translated it into a little bit more formal language of the mathematics, which is using concepts of sets, elements of the sets, subsets and the additive measure. This is methodization, if you wish, of more intuitive concepts of the theory of probabilities. Now, I will actually move it further because I would like to introduce the continuation of this modeling, of this equivalency and right now I'm going to address the logical operations on the events. For instance, we would like to know not just event A or event B, but something like what's the probability of event A or B, something like this. So we have a logical operations. Now, the operations I'm going to consider are OR and NOT. So what's the probability of NOT having something or what's the probability of having something and something else? So these are three major topics which I would like to address right now. All right, so let's start with an operation OR. So we know this equivalency, all this modeling with the set theory and let's consider a concrete example. Now, the one which I have here is the following. Let's consider the game of craps and we would like to know the probability of having 7 or 11 on two dice. So again, let's go to the probabilistic side of it. Now, what are the elementary events? What's our sample space? Well, it's basically all the different results of rolling two dice, right? So if we would like to get 7, then the dice number 1 and this is dice number 2. What we can have is 1, 6, 2, 5, 3, 4, 4, 3, 5, 2 and 6, 1. So we have 6 different pairs, right? Now, if we would like to know what are the pairs which result in 11, then it's actually, I put it here, 5, 6 or 6, 5, right? So this is my result for 11 and we have two pairs. So altogether, we count all the different pairs of two dice which result in something which we would like to consider as our good positive event, 7 or 11. Well, there are 6 and 2, there are 8 pairs out of how many? Well, if each dice has 6 different results, then two dice have 6 by 6 which is 36 and that's what makes our probability to be equal to 8 over 36. 6 plus 2 is 8 over 36 which is 2 9s. Now, I would like to address exactly the same problem from the set theory standpoint. So first of all, what I would like to do is I would like to model my sample space, right? So what is my sample space in mathematical viewpoint? Well, obviously the easiest way to represent this sample space is as a set of all pairs where the first and the second are integer numbers from 1 to 6. So it's like 1 6 or 2 2 or 3 5 etc. etc. So there are obviously 36 pairs. That represents my set which is a model of a sampling space of my random experiment. All right now, what we are interested right now is to get 7 or 11. So let's consider these two events separately. So I'm considering this positive result of rolling a couple of dice when the sum of 2 is equal to 7 or 11 as two individual events 7, 11 and conditional between them is or. So what's the a subset of this set which represents 7? This subset contains 1 6 pair, 2 5 pair, 3 4 pair, 4 3 pair, 5 2 pair and 6 1 pair. So this is a subset of this set. Okay now the sum equals to 11 is another subset 6 5 and 5 6. These are two subsets of my set. Now obviously the operation of union which is an operation of the set theory we know how it operates. In these two cases what is the union? Well the union is obviously all these and all these all together eight different pairs out of 36 which makes the probability equals to 836 because each pair has a measure of 1 over 36 right? Each pair has a measure of 1 over 36. So eight pairs, eight different pairs have the probability of 836. So it's exactly the same probability obviously it's the same. What I would like to point out is our modeling our mapping if you wish of logical operation on the events the purely probabilistic kind of a standpoint and mathematical operation of union on two subsets of certain set. So all we have to do is properly model our random experiment with its sample space into this set of pairs with numbers integer numbers for 1 to 6 each. Then our event 7 on the top on the sum of two dice is mapped into this subset of this set. Now event that the two dice result in 11 if you sum them up it maps into this subset of this set and so the whole operation the whole result of the operation of operation or getting on the top of two dice 7 or 11 is mapped into a union of each individual subset. So the or logical or between events corresponds to union between subsets which represent these events. Well this is a little bit easier case because these are all completely different pairs. What if these two models these two subsets have something common set have some common elements. Here is another example where everything works as well. So consider you have one dice and you are interested in divisible by two or three result. So same thing if you have one dice its model in the set theory is obviously a set of numbers from 1 to 6 integer numbers obviously right. So we have six different elements in this set they represent our sample space of the experiment. Now the logical operation two or three well let's do it separately. What is the model of the event divisible by two? Well that's two four and six subset of our set of six elements it's three elements. Now what is the model of the event divisible by three? Well it's three and six. Now divisible by two or three well let's get again back to the probability kind of case. What are the elementary events? Well out of the elementary events which we have divisible by two or three we have to cross out this and cross out this. Everything else is divisible either by two or by three right. So one two three four. So we have four different elements we have four different elementary events which satisfy this condition and so the probability should be four six right which is two third. That's how it should be from the probabilistic standpoint. Now let's address it from the measure theory. Now we know that probability of this guy is equal to one half right three out of six so it's three six. Probability of this is one third. We cannot add them up as we did in the previous case right. In the previous case we just added up two numbers number of combinations pairs which resulted in seven and then combinations which resulted in 11. They were all different so we just add it. We cannot add this because there is a common element six. However again if we will apply a correct operation of union back to the union between these two sets. So what's the union of two four six and three six. Well the union is all elements which belong to either this or this two three four and six. This is a correct union between these two. Six is supposed to be only ones in the result and that's why we have a correct probability of four out of six because the number of elements in the union of these two is four. Although the sum of elements three and two is five actually but that's completely irrelevant in this particular case. Again the operation or logical operation or on events is supposed to be mapped into the union between the subsets which represent these events from the theory from the set theory standpoint. Alright now let's move further. We have a next condition is end. I mean probably by now you understand that everything is mapped quite well into the operations on set theory. So the end operation should be mapped to intersection. Right now let's give an example. Let's consider you would like to again roll the dice and you are interested in the event that it's divisible by two and three. So the previous example was or now I'm talking about end. So what's divisible by two and three. Well out of all these elementary events divisible by two and three is only six. Right so we're supposed to get one six. Well let's just consider from the set theory standpoint. Divisible by two. Again we are using the same set of six numbers as our set. Numbers from one to six. Every number is an element obviously and we are talking about subsets. Divisible by two is a subset two four six. Divisible by three is a subset three six. And what's the intersection between these two? Well the common element is only one which is six. So the intersection is equal to one and only one element which is six exactly the same as in this case. And the last operation I wanted to consider is operation not. And obviously you understand that the operation not should be mapped to a complement which is a set difference or minus with a subset. Now what's the example? Example for instance not divisible by three. Okay so what's not divisible by three if you are rolling the dice? Again these are divisible by three. So that's what's left. One two four and five. Well let's consider the mapping of this onto the set of six numbers. And obviously I'm talking about the event divisible by three and divisible by three is a subset three and six. And what's the complement of this? Well the complement is a total set without three and six. So what's left? Exactly the same thing is here. So my not operation on the random events is modeled as a complement to a subset which is a model of the event which we are negating. All right so my main point actually of this entire lecture is that all our intuitive understanding of the theory of probabilities can very well be represented using the language of theory of the set theory and the measured theory. And there are a couple of requirements obviously. So the measure is supposed to be additive. The measure of every element of the set and we are talking about only finite case as you remember. The measure of each element in the previous lectures we were introducing the equal chances or not equal chances. So equal measure of the elements or not equal doesn't really matter as long as every subset of the set is measured as a sum of measures of all the elements which comprise this particular subset. And another requirement is that the measure of the entire set is supposed to be equal to one because that's kind of a probabilistic approach we have to model the frequency right. So the frequency of an entire results of all the different results from the random experiment the frequency of occurring is basically one obviously because it's always something which occurs. So these are you know few requirements but basically the whole probability theory is just a part of mathematics if you approach it from the set theory and measure theory standpoint with a couple of requirements to make this theory of probability a particular case of set theory and measure theory. So both these concepts the concept of a set and the concept of an additive measure applied to this theory basically gives you a complete picture of the theory of probability. And that's why the theory of probability is a mathematical theory it's not just some kind of you know half intuitive half precise half analogical and half eulogical and have some guessing and predictions and stuff like this all these concepts are much less mathematical than the set theory and the measure theory. So that was my point to show you that this is actually a precise and mathematical subject if approached from this particular way. I recommend you to read the concepts which I'm talking about today on theunisor.com there are notes to this particular lecture so if you read it again it might actually better provide you better understanding of this mathematical concept mathematical approach to theory of probabilities. Well that's it for today thank you very much and good luck!


Welcome to JSA TV and JSA Podcast, the newsroom for telecom and data center professionals. I'm Candice Sipos from JSA, coming to you from Virtual PTC 2021. Joining me today is Mike Janes, SVP of Business Development at DirectLine. Mike, welcome to JSA TV. Thank you very much. I'm happy to be here. Excellent. We're happy you're here. First of all, let's just set the stage with a quick question about DirectLine. Could you just let our viewers know a little bit about DirectLine, what you all do, and who you serve? Yeah, absolutely. We're coming up on our 25th year anniversary. We've been in the telecom industry this whole time. Specifically, we work in the data center space. We work with many cloud companies and a lot of the vendors and manufacturers that build out the infrastructure for telecommunications. We're in APAC, we're in the US and Europe, and we're continuing expanding with some of the household names that we're all using now with COVID. Our industry is booming and we're continuing to grow with it and trying to expand and just keep up with the market. Our core competency is building out the physical infrastructure for the data center space. Excellent. Perfect. Thank you so much. DirectLine is sponsoring Virtual PTC this year. What's your main takeaway, your main message that you want to get across to the PTC audience? For us, PTC is a place where we find all the experts in the industry, from the land developers, to the data center owners, to the large carriers all in one place. It's a great venue. It allows a company like ours that would not necessarily have access to that group in a short amount of time. PTC, to have those thought leaders of the industry in one place and to be just in the audience is something very valuable to me and our company, but also the accessibility to a lot of these thought leaders is unique to this event. Now this year it's virtual but I still feel like that audience and that participation across all those layers is still wide open. For us, it's just been an invaluable event every year. This is our third year. This one's virtual, but we're very excited to continue with this new normal for however long it takes. Excellent. Great. You're officially celebrating your 10-year mark with DirectLine. You've been with the company since 2011. How have you seen the company evolve over the past decade? Lately, I think this is the obvious answer most people might give is just with COVID-19, people working from home, the amount of data being pushed through even this phone that I'm talking to you on, it's just 10 years ago, it didn't even seem possible. 12 years ago, I think I had a BlackBerry and it didn't have video, so the amount of infrastructure is mind boggling to me that these carriers and the large cloud providers have put in place through the different countries. If you go and look at just the intercontinental cabling that's been done, to me, that feeds directly to what we're doing right now. I don't know that the country that I'm in or the countries around the world could manage this situation without this type of infrastructure in place, and hats off to all the guys and gals that write code for this. Everybody that's the brains behind all this, because to me, this is like I'm watching Star Trek, if I want to date myself a little, that we're talking on video and then you're able to publish this. I think that's the biggest change in the industry is the ability for all this equipment and infrastructure to be put in place, and now to allow us to communicate better, and that communication is invaluable, whether it's 5G, whether I'm able to talk to my daughter remotely on a trip, and that's the biggest change in the industry. It's just made our lives a lot easier. I already thought the world was pretty simple, but this has really brought down barriers and allowed access, I think, to everybody to technology. Again, the thought leaders at this conference are making that happen. They're looking ahead. Sometimes we get stuck in our company where we're looking two or three years ahead. I feel like this event allows us to look 10 years ahead, and that's kind of what we're. 10 years ago at PTC, I'd be interested to see what they were talking about, because I bet it could have been something like what we're doing today. But yeah, the industry's changed a lot, but the world has changed a lot and it's kept up with it amazingly. Absolutely, so well said. And so what are the most common missteps that you see enterprises and data center operators taking when it comes to data center safety and quality? So safety and quality, it sounds a little trite, that it's important, but it is extremely important. And I think some of the mistakes on a high level is that you don't take it seriously. And when I say take it seriously, it's as simple as somebody wearing safety goggles in an environment where there really is no sharp tools, there's nothing that you would think could go wrong.  The obvious stuff I think as human beings we're aware of, we're not gonna jump into a burning building, but you do really have to take it seriously right down to those details. And in the data center space, there is a lot of electrical equipment, there's a lot of heating and cooling equipment going on. And you do at some point in our industry when you're in the infrastructure build phase, there's a lot of bodies moving back and forth. And I think the biggest misstep is just not taking the simple things seriously. It's almost like when you tell your children not to run with scissors, you almost have to tell adults, don't run with those scissors. And there is very, very well run safety protocol in the industry and you just have to manage it. For direct line, we've created a whole division around safety. We've created VPs and directors and managers that report up as a company overhead cost. We're not trying to recoup that cost. We just see it as the new normal and it's something all companies need to be very, very aware of and take it extremely seriously. And I would think the biggest misstep is just high level, not doing whatever you think you're doing constantly improve on it. And that's a never ending process. Absolutely. So let's end here with a trends question. So what trends are you seeing lately regarding cloud for data centers? A lot of what we do, we work with a lot of major manufacturers like Corning. And what we're seeing is a lot of cooling advancements on how to cool equipment with large manufacturers that sell equipment. We're seeing the cost of fiber optics going down but also the amount of single mode fiber in the industry is kind of outpaced even 10 years ago what we would consider connectivity for a data center. Very little copper, a lot less what I'll say is a multi mode fiber. And the optics on the equipment is catching up with the ability of the speed of light basically on a single mode cable, which is why we can do the things we do which is download a video and watch it live in your car while you're driving wherever you're driving wherever your kids are driving, not the driver. And I think for us, I think the ability to get a lot more physical infrastructure in a smaller space. And we work with a lot of the leading cloud providers and also a lot of the social networking firms. And I just know firsthand that the amount of space and cooling needed to what they put in this space a lot today is a lot less. I mean, it's remarkably less. And even though we're advancing and continuing to grow, I think the industry is getting smarter and smarter on how to do a lot more in a lot smaller space which is allowing us, again, like I mentioned earlier to do a lot of throughput through the small, through my phone up to a satellite back to your audience. And it couldn't happen any other way. And the industry is just, as it always has been, it seems to be one step above ahead of everybody else. Excellent, what a great way to wrap it up. So where can viewers who are interested in learning more about DirectLine? Where can they go to learn more? No, we have a booth at PTC. So that's one way to go. And I think that's probably the easiest way. There's also, you can go to our website, which is dlglobal.com. And our contact information is again on the attendee list at PTC. That's probably the easiest way. And we would love to talk to anybody just about the industry and just get smarter ourselves and share ideas. Excellent, okay, great. Well, you heard it here, dlglobal.com. Definitely check that out. And thank you so much, Mike, for your time. Thank you, we appreciate it. Really, and thank you viewers for tuning in to JSA TV and JSA Podcasts. Happy networking.


Okay. We began. Welcome, everyone. It is the resumption of our cohort. Update the video description. It's the resumption of cohort one of the active inference textbook group. It's our fourth. Okay. Could someone mute Giuseppe or feel free to say whatever you want to say. Can you hear me? Yes. Yes. Okay. So, sorry, but I'm completely new to this interface of a gather and code. So, I'm not sure I understand cohort one and cohort two here. Yes. So, because cohort one was the, wasn't it the previous one, like the one that started last year? Yes. Well. From May till July, we did chapters one through five. Okay. And now we are in this cohort. So, if those who did not participate in this part, like respectfully, you know, thanks for the question, but everyone in general respectfully let's try to have people who are in the cohort participate in it. Everyone's welcome to join and of course rewatch. But contributions and the questions and the chat are probably best so that we can respect the people who are continuing on. This is our 14th meeting. And now we're heading into the second five chapters of the book. Okay. Does any other person want to give classes?  So, the current one that is going on right now is the cohort one and not cohort two. We're all learning in different stages. So, the previous hour was the cohort that is focusing on chapters one through five. Okay. And now some of us a different set of people, some are joining both. So that's why we made the meetings convenient was so that we could like for many of us who wanted to both we can join or there's but this is a separate set of people. I see. I see. Yes. So, okay. So cohort two was was first and then I mean the right in this meeting in this meeting right now cohort two was first. Yes. And now is one which started. Correct. Before we warmed up the chapters one through five. Okay, so I will leave because I subscribe for cohort two. So excellent. Okay. Good. Thank you so much. See you next time. Thanks for setting up all these. Yeah. Okay. Bye. Bye. Yes. Awesome. Okay. Anyone else want to add anything? We don't need to do a code overview. I would say people who are watching this recording can look at the live recording if they want a code update that we just went through for the cohort twos live meetings. But does anyone want to give any introductory thoughts otherwise there's a few ways I think we can go for this session. But we're here just to rejoin our activities and orient towards chapters six or 10. We can scan through the chapters. We can have any suggestions or discussions around ways to approach them. I don't know. Rohan and then anyone else. I was wondering when are we going to get to the projects part or discussions about the projects. Great question. Let's look at the chapters and see where that first off it can happen. Whatever you want with contacting people and like we can make a sub page like I see exists here this looks really awesome. So people can request a sub page they can mention it that contact them now or however. So it's up to you for a project that is under your control. It can be developed in the open here or however. You can also participate in many ongoing projects like active block fronts which also which might all share this. Our get coin grant was approved yesterday. So if people are familiar with this or want to become familiar this is a way to like provide or receive support possibly. So you can get these projects in block fronts and contributing to that open source package. Does that address what you were thinking were you thinking about these project ideas or were you thinking more about like the sort of build your own model approach that will be starting in chapter six. No project ideas and the code. Awesome. Yeah, like these are. These types of projects clearly more will be added. But they're of difference. They're not necessary. They might involve building a generative model, but they are not the generative model itself or only. Let's look at chapter six. Because this is where the generative model construction is going to come into play. And there's a lot of projects that you would only need to qualitatively think about generative models for like educational material production is related to the generative model or could be modeled as the generative model of a learner. But you wouldn't necessarily have to make a generative model but in chapter six. It's a recipe for designing active inference models. It is going to rock. Just really quick. I think Luke is here. No, it doesn't have access. He asked for access. Okay. Okay. Message in discord. I mean, message and gather your email address and I'll add you. Okay. So, sorry, didn't. Okay. You requested access. All right. I'll add you. That's enough then. In chapter six, it's going to ask some questions that are driving the design of the generative model. Which system are we modeling system of interest. What is the appropriate form for the generative model. And also all these other questions that aren't exactly within the textbook, like temporal depth, hierarchical nesting, which parameters are learned versus fixed, all these different directions that the models actually have to be elaborated on, even before getting to the data engineering and maybe even code implementation. Just from a structural perspective, what form is it. How to set up the generative model is where some of those analytical details begin being introduced. Not necessarily even the program level implementation or an executable simulation. But like, okay, we have a preference vector that's, is that, is there two states are, is there some continuous preference distribution, whatever it is. What is the actual details of the generative model. And then the other side of the coin slash blanket is the generative process. So what are the endogenous dynamics and the causal mapping with action for the generative process. And there's kind of cases where you have more of a communication setting active inference entities on both sides. You could also have more of like a simple, simple partnering, like two deterministic programs that send messages to each other, or it could be like one more cognitive, more agent like generative model, and one more environmental nonliving type. Any thoughts or overviews or how would people think about how can we make this type of a recipe design, should we be all designing a model, or how do we even go about reading a section of the book in a chapter that begins with a recipe provision. Yeah, so, so I spent a lot of time building what I think would be classed here as generative models and what I find is that this, what I characterize it as the step of framing it up framing up is, is often far trickier, sometimes much harder, frankly, than building a model, depending on what, what the situation is. And in my experience, I find that it all comes down to making sure we understand what is the question that we're trying to answer, right? It's sort of like, because, because every modeling process, I'm sure everybody on this call knows, is the process of deciding what to leave out, right? What to put in, what to leave out, and what level of representation. Then it all has, where everything that's in there, if it's going to be a good model has to be necessary and necessary to answer a question or provide a particular insight, or so forth. So that whole issue of framing out what you're going to build, you know, and in all those different to 10,000 questions, you know, there's more than four, you know, ultimately, many. Then it's all about that, which often means understanding the audience. If, if the model builder is the only audience, this is a much simpler. If the audience is, you know, some much larger group with different perspectives, a lack of, of homogeneity and insight. Then there almost has to be, I'm going to say almost a pre-modeling or framing process of sort of framing up what are the questions we care about. And then we can talk about how, how those translate into a model. So that's just some general framing. Thank you. That's very interesting. It makes me think about like this audience question for the model, like, why are we building the model? Why are we shaping our regime of attention to build this model? Model building can be an end of itself. It can be creative and expressive and fun and all these other things. And maybe later there's a road that has some pragmatic value too, but also it can just be like fun, like, you know, what would a generative model that could do this look like. And that can be very didactic. There's other times where you're presenting information. Oh, I made a simulation of Twitter discourse and dot, dot, dot. It's always going to be presented in a way that's not only just like the model distilling down from the world, but then you're communicating it. And then when you're actually not just communicating, but if you're making an application that does something and communication is doing something as well, then the system of interest, as Lyle mentioned, is totally non trivial. And there's the whole framing in some of these early stages, especially because they can't always be changed easily later. Ron, and then anyone else? Yeah. So I'm just curious when you say who's the audience? Is it that, like, isn't this part of the active inference model itself that, okay, so whatever makes sense in that framework? Wouldn't that be the audience here? And then it has to survive, right? Your agent has to survive. So whatever a generative model helps it survive, would that not be the model of choice over here? And I'm just curious, I'm not sure. That's awesome. It's awesome, like, way to frame it. And it's maybe someone can share the free energy governance link in the chat. I just can't look it up right now, but it puts this very nicely in a recent pretty short book slash dissertation about, like, that imperative for organizations. And yes, in one sense it can be said the right generative model or like the audience for it is whatever its survivability conditions are. But, and within our textbook group, the survivability conditions are open. However, we're also learning about, or even just gesturing towards, like, okay, not just we're going to imagine a room with a person who can take on a jacket or take it off. We can make that a didactic model and the audience could be this textbook group or future cohorts of the textbook group and the function could be just sort of like a neutral exemplar active inference generative model. But then, of course, the considerations for information presentation, empirical data analysis, any kind of application. The system of interest is not just the one person with the jacket on or off two states room with assigned fluctuation. So that's a different situation for model building. So is that how should we interpret this recipe? Oh, okay. But is there not like a general framework for what a good generative model looks like is what I'm saying. Like, I guess you could frame that differently. So if you want to build pixel level representations, for example, you can use a GAN. And that's a pretty decent one, but maybe pixel level representations are not a good, not good for the task at hand or something like that. So it should fit a general category, right? So this is what a good set of models looks like for active inference so that that sort of is getting it. Yeah, that's a very fascinating framing. Does anyone want to add something to that? I totally hear you like on what is there a rubric? Like what are we evaluating the generative model and process fit? Because it's not like there's just simply a best generative model, you know, bigger or you know, whatever, no feature about it except outside of a generative process context is the fitness. And then what is the rubric is our gold standard? Is it like, oh, you're dealing with audio data. Here's the file format. That level of standardization certainly not. However, are there some practices or lenses that we could bring in from people's experience with evaluating model adequacy and relevancy? There probably are. Lyle? Well, yeah, that really comes right back to purpose, right? So a model always fit for purpose. And you, of course, this also surfaces the questions of model validation, right? One of the things we have a talk about here is what's the right model? How do we frame up the right model? What do we choose to put in what we leave out? Part of that is purpose. And how would I evaluate, you know, if I do what I'm imagining a model will be, how do I evaluate its quality, its validity? Well, what data is actually available? That's one thing you always have to ask at the outset. What data is available? What data can I use? What's computationally adequate? And what parts of this then when we kind of project, you know, when we apply this model, if that's its role, then does it fit for the purpose? Does it provide, you know, good, you know, adequate results and improve to be, you know, whatever behavior we're trying to address? So you can't, you can't say if it's good if you don't have a purpose. So if your purpose is just to explore model building, which is something I love to do, then that's a pretty big, there's a lot of things that fit for that purpose, right? But if the purpose is to, you know, do a prospective analysis of a system and what actions might be taken to intervene, then that's a different thing. Thanks a lot for sharing it. I'm really happy and I think it's relevant that we're having this kind of a discussion because we've gone through some of the first chapters. And we will continue through chapter six, I think into having this conversation. But does anybody else want to add something about this more general topic of like, how are we even coming to talk about what system or how are we framing the system that we're modeling? That's in section 6.3. I mean, this is too broad to, it's not active inference specific, but whenever I'm trying to model something, the only questions that I'm, I mean, it is contextual to the purpose. It entails a purpose in an audience, but all I want to know basically is what are the questions that need this model needs to like generate an answer for? What is the information that is like necessarily therefore kind of required to model a system that would have such answers in it? And maybe another way to say the same thing is like what affordances would the model require to answer or address whatever the some set of questions that are posed the system.  Then I wouldn't need to record like the number of bikes or their colors that are, you know, using the bike lane or buses or trucks, large, you know, like this is maybe outside the scope of what I mean by yellow. How many, you know, cars out of all the cars, how many are yellow or something. That's right, driving down this road or whatever. This is like not even exactly a generative model, but my point is that modeling that system there, there is obvious data that's like completely irrelevant, right? And so if you were going to build some sort of simulation of any kind that's going to be generative, like there's often a lot of data that's just completely extraneous depending on what questions you're going to ask of it. So thanks. In 6-3, in the first paragraphs, they're going to come out hard on the interface concept of Markov Blanket. This is how you'll do system modeling is by finding interfaces that distinguish the internal and external states of a system. Then that is critiqued or elaborated because there's an infinite degrees of freedom in the course screenings, and those are modular specific. And they suggest that that matters, especially if you want to be considering embodied extended perspectives where just descriptive interfacing models won't give you the whole answer. There's a great paper, could a neuroscientist understand a microprocessor showing that even if you have total access to the microprocessors firing like an EEG and a generated set of single and double lesions, a lot of the interpretations would be strongly misleading. Yet people want the wiring circuit of the brain, which is dynamic and also involves diffusive molecules. We have all 302 nematode neurons mapped, but that also as an interface diagram is not even close. So if you want to describe the nematode like model building, then it's a fit for purpose. However, there might be very simple models that could be doing a lot better in this in nematode behavior observation. The form is discussed. There are three main design choices. First, discrete and continuous time. We had some awesome discussions in the previous months about like similarities and differences, and where like in theory, they're different and then in practice, where they're different. The whole question of like discretizing continuous systems. The second choice is between shallow models and hierarchical models where inference operates at multiple time scales. The third choice is the consideration only of the present kind of the variational free energy versus models with temporal depth. Temporal depth consideration could be purely passive, and it could also include some element of affordance, which if we remember to like the B matrix, actions are influencing how states of the world are changing through time. So that is how active inference is unifying policy comparison by kind of embedding action into estimates of how things could evolve probabilistically. Those three design decisions are explored in slightly more detail in the subsections. Six five, how to set up the generative model. After specification, then the specific variables have to be included. Okay, the latent state temperature is going to be continuous. The observations in my thermometer, I'm going to take in as just integers. And then there's going to be a person who is going to be in a binary state of like whether it's hot or cold, or maybe I want hot neutral cold, or maybe I want them to have a 10 point scale, or I want them to have a scale that's doing dot dot dot. That is in this stage of actually setting up the generative model and giving a little bit of like color to what had been just outlined. It's going to be a nested model with this continuous variable and this kind of a discrete variable. Here we return to the frog example from earlier in the book, where there's like, but it's kind of being generalized a little bit. It was introduced with the whole Bayesian equation walkthrough. Now we're returning to it and thinking more about multimodal, or like even you could consider this as sensor fusion, because there's some hidden cause. The jumping or the action of a frog that is inducing several domains of impact, potentially in the generative process. And then that leads to specific observables from the perspective of the cognitive entity. Those could be again two communicative cognitive entities or one and not or however. So this is like, okay, we're going to be modeling forest fires. So forest fires, they change the temperature, they change the chemical composition, they change the vibrations in the ground or something. Okay, and then maybe there's three sensors, maybe you have three thermometers, and then what about them? Are you going to average them? Are they going to be like three parallel modeled time series? That is where some more specification of the generative model comes into play, keeping the active inference ontology in mind. What are the affordances of the frog? What are the latent states that are being changing through time, like sound, physical presence or photon emission or something? And then what are the data that would be the observations? This box looks like it's about different sensory modalities. I'm sure there's a lot of interesting discussions we could bring in here, priors and empirical behavior, complete class theorems. Any statistical decision procedure behavior may be framed as Bayes optimal under the right set of prior beliefs. Discussion of fixed and learned variables. One can imagine the pros and the cons generally of having fixed and learned variables, like computationally it's simpler to fix hard code of variable. However, if there's a setting where the model's adequacy depends on being able to update that, maybe you want it learnable. However, then you have to deal with these questions about like the kinetics of learning, like instantly switch or slow switch or trend averaging. So there's a lot of discussions around learning. How is attention regulated? What is precision on learning? It's like it very much complexifies the model. And there's many variables that you can bring into a learnable setting. But when it's framed as just static variables and only like the hidden states changing through time, that's like the simplest case. But more and more cognitive entities probably are going to entail considering learning dynamics. Setting up the generative process. The reason we postpone the design of the generative process. So little slate of hands. Entity first, not the niche first is that in many practical applications discussed in this book, we simply assume the dynamics of the generative process are the same or very similar to the generative model. We generally assume the agents generative model closely mimics the process that generates its observation. That is clearly a simplifying case. Because it doesn't address what if you're paying attention to predicting width and the world is dependent on height. There's so many complexities of that, which is really that broader like what is being modeled what matters question. But in some way very upstream or very close to the stream. It is like the rabbit being put in the hat. Like if the rat knows that there's a five by five maze. That's a huge amount of information versus if it only has access to pure local information. And that's just something to like, I think for us to know as we look through models. Like are we modeling the generative process. Oh, so the seasons oscillate so it is a sine wave. So then the generative model of the agent is also going to be fitting a sine wave. Well, then it kind of collapses to like a stochastic regression. And maybe then it looks like the fit is going to be very good. Active inference modeling brings in another complexity with action influencing outcomes that prevents some I guess fallacies of modeling. But by no means all and probably introduces many others, Eric. Yeah. Can you hear me? Sounds good. So this might be a time to to discuss the question I posted and I apologize. I didn't put it in the right place the other day. I just figured out today that it goes under this particular location, but this is about the question about. Why modeling of a generative process is necessary is a necessary step for building an active inference model. So let me just read it because it's a lot of words. So, you know, we know that an active inference agent employs a generative model as its model of the external world. And it uses a generative model to perform inferences about perceptual input and to make decisions about actives. So in general, the external world is complex and unknowable to the to the agent. The generative model may or may not be able to learn. But if learning is supposed to if it is learning is supposed to put the generative model in a better alignment with the world's generative process, whatever that may be. I can see how one might model the generative process. If one is building an artificial agent in a laboratory where you kind of have access, you you control how the world behaves with respect to the agent. And then you might want to study how well the agent design works versus one versus another under control conditions. But this is not the same as designing an agent to go out and cope with some real world environment where you really don't know what that generative process is. I think that the recipe for designing an active inference models would include formally setting up the generative process only in the kind of a laboratory situation. But not if you're really trying to build something out for the real world because you don't know the generative process. You might create an artificial laboratory kind of situation by trying to build a model of how the world works and say, well, does my agent work under those assumptions or not? But that, you know, that might set you up for putting the agent in the real world. But in fact, you don't know the generative process if you're really trying to build something to work in the real world. That's my question. That's a very insightful question. Thank you. Lyle? Well, I love Eric, I love that framing because I think there's multiple different cases, right? I think if you're modeling something that, as you say, goes in the real world, then, you know, perhaps it's a, you know, some sentient creature or being. Then, then it could obviously there's the real world, even if we knew everything about it is too complex to model, right? So, so that's, that's fool's gold, you know, to assume you know everything, right? There, and so I don't, I'm just gonna say, yeah, that's hard. You know, typically, I guess we would say what are the parts of the generative, the real world, the generative process that we're going to consider relevant and deal with that and knowing that we're making a leap of faith. But there's another case, I think, which is more generalizable just to a complex adaptive systems that operate in what I call the built world, right? So, I work with a bunch of people who build digital twins. They build digital twins of human infrastructure, right? So buildings and all this stuff. There, the generative process that we're concerned with is largely knowable, right? And largely representable. And so, and what's interesting about that is there are a bunch of blind spots and inadequacies in what we know about that generative process. And the ability to do inference about what the real state of that system is then becomes the value of this approach in that setting, right? So, so I think I don't think there's a general answer. Once again, I think it really comes down to purpose and what the specific framing you're looking to do. To me, this ability to say something about what I like that idea of decision agents, right? Decision agents that are going to potentially take action or infer actual states is much richer than what a lot of the modeling, historical modeling paradigms have given us. So, I think that's really interesting. Thank you, Lyle, Ali. Yeah, and I also think that the distinction between generative process and generative models become significant if we want to simulate learning rather than just inference. I mean, that's the answer I got from Ryan Smith, because I asked him almost the same question. Why do we need generative process in order to simulate the agents? Because you see, for the generative process, if the generative model exactly maps into generative process, we only need that capital D matrix, right? And that's just when we're just trying to simulate the inference side of the agent, right? But when the learning comes along, then we need to separate that capital D from another matrix, probably the case D, which maps onto the generative process. So, yeah, one of the situations that the distinction between two might be necessary is when those two processes, I mean learning and inference, are taken as two separate phenomena to model. Thanks. One note is also there's work on symmetries in the generative process, generative model, like I think like the bidirectional paper with Matt Sims and Blue discussing it. And then here will be a defense to Eric's excellent question. The entity first modeling approach that's taken by this chapter. One can say I don't know whether I'm going to a forest or a desert, but I'm going to have these sensors on my designed interface, and I'm going to do extensive modeling on interception and homeostasis. And if I can learn policies that balance homeostasis, then I've survived.  So that doesn't mean that it works or it's doing the right thing fit for purpose, any of those aspects. But one of the insights from the four E and the embodied side is like a vast amount of our what is modelable as cognitive isn't necessarily the declarative. I think therefore I am possibly even symbolic type thinking linguistic. There's a lot going on. And many of that a lot going on can be simplified by not even knowing about the external process, maybe not even the as modeled kidney, knowing about what the as modeled liver is doing. So this type of a focus was like we're going to define our entity types and the kinds of observations that they can make the kinds of affordances that they have or do empirically or that they conceptually could do. That approach is consistent with embodied biological systems and persistence of organizations. And so I'm wondering how that piece comes into play with this discussion that's very important about and also their earlier discussion of the embedded and extended cognition is that it kind of blurs the line with what is a generative model, what is a generative process. So, hence there being a lot of thinking and attention on what the systems modeling is. What are the known unknowns and unknown unknowns going to be. Let's just see. Chapter ends 67 simulating visualizing analyzing and fitting data using active inference. So standard routines for active inference that provide support for all functions are available. Hashtag SPM and appendix C. Step by step model is a great look through this. This is MATLAB code. One amazing work that we could all iterate on would be porting MATLAB into the ontology into Python and or Julia with PI MDP or active blockference. But there's a lot in SPM and some of its neuro imaging specific. Some of its very variational base specific, not all of it is going to be state of the art or the most useful in every situation. However, I wonder if only offering certain routines and MATLAB, which is like a traditionally very academic software platform and potentially non free can be a limiting factor. So those who feel like they want to learn more or contribute this way. Helping structure some of the code architecture so that cohorts coming through can be doing multiple language. Maybe first we can just move some of these routines into a folder. And then people can start to organize those types of aspects. Summary. It's a four step recipe. We walk through it from the consideration of the system of interest broadly like the entity and the process, focusing in on the entity specifically thinking structurally about what it is going to be like doing slash composed of specifying that to a few levels of detail, then doing the same for the generative process. And then once that is specified, it's not quite quite there for most people today. But where it seems like they are laying out a path towards and where we probably can and will be after that level of setup in some potentially graphical editor or parameter file. Then as SPM and Matlab have done in many, many papers, the generative model specification almost prepares the working script. But there's still a lot of details and pieces to add in, especially in a modern environment. And for all of these like non standard and novel cases that people are wanting to consider. But that is once we have a notebook that goes through the recipe, then the recipes can be forked and so on. And they can be written in different languages. PyMDP, Blockference, Ali. Yeah, just one thing that I think is not made explicit in this chapter is that actually that first step which system are we modeling, especially the identification of the Markov blanket part is basically at this point of active inference research is more like a hypothetical step. Because I also have a misapprehension that we can somehow identify the Markov blankets from data. But then as I went on through my project and by consulting Maxwell and others, actually this is the comment Maxwell made about my proposal that he said that identifying Markov blanket from data is still an outstanding issue that is not resolved yet in the research and active inference. And one of the most active areas of research they're doing at versus lab is just focused on this part of the modeling recipe. I mean, how to how we can identify automatically identify or somehow learn the Markov blanket from just pure data points. Awesome. And that ties in with Dalton S's work on the blanket index and like continuous variables for dynamic assemblies of blanketing. This is going to get really nuanced and empirical with the discovery and the thresholding of Markov blankets and causal inference in real world systems with many different kinds of sensors and doing structure learning on generative model and process and like everything empirically, which is why as a simplifying step, it actually really reminds me of how Dave Snowden situates the difference between systems thinking and complexity thinking, which is systems often uses like a lot of nodes and flow charts to represent system elements and relationships and like interfaces. Whereas in complexity and the Kinevin especially framing, it's like more like self organizing sand dunes. And so causal relationships might be very much in flux and it puts a higher focus on action rather than system description, especially in situations like moving your head where the relationship of different things is going to be heavily action dependent. And so for now, we're kind of in the systems world where it's like a priori here are the system interfaces. And then we're going to take whether it's a heuristic or whether you take a literal interpretation, but you don't have to. You could just say I'm taking heristically the approach of the systems mapping. But that's not to say that that generative model couldn't be trained in a systems mapped context and then placed into a different setting where there was a mismatch or different generative model. And so it's going to be an ongoing discussion how are when are these lines drawn one other point other than not needing to use last names to refer to specific concepts. Like, are we talking about the blanket that statistically inner insulates every partition of nodes in these base graphs, which are going to be vast. As Ali and Jacob and I were discussing on the branching time active inference from just a few days ago yesterday, like these graphs are going to be vast. And so just saying there will be a markup like it in fact there will be many markup blankets with different semantics that you might assign to them or not. How does that map onto the real world is like the realism instrumentalism, pragmatism, abduction conversation that we've been having. Do you come in with these kinds of boundaries, heristically and distinctions, or how many levels of uncertainty and nesting. I don't know how many categories of blank there are. I don't know if it's a category or a continuum of this. You can actually still take on multiple levels of uncertainty in the modeling, but then fitting it with empirical data. If it's fit for purpose use is to do some sort of statistical inference or like provide meaning or action. But just didactically, when the models purpose is educational, then there's a lot of things in architectures we might play with. And then the recipe and also this conversation helps, I hope hold space for the educational and the curiosity driven model development where we're going to have a lot of fun and interesting GMs and people's applications and working with different real world constraints and different settings will all be learning a lot from it. And hopefully some of it will be in repos we can reference. Other people may want to play around inversion within folders that we can make if anybody wants to be added as a collaborator in this textbook repo, which is just pretty much empty except for, I guess, a script from Jakob. And there'll be more to say on probably GitHub and on as we continue through. But in these last minutes, does anyone have any thoughts for our continuation of the cohort? I have one question, Daniel, you referenced a paper earlier in the discussion that I'd love to get the reference to about persistence of organizations and survivability. Oh, yes. All right. I will put it into resources. Here's the work. It's a PhD dissertation that was published as a book and I'll upload the PDF as well. This is extremely interesting work. Yeah, it just came out. In our last minutes, it's too fun not to share. So Carl Friston has written the foreword. What is a firm's purpose? What is an organization's purpose? It's as difficult to answer as why am I here? Free energy governance and the FEP inverts the question. Instead of asking how a system, how must the system behave to survive? It asks how do systems that survive behave? The answer is rather deflationary. They survive. Their purpose is just sustainability. So some classic Fristanisms, some very nice framings on page 95. There's some great juxtapositions. So it's always awesome to see this kind of quality work.  And I don't see any scripts here. That's the textbook. But who knows? Maybe we can do some generative modeling of organizations or we can specify it and iterate on it. Realize it in Blockference and PyMDP and FortyLab and JF's symbolic suite. So there'll be a lot of fun things to explore this cohort. Any other questions or ideas that people want to share? Thanks and congratulations to people for joining this continuation. It's a great continuance. And I know that this part is going to be very interesting. The next three months will be interesting.


Welcome back to approach to abdominal pain part 4. In this final video, we'll discuss how to put all we've learned in the past three videos together. Like all emergency medicine patients, if the patient is unstable, we want to start resuscitating them first. After that, we want to do a simultaneous approach to investigate and treat at the same time. Resuscitation starts with ABC. We need to make sure the patient's airway is patented and they're protecting their airway. We need to give patients oxygen if they're hypoxic. For circulation, we need to put patients on monitor to monitor their vital signs. If the patient is hypotensive or tachycardic, we need to give them crystalloids such as normal saline or ringers lactate. In the patients who are septic because of abdominal infection, early and aggressive IV fluids is key. Once we've adequately resuscitated the patient, we can start investigation and treatment at the same time. We'll first discuss the investigations. Your investigation will be dictated by what you find on history and physical. The investigation can include lab tests and imaging. In terms of their specific lab, I'll refer you to the previous video for the details. They can include routine labs such as CBC, electrolytes, and kidney functions. Depending on the location of the pain in our clinical suspicion, other tests such as liver markers, lipase, can be added. In certain cases, a urine dip and a beta-HCG is also necessary. As discussed before, our imaging choices can include x-ray, ultrasound, bedside or formal, or CT scan. The choice of the imaging will depend on what we think the problem is and how stable the patient is. As it's often mentioned before, an unstable patient should not be leaving the emergency department until they are more stable. For unstable patients, they might be able to have a portable x-ray in their bed and a bedside ultrasound. For patients who are stable, they will be able to leave the emergency department to get a formal ultrasound or a CT scan. At the same time of our investigation, we also would like to start treating the patient. Our treatment includes the following, medications and definitive surgical repair. We can expedite this by giving patient medications early in the course of their stay in the emergency department and expediting their diagnosis so they get to the appropriate surgical repair faster. We will give patients medications to decrease their pain. Good choices include parenteral opiates. Often an IV route is better because patients will usually be kept NPO prior to surgical repair. Anti-nausea medications can also be given. If we are suspicious of an infectious process, antibiotics should be given to patients early. Antibiotics should cover gram-positive, gram-negative and anaerobic organisms. The regimen will vary from institution to institution and is best to check with your staff. Our goal again in the emergency department is to get the patient to definitive treatment by surgeons as soon as we can. In a stable patient, we can often wait until after a definitive diagnosis is done through imaging before referring the patient. However, in the unstable patient, we may not have time to come up with a definitive diagnosis. In those patients, we like to refer early and we will work together with a surgical team to come up with what we think is the most likely diagnosis. In summary, we discuss how to put it all together in approaching the patient with abdominal pain. We will start with resuscitation ensuring the patient's ABC is fine. And then we will start a parallel approach of investigation and treatment. Based on your history and physical, you then choose the most appropriate lab work and imaging modality. At the same time, treatment should be given to control the patient's pain and discomfort. Antibiotics, if we're worried about an infectious process. And expediting the patient's surgical care by involving the consultants early, particularly in the unstable patient. For specific treatment, I refer you to the other videos in this series. We hope you find this helpful. Thank you for watching.