 Hi team and welcome. I'm Jeff Walser, the Vice President of Exploratory Science here at IBM Research, and I'm really happy today to start with going to be a series of periodic talks we're going to be doing over the next several months. Hopefully many of you got to join our first Distinguished Speakers series with Yoshio Benjio a few weeks ago, and of course we'll continue to bring in distinguished speakers from outside. But as IBM researchers, we actually have the pleasure each day of working and collaborating with an amazing array of the world's most brilliant minds right here in the labs. Some of our colleagues have been recognized as very high honors by the external scientific community for making foundational advances which have transformed a technical area or an entire industry, or even for starting an entirely new field of research. In some cases we may work with these individuals for years without fully coming to appreciate the contributions that they've actually made to science and IBM. So these stories are an inspiring example internally, but of imminent careers of research and stories which we can all learn from. Therefore on occasion we'll be inviting distinguished members of our community to tell their story and what we're calling an IBM Research Special Seminar, describing their notable technical accomplishments reflecting on their career path and sharing the inspiration that made these possible. So today I'm excited to welcome Ron Fagan, IBM Fellow at the Almond Research Center. Ron is recognized in the computer science community as a founder of relational database theory and the creator of the field of finite model theory. He's also authored several work in the field of information integration and aggregation and of reasoning about knowledge. His work advanced both the theory and practice of modern computing systems, especially data management systems. Ron's key inventions used in IBM products include extendable hashing, differential data backup, and critical tools for database design. Ron has earned a long list of distinctions through his 47-year career at IBM Research. He is an ACM Fellow, an IEEE Life Fellow, and a Fellow of the American Association for the Advancement of Science. The work Ron has published with his colleagues has been awarded the 2014 Goodwill Prize and the 2020 Alonzo Church Award, some of the world's highest honors for research in theoretical computer science and logic. And he's a member of three prestigious national academies, National Academy of Engineering, American Academy of Arts and Sciences, and most recently the National Academy of Sciences. So that's a three-fer for the National Academy's forum. Ron is also known among his co-workers, anyone in Almond in particular, for his unfailing cheer and kindness. He's always a favorite with the interns who are in town. When we used to have all hands in the auditorium, he has a special seat right in the front where he could always ask the very first question after every talk. He's always open to answering questions as well. He's known as well for his remarkably quick wit and his remarkably slow driving speed as anyone can attest to the propulsion of the Almond and Hill. But today, Ron will share some perspectives on applying theory to practice and practice to theory, gained through the course of his notable career. In this talk, Ron will describe two case studies from his career, in which the mutual benefit close parallel aberration between theoreticians and practitioners, combined to propel significant scientific and technological advances. I'd also like to introduce Alex Gray, the VP of Foundations of AI at the IBM TJ Watson Research Lab. He'll be my co-host. Alex will be moderating the question and answer period at the end of Ron's seminar. Please use the Q&A panel in your console to submit any questions you have throughout today's session, and then we'll get to them at the end. So with that, I know we'll further ado. Ron, welcome, and thanks for sharing your experiences and inspiring story with us today. Great. Well, thank you so much, Jeff. Appreciate it. I was not ready for the driving part, but that's interesting to hear. Anyway, so hello, everybody. So, welcome to my talk. Now, the purpose of today's talk is to, a purpose is to encourage collaboration between theoreticians and system builders. I call them practitioners, but Laura Ha's objected. She told me, call them system builders. It sounds better. So system builders it is. And I'm going to do this, as Jeff mentioned, with two case studies. One of these case studies was initiated by the theoreticians and the other by the practitioners. Now, there's several messages here for theory people and one message is how to apply theory to practice and why this leads to better theory. And for practitioners or system builders, the value of theory and the value of involving theoreticians in your work. So in the first case study started way back in 1996, garlic, and Laura Ha's came up to me. Now, Laura Ha's at the time was just a first level manager, but later on she became an IBM fellow. She became the director of computer science. But she knocked on my door one day way back in 1996 and said, okay, Mr. Database Theoretician, we've got a problem with garlic, our multimedia database system. Now, what was Laura's problem? Well, here's what it was. So garlic is a middleware system. It's on top of other systems. So it's on top of things like DB2, which is a relational database system, on top of cubic, which is queried by image content where you can query on the basis of color, shape or texture, and top of other stuff too. So, so now the problem we're ahead was that the answers were not compatible, which is getting the answers and DB2 were sets. And we'll see an example in a second, whereas the answers in cubic are sort of sort of like what you get in Google, you know, you get a list of answers, you don't get a set. So, so now, so let's look at an example. So let's say we have the CD database, and you're searching for artist equals the Beatles, say DB2. So you get DB2 won't have this fancy thing appearing, but you would get a set of albums. Now this is from MusicBrainz, which has 12 million CDs in its collection. Now, so let's say we have the query album color equals red. Well, you get a certain list. And here's your history should get back from MusicBrainz. The reddest thing first, I guess counting red pixels and with a redness score there. And so now, how would you make sense of a query like artist equals Beatles and album color equals red? Well, you'll say, come on, Ron, big deal. We'll just have a list of albums by the Beatles, sort of by how red they are. What could be easier than that? Okay, smart person. What about artist equals Beatles or album color equals red? Not at all clear what you do, is it? And how about, let's say we're doing this multimedia query color is red and shape is round. How would you make sense of that? How would you give an answer to that? So that's what I dealt with. So what was my solution? Well, first of all, it's often the case that when a practitioner asks a theoretician a problem, they give out something important. And what Laura left out was that these weren't just certain lists, they were scored lists. You saw with the redness thing, there was a score there. I thought, aha, scores. And so I thought, gee, now we're in there, we can match these things up. Sets are scored lists also. Zero if it's not in, one if it's in. So they're both scored lists. So I can combine these scored lists. Wonderful. And that reminded me of real valued logic. Some flavors of that are called fuzzy logic where things have scores, not necessarily zero or one, but in between zero and one. And you deal with that. Now in real value logic, conjunction is often taken to be the man. This is what was the original motivation in doing fuzzy logic by Zada. He took conjunction with the man and disjunction with the max. The people use other rules and other real value logics. So then I said, great. I went back to Laura and said, Laura, good news. I've got a solution for you. Use real value logic. I was happy. I thought I was done. And Laura said, well, hmm, she says, you know, I like your solution. She said, but you know, we need a practical algorithm. We can't just look at every object in the database, get it, say, ready to score and round the score if that's what you're looking for. It scores in every attribute. And use real value logic. We just can't afford that run. We need an efficient algorithm. So I thought, hmm, so I scratched my head, came back to her a couple of days later and said, Laura, good news. I've got an efficient algorithm instead of winning your time. And we're ends in number of items in the database where you have to look at everything. It's squared event. So you can use squared event accesses and get the top K. So that's great. I was very happy. But Laura said, and I'll never forget her answer. She said, good. She said, certainly better than linear. She said, but you know, we database people are spoiled. We're used to log in things like B trees. So she said to me, and I really will never forget it. Be smarter. Go get me a log in algorithm. So I thought, hmm, so scratch my head, came back to her a couple of days later and said, guess what, Laura? I can prove you can't do any better than squared event. That's it. No better algorithm. She said, fine. Okay, we'll take it. And they implemented it in garlic. Now the, let's just see the difference between n and squared event time for the accesses. Let's go back to music brains with this 12 million CDs. So now if you've seen the thousand accesses per second and you know, searching every item of the end items, the database would take in the naive algorithm and take about three hours squared event, about three seconds. So it's a huge way to do square event versus add. So generalizing the algorithm. Well, you know, we see your dishes like to generalize things. So the algorithm would work not just for men or anything like that, but any monotone scoring function, one where if you increase the scores, you can't decrease the overall answer. So influence. Well, first of all, the algorithm was implemented in garlic. And it's influence a number of IBM products, including ones on this list. Watson, a bundle search system, infrastructure, Federation server, Webster commerce and others. So it influence a number of IBM products. And the paper that interests the algorithm, which by the way is now called Vegas algorithm has about 2000 citations, according to Microsoft academic. By the way, I use Microsoft academic instead of Eagle scholar because it gives more and gives a bigger number. They search more stuff. So, you know, why not give the bigger number? Okay. Okay. See a comment on the screen. I can't read it. Okay. So now. So now something happened though in 2001. So I'm not a lot of money. Now our and I came up with a new algorithm, which we call the threshold algorithm. And just to just tell you the algorithm. I'll tell you what the problem is. Just be more concrete. So there in other M attributes, let's say a redness and roundness will take M to be two in our example. And every object has a score for each of these attributes. It's got a redness score and a roundness score, for example, in our example. And now. So we have in sort of the list, like a redness system around this list. And. And now our goal is to find the top K objects according to some monotone scoring function while minimizing database accesses. That's our goal. That's, that's the problem. So here's an example. Here's a table with redness and roundness. So object 177 is the very reddest objects. It's got a score of .993. As you see in the upper left, in the bottom right, you see it's not so round. It's got a score of .406. So it's a little bit round. In the upper right corner, you see object 235 with a roundness of .999. That's probably a circle. But in the bottom left, you see it's not so not so red. There's its redness score. So, so now. So now let's talk about scoring functions. So let F be a scoring function. So as I said, the one commonly used, like Zata used in fuzzy logic was min. There's many others you can use, one of which is average. It turns out that in real life they've done psychological studies on people. And when you use average and give the answer with the highest average, people like the answer better. So average is a good, good choice. So let X1 through Xm be the scores of object R. It's redness score and it's roundness score, in our example. And then F of X1 through Xm, you apply your scoring function F, is the overall score. We may write that as F of R. So that's the score of object R in this, under this function F. And so now, now here's a formal definition of monotone. A function F is monotone. If whenever the XIs are less than or equal to the YIs, then F of the XIs is less than or equal to F of the YIs. So modes of access. Well, a cube is limited in its access. It has two flavors of access, sorted access, where you say give me the reddest thing, the next reddest, the third reddest, and so on. That's sorted access. And also random access. Maybe you just saw some object with a high redness score. You say, what is this roundness score? So you can go ask, what's the roundness? You can go ask for that. And now our goal is, I said, to minimize the number of accesses to the database. So we want an algorithm to find the top K object. K is 10, for example. Now, the naive algorithm goes and looks at absolutely everything, finds the top K, and gives the answer back. But that's way too expensive where it made very clear to me. So we wouldn't do better than that. So here's the algorithm that we came up with. And then look at Moni and I, the threshold algorithm. So how does it work? Well, it does sort of access in parallel to each of the lists. So it does a sorted access to the redness list and to the roundness list. And then as soon as you see an object under sorted access, in one of the lists, you go get a score in the other list. So if you get an object appeared in the redness list high at the list, you go get its roundness score. And then you can compute its overall score, because you have all of its values and all of its attributes. So you get its overall score. And then if this is one of the top K objects you've seen, great. Remember it. This is a candidate for the final top K. It's one of the top K so far. And you throw away anything that it replaces. So you have your current top K list. And now we need a stopping rule. When do we stop? Well, for each of these objects, you see, for each of these lists, I let T sub I be the last object you saw under sorted access. In the redness list and the roundness list, you have those, the scores. And then you define the threshold T to take your scoring function F and apply it to those thresholds. Now, that is not the score of any object, but still it makes mathematical sense. You can apply F to these numbers. And we'll call that the threshold T. And here's our stopping rule. As soon as you've seen K objects whose overall score is at least T, stop and output your current top K list. That's the algorithm. So let's see why it's good. First, let's see an example. So here we go. So here's the redness list and the roundness list, object 17. We got the top red, the redness object and the roundness object. And now for the top red object, you get a score in the roundness list down there at that bottom right. And for the top object you've seen so far in the roundness list, you go get its redness score. And then you compute their overall scores by applying your scoring function F to them. You get their overall scores. So we're saying min for simplicity in our example. So object 177 is the min of 0.993 and 0.406. So 0.406, so that's its score. And this is the threshold so far. You take the scoring function F, which is the min applied to the last things you saw in started access. So it's the min of these two numbers, 0.993, 0.999, which is 0.999. And you keep on going. And you keep doing that process. And you'll notice the threshold keeps dropping. Now it's the min of these two smaller numbers. You keep going. And now it's the min of these two smaller numbers. So the threshold keeps on dropping. And you're watching carefully to see if you have k objects whose score is at least that threshold. So now let's say, why is this halting real correct? Why is the threshold not successfully stopping then and not making a mistake? Well, suppose you have k objects so far whose score is at least t the threshold. What could go wrong? Well, what could go wrong is you have some object r you have not seen yet somewhere deep in one of these lists. You have some object s in your top k. But the score of r is bigger than the score of s. Then you've screwed up. So let's show this bad thing cannot happen. You cannot screw up like that. Well, let's say r has scores x1 through xm. It's got a written score and around the score. So now, since you haven't seen object r yet, the xi is less than or equal to ti. You haven't seen it yet. So in each of the lists, its score is less than that threshold value ti for that list. So now we're going to apply monotonicity. The score of object r is f of these xi's, which by monotonicity is less than or equal to f of the ti's. Well, my definition, f of the ti's is the threshold t. And now we know that the score of s is at least t because that was in our final stopping list. So we stopped when this object, we had k objects whose score was at least t. So, but now you see there's a contradiction. Up above we have f of r is bigger than f of s. And down here we have f of r less than or equal to f of s. Contradiction, so this bad thing cannot happen. So indeed the stopping rule is indeed correct. So now we found this wonderful notion in working on the threshold algorithm, something we call instance optimality, a wonderful magical property of an algorithm. So we tell you what it is. So let's say A is the class of algorithms, legal algorithms for a problem. D is the class of legal inputs. I'm thinking of these as databases. I may call them databases. Now for each algorithm A in the set of A algorithms and D in the set of inputs or databases, it's got a cost of applying algorithm A to input D. And this cost may be the number of accesses. It may be time. It may be whatever. We have some scoring, some cost. And now here's what it means to be instance optimal. So this algorithm A in bold A is instance optimal over bold A and bold D. The set of possible algorithms and possible databases. If there's some constant C1 and C2, such that if the adversary picks an algorithm A prime and the adversary picks a database D, that's his choice, the cost of running your algorithm on the adversary's database is less than equal to C1 times the cost of the adversary running his algorithm on his database plus C2. I mean, that's pretty heavy duty because the adversary can fine tune his algorithm to his database. He can fine tune his database to his algorithm. A pretty brutal condition to have to be able to do that. And we'll refer this number C1 as the optimality ratio, this multiplicative factor. So now I'm claiming the threshold algorithm is instance optimal. So now you might think that follows because you might say, well, the next object you see might have score equal to the threshold values. So this is why you can't do any better, but unfortunately that doesn't quite go through. Wife is a little more delicate. So we need another notion that I'll tell you about that we're going to forbid, something called wild guesses. So wild guesses is you ask for a score of an object you've never seen before under random access. So not something you've seen under sorted access, but for some reason just out of thin air you say, you know, I'm out of the blue, I've never seen object 393, but tell me it's redness score. That's a wild guess. You have no good reason to do it. It's not appeared in any of the lists. That's a wild guess. Now neither thing is algorithm or the threshold algorithm make these wild guesses. And in fact, your system may not even allow wild guesses. So now here's the theorem for every monotone F, A be a class of algorithms that are legal. They always give the right answer for every input and it does not make any wild guesses. Then and D is a class of all inputs or databases. Then the threshold algorithm is is this optimal over these. So we actually a theorem proving it is is this optimal under this assumptions. The only tricky assumption is no wild guesses. Now, oh, I went up. Oops, let me back up a second. Sorry. So sorry about that. So now the late David Johnson came to my office one day and I was very proudly told in this theorem about this is optimality. And he said, you know, Ron, he said, I would have a stoner notion of this is optimality, not only the stuff you say, but it's got to have the best possible optimality ratio that constant C1. I thought, oh man, that's an interesting hard problem. So I went back to my office or the next day and I found the optimality ratio. It's this complicated thing. M is a number of lists, like two of its radius and roundness. C sub r is the cost of random access, C sub s is the cost of asserted access. This is the optimality ratio for the threshold algorithm and I proved it's best possible. So it's among all its optimal algorithms. So it's it's optimal in that strong David Johnson sense. So then, great. I went to Laura said, Laura, new algorithm, threshold algorithm, even better than thinking it's algorithm, because it's optimal in its stronger sense. It's not a worst case sense, the usual method, or average case, but in every case, it's optimal at every instance. And Laura said, Ron, we implemented your algorithm all over the place. You told me it was optimal. What's going on? I said, well, Laura, there's optimal and then there's optimal. So that was the way it was. Influence, well, so we submitted this paper to PODS 2011. It's the top database theory conference. And I was really worried. You saw the threshold algorithm. It takes about 11 lines to write it down. And I thought, man, oh, man, the program committee is going to look at this and say, are you kidding me? We're the top database theory conference and we're going to accept a paper with an 11 line algorithm. Forget it, reject. So I thought, how am I going to get around this? So I thought, aha. So what I did is in both the abstract and the introduction, I called it a remarkably simple algorithm. Turning a bug into a feature. That's something good to remember if you're trying to get a paper accepted in the conference. Turn the bug into a feature. A remarkably simple algorithm. And the paper not always accepted, but it won the best paper award. So it really, really worked. The paper was very influential. It's got 3,800 citations. It won the Test of Time award 10 years after the conference. And I won the IEEE Technical Achievement Award for figures, algorithm, and threshold algorithms together. And then the biggie, the Gertel Prize. This is the highest prize for paper at theoretical computer science. And this paper won the Gertel Prize. You can't do any better than that for paper at theoretical computer science. And I've mentioned that there's something called Jim's of Pods. They looked back over the last 20 or 30 years and said, what are the best papers that have ever appeared in Pods? Let's have it in 2016, but the very first time they did it. And this is one of the two papers selected. And they totally by there was a top rate among those two for Jim's of Pods. So it's got a gazillion applications. I'm certainly not going to read this to you, but one reason why it's been so influential and one reason around the girl prize is people use it all over the place in many, many, many different applications. Measures of success. Well, making our products better. That's certainly a ultimate measure of success for a practitioner. Creating a new subfield that is an ultimate measure of success for a theoretician. And so we did both of these. And if I want to make an argument to a theoretician, you will do a better theory if you just talk to those practitioners. I cannot make a stronger argument than this. Here's a paper that arose from a very practical real world problem and by golly it won the girl prize. What more could you ask? I mean, that's strongest argument I could get to a theoretician. Talk to those those messy old practitioners. Second case study. Clio. So, now Clio deals with data exchange. I'll explain in a moment what that means. Where you convert data from one format to another. Now, Laura has left garlic and after it's successful and implemented and started Clio. And I followed her. She was my manager. I was in the theory group, you know, I had a wonderful success with Laura before. I will start going to Laura's meetings and I actually sat in Clio meetings for a full year. And then something happened. So four of us, Vicki and Colitis, Renee Miller, Uchin Popa and I said, look, let's do how we do data change from scratch. If we didn't have any, you know, thing that all this worth has gone into Clio, just start from scratch what we do. By the way, Renee Miller is very sensitive about data change. She doesn't allow her picture. She will not allow her picture to be public. So that's a picture Renee Miller aged three. So she allowed me to use that. So she was not a child prodigy. That's the picture she allowed me to use. So data exchange. So you have a source database and a target and you're trying to convert data from one format to another. I'll give you an example in a second. So here's the example. One of them has an employee manager relationship and the other has an employee department department manager relationship and we want to merge these two. So we want to somehow combine this. So here's what we're going to use data exchange. What do we do? So now there's something called double generating dependencies or TGDs which has been used in the past for a number of contexts, including normalization and this is what we're going to use to describe it. As I said, it's originally used for other senses. So here's the double generating dependency or TGD we'd use in this case. We say if a double EM is an employee manager relationship. So employee manager M. If there's some department D where employee E is in department D and department D is managed by manager M. So now here's an example. We have this database here. Gertl is reporting to Hilbert Turing and Hilbert is reporting to Gauss. Now I'm going to give you three possible databases that you can convert this to and you're going to think about which one you want. Now if I were doing this in person which I might give this talk in person I'd make people vote. I say here's the three answers how many vote for number one, number two and number three and people don't do very well on that but here you have to privately vote yourself and see how you did. Okay so here's solution number one. So we name the department after the manager we say Gertl is in the Hilbert department which is managed by Hilbert. Turing is in the Hilbert department, managed by Hilbert and Hilbert is in the Gauss department, managed by Gauss. So that's solution number one. Solution number two you create these dummy values D1, D2 and D3 and you say okay Gertl and Turing are in department D1 which is managed by Hilbert and Hilbert is in department D2 managed by Gauss. So that's solution number two. So solution number three you say well wait a second just because Hilbert is a manager of both Gertl and Turing they may be in different departments maybe this guy's managing several departments so we have D1, D2 and D3 Gertl is in D1 Turing is in D2 Hilbert is in D3 and D1 and D2 are managed by Hilbert and D3 is managed by Gauss. So decide for yourself what your solution is. Would you take number one number two or number three? So we have good reason for which one we choose. We have this notion that we call a universal solution. A universal solution is something that is as general as possible makes as few assumptions as possible. In this case solution number three is the universal solution for example it's not assuming that each manager manages only one department. Now if we had this other restraint that says here that each manager manages at most one department then in that case we would say solution two was the universal solution. Okay now how do we obtain a universal solution? Well there's this well known method called the chase. It's been used for many many years in database design and used in normalization theory in other places and so we're going to use the chase to create the universal solution. So how does it work? So let's go back to our TGD TumbleToonerIndependency that says employee manager manager relationship with department D where employees in department D and D is managed by M. So what we do now is we take each tuple in that first relation like Gerdo Hilbert and now we create this W value D this so-called label null and say Gerdo's department D and D is managed by Hilbert and these are called label nulls so that's what we do and then if there happened to be the EGD is like each manager manages at most one department you equate some of these label nulls you equate both the label nulls dealing with the same manager. So now something else happened when you have a problem many problems arise afterwards so one day we should public came to my office and said Ron we got another real real problem with these mappings. He said we use these TGDs to go from schema one to schema two and we have these TGDs going from schema two to schema three. How do we describe how you go from one to three directly so my first thought was well there's going to be another TGD it's more complicated than you know complicated but still some other TGD will describe directly how to go from one to three. Now let me remark that TGDs are very special cases of formulas of first order logic. If you know the first order logic and you saw it from running down to use his first order quantifiers for every X and stuff like that so this but here's what we discovered. So Fouquien, Colitis, Lucian, Popo, Wang, Chutin and I studied these things and we found the following it's a very surprising thing when you compose these things you leave first order logic. So to use it in this simple TGD a special case of first order logic from schema one to schema two uses very simple TGD from two to three but going directly from one to three you need second order logic where you quantify over sets and over relations and over functions. That was quite a surprise. And so we invented something we called second order TGDs which is a very special case of second order logic and we showed that this exactly does a job that you compose schema mappings with TGDs and given any second order TGD it's resulted in composing first order TGDs normal TGDs and so so now we gave an algorithm for doing composition for computing these so measures of success well our first of all our stuff is used in these various IBM products that I've listed here DB2 control center rational data architect and control manager by use I mean the following so first of all they use universal solutions they decided that's a good answer the result we're going to take will be a universal solution people weren't doing that before even at Alamedin when they were working this originally they were doing kind of crazy solution sorry and but they weren't universal so they not only used our our universal solutions but they used our algorithms they used our algorithms for producing universal solution and they used our algorithm for composition so it was really heavily used our stuff now our paper our initial paper won the test of time award for the international conference on database theory that's like the second best database theory conference that's when we submitted that paper to and now something funny happened I got a letter one day from the editor chief of the journal theoretical computer science which is where the journal version appeared he said congratulations your paper was the second most highly cited paper of the decade of papers that appeared in theoretical computer science so great but I just out of curiosity I sent him an email saying okay what was first he said well it was a survey paper we felt a little bit bad about giving it the top number one but we had to it was in the journal so what could we do so that was the top rated paper now our paper on composition won the test of time award for international conference on database theory ten years after it appeared and I wrote a follow up paper with two other people Marcello Arenas and Alan Nash that won the best paper award for another international conference on database theory this was a follow up paper on composition that showed some surprising things that like a second order TGD can be taken by composing only two first order TGDs you didn't need some large number of them but anyway won the best paper award influence well this created a new subfield you know I told you that's a great measure of success for theoreticians in fact every major database conference suddenly had sessions on data exchange and now here's something that Jeff mentioned that made us very happy that we just won this award the Alonzo church award which is given for outstanding work in logic and computation they can look at a paper a body of papers they look over a 25 year period and see what's had the most influence and we won by the way I was told that in these committees that normally people look at things near the borderline like if it's a 25 year period they get paper that's about to expire because they want to give that paper a chance so ours was way less than like half of that roughly and yet we still won which is really great so before I go on to very recent work I was told to put in a slide here on very recent stuff so I did that but first I want to say one more comment and that's the following so one important issue is to figure out what the real problem is that theoreticians have to do, practitioners have to do what is the real problem so I want to read to you a quote from my academic grandfather Albert Einstein pretty impressive academic grandfather and in the Q&A I'm hoping someone will ask me Ron how was your academic grandfather and I will answer that question but let me read to you Einstein's quote this shows by figuring out what the problem is is important Einstein said if I had an hour to solve a problem and my life depended on the answer I would spend the first 55 minutes figuring out the proper questions to ask for if I knew the proper questions I could solve the problem in less than five minutes that's what Einstein said what more do you want this is a quote from the great man Albert Einstein himself okay so now recent work so I was told to add to this one more slide about what I'm doing very recently and I'm very happy to do that very recent work, very very recent like in the last few months so I'm working with Alex Gray department on Neurosynbolic computation and one of the important issues that arise there is real valued logic because you have uncertainty so you have inputs and neurons and they have scores between 0 and 1 it's like a measure uncertainty or probability these things we wanted a logic for dealing with these for dealing with this combining how much does this uncertainty affect that uncertainty now it turned out that what people have done in the past was the following a very weak form of axiomization they found a bunch of things that were tautologies in their logic they were always true in their logic no matter what truth values you assign to these things and from that they could prove everything else that was a tautology that was proved not good enough for us this uncertainty implies that uncertainty and I did that very very first example soundly complete means everything that proves is correct and anything that something is an implication of other things you can prove it in your logic so I gave the very first one that shows this amount of uncertainty here that amount of uncertainty there how much uncertainty does it yield here by the way I read this by some experts in the field experts in real valued logic that says has anyone ever done this no no no it's the very first time anyone's ever done that so I was very very happy the very first soundly maximization that deals with complete this uncertainty implies that uncertainty so that is my recent stuff so that's it and we will be in an archive paper we're still having to put the final version in an archive but if anyone wants a copy I'm thrilled to send you a copy of it and any questions of course I'd be happy to answer either now or later on so that's it that's my talk thank you very much