Welcome back everyone to SuperCloud 2, live here in Palo Alto, our studio, where we're doing a live stage performance and virtually syndicating it out around the world. I'm John Furrier with Dave Vellante, my co-host with theCUBE here at Kit Colbert, the CTO of VM. We're doing a keynote on cloud chaos, the evolution of SuperCloud architecture. Kit, great to see you. Thanks for coming on. Yeah, thanks for having me back. It's great to be here for SuperCloud 2. And so we're gonna dig into it. We're gonna do a Q&A. We're gonna let you present. You got some slides. I really want to get this out. It's a really compelling story. Do the presentation and then we'll come back and discuss, take it away. Yeah, well thank you. So we had a great time at the original SuperCloud event. Since then been talking to a lot of customers and started to better formulate some of the thinking that we talked about last time. So let's jump into just a few quick slides to sort of set the tone here. So if we go to the next slide, what that shows is the journey that we see customers on today. Going from what we call cloud first into this phase that many customers are stuck in called cloud chaos. And where they want to get to, and this is the term customers have actually used. We didn't make this up. We heard it from customers. This notion of cloud smart, right? How do they use cloud more effectively, more intelligently? Now, if you walk through this journey, customers start with cloud first. They usually select a single cloud that they're gonna standardize on. And when they do that, they have to build out a whole bunch of functionality around that cloud. Things you can see there on the screen, disaster recovery, security, how do they monitor it or govern it? Like these are things that are non-negotiable. You've gotta figure it out. And typically what they do is they leverage solutions that are specific for that cloud. And that's fine when you have just one cloud, but if we build out here, what we see is that most customers are using more than just one. They're actually using multiple, not necessarily 10 or however many are on the screen, but this is just as an example. And so what happens is they have to essentially duplicate or replicate that stack they've built for each different cloud. And they do so in kind of a siloed manner. This results in the cloud chaos term that we talked about before. And this is where most businesses out there are. They're using two, maybe three public clouds. They've got some stuff on-prem. And they've also got some stuff out at the edge. This is apps, data, et cetera. So this is the situation. This is sort of that cloud chaos. So the question is, how do we move from this phase to cloud smart? And this is where the architecture comes in. This is why architecture I think is so important. It's really about moving away from these single cloud services that just solve a problem for one cloud to something we call a cross-cloud service, something that can support a set of functionality across all clouds. And that means not just public clouds, but also private clouds, edge, et cetera. And when you evolve that across the board, what you get is this sort of super cloud, this notion that we're talking about here, where you combine these cross-cloud services in many different categories. You can see some examples there on the screen. This is not meant to be a complete set of things, but just examples of what can be done. So this is sort of the transition and transformation that we're talking about here. And I think the architecture piece comes in both for the individual cloud services, as well as that super cloud concept of how all those services come together. Great presentation, thanks for sharing. If you can pop back to that slide on the cloud chaos one, I just want to get your thoughts on something there. This is like the layout of the stack. So this slide here that I'm showing on the screen that you presented, okay, take us through that complexity. There's the one where I want to live. That looks like spaghetti code. Yes. So do you turn this into a super cloud stack? Right, is that? Well, I think it's an evolving state that like, let's take one of these examples like security. So instead of implementing security individually in different ways, using different technologies, different tooling for each cloud, what you would do is say, hey, I want a single security solution that works across all clouds, right? A concrete example of this would be secure software supply chain. This is probably one of the top ones that I hear when I talk to customers. How do I know that the software I'm building is truly what I expected to be and not something that some hackers got into and polluted with malicious code? And what they do is that typically today, their teams have gone off and created individual secure software supply chain solutions for each cloud. So now they could say, hey, I can take a single implementation and just have different endpoints. It could go to Google or AWS or on-prem or wherever have you, right? So that's the sort of architectural evolution that we're talking about. You know, one of the things we hear, Dave, you're on the queue all the time and when we talk privately with customers who are asking us like, what's going on? They have the same complaint. I don't want to build a team, a dev team for that stack. So if you go back to that slide again, you'll see that that illustrates the tech stack for the clouds and the clouds at the bottom. So the number one complaint we hear and I want to get your reaction to that. I don't want to have a team to have to work on that. So I'm going to pick one and then have a hedge secondary one to backup. Here that's one, that's four, five, eight, 10 environments. That's going to be the reality. So what's the technical answer to that? Yeah. Well, first of all, let me just say this picture is again, not totally representative of reality oftentimes because while that picture shows a solution for every cloud, oftentimes that's not the case. Oftentimes it's a line of business going off, starting to use a new cloud. They might solve one or two things, but usually not securities, you're not some of these other things, right? So I think from a technical standpoint, what you want to get to is yes, that sort of common service with a common operational team behind it that is trained on that that can work across clouds. And that's really, I think the important evolution here is that you don't need to replicate these operational teams, one for each cloud, you can actually have them more focused across all those clouds. Yeah, in fact, we were commenting on the opening today. Dave and I were talking about the benefits of the cloud. It's heterogeneous, which is a good thing, but it's complex, there's skill gaps and that skill required. But at the end of the day, self-service of the cloud and the elastic nature of it makes it the benefit. So if you try to create too many common services, you lose the value of the cloud. So what's the trade off? In your mind right now, as customers start to look at, okay, identity, maybe I'll have one single sign on. That's an obvious one, other ones. What are the areas people are looking at from a combination, common set of services? Where do they start? What's the choices? What are some of the trade-offs? Because you can't do it everything. No, it's a great question. So that's actually a really good point. And as I answer your question, before I answer your question, the important point about that, as you saw here, across cloud services or these set across cloud services, the things that comprise the super cloud, at least in my view, the point is not necessarily to completely abstract the underlying cloud. The point is to give a business optionality and choice in terms of what it wants to abstract. And I think that gets to your question, is how much do you actually want to abstract from the underlying cloud? Now what I find is that typically speaking, cloud choice is driven at least from a developer or app team perspective by the best of breed services. What high level application type services do you need a database or AI, ML systems for your application? And that's going to drive your choice of the cloud. So oftentimes, businesses I talk to want to allow those services to shine through. But for other things that are not necessarily highly differentiated and yet are absolutely critical to creating a successful application, those are things that you want to standardize. Again, like things like security, the supply chain piece, cost management, like these things you need to and things like COGs become really, really important when you start operating at scale. So those are the things that I see people wanting to focus on. So there's a maturity model. Yes. And we heard earlier from Walmart who's fairly advanced, but at the same time, their super cloud is pretty immature. So what are you seeing in terms of super cloud, momentum, cross cloud, momentum? What's the starting point for customers? So it's interesting, right? On that three tier journey that I talked about, this cloud smart notion is that is adoption of what you might call a super cloud or architecture. And most folks aren't there yet, even the really advanced ones, even the really large ones. And I think it's because of the fact that we as an industry are still figuring this out. We as an industry did not realize this sort of cloud chaos state could happen, right? We didn't, I think most folks thought they could standardize on one cloud and that'd be it. But as time has shown, that's simply not the case. As much as one might try to do that, that's not where you end up. So I think there's two things here. Number one, for folks that are early in to the cloud and now are in this cloud chaos phase, we see the path out through standardization of these cross cloud services through adoption of the sort of super cloud architecture. But the other thing I think that's particularly exciting is I talked to a number of businesses who are not yet in the cloud chaos phase. They're earlier on in the cloud journey. And I think the opportunity there is that they don't have to go through cloud chaos. They can actually skip that whole phase if they adopt this super cloud architecture from the beginning. And I think being thoughtful around that is really the key here. It's interesting because we're going to hear from Iona's Pharmaceuticals later. And yes, there are multiple clouds, but the multiple clouds are largely separate. And so it's a business unit using that. So they're not in cloud chaos, but they're not tapping the advantages that you could get for best of breed across those business units. So to your point, they have an opportunity to actually build that architecture or take advantage of those cross cloud services prior to reaching cloud. Well, I actually, you know, I'd love to hear from them if you say they're not in cloud chaos, but are they? I mean, oftentimes I find that each BU, each line of business may feel like they're fine and you know themselves. But when you look at it from an overall company perspective, they're like, okay, things are pretty chaotic here. We don't have standardization. I don't, you know, like, again, security compliance, these things, especially in many regulated industries, become huge problems when you're trying to run applications across multiple clouds, but you don't have any of those company-wise standardization. Well, this is a point. So they have a big deal with AstraZeneca, who's got this huge ecosystem. They want to start sharing data across those ecosystems. And that's when they will, that cloud chaos will, you know, come to four, you would think that. I want to get your take on something that Bob Muglia said earlier, which is he kind of said, hey, Dave, you guys got to tighten up your definition of it. So he set a super cloud as a platform that provides programmatically consistent services, hosted on heterogeneous cloud providers. So thank you, that was nice and simple. However, others in the community, we're going to hear from Dr. Nehlu Mihai later, who says, no, no, wait a minute. It's got to be an architecture, not a platform. Where do you land on this architecture V platform thing? I look at it as, I don't know if it's, you call it maturity or just kind of a time horizon thing. But for me, when I hear the word platform, I typically think of a single vendor. Single vendor provides this platform. That's kind of the beauty of a platform. It's that there is a simplicity, usually consistency to it. They did the architecture. Yeah, exactly. But I mean, well, there's obviously architecture behind it. It has to be, but you as a customer don't necessarily need to deal with that. Now, I think one of the opportunities with super cloud is that it's not going to be, or there is no single vendor that can solve all of these problems. It's got to be the industry coming together as a community, interoperating, working together. And so that's why for me, I think about it as an architecture, that there's got to be these sort of well-defined categories of functionality. There's got to be well-defined interfaces between those categories of functionality to enable modularity, to enable businesses, to be able to pick and choose the right sorts of cross-cloud services, and then weave those together into an overall super cloud. Okay, so you're not pitching necessarily the platform. You're saying, hey, we have an architecture that's open. I go back to something that Vittorio said on August 9th with the first super cloud. Because as well, remember we talked about abstracting, but at the same time giving developers access to those primitives. Yes. So he said, and I think your answer that confirms this, I want to have my cake, eat it too and not gain weight. That's good. Right. Well, I think that's where the platform aspect can eventually come. After we've gotten aligned architecture, you're going to start to naturally see some vendors step up to take on some of the remaining complexity there. So I do see platforms eventually emerging here, but I think where we have to start as an industry is around aligning, okay, what does this definition mean? What does that architecture look like? How do we enable interoperability? And then we can take the next step. Because it depends too. Because I would say Snowflake has a platform and they've defined the architecture, but we're not talking about infrastructure here. Obviously, we're talking about something. Well, I think that if the Snowflake talks about what he's talking about, security and data, you're going to start to see the early movement around areas that are very spanning oriented. And I think that's the beginning of the trend. And I think there's going to be a lot more, I think on the infrastructure side, and to your point about the platform architecture, that's actually a really good thought exercise because it actually makes you think about what you're designing in the first place. And that's why I want to get your reaction quote from- Well, I just have to interrupt, since later on you're going to hear from near-Zook of Palo Alto Network, he says architecture and security, historically they don't go hand in hand because it's a big mess. It depends if you're whacking the mole or you're actually proactively building something. Well, kid, I want to get your reaction from a quote from someone in our community who said about SuperCloud, the SuperCloud's great. There are issues around computer science rigors and customer requirements. So there's some issues around the science itself as well as not just listening to the customer, because if that's the case, we'd have a better database, a better Oracle, right? So, but there's other, there's tech involved, new tech. We need an open architecture with universal data modeling, interconnecting among them. Connectivity is a part of security. And then once we get through that gate, figuring out the technical, the data and the customer requirements, they say SuperCloud should be a loosely coupled platform with open architecture, plug and play, specialized services ready for optimization, automation that can stand the test of time. What's your reaction to that sediment? You like it? Yeah, that probably aligns with my thinking, I think. And what I see from talking with customers as well. I mean, I like the, again, the listening to customer needs, prioritizing those things, focusing on some of the connective tissue networking and data and some of these aspects, talking about the open architecture, the interoperability, those are all things I think are absolutely critical. And then yeah, like I think at the end, on the computer science side, do you see some science and engineering, things that need to be engineered differently? We heard databases are radically gonna change and that are inadequate for the new architecture. What are some of the things that are from a science standpoint? Yeah, yeah, yeah, some of the more academic research type things. Or tech, better tech or is it? Yeah, look, absolutely. I mean, I think that there's a bunch around, certainly around the data piece around, you know, those issues of data gravity, data mobility, how do you wanna do that in a way that's performant? There's definitely issues around security as well. Like how do you enable like trust in these environments? There's gotta be some sort of hardware route of trust and a whole bunch of various types of aspects there. So a lot of work still to be done? Yes, I think so. And that's why I look at this, is this is not a one year thing or it's gonna be multi years. And I think, again, it's about all of us in the industry working together to come to an aligned picture of what that looks like. The world's moved from private cloud to public cloud and now cross cloud services, super cloud, meta cloud, whatever you wanna call it. How have you sort of changed the way engineering's organized, developers sort of approach the problem? Has it changed and how? Yeah, absolutely. So, you know, it's funny. We at VMware are going through the same challenges as our customers in any business, right? We use multiple clouds. We got a big, of course, on-prem footprint. You know, what we're doing is similar to what I see in many other customers, which you see the evolution of a platform team. And so the platform team is really in charge of trying to develop a lot of these underlying services to allow our lines of business, our product teams to be able to move as quickly as possible, to focus on the building while we help with a lot of the operational overheads, right? We maintain security, compliance, all these other things. We also deal with, yeah, just making the developer's life as simple as possible. So they do need to know some stuff about, you know, each public cloud they're using, those public cloud services. But at the same time, we can abstract a lot of the details that don't need to be in. So I think this sort of delineation or separation, I should say, between the underlying platform team and the product teams is a very, very common pattern. I noticed the four layers you talked about were observability, infrastructure, security, and developers on that slide. The last slide you had at the top, that was kind of the abstraction. Key areas that you guys at VMware are looking at. There's some groupings that we've come up with, but we love to debate them. I noticed data is in every one of them. It's not like, back to the data questions, that security is called out as a pillar. Observability is just kind of watching everything, but it's all pretty much data-driven. Of the four layers that you see, I take that as areas that you can consistently rely on to have standard services. Which one do you start with? What's the, is there a order of operations? I think infrastructure is number one, but the observability you need to know what's going on. Yeah, well, it really is highly dependent. Again, it depends on the business that we talk to. I mean, it really goes back to, what are your business priorities? And we have some customers who may want to get out of a data center. They want to evacuate the data center. And so what they want is then consistent infrastructure, so they can just move those applications up to the cloud. They don't want to have to refactor them. Well, we'll do it later, but there's an immediate and sort of urgent problem that they have. Other customers I talk to, security becomes top of mind or maybe compliance because they're in a regulated industry. So those are the sort of services they want to prioritize. So I would say there is no single right answer, no one size fits all. The point about this architecture is really around the optionality of it, is it allows you as a business to decide what's most important and where you want to prioritize. How about the deployment models kit? Does a customer have that flexibility from a deployment model standpoint or do I have to approach it a specific way? Can you address that?  So running a control plane in the cloud and communicating elsewhere or having a single global instance or instantiating that instance. So that's a good point actually. And the white paper that we released back in August around this sort of concept, the cross-cloud service. This is some of the stuff we need to figure out as an industry. So when we talk about a cross-cloud service, we can mean actually any of the things you just talked about. It could be a single instance that runs, let's say, in one public cloud, but it supports all of them. Or it could be one that's multi-instance and that runs in each of the clouds and that customers can take dependencies in whichever one, depending on what their use cases are. Or even going further than that, there's a type of cross-cloud service that can actually be instantiated even in an air-gapped or offline environment. We have many, many businesses, especially heavily regulated ones that have that requirement. So I think- Global, don't forget global. Yeah. Regions, locales. Yeah, there's all sorts of performance latency issues that we're concerned about. So most services today are the former. They're a single sort of instance or set of instances within a single cloud that support multiple clouds. But I think what we're doing and where we're going with things like what we see with Kubernetes and service meshes and all these things, well, better enable folks to hit these different types of cross-cloud service architectures. So today, you as a customer probably wouldn't have too much choice, but where we're going, you'll see a lot more choice in the future. If you had to summarize for folks watching the importance of super cloud movement, multi-cloud, cross-cloud services, as an industry influx, because I'm always riffing on the whole old school network protocol stacks that got disrupted by TCP, IP. That's a little bit dated. We got people on the chat that are like 20 years old that weren't even born then. So this is one of those influx ones that's once in a generation, inflection point, I'm sure you agree. What's scoped the order of magnitude of the change and the opportunity around the marketplace, the business models, the technology and ultimately benefits the society? Yeah. Wow. You're getting there again. You have 10 seconds. I know. Yeah, exactly. No, look, so I think it is, what we're saying is really the next phase of what you might call cloud, right? That this notion of delivering services, the way they've been packaged together traditionally by the hyperscalers is now being challenged. And what we're seeing is really opening that up to new levels of innovation. And I think that will be huge for businesses because it'll help meet them where they are. Instead of needing to contort the business to make it work with the technology, the technology will support the business and where it's going, give people more optionality, more flexibility in order to get there. And I think in the end, for us as individuals, it will just make for better experiences, right? You can get better performance, better interactivity, given that devices are so much of what we do and so much of what we interact with all the time. This sort of flexibility and optionality will fundamentally be better for us as individuals in our experiences. And we're seeing that with chat, GTP. Everyone's talking about just early days. There'll be more and more of things like that that are next-gen, like obvious, like, wow, that's a fall out of your chair. It'll be the next wave of innovation that's unleashed. All right, Kid Colbert, thanks for coming on and sharing and exploring the super cloud architecture, cloud chaos, the cloud smart. There's a transition progression happening and it's happening fast. This is the super cloud wave. If you're not on this wave, you'll be driftwood. That's a Pat Gelsinger quote on theCUBE. This is theCUBE. We'll be right back with more super cloud coverage here in Palo Alto after this break.


