See if we have anything running at all, this should be a bit louder. Just moving the microphone around, see what difference it makes. Yeah, we should be here live, start in a second, yeah, I'll just assume all the streams are working. The microphone, yeah, we seem to be using the correct mic, that's good. This session is meant to be interactive, so please do comment, questions, suggestions, especially if you checked Bionicales.com, that will be highly appreciated. We'll start in a sec, start developing in a second. But yes, as you imagine, this session is meant to be interactive, so do make comment suggestions. So this last stream will actually be potentially better if you do minimize all the windows that I don't need anymore. What Chrome is using quite a bit of CPU, and that's a bit odd, I'll do, yeah. The last streaming on three platforms, YouTube, was where I always, that's the platform of choice, a priority. I'm still trying to get monetized on YouTube. Then we have Twitch, because someone suggested, said it's much better, I don't know, highly doubt it, but okay. And then I'm last streaming on LinkedIn, which is the least convenient one because, for example, it won't remember the stream settings. You can just go live in with one click of a button to do a whole process of generating a new event and stuff. We'll start developing in a second. Hopefully more people will join in. Why do I need to actually monitor the stream in various places just taking up bandwidth? But it seems like there's no option to turn it off and just leave it as is. Okay, just one technical, I'll start with the technical side of things. Just a comment on... So I'm using Visual Studio Code, even though it's a Microsoft product, obviously, using it in Linux. It doesn't really help. One thing with GitHub, co-pilot, chat. Let's start a new session. Just realize, open a new window. So this is... I used to have the whole project open like this. And then I will try to use GitHub chat, co-pilot. What will happen is if I use the workspace, which meant to look at multiple files, not just one, it will give me an error. So we'll try it now. Say, project structure. Yeah, this is opening the home, binary chaos, stuff, all the files and everything. So it's collecting workspace structure, deciding which information to collect. So essentially looking at which files to look at and then eventually was always giving me this array buffer location failed. So the way to fix it is actually select a smaller chunk of your project or not have big projects to begin with, will also help. And when you have a small project, if I do project structure on less number of files, it's again doing collecting structure, which workspace information to collect and actually working. So it's telling me that my structure is the follows. I have a Python flask application static folder in which I have two JavaScript files. We also have a template folder in which we have an index HTML. So it's done that it's done that the flask application file and folder structure.  Where is the the if you're loading too many to large project too many files, then it just refuses to work with some buffer allocation issues, essentially tells you it's too much stuff. Close this for now. Eventually everything I do a piece on buying case.com. Mg to music conversion is still the last tool that we had. We also have that gesture to music conversion thing. But that one doesn't have been properly published yet. Still working with a description, thumbnails, things like that, the boring, boring stuff. Let's get into it. We have this flask application we are working on. So might as well run it if it does anything useful or not. We start off this game, ECG detection game. What you meant to do in this game is you have ECG waveforms scrolling on the screen and you're meant to click on ones that are abnormal. It should be pretty straightforward, especially when you know what normal ECG looks like. It doesn't look like that. This is abnormal ECG, so I keep getting hits. This is also abnormal if I don't click on it, I get a miss. This is also abnormal if I get another miss. This is abnormal if I click on it, I get a hit. So greens are good, reds are bad. Another hit. Waiting for a normal one. I don't remember what the ratio is. This should be 4060. I think normal to abnormal. Yeah, so that was normal. I correctly rejected it. Why do I get errors? Right, so what we want to do now and the advantage of having synthetic data like this, synthetic ECG is that you could design algorithm and AI machine learning or whatever that will play this game.  So we'll be competing against the bot who can detect this thing better. This thing we also designed using a bot. We're currently using a fuzzy logic algorithm to train some machine. It's an explainable AI machine learning algorithm that we can actually tell what is it doing. And later we might be using neural networks as well, which pretty much everyone under the sun is using these days. Might do that as well. Just got a false alarm when clicking on a normal ECG. And my score went down. Okay, so we also started GPT-4. So currently we have this structure. We have both GPT-4 and GitHub co-pilot. What we do is use GPT or the general context of things. It seems to be better at keeping a broader context of the project. We might have here, let's do quick format document. And comment at the end saying a more code is coming in the next prompt. Assuming GPT is aware what's the current prompt and what's the next prompt is. I really can tell we're having some errors coming through that's happening for this analysis result. So this analysis result is a result of fuzzy logic analysis. This code snippet demonstrates a fast application designed to analyze waveform data using fuzzy logic. It's well structured and modular, which is great for maintenance and scalability. Key points. Global variables. These are used to track the minimum and maximum values of frequency, peaks and amplitude. It's a sensible approach for normalization, although you need to be cautious about thread safety and concurrency issues in a web server context. Flask roots. You have defined two roots, a home root and an analysis root. Analyze underscore waveform. This structure is clear and follows Flask standard practices. Data processing. The process underscore data function uses FFT for frequency analysis, peak detection and amplitude calculation. This is a solid approach for waveform analysis. Just ensure your incoming data format is consistent with these expectations. Fuzzy logic analysis. You're using psychic fuzzy for fuzzy logic analysis, which is a good choice for Python. The definition of membership functions and rules seems appropriate for a basic system. However, the effectiveness of these rules will depend on the specific application and data characteristics. Overall, your code is well organized and seems fit for the purpose of waveform analysis in a biomedical context. You might want to add more error handling, especially if the data inputs are during the FFT and peak detection processes. Additionally, instead of security implications of receiving and processing data in a web application. Currently in the app Python file, it will find where is the file actually located. So I have the chppt response. It's talking about global variables. We have this analyze waveform. Flask roots. Pretty sure we have more of them. Check them in a second. In this signal, we're looking at three features at the moment. We're looking at frequency amplitude and the number of positive and negative peaks. So ideally we want to display them all in here. Just keep going to HTML. Next. The other problem with GPT-4 is that eventually it will give us a timeout. Your HTML code for the CardioQuest ECG scoring game is well structured and seems designed to provide a good user experience. Here are some observations and suggestions. Metatags. You've included meta tags for social media sharing, open graph tags, which is great for visibility and shareability. Sorry, I forget that it was actually talking to us. Sorry for that. I was talking over it. Both audio outputs were going into the stream. Unfortunately at the moment when I record the video locally as well. But unfortunately the two audio streams are just mixed together into one. That's not good. I'll try and correct it later. Let's do the waveforms next. So it knows what the waveforms are. Well then just so we don't stop overloading GPT-4. We will not be generating code with it. We'll be asking you to generate prompts from what we discussed. And then I'll use a GitHub co-pilot for actually doing the code. We have the game logic as well. Just format this document quickly. Let's give you some general stuff about the code. Which we already went through previous streams, but I'm happy to go over it again. We'll go over the relevant bits for what we're trying to do. Generally, yeah, explain what the game is doing. It's available on the site. You can go try it out, play with it. And now we're making a board that will play the game. And then potentially can compete with the board. So at the bottom here is meant to be the result of the fuzzy logic analysis. There's essentially a machine learning that will now be going over. I'll explain more about how it works. Yeah, this error here. Yeah, I'm pretty sure I know why it's happening. Just open this full screen. This patch. Yeah, we're using... Let's forget that Ctrl C is what happens with Windows users. If you press Ctrl C, in this case it will stop the execution of the Flask application. Instead of just copying the terminal results. So I'm looking at... What am I looking at? This bit. Ctrl Shift C. Let's pop it into... I think it might be too much for Copilot to handle. We'll check it anyway. Let's bring it back here. So we have the game logic. I did say canvas, click event handling, game loop, regression with background result display, performance. All right, we have this thing where as your score goes higher, the stuff on the screen starts moving faster. So I think from memory every 50 points, the speed increases. So now we minus 50, so it goes back. If you're losing points, then it goes back to be slower again. Okay, I might not use the Bluetooth headphones that are going low on battery. Air handling. It's always suggesting to do more air handling. So the error message indicates that the phasologic system is unable to calculate a crisp output because the system too sparse. We'll need more explanation on this one. I know vaguely what this means. My hypothesis is that the outputs are not normalized. So essentially the display of how the phasologic is doing its decisions. We also have... I thought we have a CSS, but it's okay. We'll deal with CSS later. If no one wants to chat... Unfortunately, I'll have to chat with the stone cold soulless bot. Clear. I might turn this speaker on quickly. Clear. So we have this flask application to troubleshoot how the phasologic system is working. Essentially how it is making decisions regarding the output. Can you recap what the phasologic system meant to be detecting? Yep. Your flask application, which incorporates fuzzy logic analysis, is designed to analyze ECG, electrocardiogram, waveforms. The purpose of this system is to detect abnormalities in ECG patterns. Here's a recap of how it's meant to work and what it's detecting. Input waveforms. The system takes ECG waveforms as input. These waveforms represent the electrical activity of the heart and are typically characterized by distinct components like P-waves, QRS complexes, and T-waves. Dominant frequency, extracted using Fast Fourier Transform, FFT. It represents the most prominent frequency component in the waveform. Number of peaks, detected using peak detection algorithms in the Skidby Library. Peaks can correspond to the various waves in the ECG, like the P, Q, R, S, and T-waves. Amplitude, calculated as the difference between the maximum and minimum values in the waveform. It indicates the strength of the heart's electrical signal. Normalization, the extracted features are normalized against global minimum and maximum values to ensure consistency and comparability between different waveform samples. The application uses Psychic Fuzzy to implement the fuzzy logic system. Fuzzy sets and membership functions are defined for each feature, frequency, peaks, and amplitude, and for the output variable, which is the level of abnormality. Fuzzy rules are established to determine how the input features contribute to the output. For example, a rule might state that if the frequency is high and the number of peaks is low, then the likelihood of an abnormality is high. The system outputs a score or value indicating the likelihood of an abnormality in the ECG waveform. This score is derived from the fuzzy rules and membership functions, representing the system's assessment of how abnormal the waveform is. Purpose, detection of abnormal ECG patterns. The primary goal is to identify patterns that deviate from normal ECG characteristics, which might indicate various cardiac conditions or anomalies. To troubleshoot or fine-tune the system, you might need to adjust the membership functions, re-evaluate the fuzzy rules, or look into the normalization process to ensure it's handling the data correctly. It's also important to test the system with a wide range of ECG data, including both normal and abnormal waveforms, to assess its accuracy and reliability. Your system's effectiveness in detecting ECG abnormalities will largely depend on the accuracy of the feature extraction process, the appropriateness of the fuzzy logic rules, and the quality of the input data. Okay, so this is correct. Sounds legit. Just a recap of what we are doing. So, yes, we're looking at the dominant frequencies using FFT. The number of peaks then could indicate if this number is lower than PQRST 1, 2, 3, 4, 5, then it's highly likely that the ECG is abnormal. Amplitude could be tricky, because if the amplitude is way too high, it could mean there is some sort of noise, but if it's too low as well, it could mean that the system is just not working, that no ECG is being generated. This would not necessarily mean abnormal ECG, but if the amplitude is within a certain range, then it should be okay. Specifically, could somehow, by looking at the amplitude, it would be primarily looking at the R peak, or because that's the highest peak in the ECG signal. Now, normalization is very important, because membership functions will need to be designed accordingly. So the question is if normalization is working as expected, because from memory we had this adaptive normalization that will just get improved as you have more waveforms coming through. The main thing is that we want to be able to review on the front panel, on the HTML page how the fuzzy logic system is making the actual decision. So we need to display essentially all the parameters of the fuzzy logic system. Can you, shall we, would it be better for you to provide prompts for GitHub co-pilot to do the actual coding and improve the current script? Yep, sorry for that, it's just a long one, but... Certainly. Integrating a front-end display to show how the fuzzy logic system in your Flask app makes decisions is a great idea. This will improve transparency and understanding of the system for users. To achieve this, you'll need to modify both the back-end, Flask app, and the front-end, HTML, JavaScript. Here are prompts that can be used to guide further development, potentially with GitHub co-pilot or other coding assistance tools. Enhance the JSON response. Modify the analyze underscore waveform route to include more detailed information in the response. This should include the raw feature values, frequency, peaks, amplitude, their normalized values, and details about the fuzzy logic decision-making process, like the degree of membership in different fuzzy sets. Prompt. Modify Flask route to include detailed fuzzy logic analysis data in the response, such as raw and normalized feature values, and fuzzy set memberships. Prompt. Modify Flask route to include detailed fuzzy logic analysis data in the response, such as raw and normalized feature values, and fuzzy set memberships. Logging or debug mode. Implement a logging or debug mode in the Flask app that provides detailed console outputs of the fuzzy logic processing steps. Prompt. Create a debug mode in Flask app to log the steps in fuzzy logic analysis for troubleshooting. Display analysis data. Extend the front-end to display the additional data received from the back-end. This could be in the form of a table or a series of divs that update with each analysis. Prompt. Write JavaScript code to dynamically update the HTML page with detailed analysis data received from the Flask back-end. Prompt. Write JavaScript code to dynamically update the HTML page with detailed analysis data received from the Flask back-end. Interactive visualization. Implement an interactive way to visualize the fuzzy logic data, perhaps using a library like D3, JS. This could include graphs showing the degree of membership in different fuzzy sets for the current waveform. Prompt. Develop an interactive visualization for the fuzzy logic analysis data using D3, JS or a similar JavaScript library. User control for debug information. Add a toggle on the web page that allows users to turn on, off the detailed analysis display. This enhances the user experience by providing control over the amount of information displayed. Prompt. Document a feature on the web page allowing users to toggle the visibility of detailed fuzzy logic analysis information. Test with diverse data. Ensure that the system is tested with a wide range of ECG waveforms to validate the effectiveness of the fuzzy logic analysis and normalization. Okay, let's see if it's legit. Particularly, so in the back-end, yes, it makes sense to include the other details about the fuzzy logic system in the JSON response. What do we currently... Where's the JSON? Right, so only including... Okay, can we do this one step at a time? Can we modify the back-end first? What prompts do we need to modify the back-end? Yep, let's do it one by one. Certainly, let's break down the task of modifying the back-end step by step. You will need to enhance the Flask application to provide more detailed information about the fuzzy logic analysis in its response. Here are the specific prompts to guide the modification of the back-end. Expand the data processing function, modify. Modify the process underscore data function to return not only the normalized values, but also the raw values of frequency, peaks, and amplitude. Update the fuzzy underscore logic underscore analysis function to include details about how the input values map onto the fuzzy sets. This can involve capturing the degree of membership in each fuzzy set for each input feature. Okay, okay, let's do this one by one. So updating the process data function. It already returns just the normalized peaks. I want to see how the normalization works. Just do that. So it's returning the raw and normalized. That's fine. The thing is, you do ctrl-I update to return both raw and normalized frequency, peaks, and amplitude. Okay, let's accept that. So expect the thing to stop working. It's not running at all. It's still working, but not producing any analysis result. That's okay. Now fuzzy logic analysis. We want to enhance the fuzzy logic analysis function to include and return the degree of membership for each input feature in its respective fuzzy set. So doing ctrl-I, that prompt, change anything there. So instead of return result does more. Right, so we have frequency membership, low, medium, high, amplitude, low, medium, high, and a number of peaks, a few, moderate, and many. Yeah, okay, maybe, okay. See how we go. So where the test should be a separate thing, shouldn't it? Let me try it out quickly. So the unit test should be a separate file, is it? Asking the test module, this test will bother the output of the fuzzy logic analysis with a variety of SCG waveforms. And let's do a test-py. How does testing work? Test, okay. It's not giving me much, is it? Yeah, because it doesn't even have the test waveforms. So the test waveforms actually come from waveforms.js. So this would not work. Okay, let's leave it for now. Okay, the testing doesn't work because the actual waveforms are in waveforms. The actual waveforms are in waveforms JavaScript file. So Python testing would not work. Let's move on, though, to the front end changes. Understood. Since the waveforms are generated and processed within the JavaScript environment, Python-based testing wouldn't be directly applicable. Let's move on to modifying the front end to display the detailed fuzzy logic analysis from the flask back end. Here are the steps and corresponding prompts for making these front end changes. Create HTML elements for displaying analysis data, add. Add new elements in your HTML page where the analysis data will be displayed. This could be a series of divs at a table. Update JavaScript to handle extended response. Modify the JavaScript that handles the response from the flask back end to extract and display the additional analysis data. Okay, let's do one at a time and I wonder if it will understand the context. So, for example, I'm wondering if I'm in the Python code and I pop this prompt in. What would it do? No, it's giving it the... Okay, let's actually go HTML. Let's do Ctrl I over here. Delete that bit. Okay, that's not it though. Instead of that, yeah, the chat... GitHub Copilot Chat response was better. Okay, we'll sort this in a bit. Let's do the JavaScript next. So, the JavaScript fetch request. This will be in game logic. It's a fetch. And let's do it with Ctrl I. Analysis result, analysis data. Back for a sec, select the whole thing and put the prompt in the chat. I'm just trying to understand how it all works together. What doesn't. Ctrl Shift Z. Analyze waveform, content type, body chase and stringify. Okay, obviously that's better. Yeah, optional interactive visualisation. We'll do it later. Total feature on the web chat in Russian. Allowing users to show high-detail fuzzy logic analysis information. Yeah, we'll do that later. Okay, I don't understand how something like that... Like this is a good prompt. It's not running at the moment, is it? Yeah, because we're doing the test there now. It should be actually running. This number is to not produce anything. Let's click this to know which file is the problem with. Can we do slash workspace? And this error might need you to determine where the problem is. Or even better, explain it. There's a type mismatch. The frequency input. The data frequency is flawed, but the universe max is a dictionary. Yes, it should be a numerical value. So if it is a dictionary, so what should it be? Data frequency of raw. It's a good question. It's a good question. What keeps up? Have a better explanation? Normally does. The error you're encountering is a type error in the fuzzy logic analysis function of your flask application. It seems to be occurring when you're trying to set the input values for your fuzzy logic control system. The error message type error, less than, not supported between instances of float and dict, indicates that there's a mismatch in the data types being compared or assigned. The issue seems to be with this line, abnormality underscore analysis, input, frequency, equals data, frequency. The data frequency is expected to be a float, but it seems to be a dict instead. Let's address this. Check the process underscore data function, E. Verify data passed to fuzzy underscore logic underscore analysis. Before calling fuzzy underscore logic underscore analysis, processed underscore data, add a print statement to check the contents of processed underscore data. This will help you confirm that the data is as expected. If processed underscore data contains the correct values but in the wrong format, like a dict, you may need to extract the values and convert them into floats before passing them to the fuzzy logic system. Modify the way inputs are set in the fuzzy underscore logic underscore analysis function. Ensure that each input variable, like frequency, peaks, amplitude, is set to a float value. Add error handling in the fuzzy underscore logic underscore analysis function to catch type mismatches and log helpful error messages. By implementing these steps, you should be able to diagnose and fix the issue causing the type error in your flask application. Remember, the goal is to ensure that the data types being passed to and used within the fuzzy logic system are consistent and as expected. Let's go to those processed data. Okay, let's print it. Yet the normalization doesn't work. So we have frequency, rho is 0, normalize 0, peaks, rho is 2, normalize 0, amplitude. Yet those do not work, let's see. The issue is now clear from the debug information you've provided. The processed underscore data contains dictionaries for each feature, frequency, peaks, amplitude, with both rho and normalized values. However, the fuzzy underscore logic underscore analysis function expects float values, not dictionaries. Here's how you can resolve this. Update your fuzzy underscore logic underscore analysis function to handle the dictionary format of processed underscore data. You need to extract the normalized values, or rho values, depending on your fuzzy logic design, from each dictionary and pass them as floats to the fuzzy logic system. Extract the correct values. Before setting the inputs for the fuzzy logic system, make sure to extract the correct values, in this case, normalized values, from the processed underscore data dictionary. Ensure correct data types. Confirm that frequency underscore val, peaks underscore val, and amplitude underscore val are float values. This is crucial for the fuzzy logic system to function correctly. Update the backend accordingly. Apply these changes in your flask application, ensuring the fuzzy underscore logic underscore analysis function receives the data in the expected format. By implementing these changes, your application should correctly process the waveform data and avoid the type error you are encountering. Make sure to test with various data inputs to ensure robustness. Yeah, this doesn't make sense. This doesn't make sense. Yeah, probably. Maybe there's a problem with how I use GPT-4 and GitHub co-pilot, whereas GPT-4 is generating prompts for GitHub co-pilot. The problem is that the GPT doesn't have the... Okay, so I was using GitHub co-pilot to change the code. I don't know if it's a good idea or not. What do you think? Here is the updated Python script. The whole app by file. Using GitHub co-pilot for coding can be helpful, especially for automating repetitive tasks, generating boilerplate code, or getting suggestions on how to implement certain functionalities. However, there are a few things to keep in mind. Accuracy in context, co-pilot generates code based on patterns it has learned from a vast corpus of code. It might not always understand the specific context or requirements of your project. Therefore, it's crucial for review and understand the code it suggests thoroughly. Customization and optimization, the code generated by co-pilot may need to be customized or optimized for your specific use case. It's important to adapt the suggestions to fit your application's architecture and performance needs. Debugging and validation, like any code, what co-pilot generates... Okay, okay, okay, okay. Yes, it might be an issue if using it this way. Regarding your updated Python script for the Flask application, it looks like you've made significant changes to handle the fuzzy logic analysis and the data returned. The script now appears to process the ECG data, apply fuzzy logic analysis, and then extract the degree of membership for each input feature. This is a good approach for providing more detailed analysis results. However, ensure that in the fuzzy underscore logic underscore analysis function, the data passed abnormality underscore analysis in better floats. You might need to modify these lines. These lines should extract the normalized float values from the data dictionary, similar to what was discussed in the previous solution. Okay, we need to do the same. We need to do the same for the game logic JavaScript file. Share the updated script in the next prompt. Please let me know how to change it as I'm still getting errors. This is the output of the terminal. Yep. Yeah, I'm really going to hit the 54 limit. The area you're encountering, object of type state per simulation is not JSON serializable. Typically occurs when trying to convert an object to JSON that isn't natively serializable by Python's JSON module. In your flask app, this is likely happening because the return value from the fuzzy underscore logic underscore analysis function includes objects that can't be directly converted to JSON. The issue probably lies in the attempt to include the fuzzy logic system state or other complex objects in the JSON response. Python's JSON module can handle basic data types like strings, numbers, lists, and dictionaries, but it cannot serialize custom objects like those from scikit fuzzy without some additional processing. You need to extract only the serializable data from these objects before including them in the JSON response. Typically, this means converting the relevant information into standard Python data types like floats, ints, lists, or dicks. Here's how you can modify the fuzzy underscore logic underscore analysis function. Extract relevant data. Instead of trying to return the entire state objects, extract only the necessary information, like the degree of membership values, and store them in a serializable format, like a dictionary. Return serializable data. Ensure the function returns a dictionary or a similar serializable structure. After making these changes, ensure that the rest of your flask app, especially the root handling the analysis, is updated to handle the modified return structure of fuzzy underscore logic underscore analysis. This should resolve the serialization error and allow your flask app to return a proper JSON response. To ensure that your flask app handles the modified return structure of fuzzy underscore logic underscore analysis, you need to update the root that calls this function. Here's a step-by-step guide on how to do this. Update the root to handle the new root. This should resolve the serialization error and allow your flask app to return a proper JSON response. Can you actually do this for me instead of... To ensure that your flask app handles the modified return structure of the fuzzy underscore logic underscore analysis function correctly, you need to update the root that calls this function. Update the root to handle the new return structure. The analyze underscore waveform root should be modified to handle the dictionary returned by the fuzzy underscore logic underscore analysis function. Extract and format the response data. Extract the relevant data from the dictionary returned by fuzzy underscore logic underscore analysis and format it into a JSON serializable format. Here's an updated version of the analyze underscore waveform root incorporating these changes. Error handling, the try accept block will catch any exceptions, providing a useful error message and a 500 status code. This is crucial for debugging and ensuring your app doesn't crash on unexpected inputs. Debugging, the print statement for process data is helpful for debugging. You can remove it or comment it out in a production version of your app. Data validation, ensure that the data being processed and returned is validated. This is important for both the security and stability of your application. Testing, after making these changes, test the endpoint with various inputs to ensure it behaves as expected and the front end receives the data in the correct format. By updating the root as shown, your flask app should correctly handle the modified structure returned by the fuzzy underscore logic underscore analysis function and provide the necessary information to the front end for display and further processing. Okay, so I think that error actually went away. Yeah, now we're actually having trouble with the action with the numbers themselves. Yeah, because if we have, I think we don't have the technical issue anymore. But now we have a problem with the numbers themselves, particularly with how the normalization works. Well, it's actually doesn't work very well. Here is the terminal output really going to hit that limit. The issues you're encountering seem to stem from two main areas, the normalization process and the handling of fuzzy logic analysis in your flask application. Let's address these one by one. The normalization process seems to be not working as expected, with some values being normalized to zero or one, which might not be accurate. The normalization function is crucial as it ensures that the input values for the fuzzy logic system are scaled appropriately. Revisit normalization logic, check the logic in your normalize function. Ensure it correctly handles the range of values you expect for frequency, peaks, and amplitude. Be particularly cautious about how the minimum and maximum values are updated and used. Data range consideration, consider the range of values your ECG data might have. Ensure that the global min max values are being updated in a way that makes sense for your data. For example, if the range of your data is not wide enough, it might lead to incorrect normalization. The error float argument must be a string or a real number, not state per simulation indicates a mismatch in the expected data type for the fuzzy logic systems inputs. The other error regarding crisp output calculation suggests that the fuzzy rules might not be adequately defined for the given inputs. Correct data types for fuzzy inputs ensure that the inputs to the fuzzy system are floats. The error suggests that one of the inputs might still be a state per simulation object. Double check the fuzzy underscore logic underscore analysis function to ensure that all inputs to the fuzzy system are being correctly extracted and converted to floats. Okay, I might have to say bye-bye for now. Please leave comments, likes, go check bodykills.com. You know what to do. And might just continue what we are formally done with the stream. And the normalize function to be corrected def normalize value. Pretty sure we changed that last time. Right, someone is asking, yeah, we could probably sum up by explaining again what is it we are trying to do. Basically, we have this game on bodykills.com. You can go on the main page and play it yourself. It looks like this to click on abnormal ECG like this. And then your score goes up and this will measure your performance. This looks very much abnormal. Remember the ratio between normal. No, this looks normally G. So if I ECG, so when I do not click on it, it will give me a correct rejection, which is good. This should be another correct rejection. So my score went to 10. This is abnormal. So that's I clicked on it. So that's a heat. This is normal. Now correct rejection. Normal again. Correct rejection before. This one is normal. They're coming in a row. And once you get to 50, it will start going faster just because you're an expert in detecting ECG types. This is obviously abnormal. Every 50 points will start going faster. That was abnormal as well. This is abnormal. It was missing one of the peaks. This is abnormal. It's missing the last peak. This is abnormal. It's missing this downward peak after the R peak. And so on so forth. So you can go play this game. We have a video where I play this game and get to about 1,000 points. So see if you can beat me. It will get faster and faster. It should be easy once you know what the normal ECG signal looks like. Then it's easy. You can easily detect the ones that are missing certain bits. Now what we're trying to do in the last couple of streams is make a version of this that will look at the frequency, number of peaks, amplitude. And use the machine learning in the form of fuzzy logic, fuzzy set membership functions. And we'll tell you if the abnormality is likely possible or unlikely in this particular waveform that you have scrolling on the screen. So that's what we're trying to do. Obviously have some trouble. We get off GPT-4. We have both GPT-4 and GitHub co-pilot trying to help us. GPT-4 has a limit of currently 40 messages per 3 hours. So we're trying to just get it to generate prompts for GitHub co-pilot. And co-pilot will actually modify the code. We're doing this because GPT-4 seems to hold a better context for the whole project. Whereas co-pilot has the, you know, better, it's set up better for actually modifying the code. So I don't know if this is a good idea or not. What do you think? Yep. Using GPT-4 in conjunction with GitHub co-pilot for your project is a creative and effective strategy. Here's a breakdown of how these tools can complement each other. GPT-4's strengths, GPT-4 excels in understanding context, providing explanations, generating ideas, and offering prompts or high level guidance. It can give a broader perspective on your project, suggest best practices, and help in troubleshooting by generating targeted prompts for coding tasks. GitHub co-pilot strengths, GitHub co-pilot is more focused on code generation and completion. It can take the prompts or ideas generated by GPT-4 and turn them into concrete code snippets. It's particularly useful for quickly producing boilerplate code, implementing standard algorithms, and filling in gaps in your code based on context. Combining their capabilities Use GPT-4 for guidance and problem solving. You can leverage GPT-4 to understand complex issues, get advice on best practices, and generate prompts to describe what you want to achieve in your code. Use GitHub co-pilot for code implementation. Once you have a clear idea or prompt from GPT-4, you can use GitHub co-pilot to actually write the code. Co-pilot can rapidly generate code snippets based on the prompts, which you can then fine-tune or integrate into your project. Advantages of this approach Efficiency, this method can save time, as you get the best of both worlds, strategic guidance and practical implementation. The normalization process seems to be not working as expected, with some values being normalized to 0 or 1, which might not be accurate. The normalization function is crucial as it ensures that the input values for the fuzzy logic system are scaled appropriately. I didn't realize we had yet a normalized function. It's been funny. Do we actually have to normalize? Can we actually try not normalizing? This will probably mean we need to change the membership functions, particularly the range, obviously. The range, the range, range. Deciding not to normalize your data before feeding it into the fuzzy logic system is a significant change and comes with its own set of considerations. Here's a breakdown of what this entails and the steps you might need to take. Impact on membership functions. If you choose not to normalize, your membership functions in the fuzzy logic system must be defined to accommodate the actual range of your data. This means that the universe of discourse, the range over which your fuzzy sets are defined, for each input variable must align with the real-world range of these variables. Potential loss of generality. Normalization often helps in making a system more general and robust to variations in input scales. Without normalization, your system might become more sensitive to specific ranges of data and might not perform well if the input data characteristics change over time. Risk of misclassification. The effectiveness of fuzzy logic heavily relies on how well the membership functions represent the data. Oh, come on, just stop the talking. Okay, you convinced me. Let's do the normalization. Can you describe how the normalization currently working and give suggestions as to how to modify it? Yep. Certainly. Let's review how your current normalization process works and explore potential modifications to improve its effectiveness. Your current normalization function appears to linearly scale each value based on the global minimum and maximum values for each feature, frequency, peaks, amplitude. The process is as follows. Calculation. The function calculates the normalized value by subtracting the minimum value from the current value and then dividing by the range, max, min, python copy code def normalize, value, min underscore val, max underscore val. Return, value, min underscore val, max underscore val, min underscore val, if max underscore val equals min underscore val L0. Global min, max updates, whenever a new data point is processed, the global minimum and maximum values for each feature are updated if the new data point exceeds the current ranges. Edge cases. The function handles the edge case where the maximum and minimum values are the same, to avoid division by zero, returning zero in such cases. Static range problem. If the initial waveforms are not representative of the full range of possible data, the normalization might not scale new data correctly. Sensitivity to outliers. The normalization is sensitive to outliers, which can skew the global min, max values, leading to ineffective normalization for subsequent data points. Initial values. Setting the initial global min to float, inf, and max to float, inf, works well for updating with actual data, but it assumes the first data points are representative. Predefined range. If you have prior knowledge of the expected range of your data, consider setting initial min, max values based on this range instead of using the first data points. Handling outliers. Implement a method to detect and possibly exclude outliers from impacting the global min, max values. This could involve statistical methods like calculating the standard deviation and ignoring values that fall too far from the mean. Smoothing or windowing. Instead of updating global min, max with each data point, consider using a rolling window or a smoothing technique to update these values. This can help in reducing the impact of sudden spikes or drops in the data. Dynamic adjustment. Implement a dynamic adjustment mechanism where the normalization range can be updated based on the distribution of a certain number of recent data points, not just the global extremes. Avoid zero division. Enhance the edge case handling where min and max are equal. For instance, you might return the midpoint of your expected range instead of zero, or handle this case based on the specific requirements of your application. Logging and monitoring. Implement logging to monitor how the normalization values change over time. This can provide insights and help in fine tuning the process. Here's a simple example of a dynamic adjustment mechanism. In this example, rolling underscore window keeps track of the last window underscore size data points, and the global min, max are updated based on this window. This approach can help in mitigating the impact of outliers and provide a more stable normalization over time.


think the walks walk guys it'll kill you and I think it's proven for me over the course of this year the more I walk guys and the more trouble I get myself in.  No I just couldn't I just couldn't really find the zone. Frustrating for you knowing you got another opportunity to to start and maybe have it not go the way you would have liked? I mean frustrating when we lost the game it's always frustrating when you when you start games and you know come away with losses and it's always frustrating. Is it any harder to take considering the A's are gaining ground and you guys just too back now in the crucial time of year? I mean we can we can we control what we can control and then there's nothing I mean there's nothing else that that we can do other than then control you know it's locker room control the games that we play in. You feel like guys in here are feeling the pressure of the season winding down? Yeah I don't think so I mean we lost one game I mean we're fine I feel like everyone's got in good spirits and you know we'll come out tomorrow and get behind Seve and try to win a series here.


Hi everyone, Dr. Sal here in Beverly Hills. We have our patient here beautiful young lady Give you a little history about her. She had She's had had tummy tuck and breast augmentation with saline implant at this time She wants to take out the saline implant and she wants to do if that Transfer instead of implants to her breast Since her breasts are saline this kid this cannot be done with silicone because it's saline What I'm going to do for her is do a deflation of her implants Very simple procedure in office will take like about 10 minutes What we're going to do is we're going to take out the saline implants just to just a fluid not the implant Just deflate it suction out the fluid let the skin close up and It'll give her an idea of how much breast tissue she has and what she's looking to get into So we're going to do this pre-surgery and then on surgery date You guys will see her and see how she looked before so let's turn around you see She has nice fullness on this side nice fullness on this side She had a little bit of capsule contracture because you could see the empty the lower part of her breast is empty the implant is stuck and Contour to the chest up top on this side so we've numbed the patient we cleaned that off we put numbing We're going to put the needle in I'm just squeezing the implant to make sure all the saline is out there It is all of it is off So that's her actual breasts. You could see the comparison. How many cc's of fluid did we get off? So her implants are about somewhere around 300 cc So you could see the area has been clean cleaned off numbing has it been applied. I'm just going to go in go inside and then Take this off and turn on the suction And there we are Okay, that procedure just took us few minutes. You can see with the implant gone She's deflated up all the way up here.  It's all gone She does have some breast tissue down here. This is breast tissue So our goal with the fat transfer will be to put it up here and she doesn't want big breasts You want as I say, it's going to go about half a cup to one and a half cup larger than what she is right now I think these are like a B cup. So she'll be a B plus C. That's that's what you get with fat You can't put too much in there because of the surface area.  We'll show you guys her results after we're done If you if you remember a few days ago We had her actually last week come in and we deflated her implants We did that for a couple of reasons one. We wanted the skin to contract To we wanted her to see what her breast looks like without the implants So what are we going to do today is we're going to go through the areola and actually take out the Sack of the implants. So we're going to take out the implant the outer layer the inner layer It was same means so we just sucked it out. So this is actually her own breast and She has the implant in there all the tissue down here in the lower pole is her own That so I'm going to cinch in her waistline if you see right now her waist and her hips are even I'm going to cinch it in all the way She measures today around her belly button at 36 inches. So I'm thinking Five inches you guys take a guess at home. I think afterwards. I'm going to be at least five inches We're going to take out the love handles. We're going to take out the upper back put your arms down We're going to try to take out the rolls Remember these rolls are calm are caused by Adhesions just like the adhesions. I'm holding you person because we're going to take her back and Put it in her breast. There are a couple advantages over that number one. It's hundred percent organic hundred percent vegan hundred percent natural It's her own fat number two is that she doesn't have to change every 10 years with implants after every 10 12 years You're going to get a cap So they're going to become hard and you have to change them this way She's not going to have to change them number three They're going to look very natural and very modest. She wants a nice Refreshing look and that's what it's going to give her. That's what she wants. So that's what we're going to give her Going to go up about a cup size Remember half a cup to a cup maybe a cup and a half, but that's the most but she wants and to get the implant out I'm going to go right around the areola and take out the old implant in there Stay tuned as we start the case. Okay. So as we talked about in pre-op the patient has The implant in there although the implant is deflated We're going to go in and we're going to take out the implant And the capsule that's around it So we're going to go through the same scar that they put it in right through there And uh, we're going to find the implant Let's see where it is So we went through the skin through superficial fat. We went through the breast tissue There's the pectoralis You can see me zapping it and it contracts So this is this implant was placed underneath the muscle So in order to get to the implant we need to go underneath the muscle too And there we are. We're underneath the muscle now There it is And There is the capsule. I already see the capsule I'm just taking off the muscle right off the top of the capsule. You could see that little hole right there That's the capsule where the implant it is in there So here's the anterior aspect of the Capsule you could see I'm taking it off very thin capsule But I'm taking all of it out for her as I promised her she wanted everything out And I'm taking it all out for her There's the capsule and here's the implant See it all deflated away. There it is It was a saline implant. So it's salt water. So if any of it is in there, it'll just she'll just absorb it It was a 350 cc's allergen implant. And here's the capsule that was on top of it So this is the rib. Look at that. You hear it That's rib. That's intercostal muscles intercostal muscles The higher rib we took out the capsule as much as possible We cleaned the whole area out And then we're going to put some fat in there That's it. And here's the deflated implant from this side. There it is So if there's nothing wrong with poking a hole and taking out the salt water because it's nothing dangerous The shell is intact. All we did was remove the salt water. So it would contract better So now we're just going to clean up the rest of the capsule So this is her rib cage. Her rib cage ends right here. So we emphasize the curvature right here You can see she's very thin here. I made her very thin right where the ribs end So it comes contours in and gives her that waistline