My name is Andrew Cleed, I'm Professor of Energy and Environmental Economics here at Penn State and I'm also Program Officer for the Energy Business and Finance Program. I'm pretty recently working here, I worked at Louisiana State University and for the Federal Trade Commission in Washington, D.C. and I have a PhD in Economics from Yale University. My current research topic deals with electricity issues and electricity supply issues. And this is very interesting for a couple of different reasons. One of which is that many people, perhaps including myself, are trying to deregulate electricity markets. But deregulating electricity markets is not as easy as, say, deregulating telephone or airline markets. Electricity is a funny creature that goes where it wants and setting up the institutions to do that is very difficult. And the need for me and other economists interested in electricity issues, if you think about the issues in 2000, 2001 in California, where a purportedly restructured system completely crashed. So here in Pennsylvania we have a very effective restructured system. And in particular, that system is well suited to pick up the additional demands that our state legislators and our federal legislators are imposing of renewable energy sources that each state will now have a certain amount of power that will have to be renewable in this state in large part wind power. But wind power has its own interesting issues because if you think about electricity grid, you don't want the electricity grid to crash. And because electricity isn't storable, you need supply to equal demand at all times. But what happens if you base 20% of your grid on wind power and one day the wind stops blowing? Do the lights go out? This is a very difficult problem and a problem that we'll be studying for some time. And that's where my current research interests lie. I just want to say that a famous person who is George Bush's first secretary, Ari Fleischer, who's bald like me, I just want to say in college I taught him, when I was news director at the college radio station, I taught him how to be a newscaster. And yet I picked up his biography and he didn't mention me. And I'm still annoyed. So Ari, if you're out there, send me some love.