What's happening guys? It's Shane here. So this video is gonna be about the highest paying college degrees and by that I mean four-year degrees only. So we're not gonna include any master's degrees, doctoral degrees, professional degrees Anything that takes more than four years is gonna be off the list. Not today Satan. But Shane money doesn't matter And you should always follow your passion. Okay, so obviously pay isn't everything I know this. There's a lot of things that you want to consider job Satisfaction passion quality of life, but that's not what we're talking about today Today, we're just gonna be going over the degrees that pay the big money so that you can secure the bag And if you understand this video once you secure the bag Whatever the heck that means you'll have the freedom to smash the like button on this video all day long because you can do Whatever you want and you're just awesome like that So before I start this video I did a ton of research on this and it's really difficult to determine which ones actually pay the most because Almost all of the studies rely on self-reporting data, which isn't always accurate But with that being said I got all of my information from three different sources the Bureau of Labor Statistics a survey by PayScale.com and an analysis by Glassdoor.com now most of this data is going to be based off of your first five years after Graduating, but I also took into account the overall median pay of everybody that graduated with a degree as well Okay So we're gonna skip all the way to number one on the list Which is skipping college all together and being mr. Beast's friend Seriously mr. Beast if you ever see this can we please be friends? Just kidding number 10 on the list is going to come in being a finance degree and that's going to be around $85,000 to $88,000 a year now I notice that some people say finance and others say finance so don't get mad at me if I pronounce it differently than you In fact, you know what let's see what google says. What's the what's the correct way to pronounce this Finance now there are many different career paths that you can go down with a finance degree Two really common ones are going to be a financial analyst or a personal financial advisor So financial analysts are going to provide guidance to people who are making investment decisions So this could include businesses as well as individual investors personal financial advisors on the other hand are more boots on the ground And they're going to be interacting with normal people that are just trying to save for retirement Now there's lots of job openings for both of these careers And they're both growing a lot faster than average and a good friend of mine from high school ended up becoming a financial analyst And moving to new york and he's doing really well compared to pretty much anybody else in my high school So i've seen firsthand how good a finance degree can be Number nine on the list is going to be a physics degree and you can become a physicist with this degree But there are a lot of other options as well now overall people who graduate with a physics degree are making around $97,300 a year if you do decide to go for a higher level degree You can make a lot more than this and physics graduates are paid really well And they're highly sought after because this is probably the most difficult degree that you can get in undergrad So companies know that when they're hiring someone with a physics degree, they're getting a very smart hardworking individual That's going to solve problems for them Now the big problem with this one is that if you only get a bachelor's degree You're probably not going to find that many opportunities to work as a physicist So if that's the path that you're trying to go down you're going to need to get a master's or a doctoral level degree But like I said, there's still a ton of other options and physics majors get paid very well after getting out of school And this is one of those degrees where you want to have a very clear idea of what careers Interest you because there's not a clear path of which job you're going to get after you graduate You know, if you get an engineering degree, you're going to become an engineer If you get a physics degree, there's a lot of other things you could potentially become And getting a physics degree and expecting to become the next elan musk would be kind of like getting a theater degree And expecting to become the next robert downey jr Number eight on the list is going to be mechanical engineering and that one's going to come in at about $87,000 a year And they basically helped to design develop and build mechanical devices Now this one probably isn't going to surprise anyone But mechanical engineering is a really solid option on this list And it's going to be the first of many different engineering degrees They also have a lot of job openings in this career And it's a very flexible degree where you can do a lot of different things with it So overall, this is a very solid choice Number seven on the list is going to be industrial engineering and that one's also going to come in at about $87,000 a year And they help to create efficient systems within a business that integrates the workers as well as the information and the systems All of that comes together to make a better product And this one's a really valuable skill to have because it sort of combines engineering with entrepreneurship And I see this one being even more valuable with automation as well as artificial intelligence coming down the line This is also one of the fastest growing engineering careers at about 8 growth Which is really good for them and this one barely edges out mechanical engineering on the rankings Overall, this one is an amazing option lots of jobs lots of future opportunity as well And I know there's a lot of engineering degrees on this list, but that's no mistake Now I know I've poked a lot of fun at Starbucks baristas in the past But think about it. Have you ever seen a Starbucks barista that has an engineering degree? So I cheated a little bit just because there's so many of these I'm grouping electrical engineering with computer engineering at number six on the list So I grouped these two together because computer engineering is technically a subset of electrical engineering Now of course computer engineering focuses more on designing and creating computer systems And electrical has a great salary to about $99,000 a year But computer engineering has an even better salary And I think these are both fantastic options. Electrical engineering is a little bit more flexible You can get a lot of different types of jobs with that one Whereas computer engineering pays a lot more and it's also a really good option because it's so easy to transition into Maybe the best industry in the world, which is the tech industry Number five on the list is going to be chemical engineering and it comes in at about $105,000 a year Now chemical engineers apply the principles of biology chemistry physics and mathematics To make all kinds of different things from food to fuel Now this one isn't as flexible as a lot of the other ones on the list and it doesn't have as many job openings So you'll likely have to move to wherever the opportunity is But overall this is still a very solid choice Now number four on the list is probably going to be a little bit of a surprise and that is an economics degree And I was surprised at how high this was on the list, but it's a very solid option Now if you want to purely become an economist, you're probably going to have to get at least a master's degree But there's a lot of other options out there for people who just opt for a four-year bachelor's This one also has some of the best statistics when it comes to starting your own business and becoming an entrepreneur Overall, this is a very solid option for you, especially if you don't want to go down the engineering route And it's really hard to calculate exactly how much they make because many of them end up getting their masters or their doctorate And there's no way to differentiate with the data But broadly speaking this one pays very well Number three on the list is going to be computer science and this one comes in at about $109,000 a year Now this one was extremely difficult to rank You could make a good argument that it's number one on the list But there's just so many different options for you if you get a computer science degree You can be a front-end engineer. You can be a back-end engineer. You can be a computer network architect You can get a chill remote job where you're working on your code from anywhere in the world A guy I know who's a computer network architect only works about 10 to 20 hours a week and he makes over 300,000 a year or you can go all out move to silicon valley and go for jobs that pay over 500,000 a year This one is also really great if you want to start a business in the tech industry There's honestly so many options out there that it's really difficult to rank this one You can easily rank it number one and at the end of the day it sort of does come down to your opinion But overall this one is extremely solid The next two on the list don't have anywhere near as many job openings as computer science does and they're both pretty Niche options, but they're niche options that pay extremely well So the first one number two is going to be aerospace engineering and that comes in at about 115,000 a year and I think you can sort of guess what they do they design all sorts of different objects that fly through the air from satellites to drones to Helicopters spacecraft, etc Now this one pays extremely well, but there aren't that many job openings and it's not as flexible as some of the other Engineering degrees as well. So because of that you'll likely have to move to a place where there's more opportunities for aerospace engineers One of my roommates in college is an aerospace engineer and I have to say to this day He might be the smartest person I've ever met in my life I still remember in my head this guy playing skyrim during finals week for like 10 hours a day While everybody else was pulling all nighters just to barely pass their tests and he finished as the number one student in This class it was ridiculous. So if you're going into this one your competition is going to be really tough You're going to be going against people who are pretty much geniuses So you're going to have to work really hard unless you're a genius like my roommate was Overall, this is a great option for the right person and it pays ridiculously well But not quite as well as number one on the list, which is petroleum engineering at 137,000 a year.  And you can probably guess what they do. They design methods of extracting oil and gas from deposits that are below the earth's surface Now this is another one where the pay is amazing But there's not that much demand and chances are you're going to have to either move to a town in the middle of nowhere Or you might even have to move out onto an oil rig in the middle of the ocean Now on top of that, it's not as flexible as a lot of the other engineering degrees So if you don't want to work in the natural gas field, you're going to have a little bit more trouble transitioning into something else Overall, it's insane that they can make almost a hundred and forty thousand dollars a year with just a four year degree And I want to just note here that the comparisons aren't perfect because Someone might go for an engineering degree for four years And then they end up becoming a computer programmer And there's just no way to differentiate all of that sort of thing in the data But make sure to watch my videos right here. I made them just for you Go ahead smash the like button hit the subscribe button ring the notification bell Comment down below any ideas you have on this video or any other videos that I should make Thank you so much for watching and bye for now