Hi everyone, Joe for jaspyscasebreaks.com coming at you with 2019-2020 Panini Prism Basketball Retail Pack Break. It's just a one-pack break number 262 We're giving away three of those five hundred dollar mixer spots at the end of the break separate dice roll separate list We always do the break itself first We'll make you sweat it out a little bit and we'll re-randomize your names hop three five dollar mixer spots Now as it stands right now if you look at the center of your screen right here We just need to do two more packs and three full spots and then we're in breaksville on that or if the Straight-up spots sell out. I can maybe I can cancel a pack and then add three more spots or Take out those three full spots and add an extra filler pack. We can be a little nimble about how we accomplish that but Pretty close and check out the Michael Jordan giveaway jaspyscasebreaks.com big. Thanks to these folks for getting to the action We're gonna do the break first Thank you. All the teams are in right here. Let's roll it. Let's rando it 12 times for names and teams and 12th and final time nice Jared Smith down to Brian Crouch after 12 and then 12 times for teams 11 and 12th and final time after 12 we got the calves down to the timber wolves I'm not gonna read up all the names here, but for what it's worth Michael Robinson We got the pelicans in this little pack break only four cards, and you also have the grids now if It'd be kind of awesome if One of those players emerged from a four-card pack break I mean, obviously the whole point of this break is to to give away those spots those are the hits But could there be a surprise in the pack? Possibly. All right. I got Andre Roberson Mark Heath Morris and a silver silver Ben Simmons. Okay, and Alan Iverson with Ben Simmons autographs being exclusive to upper deck Consequently these panini card even even though it's a non rookie Carry a little extra little extra weight on the secondary market So there we go and the silvers are always nice. All right, so good luck to everybody here I'm gonna re randomize this list and Someone or three people are gonna get spots in that $500 mixer $500 spot mixer that is featuring the Jordan. All right, so we got Natalie down to Natalie right now with the Hawks now with wizards. Okay, let's roll it. Let's randomize it snake eyes Just two times. It's gonna be top three after two good luck one and two Now from four down to 30 my apologies There are other opportunities to get into the action. I would I would give it a shot I mean to chase a $500 spot and maybe turn that into a Michael Jordan. I think that'd be pretty cool Alright, so thank you again for trying top three. Congrats Jared Smith Natalie Hill and Li Xiao Chen boom Congrats to the three of you. You're in that big mixer Maybe try a game you can win you can win multiple spots give yourselves more opportunities to get that Jordan and the hits in the break itself I'm Joe for jazzy's case breaks calm. I'll see you for that next time. Bye. Bye


Hi everybody, my name is Jacob Wyschniewski and I am a research software engineer at MI Square Data Lab and a student at Warsaw University of Technology. And today I'll be presenting my joint work with Przemysław Biedzek, which is Air Package for Models. For Models is a flexible tool for bias detection, visualization and mitigation. Now let's answer the question, why should we even care about algorithmic fairness? Well, decision making systems and machine learning models had a history of discrimination and somewhat shady practices. For example, ProPublica found that the software used across the United States to find whether someone would be a recidivist or not was biased against blacks. In gender shades, the researchers found that the popular gender classifiers were biased against darker females. The algorithms performed best on light male faces and the gap of accuracy was as high as 30%. As Diverge reported, Google removed gorillas from the training sets of images because the model was prone to categorize black people as gorillas. So as you can see, there are many potential harms to be made and it is necessary to test our models before we put them into production. Now let's define this bias because you may have many meanings but in this presentation and in this fairness field, we'll define it as some discrimination of some groups of people giving unfair advantage to others. From now on, I will call those groups of people subgroups and one of them, the one with the most advantage, would be called privileged subgroup. The vector of indicators of membership to those subgroups will be called protected vector. Bias can be detected by some non-discrimination criteria which are independence, separation and sufficiency. Essentially, they're trying to answer the question if the response of the model or the target of the model is independent of some protected vector or independent given some condition. But this mathematical way of measuring bias is inconvenient and we'll use some relaxations and sometimes equivalence of those discrimination criteria. We can do this with some fairness metrics. Those metrics can be derived from confusion matrices for each subgroup. So with a well-known metrics like true positive rate, false positive rate, precision, accuracy, we can now detect bias. For example, like in ProPublica case, we would like our model to have similar false positive rates for both black and white defendants. The backbone of fair models is Dalek package, which is a wrapper around the data and model and it is model agnostic. So it does not matter if you use XGBoost models from Carat or MLR. Fair models focuses on group fairness metrics and utilizes this iterative accumulative approach where after obtaining a model, you can make a fairness check. You then receive the answer if your model is fair or not. If your model does not pass the fairness check, you have some options. For example, use different data, use different model, or maybe use some mitigation techniques. With fair models, you can, for example, make a dozen of machine learning models, then make some visualizations where you can pick the best one and check if this model passes fairness check. As you can see, this sort of pipeline or model development flow is easy for testing and prototyping your solutions. Now, we'll dive into the details. Let's take German credit data where we aim to predict whether some person will have a good or bad risk of credit. In this case, this is a binary classification. And we'll be looking at bias and fairness with perspective of this protected vector, which is the gender or sex of the person. So let's start with a simple classification model, which will be logistic regression. The next step is to make a Dalek explainer. This can be done with one line of code where we pass the model, the data, and the numerical target. Now we are ready to check fairness. The main function of fair models is fairness check. It wraps around and encapsulates explainer, protected vector, and privileged subgroup, which describes which element of the protected vector is suspected of the most privileged.  The f object can, of course, be plotted. It includes five metrics course depicted by the bars, which are on top of the red and green areas. The area symbolizes the field. The red area symbolizes the field where the bias is significant. So intuitively, when all the bars are lying within the green area, then the model, in terms of these metrics, can be called fair. The border between red and green area can be adjusted with texanum parameter. On y-axis, the subgroups are presented, and for each subgroup, the metrics are calculated. If there would be more than one subgroup, there would be more bars for this metric. So the protected vector doesn't have to be binary. It can have many, many values, or categorical values or some levels. But what are those values on x-axis? Well, let's dive deeper. The idea behind those values is the ratio of the metrics for unprivileged subgroup, which in our case is female, and the privileged subgroup, which in our case is male. We don't care if the metrics are high or low as long as the ratio of them is close to one. For example, let's take equal opportunity ratio, which can be measured by true positive rate. When those true positive rate scores are close to one, then they would be lying within the green area, and we would say that there is no visible bias here. So formally speaking, we would like our ratio to be within epsilon and one divided by epsilon, where epsilon is some value between 0 and 1, which denotes the lowest possible ratio between unprivileged and privileged subgroups. Now let's understand some code behind this furnace object. The values after the privileged parameter are the default values for this function. The epsilon parameter is on default set to 4-fifths due to a guideline set by equal employment opportunity commission. Generally, any selection rate below 80% or 4-fifths can be considered as adverse impact. Cutoffs and labels can also be adjusted. Labels have to be unique for each explainer in furnace check. With such a newly created furnace object, we of course can plot it and print it. Printing is a way of summarizing the plot. The print method shows how many metrics does the model pass, and it also shows the total loss of the model, which is summarized height of the bars. A cool feature of furnace models is that you can incrementally add explainers to furnace object. Notice that when we pass furnace object, we don't have to provide any protected vector or privileged parameters because they are already included in the object. On the furnace check plot on the right, we can see green bar areas added, which denote the ranger metrics for this female subgroup. It passes all of them. So in this print method, it will be printed with green colors. If the ranger would exceed more than one acceptable metrics score, it would be printed in red. Sometimes there is a need to plot unscaled metrics scores, which aren't the ratios we have seen earlier, but the raw metrics scores of the models in specific subgroups. On the plot legend, we have colors and shapes. Each color describes a model, and each shape describes certain subgroup. You might ask, where is this male privileged subgroup? Well, it is represented by those vertical lines. So the intuition behind the spot is that the closer the shapes are to those vertical lines, the better. In some visualizations, parity loss is used. It is a custom function that aggregates some metric ratios over all of the subgroups. So for example, let's take a true positive rate and calculate its parity loss. The intuition behind this method is that the bigger the difference between the metrics in the subgroups, the larger the parity loss will be. These are some other visualizations that use parity loss, and they can be obtained with a code snippets below the plots. Those are only two of many visualizations that can be used in for models. On the left side, there is a rather plot, and on the right side, there is a stacked metrics plot. They both visualize the amount of bias in many metrics at the same time. In the package, there are also some simple bias mitigation strategies, which can be used during a data preprocessing, and after, we create a model with explainer post-processing. The resampling focuses on statistical parity mitigation. It duplicates for remove observations given some condition. The reject option-based classification pivot is a post-processing method that adjusts the probabilistic response of the model. When unprivileged subgroup is close to the cutoff, it pivots to the other side. The opposite things happens when the privileged subgroup is on the right side of the cutoff. You can see the effects of mitigation on the plot on the right. Both methods successfully mitigate the bias in our model. Somewhat new addition to for models is the support for regression type models. It works just like the one for classification, but instead of using fairness check, user must use fairness check regression. This experimental module is using logistic regression to approximate fairness non-discrimination notions. The module is relatively new and still awaits some feedbacks. So if you use it, please let me know what do you think. To dive deeper into the concepts of fairness in Fair Models, I recommend visiting Fair Models' landing page available at this link. There are many sources to choose from, including article, blogs, documentation, and tutorials. You can also visit our blog, which focuses on responsible machine learning. Some things like explainability, new packages, case studies, and there is even whole series about basics of explainable AI. If you want to explain the behavior of your model and understand on what grounds does it make the decisions, you can check out Dalek package, where there is also Fair Models in Python implemented as Python package Daleks module. That will be all for me. Thank you for the attention. I hope that I gave you some intuition and basic understanding of Fair Models. If you have any questions, please go ahead. Thank you. Thanks a lot, Jakub. We have a couple of questions in the Q&A. So the first one would be, is the origin of the bias from the methods of collecting data, or was it the data that were biased themselves? Well, there are many origins of the bias. I once saw the paper that found as many as 20 of them, and it can be obtained or it can lead to the data on many stages, for example, in the data collection or in this state while depicting the state of the world, that we don't want to propagate, or for example, while data labeling, et cetera, et cetera. So the bias can be picked along the road, I guess. Thank you. Another question that we got from Andy is the following. What would be the advantages or disadvantages of measuring the fairness against all cases rather than against only the privileged group? Is there a way to automatically detect the privileged group beyond picking the larger class? Okay, great question. I guess there is not like this automatical way implemented, but you can iterate through every class, see if this bias exists. This numerical values can be accessed through the fairness object. So there is a nice way to do it. So I guess, yeah, it can be like iterated through each subgroup. Thank you. Yeah, we have more time for another question. So just keep them coming. We also have time after all of the talks to answer more questions. So I see another question. What happens if the mitigation is done in a biased way? How do you check or how do we check if the changes fix the biases or result in introducing more bias? Another great question. Well, I guess that in terms of this five metrics that you saw on the fairness check, you can always like plot it after the mitigation to see if the bias indeed mitigated or there were some other biases introduced. You have to also keep in mind that while using this bias mitigation methods, you also affect the accuracy or the performance of your model. So it will most likely decrease. It is not always what we are looking for, but it also can be visualizing for models. Nice, and thanks a lot. And we can get back to more questions. I see there's more coming and I also have some questions for later, I guess. Okay. But now let's hand over to Liz again. To introduce our second speakers. Yes, our next talk is about double ML or double machine learning in R. So it fits very well that we have two presenters, Philip Bach and Malta Kurs from University of Hamburg. They're gonna talk about the estimation of causal parameters by machine learning applied to a wide variety of models. And let's see what they have to say. Welcome everybody to our talk on the double ML package for R. We are Malta Kurs and Philip Bach from University of Hamburg. And we present this project, which is joint work with Victor Schenel-Zukhov and Martin Spindler. First of all, I would like to thank the organizers of USR 2021 for inviting us to present on our R package. Today I'm going to start with an introduction to the double machine learning framework, which is the statistical framework for our package. Later Malta is going to provide some insights to our implementation in R. Let's start with this basic question. What is double machine learning? In some sense, double machine learning can be considered as a combination of the strengths of two separate fields. On the one hand side, we have the literature on machine learning, which is illustrated here by the box on the left hand side. On the right hand side, we have a box which stands for the literature in the fields of econometrics and statistics. Whereas in machine learning, powerful tools have been developed that are able to deliver very, very accurate prediction rules, such as lasso or regression trees or in the forest. The statistics and econometrics literature has developed various approaches to causal inference and also delivered asymptotic analysis of certain estimates of causal parameters. The double machine learning framework makes it possible to estimate causal parameter and thereby base estimation on these powerful machine learning techniques. As a result, the procedure is going to output an estimator that has nice statistical properties, such as an asymptotically normal distribution and we can set up hypothesis test and confidence analysis. On the next slide, we have listed some examples on when causal machine learning might be of interest. For example, when data scientists perform and evaluate a bee testing, when researchers evaluate clinical studies or maybe in political science or economics, when certain policy measures are evaluated. The general question is underlying all these research agendas is what is the effect of a certain treatment on a variable of interest? Let's continue with a short example on a partially linear regression model. In this model, we are interested in the causal effect of a variable D on the outcome Y, provided we control for some confounding variable X. And this way of controlling for these confounding variables can be very general. In this model, we are interested in the parameter theta, which represents this causal effect. When we want to estimate this causal effect by using machine learning methods, we have to be very careful in general because machine learning methods, they generally introduce some form of regularization and thereby some bias. If we naively apply machine learning procedures to estimate the parameter of interest in the, for example, in the partially linear regression model, and the resulting estimator might be severely biased and also have a non-normal asymptotic distribution. In the histograms below, we have illustrations of two separate naive approaches. One is based on the Lasso variable selection, step, and the second one is based on naively plugging in predictions obtained from random forest. In both these histograms, we see that the empirical distribution of the estimators is very, very different from a non-density, which is illustrated by the red solid line. The machine learning framework is a general approach for estimation of treatment effects based on machine learning estimators. Identification of the parameter of interest is based on a moment condition with a score function psi, some data w, and a nuisance term eta that has population or true value eta mod. The machine learning approach can be generally summarized in terms of three key ingredients. The first one is name on a signality. The second one is the use of high quality machine learning estimators, and the third one is the use of sample splitting. Let's turn to the first ingredient, name on a signality. Name on a signality is a property of the score function that is used for identification. The idea is that the moment condition that is used for identification of the causal parameter tolerates some small errors in estimation of the nuisance part eta around its true value eta mod. In some sense, the estimation procedure is now immunized against these first-order or regularization biases that will result from using machine learning estimators. In the partial linear regression example we saw before, we can establish orthogonality by including an additional regression step. Here, if we include the first stage relationship, which is a regression of the treatment variable D and all covariates X, we can achieve or we can get the name of an orthogonal score that has the form below, which now has two nuisance components. The first one is the function G showing up in the main regression equation and the M comes from the first stage step. Let's go to the second key ingredient, which is the use of high-quality machine learning estimators. So in general, we want to use, of course, very, very accurate machine learning methods for estimation of our nuisance part eta. In theoretical terms, this amounts to rate requirement on the rate of convergence associated with the estimators in use. In practice, when we think about the use of machine learning methods, we will base this on structural assumptions. For example, whenever we are willing to make an assumption of sparsity, we won't maybe use some R1-panelized estimator, like LASU. The third ingredient is the use of sample splitting, which is common procedure in machine learning. Sample splitting avoids biases that arise from overfitting. So in the algorithm of the double machine learning estimator, we fit the machine learning methods only on one part of the data, trade sample. We generate prediction on the holdout sample, which is test sample. And then we can swap the roles, which is called then crossfitting. By swapping the roles, we can basically use every observational dataset once for training and once for fitting. Once we obtain these predictions, we can plug them in to the score and solve our target parameter data. Once we include all these three ingredients and under some regularity assumptions, it can be shown that the double machine learning estimator, theta tilde naught, is asymptotically normally distributed. More details involved, and this is why we refer to the paper by Shana Zuckoff and co-authors 2018, and also in our package unit, which is available online, and we have additional and a more sensitive introduction to the double machine learning framework. To conclude our partial linear regression simulation example, we included here now the two histograms that are associated with the machine learning estimators based on lasso and random forest, where we use now orthogonal score and sample splitting. And we see that the empirical distribution is now much more similar to the normal density that is illustrated by the red solid line. That was the theory part, and now I hand over to Maite. Yeah, thank you, Philipp. After we have now learned how this double machine learning framework works, we now want to have a closer look at the actual implementation in the R package called double ML. We have just learned what are the three key ingredients of double machine learning, namely the orthogonal score, high quality machine learning methods, and sample splitting. And these three key ingredients also translate to the central parts of our implementation. So the orthogonal score gets a central role via an object-oriented implementation using R6 classes. And we also wanna provide the user the ability to use high quality machine learning methods. This is achieved by having the API flexible with regards to using all the machine learning methods that are available via the MLR3 ecosystem. And also sample splitting is needed. And here we also built on top of MLR3. So we have just learned the main dependencies of our double ML R package are the MLR3 ecosystem in terms of the MLR3 package, the MLR3 learners, and the MLR3 tuning package. Besides that, for object orientation, we need the R6 package. And as a data backend, we use for efficient data search, we use data table. How could you install or get our package? It is available or we release it to C-Round so you can install it via the standard command and the development version is available through GitHub. So why did we actually choose to implement this in an object-oriented fashion? So we have learned that this name and orthogonal score function is having a prominent role. And if we have defined this name and orthogonal score function for a model we are interested in, we can implement a lot of things in a very general way. So if we have defined this score function, we can, for example, implement the estimation of orthogonal parameters, the computation of the score function, estimation of standard errors or confidence intervals, and also a multiplier bootstrap. In a general way, just using the score function. And this is then actually done in an abstract base class called double ML. And from this we can then inherit all the model classes. So the only model specific parts are then how this score function is actually implemented and which resource models we have to estimate using ML methods. And coming to what models classes do we have. So we have Philip introduced to us the partially linear regression model we see here on the left. But we also have other model classes. So at the moment we have four different models. And for example, if you wanna add an instrumental variable to your partially linear regression models, you can use the partially linear IB regression model. Or if you are interested in heterogeneous treatment effects, we have also interactive regression models. And all those model classes are inherited from the double ML abstract base class. And you can then, for example, also extend that by adding other model classes. So what are the main advantages of this object-oriented implementation of double ML? So first of all, it gives the user a very high flexibility with regards to the model specification. So you can throw in all the different ML methods you might wanna use for estimating your new resource functions. You can alter the resampling scheme. So how many folds are you using? How many repetitions are you using for the repeated crossfitting? You can choose among two different DML algorithms. And you can also choose among different name and auto-general score functions. A second key advantage is that our package double ML is easily extendable. So you can add new model classes by inheriting from this central abstract base class double ML. But you can, for example, also add other resampling schemes. Last, I wanna quickly advertise our online resources. So we have a website double ML.org. There you find like an extensive user guide and a lot of examples. But you can also, for example, see there that we have a Python twin. So if you are not only interested in R, but also sometimes use Python, that's also available there. And in addition, of course, have like a package vignette, which is available as an archive working paper. And with that, I'd like to conclude and wanna thank you for watching this video. And we are looking forward to the discussions at the USR conference. And as we have a bit of time left, I wanna quickly show you, we have two papers available for the two different packages. And on our website, you, for example, also find things like the double ML workflow. It's basically showing you how for a data example, you can use the double ML package and it basically guides you through the steps, the important steps to do, to use double ML for causal machine learning. Thank you. So thanks a lot, both of you. We're still waiting for questions. So please everyone type your questions. In the meantime, I would like to say, I really like the logo of your package. I would also like to know how you came up with that. But I can also start with a question on your talk. So at the end, you said that double ML is really easily extendable to other models, or all kinds of models. Did you get any feedback from people who tried to extend it and made good experiences with that? So I think I can take this, right? Yes, we already got some feedback. And of course, I mean, the paper by Victor Schoena-Zukoff on double machine learning, it's pretty general and it's a very general approach. So it's, I think, pretty common as a statistical framework that it's first developed in a very general way. And practitioners have to kind of adjust the details according to their analysis, right? So you have to cluster standard errors, for example, or you have to kind of, I don't know, you want to take some extension, some slight modification, you want to trim your propensity scores and all these little things that you have to tune and to parameterize in your analysis. And I think this is the part, like we are currently developing the package and we are going to integrate more and more of these kind of, yes, details that are more relevant or like there are not details in the analysis, but they are like relevant if you really work on a particular application. That makes a lot of sense. Thank you. So I see there's quite some questions coming in. There's also one of the questions that I actually had from Andy Pryk, where there are particular real world applications which inspired you to do this work. So we have some kind of experience. So we are here to check statistics and we already have some experience with using like basically Lasso-based methods for causal inference and practice. So, and then the natural development or extension was generalizing it to this double machine learning approach. We basically can use any kind of learning. And then of course we're curious and what to find out if everything works well. And yes, and then this is how we got to this problem. So actually it was kind of, of course given because we wanted to use all these machine learning stuff in applications. Great. I see a more like productive question from Carlo, I guess. You're combining machine learning and statistics. Do you want to conquer the world? I don't know how to answer this question. You can help me out on this. So we don't have plans to conquer the world. We just want to, I don't know, try to combine these two different literatures because they are of course relevant. And I mean on the one hand side, the machine learning literature is developing very, very quickly. On the other side, there is more and more happening in causal inference and there are more causal models appearing in that stuff. So I think conquering the world is like the super, super big goal. Even like keeping up with the pace of publications. This is kind of a still challenging goal. So I think we try to be productive at all. Yeah, maybe we can come back to this after the last talk. So I invite Liz again to present our last speaker. Thank you for the questions. Our next speaker is Jan Ma from Tsinghua University in Beijing. And he is going to talk to us about his package called Copent for estimating copula entropy and transfer entropy in R. Let's see what he says to say. Hello users, I'm Ma Jian. I got my PhD from Tsinghua University majoring in computer science. The title of my talk is Copent estimating copula entropy and transfer entropy in R. In this talk, I've introduced the package Copent, a package for estimating copula entropy and transfer entropy. This work is part of my PhD thesis. The Copent package was first developed during my PhD study. This is the content of my talk. In this talk, I will first give a brief introduction on background of copula entropy. Next, I will introduce the implementation of the package. Two examples will be followed next. One are wearable selection, the other on casual discovery. Finally, summary and some information. First, introduction. Statistical independence and conditional independence are two fundamental concepts in statistics with many applications. Copula entropy is a mathematical concept for multivariate statistical independence, which I proposed during my PhD study. I also proposed a non-parametric method for estimating it in my PhD thesis. Transfer entropy is a tool for measuring casualty. It generalizes the famous grandeur casualty for nonlinear cases. Recently, I proved it can be represented with only CE and therefore can also be estimated non-parametrically via CE. The copland package in R implements the above method for estimating CE and TE. This talk introduces the implementation of the package and then compares it with the other related packages. This slide is for copla theory. Copla theory is about the representation of multivariate dependence with the so-called copla function. At the core of the theory, I discuss theory as shown on the slide. With the coplas theory, we give the definition and the theorem in the theory of copla entropy. We first define copla entropy, a type of Shannon entropy defined with copla density function, with an proof of the equivalence between mutual information and copla entropy. The theorem sees that mutual information is actually an active copla entropy. The difference is that mutual information is defined for bivariate cases and copla entropy is for multivariate cases. Copla entropy is an ideal mirror for statistical independence with several good properties that the other mirrors don't have, such as multivariate, symmetric, non-negative, equal zero if and only if in the independent cases invariant to monotonic transformation and equivalent to traditional correlation coefficients in Gauss cases. The table on the slide compares copla entropy with two other famous mirrors, distance correlation and HSIC. We can see that copla entropy had several advantages over the other two. This slide forms the method for estimating CE. A well-known estimating mutual information is considered as notoriously difficult. Here we propose a method for estimating mutual information or copla entropy based on the theorem just mentioned. It's simply an elegant composal of two simple steps. First, estimating empirical copla density function with run statistic. Then the problem became an entropy estimation problem. Among the valuable method, we propose to use KN method for estimating entropy. Because both steps are non-parametric, so the final method is non-parametric. It has several advantages as shown on the slide. Police refer to the paper on the slide if you're interested in more details. This slide for estimating transfer entropy. The transfer entropy is an important concept for marrying casualty. It is essentially conditional independent testing. It has wide applications in different fields. However, estimating it is also difficult just as the mutual information. Recently, I proved that transfer entropy can be represented with only C as shown in the equation five. Transfer entropy equals to three C terms with this representation. We propose a non-parametric method for estimating transfer entropy. Compose those two simple steps. First, estimating the three terms in the equation five and then calculating TE from the estimated C terms. After the theory, this slide is for an overview of Copenhage package. It implements the methods for estimating couple entropy and transfer entropy. The latest variant is 0.2 and includes five functions of the least C on the slide. I will introduce them one by one. This slide is for the three functions for estimating couple entropy. The method for estimating couple entropy composed of two steps. So we have two functions for each step. Construct empirical coupler. It's for estimating empirical coupler density. And ENT-KNN implements the KNN method for estimating entropy. Here for estimating couple entropy from empirical coupler density from the first step. And the main function, copent, is with two line codes calling for above two functions. For user's convenience, the copent function returns negative coupler entropy. CE is the function of testing conditional independence. It's simple, just estimating three C terms and calculating the result. Transcend is the function for estimating TE. It is also simple. Just preparing the date according to the argument line which is for time line. And then calling for the function CI because transfer entropy is essentially conditional independence. Now let's demonstrate the usage of the package with examples. The first example is on variable selection. The paper and the code for this example are listed at the bottom of the slides. Variable selection with the copent entropy simply to select variables based on the rank of the association between variable and the target measured by copent entropy. There are several other related measures in R such as HSIC in DHIC package. Distance correlation in energy package. HHD test in the HHD package. Hoffman's D test and the Buxma Dysos T star sign covariance in the independent package. And ball correlation in the ball package. We will compare them in this example. The date used here is a HHD state in the UCM machine learning directory. It contains four databases including 899 samples without missing values. And each sample has 76 samples attributes of which the number 58 is for diagnosis. And 13 attributes of them are recommended by the professionals as a clinical relevant. The goal of the example is to select attributes for predicting diagnosis. We load data from the UCI server directly with the code on the slide. Here is the main code for the example. We call the functions for all the measures in R packages. With this code, we estimate the dependence between the attributes number 58 and the other attributes. This slide shows the figures for the selection result with the six measures. The red line in each sub figure is for the dependence between number 58 and the number 16 attributes which is the selection threshold for each measure. This slide for the interpretability of the selections. We compare the selections with the recommended variables to check the number of the selected recommended variables. We see that couple entropy selects more than the other members did. Next is the example on casual discovery. The paper and the code for this example are listed at the bottom of the slides. Casual discovery is to infer casuality from observational data. Here we will infer casuality by estimating transfer entropy with the Copenhage package. There are also other R packages including coronabase conditional independence in the test package, conditional distance correlation in the CDC SIS package and the conditional dependence coefficients in the FOCI package. The data used here is the Beijing PM 2.5 date also from the UCIW tree containing the hourly observation lasting five years. It has several meteorological factors. In this example, we use the pressure factor. To avoid the meeting value, we use only a part of continuous observation including 501 samples. Here is the main code of the example. We estimate the casual strength from pressure to PM 2.5 in one hour to 24 hours. We first prepare the data according to the lag hours and then call the function for each measure. For transfer entropy, we have two ways of doing the job. We can call the function transcend directly or we can call the function CI with the prepared date. This slide shows estimation result with different measures. We can see that transfer entropy, CDC and the codec has similar results. Now let me summarize the talk. First, I introduce the background of the Copenhage package. Then I introduce the implementation of the package. Next, I use two examples to demonstrate the usage of the package and compare it with the other R packages. This slide shows the reference for this talk. And this slide shows the software. The Copenhage package in R and Passen are now available on Cron and the PYPI respectively and also on my GitHub. And finally, let me show my electric car, a golf I named Corporal Entropy. I enjoy the power of Corporal Entropy on my way to office and also in my office. Corporal Entropy really gave me a lot of fun every day. I hope you can also enjoy it with the Copenhage package. Thank you for your listening. Thanks a lot for your talk, Tian. Thank you. So there's no questions from the audience yet, if I sound correctly, but let it come, please. But I can start with a question. Which one should I choose? So for example, for the variable selection example that you had, you compared different methods or different R packages and showed the results. And the popular entropy framework selected more variables than the others. So is there a reason for that? Can you explain that? I think I can explain from theoretically and practically. So actually, I think the Corporal Entropy is defined rigorously. I think it's an ideal mathematical concept for statistical independence measures and compare with other theoretical tools. I think it has the advantage over others. And for the method estimating those measures, I think our estimation method is non-parametrically. So it's model-free. It can be applied to any method. And it also takes advantage of the Corporal function, which can make our estimation method more stable and more reliable. So I think I answered your question from these two aspects. Thank you. Also regarding the same example, since you showed or compared these different methodologies, did you also compare the predictive performance of the different models that came out of the different frameworks? Yes, I did. In another paper I showed in the reference slice, there is a paper titled Variable Selection with Corporal Entropy. In that paper, I showed more details on these examples. After we select variables, we compare the predictability of each models. And the model built with Corporal Entropy also presents the highest predictability. Great. I see a question now from Martin Mechler. He also gave a comment in the questions that you can look at that they also in the current package Coppula provided or estimated the empirical Coppula. And then the question is, how do you tune the smooth thing when estimating the empirical Coppula? Estimating empirical Coppula is very simple. It's just use the round statistics and divide it by the sample size. We call the empirical Coppula. That's very simple. Just two or three lines of code. We can down the drop. I hope that answers your question, Martin. Otherwise, just ask another one. So we have two more minutes reserved for you. So I can ask another one of my questions. OK, he actually said that he thanks you and found sometimes. So they found in their package, I guess, that sometimes it needs tuning the smooth. Yeah. OK, so I don't know if you want to go on with that. But otherwise, my question would be, so you also implemented your method in Python. Do you see advantages to R or why did you do that? Because I think our estimation method is made sure to be applied to more areas. So I have applied it in my project. I have applied it to several projects successfully. So I think maybe Coppula entropy can be applied to the much larger Python community. We can use Coppula package. And also, I see many Python users have used my package in their projects. I got many feedbacks from them. That's great if it's used. That's why you need it, I guess. So I believe now we're in the global or Q&A part of this session. So I invite all the speakers to come back to the stage and switch on the cameras if they want. And I invite all the participants to keep on asking questions also in Slack. So, Liz, do you have a question that you would like to ask to one of the speakers before I go? Yeah, go for it. OK. Go for the... All right. So I hope that I give them now to the right speakers. I tried to write it down, but I'm not 100% sure if I did this correctly. So I guess the first one that I would like to ask is goes to Jakub from Anastasia. Do you think that unsupervised algorithms can also be biased? Well, I guess so. I guess it's because we have some data. We make this unsupervised learning. We are, for example, clustering something. And we measure the distance, for example, between the clusters, maybe in such way. But I didn't focus my research on unsupervised learning. So I don't know if there are some, for example, like packages and maybe more research methods on this topic. Thank you. Also, if the other speakers want to jump in, that's totally fine. Yeah, I think we're going on with bias. So I guess it's also again for Jakub. Are you testing the biases removed model against a separate data set or can you use cross-validation? You can use, I guess, some different data. For example, you may use, like, train your models on training data and, of course, evaluate this on the test data. And you can measure fairness on this test data, of course. I don't know if it answers your question. But also, in for models, you can just use different, for example, columns or different preprocessed data, et cetera, as long as the target variables match. And you are predicting on the same, for example, set of people or instances. Yeah, and then, like I said, there's another question for you. Is there any particular stage of collecting and analyzing data when we should start paying attention to bias detection? I guess the most focus should be put on the data gathering and thinking about what features do we need to get into this data to predict the outcome. Maybe some features like the gender or the place of where does this person live, et cetera, et cetera, and some correlated variables, like the zip codes, which may indicate where someone is from. I guess this is the setting of the data gathering and all the things that you have to do before making your machine learning model. This is the most important in my opinion. I guess you have to keep it in mind in all stages. Yeah, thanks a lot. So I do have a couple more questions anyway. And Liz, just if you have something, just take the floor. Are you looking on Slack as well? There's, I think, nothing. There's a couple of people that are interested, which is good. But yeah, I mean, maybe Malta and Philipp, can you give us another real data example where you applied your methodology? Yes, so what we did to kind of, as a first test of our package and everything is, so in the original paper by Victor Shamsukov, where he developed the machine learning approach. So it's 2018 in the econometric journal. Then he has an application on where you can estimate the causal effect of eligibility or the participation in certain pension plans on your net financial assets. And this is what we replicate and we have it online on our website so you can go through all the single steps, how you can estimate, and then you can basically also compare the results to what they have in the paper, also the data set has been used in other publications as well. So you can kind of see, like, you can find out what's the important part. So do the parameters vary in some way? Do your results change if you have different burners or if you change something, if you use only a subset of the data, anything. So we have one example. And also we are working on getting the package run in more and more applications so we're currently working on this and they will all be published. And also we have been yet where we go through some examples. So in case you're interested in seeing how it works, what's the idea? Because I think in our talk we're rather generally talking about general method. So maybe it's nice to see some more hands-on example and that's what's available online. So in case you're interested, have a look. It's very good to know. Yeah, I would have another question for Sian. Also regarding applications, maybe can you name an application or a case study where the copula entropy framework is favorable to other methods? You're muted, sorry. Let me mention hydrology. That means water resources and management. Copula entropy is getting more and more popular in that area. Many researchers in this area apply copula entropy in their problems. So I know one researcher from, I don't know how to pronounce it, Lisbon. Lisbon? Yes, one researcher from Europe apply our method in their projects to manage resources from Brazil. And also in my country, many researchers from different universities use my copula entropy to design water resources stations, network, and many other applications in these hydrology areas. So I know many other areas also apply our methods, but due to the time, I don't know much more. Thank you. Thanks a lot. I mean, you can also put some links maybe on Slack so that we get a better idea if you want to. Yeah, so there's still no more questions coming in, but now I just dare to ask about this logo. So for this, it's actually two rhinos on the logo. I was wondering why? How come? Very nice question. So it's basically something like two-headed rhino, right? Yes, it was kind of hard to come up with a nice logo that illustrates the idea of the estimator. So the basic idea or the basic challenge was to visualize the double robustness property of the estimator. So we thought of something double and something robust. All right, so I have one last question for Jakub. And then I think we're done, I guess. But one of your first slides, you showed this, what I call it, this diagram to show the different steps of getting to a fair model. And there you actually presented the choice of the best model before the fairness check. And I was wondering whether what is the reasoning behind this ordering and whether it would also make sense to actually do the fairness check before testing which model is the best. Well, in this diagram, there was like, you have to do a fairness check to obtain this fairness object and then you can make a lot of visualizations on top of that. And my point was that if you have many, many models and some of them, all of them, maybe not positive this fairness check, maybe there is some metric or two metrics that are not met. But you may use some visualization techniques to obtain the model with the least amount of bias. Maybe not this fair model, but the best you can get in this situation, for example, because sometimes there may be not many ways to get rid of the bias without sacrificing the predictive power of the model. Okay, so I guess it's kind of a, yeah, you have to kind of wave over somehow. Yeah, interesting. Nice. Perfect. So thanks a lot again to all the speakers, four speakers of this session. And thanks a lot to Stefan, Stefan, sorry. Also behind the scene to taking care of the, all the technical parts of this session and list to introduce the speakers. So what is up next so you can enjoy some more social events going into trivia, which will happen at 315 UTC, and then at 415 UTC so quite soon you can enjoy another very exciting joint keynote on communication. So thanks a lot all of you, and see you in the next session. I'd also like to mention that if you are interested in this topic of modeling and data analysis, there will be another session on 9C will be similar.