So the next talk is titled the IPS compiler optimizations, variants, and concrete efficiency. It is by Yehuda Lindel, Eli Oxman, and Benny Pincus. And Yehuda will be giving the talk. Good morning, everyone. I'm going to talk about the IPS compiler. IPS is Ishai, propaganda, and Sahai. Optimizations, variants, and concrete efficiency. And this joint work with Benny Pincus and Eli Oxman. In the setting of securitization, there are two main classes of protocols. Information theory can computational. In the information theoretic setting, as we've seen in the previous talk, we use very aesthetic mathematical tools that are typically very efficient. We obtain security even for an adversary who's computationally unbounded. So that's another advantage. However, we require an honest majority, in fact, even two-thirds majority that are broadcasts. And it's impossible to achieve this for a dishonest majority. In contrast, in the computational setting, we use computational hardness and heavy tools for obtaining oblivious transfer, zero knowledge proofs, commitments, and so on. The adversary is limited to polynomial time. We only achieve that level of security, which is fine in practice. The advantage is that by using this, we can actually obtain security for any number of corrupted parties, at least if you're willing to forgo on the requirement of fairness. So these really two different settings with different trade-offs of what we gain and lose. Another class or another category that we have to look at when we talk about security computation is what is the power of the adversary, not in terms of its running time, but in terms of the other things that it can do. The most basic model is semi-honest, and here the adversary follows the protocol specification but tries to learn more information than it's allowed to by looking at the transcript and looking at what it receives. In the militia setting, the adversary and the corrupted parties can basically do anything that they want. So this is, of course, much stronger security guarantee, and that's what we really would much prefer in practice. A more recent model is called covert adversaries, and here the corrupted parties can again follow any strategy that they wish, but unlike militia setting, we don't guarantee that cheating will never succeed. Rather, what we say is that if the adversary tries to cheat, then it's guaranteed to be caught with some probability, maybe a half or nine tenths or nine nine over 100, whatever, that's a parameter that can be determined. So this models cases where the adversary, in the real world, would be some deterrent of punishment if somebody cheated, maybe they'd lose reputation, they'd be thrown out of the consortium who's carrying out the computations, and so this may be sufficient. In 1987, when GMW presented their construction of circumputation, they actually presented a paradigm or a general way of working. The first step in constructing secure protocols is to construct a protocol that's secure in the presence of semi-honest adversaries. This is somewhat easier because you know what the adversary is going to do in terms of the messages it sends, but you need to check that no information, more information than is allowed is revealed. This is non-trivial, but an easier first step. In the second step, you construct a compiler that takes any protocol that's secure in the presence of semi-honest adversaries and you translate it or transform it into a protocol that's secure in the presence of malicious adversaries. And they do this by using zero-knowledge proofs and commitments and coin tossing essentially to have each party prove that it's behaving correctly and doing what it should do. And then once we get that, then essentially each party is semi-honest and the first step security kicks in. So this is the way the GMW compiler worked. In 2008, Ishai Pabagalan Sahai at Crypto presented a completely different type of compiler for obtaining security in the presence of malicious adversaries and for any number of corrupted parties. And it really works in a completely different way. The building blocks are an information theoretic protocol that's secure in the presence of an honest majority. It doesn't have to be a plain answer between two thirds or even greater, similar to what we saw in the previous talk. And also semi-honest protocols for computing small, simple functions like the product, the shares of the product of shares. Again, similar things to what we saw a few minutes ago. The advantages of IPS and I'll describe how it works in a few minutes is firstly that it has excellent asymptotic efficiency and this was discussed in the original paper but also a year later at TCC in follow-up work by the same authors. It's a completely different way of working that's always good for the field when we somehow have a construction which works in a completely different way. We can learn a lot from that and enrich the field. It's also a black box in the semi-honest protocols. I won't go into why that's so important but you can look at their papers for that. The basic idea behind the protocol is to simulate this information-theoretic protocol that we start with that requires an honest majority but we simulate it without actually having an honest majority and how do we do that? The M parties, real parties who need to run the protocol and any number may be corrupted, run small sub-protocols that simulate this large information-theoretic protocol. So this information-theoretic protocol has servers S1 through SN and the parties, real parties run distributed protocols for each of the instructions of each of the servers and we denote by Pi 1 through Pi N the small protocols that they run. So Pi I will be a protocol that simulates the instructions of the I-th server in the information-theoretic large protocol. These servers are virtual, they don't actually exist. They're all in our mind that are simulated and this large pi is called the outer protocol and the small protocols that the parties run are called inner protocols and we call them clients. So this is how it looks graphically. We have the servers that exist in a cloud. Clouds seem to be popular in slides these days. But these are actually not cloud computing but just in your mind, they're virtual, they're not really there and these two clients down here are running two-party protocols. So each time they'll run the instructions of this but in a distributed way so in a secure way so they don't learn anything more than they should and everything's correct and so on and so forth as we'd like. The main question is what security level is required from these small protocols that the real parties are actually running? If they're secure against malicious parties and everything's fine obviously because that means that nobody can cheat and that means that the simulation of all the servers is correct and private and that means that it's actually as if all of the servers are behaving correctly so of course the protocol is secure. In fact, it's as if there are zero corruptions in that protocol. However, the aim of IPS is to actually start with protocols that are secure against the weaker type of adversary. If we're starting with something that's malicious then sort of defeats the purpose. We wanna start with something weaker, say semi-honest. But this doesn't make any sense if the protocols you're running are secure against semi-honest adversaries but you have real malicious adversaries then no security is actually guaranteed and they can be completely broken so it doesn't seem to work at all. So let's start by considering a variant of IPS that actually appears in our paper where these small protocols are actually secure against covert adversaries and remember that's what we said that you can cheat, there's no guarantee that you won't be able to cheat but if you do try to cheat, it's guaranteed that you'll be caught with some probability. Let's say for here that it's probability one half and these can actually can be made very efficient. Then in order to cheat in the outer protocol and this is really the main observation of IPS, you have to cheat in many of these servers because this outer protocol is resilient for an honest majority. So if only you cheat in only a few, nothing will happen. You have to cheat in for at least half of the parties and cheating because cheating in this inner protocol is the only way to make the server deviate. That's the only way to cheat in the outer protocol. But the covert protocols guarantee that any time you try to cheat, you'll be caught with probability one half. So if you have to cheat n over two times and you'll be caught with probability one half each time, then the only chance you haven't been going undetected is just with probability two to the minus n over two which is very, very negligible. It's a very small exponential function and so therefore you're going to be caught as soon as you try to cheat too much. So you can either cheat a little bit but then the outer protocol, this information theory protocol is secure because as long as only a minority of the parties are corrupted, everything's fine. Or you can try to cheat in many protocols but then you'll be killed by the covert protocol, the covert guarantees which will ensure that you'll be detected and then we'll just stop and you haven't learned anything yet. And therefore the protocol that we get is secure against malicious adversaries. IPS wanted something more, they wanted to actually start from semi-honest adversaries. So how can they do that because then there's no guarantee in a semi-honest protocol, you can actually cheat if your malicious really easily learn absolutely everything, bias the protocol output, do whatever you want and no one will ever know. And that you can actually see by just looking at protocols like yeah. So they introduced this notion of watching and watch lists and the observation is that if you know the randomness and the inputs that a party is supposed to be using in a given protocol execution, then you can actually check that they do what they're supposed to do because you know the exact messages they're supposed to send, you know everything that they know. So you can just check, are they doing what they're supposed to be doing? So what IPS does is they set up this watch list mechanism where each party watches every other party in K out of the N of these executions. So you have N servers and N protocols simulating these N servers and in K of them you can actually know the randomness and inputs of the other parties and check that they're behaving correctly. These causes are the issues relating to corruptions whatever but if you choose the parameters correctly everything is fine. And the main point is that no party knows where it's being watched. So if you don't know where you're being watched then you have to be careful because if you try to cheat too much there's a chance you'll cheat where you're being watched then you'll be caught and then it'll be back exactly like we talked about with the covert case. The covert case if every time we cheated there's a certain probability of being caught and the same thing here you can either cheat a little bit and there's a reasonable chance you won't be caught but then the other protocol is resilient to that small amount of cheating or you can cheat a lot but then there's a very good chance you'll be caught on the watch list and you're dead and then we're happy, we're secure again against the presence of malicious adversaries. Finally our results. So we study this compiler, this new approach from a number of different angles in order to try and deepen our understanding of it. We present optimizations for the protocol for the original IPS constructions to improve its efficiency. We also consider variants of the protocol as I mentioned relating to covert adversaries and the connection between covert and semi honest and malicious. And finally we also study the concrete efficiency of IPS. I mentioned that it has excellent asymptotic efficiency but what about something concrete? Not when we have three and a half million parties running a circuit of size 10 billion will it be actually efficient for reasonable things that we actually want to run? Starting with the optimizations and I'm gonna go very, very briefly through the results because there are many but it's in the paper and also we just recently put the full version on E-print so you can see the details there. The first thing we do is we construct a more efficient watch list setup protocol for IPS and they wanted to go for general assumptions and general results so they used any OT and we use something which relies specifically on DDH assumption. We get something which is much more efficient but just in addition to the actual construction which is more efficient we obtain a more tight and exact security guarantee regarding what the adversary can do to cheat. This enables us to give us a tighter analysis to actually improve the efficiency of everything else in the protocol as well because when you reduce the possible attack vectors then you can actually simplify the outer protocol or not simplify the outer protocol where you can actually use less servers. Details are in the paper. Our setup is so much more efficient that you can actually also have more flexibility in parameters. You can deal with more servers, thousands or even tens of thousands of servers something that in the initial IPS protocol this would very quickly become the actual bottleneck and you wouldn't be able to deal with that which will then harm your overall efficiency. There are other optimizations in the paper as well. Regarding variance, IPS constructs protocols that are secure in the presence of malicious adversaries from semi-honest adversaries and as I already mentioned we use the IPS paradigm to also consider the setting of covert adversaries and understand that in more depth. So the first thing we do is we construct protocols that are secure in the presence of covert adversaries from those that are insecure and semi-honest. This is just like IPS but we now use very, very few watch lists and we get a more efficient protocol because there are few watch lists and fewer servers in the outer protocol.  We show how to construct protocols that are secure in the presence of malicious adversaries from covert adversaries that actually explain to you in depth. And the significance of these results are firstly to deepen our understanding of this covert adversarial model which at least I believe is a very realistic one and useful one in practice. And there was an open question from TCC 2010 who showed how to go from semi-honest to covert but only for the case of an honest majority type protocols and here we do it for all types of protocols and also we go from covert to malicious. So we understand much more how these things fit in. We also obtain a really conceptual and technically simple construction. The transformation from covert to malicious is actually really simple, really intuitive and very easy for example to teach in class and explain to people which is a big advantage. At least if anyone's tried to explain cryptography to anyone it's not simple. And we also get better asymptotic efficiency for at least some, for some specific problems and again I'll leave that for you to look in the paper. Finally I get to concrete efficiency. One of the things that actually when we started looking at IPS we really wanted to understand is this protocol really efficient or is it just when the asymptotics kick in the way out there in 2050. And the reason, but the problem is no one really knows and the reason why no one knows how concrete efficient is is because it has a really, really high level of abstraction. You take some information theoretic out of protocol. Which one? You use inner protocols for simulating those steps. Which inner protocols? You can choose almost anything. The number of servers and watch lists trade off in terms of efficiency and error probability. What's the best to choose? All of these things when you wanna analyze asymptotically it's quite easy but when you want to really understand concretely what's the actual cost this becomes very, very difficult. Just to give an example of why things are different in the IPS setting and we actually, for the choices of the outer inner protocols we started the concrete efficiency of actually those suggested by IPS themselves. But in order to understand why things are different in the IPS protocols when you wanna multiply do multiplication gates like what Gilard talked about in the previous talk. These were every multiplication carried out by parties required by servers requires actually an inner protocol. And this therefore becomes the most expensive thing. When any protocol says just a server should locally multiply two values which in the real honest majority setting is a very, very trivial operation here becomes expensive. And everything else that's done becomes cheap because that these we can do without distributed protocols. So what that means is that you get best efficiency by taking an outer protocol or by taking outer protocol to minimize the number of multiplications that parties have to do. We can do this using the packed secret sharing methodology but it just shows you that the most information theoretic protocol may not be the best protocol to take in the IPS setting. You have to take something which is actually very well fits in to IPS. Another issue that comes up is how many servers should you actually take? And my in the very beginning I said well you always wanna have the smallest number of servers because you have to simulate all of these servers the more that you are the more simulation the more inner protocols the more work obviously you wanna limit this that seems to be trivial. However when you start doing the actual concrete analysis you find out that less servers means that the adversary has to cheat in less protocols in order to get its dishonest majority. And that means that you need more watch lists in order to catch the less cheating. And once you have more watch lists to catch the less cheating to catch this cheating then that in turn actually requires you to take more service in order that you don't have to you can't have too many watch lists versus servers. And so instantiating IPS correctly and efficiently means finding the right balance between these different parameters. And we carried out both an analytic and numeric analysis. So we have some part which is analytical and some part we actually just ran scripts on huge amounts of different parameters to see what the actual costs would be. And we have some rather surprising results. So for the case of two parties and you have an out of protocol with a plain honest majority 4K servers is optimal. K is the number of watch lists. Now 3K is asymptotically the same. It looks exactly the same in terms of the security guarantees that you're getting. But actually what will happen is that if you take 3K you'll end up needing more watch lists and more servers than if you took 4K for a given error probability. So things really are different and surprising and also very interesting. Other difficulties that arise that for every function or circuit you wanna compute you actually need to take different parameters and you need to analyze and find doctor parameters for those. I'm gonna go through it very briefly. Also when you change the number of clients these parameters change and again you have to come up with optimal parameters and these are difficulties when you actually wanna instantiate these things. Just to give you a feeling of what the actual concrete cost is. So if you take an AES type circuit you wanna do oblivious pseudo random function evaluation then we get that for this circuit size a minimal number of oblivious transfers and multiplications because this is the main bottlenecks is achieved by taking a block size of NOV73. This block size is the packed secret sharing I talked about and then for an error of 2 to the minus 40 we came up with these magic numbers 1,752 servers and 207 watch lists and the actual cost is this for two different multiplication protocols you got 13.8 million semi honest OTs you can use OT extension it's not as bad as it looks and 4.5 billion field multiplications or 5.5 million OTs and 5.5 billion and then again so what's better well it probably depends on the machine you're using and how you trade off and is it better at doing hash functions or doing field multiplications and we carried out actually experimental results on a partial implementations and estimates to see how much this would actually cost and the big surprise at least for me when I thought that this would not be efficient for something like this is that if you're using software based multiplication field multiplication it is quite expensive 950 seconds but if you use the new Intel AES chip which gives you carry less multiplication so very very efficient field multiplications this can get down below 100 seconds which is really competitive in comparison to other protocols out there and this is without going all the way of really trying to fully optimize everything we may be a little bit overly optimistic here but this seems to be the ballpark and this tells us that there's real potential for efficiency here in conclusion from our concrete analysis we believe that IPS may be actually really competitive in practice as well in comparison to the other tools we have out there and I believe there's even more potential for multi-party where efficient alternatives are much less common we don't have many efficient alternatives there are serious obstacles and difficulties in implementing IPS there's no general protocol that takes any circuit of work so it's not efficiently because the parameters have to be set and these are difficult but the payoff may be worth it and more research may yield a way of doing this automatically and tightly and there's really a lot to be done here so in summary we have a deeper understanding of the IPS compiler we studied it within itself in terms of its parameters and its efficiency we also studied its relation to covert adversaries and use that as a means to understand other adversary models we have also optimizations in the watchlist set up and other things in terms of efficiency and practicality it is very difficult to specify and implement you have to go far, far down in this tree of abstractions but it's worth it and it seems that we can really get competitive protocols for it more understanding is necessary and more work is needed but we have a whole community here who I'm sure will take up the challenge and new optimizations may even further improve the situation and so it seems that this has real potential for the future thank you and again we have to go directly to the next talk