So we have this fuzzy logic web application. It's playing this game for us. It's an ECG detection game. You can see it's doing pretty well. We will be improving it today. This is actually the fuzzy logic analysis result. We have this project structure. It will be a flask application eventually. So this is the label that suggests we're doing a waveform feature detection using AI or AML. So this signal ECG signal has abnormalities. We could add noise to it as well. That's actually should be pretty straightforward. So if we ask, key tab generates the waveforms. Should be that the waveform JS. So yes, we have the waveform JS. Is there any noise added to the signal? The answer should be no. But we want to add that option. Will that give us any suggestions here suggesting to use math library? Sorry, not a math. It's a JavaScript function. We have the generate full waveform function already. It's been called five times. Yeah, forget how this JavaScript works. That's okay. We have the port help us out times have some crazy RPM on the website. It's a whole different story. But not sure how it actually works. Three or six. Impression RPM. That's very high. But then with every additional impression, it's exponentially going down. And that is it's not tracking overtime. What's going on in the life on LinkedIn is really bad. Doesn't tell me anything about like who joined the messages also do not appear correctly. So that's odd.  So currently, we're working. So finish the music from hands. We had the EG to music converter was the last big web application flask application, the music from hands, hands gesture is just front end. So just all JavaScript. That means that you can see the source code. You're not sending anything to the cloud. And and you are paying for the electricity instead of my server running.  And then we have the EG spectrum that we'll have to come back to some stage, another blog, another simple medical imaging app that actually had some more images for thinking, adding like a mammogram option to it. And now a blog on sampling rates, specifically in the EDA and PPG recordings, which by the way, we're not currently doing on the side, but looking for good data sets that have this data, this data tends to be noisy from consumer wearables and the like. It's hard to get anything useful from it. I'm still getting notification, turn on notifications. Yeah, so I didn't see that comment in the stream. Say it said perhaps Julia for is that programming language or something? I don't even know what it is. But then yeah, trying to stick to Python, JavaScript, just do everything locally. So no third party, anything. Even the libraries. I select a have to be like, you know, no, not like boxes, open source stuff. And we're trying to do things from scratch. So we also for EG, ECG and us, we don't use any of those big, like company libraries, we try to do everything from like math level from scratch. So this is what, for example, for the ECG game, this is what we use for the waveform a generation is basic math, a JavaScript functions currently we're trying to add a noise to it. So we essentially can monitor how well the fuzzy logic analysis algorithm is doing. We currently just changed the threshold a bit, threshold should be how to spell fresh, didn't know how to spell threshold. That was a 3.0 something. No, 1.3 is 0.3 something. Okay, it was actually in the game logic. That's why I can find it. Right, the threshold is 0.377. So when I get rid, we also don't like a magic numbers, trying to get rid of any magic numbers that we will be trying to do as well. And by the way, not monitoring my own sound, which will have me, you will have to let me know if my sound is not working. So with 0.365, this current algorithm is giving a perfect, the perfect results, but we do not like perfect results, would like for it to do mistakes. Yeah, it's always missing currently, if I change, if I change, make this number a bit higher. This is the threshold for the abnormality score that the fuzzy logic algorithm spits out. So fuzzy logic algorithm looking at the raw frequency, scaling it, positive peaks, I don't know why it's raw, it shouldn't be raw, it's just positive peaks. Because originally we, yeah, for whatever reason, we were scaling them as well, but we don't need to do that. So it's just the number of positive and negative peaks. Just check a raw, no, not draw, raw frequency. Yeah, the raw frequency is just frequency. Okay, that makes sense, because then you have a raw and scale. That's fine. Then you also have so we have four files, we have HTML to JavaScript, the waveform JavaScript that's actually generating the waveforms, the game logic, that's the game logic. It's a very good name for a file. So you don't need to explain it, the self-explanatory. Then you have the app, you have the app, what do you have? The app is the flask application. So the app should be separated and separate. So before anyone is complaining about not being able to win the robot in detecting labeling abnormal ECG, just keep in mind that the robot is not cheating. It is just seeing the raw data. So just seeing the waveform, nothing else is making this decision. It's currently set on purpose to always make a mistake to miss, well, because of that threshold. Yeah, made a miss. We can quickly fix that by adjusting this threshold back to 0.365, then it will never make mistakes again. But we actually want to get rid of it. This window is funny. It's not scaling past a certain window size, especially when there is a code being generated on the screen. You need to rewrite the description there at the bottom now that we have the bot also playing the game. Turn this off for a sec. How much stuff can it take? This is waveforms.js in the beginning and end document. It's game logic. We need the same. Yeah, we have it already. Now the other thing is we can get the read of the comments. We can get rid of the comments. We never read comments. I don't know why people power with comments, considering no one reads it, especially now with LLMs. Just pop it in. The chat will summarize it for you. So this is a good task for GitHub Copa to get rid of comments, but I'll just leave it as is. Let's see how much stuff is single prompt. Pop this in. This is the end of game logic file. Then we also have the flask application. It's format document. This is the end of line. I don't know why it is there again. Also why the linter is putting two carriage returns in some places. That's a bit of a mystery. Might as well. I don't know if it can take it all. Probably not. Currently, the abnormality is the abnormality membership function being used. Can we make sure we use the abnormality membership function in the back end and in the back end make a decision as to yes, no, if the signal is abnormal or not? I think we're already doing some of it, but it's not being implemented correctly throughout the code. As in, we may change this to the Python code, but from memory you still need to change the JavaScript. Yep. So it's probably the longest prompt we ever tried and amazingly can take it. So let's do one by one. Yes, the abnormality membership function is indeed being used in the back end of your application. If we break down our app.py code, particularly in the fuzzy underscore logic underscore analysis function, you can see that the abnormality variable is defined as a fuzzy logic consequent. This means it's the output of your fuzzy logic system intended to determine the likelihood of the ECG waveform being abnormal. Yes, but we're not currently fully utilizing it, I think. Your code has defined several fuzzy rules that combine the input variables, like frequency, amplitude, positive peaks, negative peaks, and map them to the abnormality output. The output is a score between zero and one, representing the likelihood of abnormality and the ECG waveform. Yes, that's correct. And also, we have three levels to it, but obviously for a yes-no decision. So it's essentially yes-no, maybe, well, a practically the membership function, but it's mentioned 38 times. That's the main thing. Yes, we have abnormality in this very convoluted language, isn't it? It's like a double negative or something. As we're saying, it should be normal, not like normality. And if it's if it's likely, then it's normal, then it's if it's unlikely, it's abnormal. And in this case, we have the measure for abnormality. So if it's likely or possible, essentially suggests that the signal, the ECG waveform is not normal. And those are the thresholds, except they would not work for the current code. Because the lowest it goes to is that magic number of 0.365. That's not cool, is it? So do you think the port can solve this for us? Your code has defined several fuzzy rules that combine the input variables, like frequency, amplitude, positive peaks, negative peaks, and map them to the abnormality output. The output is a score between zero and one, representing the likelihood of abnormality in the ECG waveform. Regarding the integration and decision making based on this abnormality score, your back end does analyze the waveform data and calculate an abnormality score. However, the decision, normal or abnormal, based on this score is not explicitly made in the back end. Instead, the abnormality score is sent back to the front end, where the decision could be visualized or used further. Yeah, so we don't want to do it at the front end, we want the back end to return the abnormality score, but also essentially return the decision, make a decision, normal or abnormal. And then we calculate the score. Currently, we use the magic number threshold, which is okay, but not ideal, especially if we're trying to use fuzzy logic correctly. Everything should be in the form of these membership functions. You can go and look them up, there should be a lot of content on explaining fuzzy logic, the basics of it. So, to fully integrate this new system, you want to make a decision in back end, modify the back end to make a binary decision, normal, abnormal, based on the abnormality score. You can set a threshold, and if the score exceeds this threshold, label the waveform as abnormal. Update front end accordingly. Once the back end makes a decision, you should modify your JavaScript code to reflect this. For instance, you could display this decision on your webpage or use it to adjust the gameplay mechanics in your ECG scoring game. That's what we are doing already. So, in the three items that you suggested, a couple of things. Yes, we do want to make the decision in the back end, but we don't want to use a threshold. We want to use the membership function. Now, the second item, yes, we want to modify, we want to send the decision as well as the abnormality score to the front end, and we want the decision, the yes, no, normal, slash abnormal, to be used to calculate the score. Synchronize changes, ensure that any changes you make are reflected consistently across both front end and back end. For instance, if you adjust the threshold or the rules in the back end, the front end should be updated to match these changes. Okay, so you have all the code that we have so far. Are you going to modify the script or generate prompts for GitHub copilot to use? Another problem is the current a membership functions for abnormality has a 0.3 threshold for abnormality to be unlikely. The fuzzy logical rhythm returns 0.31 for normal ECG waveform. Let's double check that. So it returns, okay, 0.56? What? No, it's doing 0.56 all the time. So 0.9 for this one. So it's highly abnormal. Yeah, there's something wrong. 0.37 and 0.36, 0.36. Yeah, 0.37 for this, like essentially slightly abnormal, 0.37 for this one. That's okay. And 0.36, 0.49, 0.84 normal, a waveform, fuzzy logic rhythm. No, fuzzy logic algorithm. It's what I'm struggling with the transcription thing. It can never get what I say correctly, unless I speak like this, but slowly. But even then, a certain terminology, it gets incorrect. As late as those live streams get transcribed by YouTube using the Google API, I would imagine. But yeah, I have to go and manually correct the text, which is not fun. Let's send that one. Okay, so making decision in the backend using a membership function. To use the abnormality membership function for decision making instead of a fixed threshold, you can modify the fuzzy underscore logic underscore analysis function in app.py. The decision should be based on the highest membership category, unlikely, possible, likely for the abnormality score. You're already calculating the highest membership category. So you can directly use this for decision making. When you have code in this window, it doesn't actually scale, it doesn't become larger properly, as you would expect. On larger screens, it just remains tiny. So I have 125% size. It's okay. Okay, now wondering what will happen if you pop this into... So we have the Python code. We're looking at the fuzzy logic analysis function. Yeah, we're ready to do that. Yeah, there is a decision. We're returning decision reviews yesterday. It's already doing that. It's already using the abnormality membership function for decision making. The decision is based on the highest membership function category, unlikely, possible, likely, likely, possible, likely for the abnormality score. Here's the relevant part of the code. Now, why do we need the categories again? And the decision is normal if highest membership equal, unlikely, else abnormal. Okay, that's fine. So we're really doing this. This modification ensures that your decision, normal, abnormal, is based on which category of abnormality has the highest membership value, not just a fixed threshold. You need to ensure that the decision made in the back end is sent to the front end. You can modify the response data structure in the Analyze underscore waveform route to include this decision. We have Analyze waveform route, have response data, write this one we'll need, else it's the result and decision. Okay, sorry, it already knows. In your JavaScript game underscore logic, JS, you should process the decision received from the back end and use it to calculate the score. You might need to modify your existing score calculation logic to factor in the decision, normal, abnormal, along with the abnormality score. All right, so are you actually going to do the code? It doesn't look like making that abnormality and the positive peaks can be just positive peaks without the row, change it in the HTML as well. Write this abnormality should be called the abnormality score instead of abnormality, call it abnormality score. You'll get rid of this one. Let's go if it's not getting context, it's called abnormality score. Then we also have should be decision. Yeah, obviously, there's no way to take it from the idea that abnormality score. Yeah, currently it's taking that abnormality score, but it should be just the decision, should be just decision. Okay, so to change a couple more things, call this abnormality score. We have it in the normalized I'll show you about this score. That's wrong, it's tracking. No, it's decision save a control by ID, it's not taking it. Decision take a request. Okay, yeah, that's abnormal. All right, because yeah, so the threshold is wrong in both cases. Okay, so we're displaying this decision on the front panel, normal or abnormal. Now, in JavaScript, we haven't gotten read this line. And in Python code, we need to adjust the membership function so that the magic number is within the normal range. Let's actually try to make something ourselves without the port. No, we will use the port. We want to generate this function, and it should be regenerate. Okay, it's actually getting it, let's see. And no, get up, call parties. And no, good. What if we select the whole code in the 201 lines of code regenerate the update fuzz score. Nope. Yeah, didn't have the context. Close it for now. This does sound correct. So instead of relying on that function, we want to rely on normal abnormal out for a sec, a copied again. Now we also write in your Python app.py file, you need to treat the abnormality membership functions so that a score like 0.36043 falls under normal category. Here's an example of how you could adjust the membership functions. Yeah, there's a problem with that is that the first abnormal like the lowest abnormality score for abnormal is very close. The lowest score for an abnormal ECG waveform is just above this number. Which is a problem because 0.5 will be too high. So 0.5 is way too high. Understood. If the lowest score for an abnormal ECG waveform is just above 0.36043, and you want this value to be classified as abnormal, you need to adjust the membership functions in your Python code so that this value falls into the likely category of abnormality. Let's modify the membership functions accordingly. Okay, this might be better. There will be overlapping like the, yeah, because it's a triangular shape. We're not plotting it anymore, but probably should. That will require more work. I don't want that. We might later do like a general, so we'll have a new tool. It will be the ECG bot, the KarioQuest bot. I'll give it another name if you have any better name suggestions, please do let me know. But, and then later we might do a more simple fuzzy logic tool. A simpler example. Scores up to 0.36 are considered unlikely normal. Scores just above 0.36 start entering the possible category, and scores from around 0.44 onwards are firmly in the likely abnormal category. This adjustment should align the fuzzy logic analysis more closely with your expectations for classifying normal and abnormal ECG waveforms. Remember, these values are just a starting point. You may need to fine tune them further based on your test results and specific requirements. Yeah, so in the beginning it's still adjusting its thresholds, so it's making mistakes. So it's going to, yeah, minus 60 score. The human one said not to go below minus 50, might change it, can go negative, it's fine. I think there's something wrong because how the fuzzy logic score is calculated. Yeah, we need to adjust this score, I'm just waiting. So normal is still generating 0.4 now, so why? It's like getting better over time. There's some thresholds that need adjustment, that are adjusting as we go. Okay, so we need to adjust how the score is being calculated. Go from HTML quickly. I know it's actually, yeah, you can select it, it's not actually text. It's being overlaid, oops, fuzzy, scored fuzzy score gets based on the decision and waveform type. There's something wrong here. I expect this should be reversed. They seem to be their fuzzy score, seem to be going in reverse. Can you double check the code you generated? The decision of normal and waveform type. Let's reassess the update fuzzy score function in your JavaScript, game underscore logic, JS. It appears that the scoring logic might be inverted. The goal is to increment the fuzzy score when the decision is correct, whether the waveform is normal or abnormal, and decrement it when the decision is incorrect. Here's a revised version of the update fuzzy score function. Okay, so we definitely do not need that anymore. I'm not sure about this update that you made. It looks the same to me. Yes, it meant to be inverted. So for abnormal, the score should go. So zero is normal. One is abnormal. Yes. Okay, why the score is not going anywhere now? Score is not going anywhere. That's some silly mistake. Okay, this should take care of it, doesn't it? My GitHub co-pilot is not working. It's not completing the code. It's taking, oops, it's done by co-pilot. Funny, like that. Taking decision. Yes, that was wrong. It's a false alarm. It's abnormal. It's essentially saying yes to anything, clicking on anything. It should become better over time. So for normal ECG, currently it gives a 0.4. What's actually later goes down to 0.36. Continuously chatting to oneself or to an iModel like GitHub co-pilot is a bit unconventional, but I understand the context here is to brainstorm or debug an issue with the code. Regarding your problem where a normal ECG waveform is generating different abnormalities scores each time, there are a few areas we can look into. If the input ECG waveform data varies even slightly each time, it could lead to different fuzzy logic analysis results. Ensure that the ECG data being passed for analysis is consistent for what you define as a normal waveform. The use of global min and max values for frequency, peaks, and amplitude might introduce variability. These values are used to normalize the input data, and if they change due to new max or min values being encountered in the data, this can affect the scaled values fed into the fuzzy logic system, leading to different abnormality scores. To address this, you might consider using fixed thresholds for normalization based on the expected range of values in a standard ECG, rather than dynamically updating them. The way the membership functions are defined can significantly impact the classification. Given your example data, the scale frequency of 0.6 is classified as normal in your system, but the combination of other parameters, positive peaks, negative peaks, normalized amplitude, might be pushing the final abnormality score into the abnormal range. It might be beneficial to review and possibly adjust the membership functions or the rules in your fuzzy logic system to better align with what you expect for a normal ECG waveform. Ensure that the fuzzy logic system is stable and produces consistent outputs for the same inputs. This can be tested by feeding the same data multiple times and checking if the output abnormality score remains consistent. Rigorous testing with a variety of ECG waveform data, both normal and abnormal, is crucial. Log the inputs and outputs to understand how the system is behaving and where it might be deviating from expected results. One approach could be to recalibrate your normalization process and review your fuzzy logic rules. Here's a pseudo code outline to guide this process. This approach focuses on reducing variability introduced by dynamic thresholds and aligning the fuzzy logic system more closely with clinical standards. Remember, fine-tuning a system like this can be iterative and may require several adjustments based on testing results.


All right, I can finally talk again. So let's let's say stuff Looking at your email. I'm also old and sick and confused You said you had a lot of thoughts about the robot gun pose and this is what you came up with I'm totally confused because I have this and this and I'm not sure what you mean with the gun pose and This is what you came up with. So maybe you're missing an attachment. I only have two attachments I don't know. Let me know. This is probably me being Old and confused other than that when you say the hands a bit too clean What do you mean? I'm don't make it dirty and how so by clean It's usually clean stuff is when like imagine that hand is down here You know behind it whatever behind the door and then it kind of goes up and it will kind of just kind of rest there It's almost like a mechanical clicking of from here to here And if you if you touch something if you want to hold on to something it could be like those fingers might get there first and Then you would have over I don't know seven frames an adjustment where you can feel the tightening of the hand The palm is actually really now resting on on the door. Yeah, whatever example would be for hand contact But something where the hand doesn't just get to the object and then stops Like imagine you grabbing a bottle but not like forcefully and quick It's just you grab something you put your hand there But then you have to have a slight adjustment and then you have the actual grip when you lift differences So there's all kinds of stuff that you can add to make it just less clean basically, but if I go back here Like actually this will be a great example, too I wish just So if you look at your hand here That that super clean has the eye goes from this pose Boom and then that's it. There is no like you can see how this is straight and the stay straight Versus you could get to this You know in the pose like that fingers somewhat curled around and over maybe 10 frames as she lowers And as this elbow goes lower as well, then you get to this with the thumb adjustments Maybe it's like curling over the fingers But you can also see how The hand is not really visible so just even just silhouette wise. This might be too much to show your arm like this You know, she ends up being too like howdy cowboy like So you might have to go in like that which might not be enough room So you might have to see how she shifts over this way you might have to shift over to the left Which you could she could do this Take that step and then because of that step. It's this leg Sorry Readjust here. I like this program for critiquing, but I wish it was a couple presets of sizes Anyway, we're just drawing off-screen was that Basically, it would be cool to shift over this way so that your body like her butt is here Her back is here so that you have a bit of this So You know, she can have her hand like that. That's maybe a bit more cliche a woman like but you know That could be something so elbows in and now you see the forearm and you see the clean silhouette of the of the wrist And by doing that so when she takes a step here See how you swing over to lean over this leg, which is fine But what if you don't do that you stay there and when she takes a step It's actually the step and this leg that pushes this way for her then instead of going this way She leans over this way and then when she goes this way Instead of you doing just a rotation here Actually would be nice because then you push off with this leg and she translates over for a weight shift to get into this Which would also add some more complexity and everything. I think that would be kind of neat and Don't forget translates here as well. This seems ever so slightly One-two rotating off the feet So you have this pivoting over then we get to this foot Then we put over this foot and then we pivot. Yeah, this one's not too bad. That's a good shift there But this and this feels a bit too one two clean Rotations pivoting over the legs This is also a bit too in sync where your hand and chest moving at the same time Like you'd be like this and then she would turn her head first So, you know, she could be like this But that chin pointing this way will be pointing this way and only then would this come into play That's cool like that though this lean back is a bit simple when I look at this I Don't feel the hits Like the hit not that she has to hit the wall But you want to feel something where the chest reacts and then the head reacts. They will be separate I think this is good. I wonder if you almost push it slightly more for a little bit of a offset Just something where we were headed away away from like straight away from the camera in a Perspective that doesn't really add much from here to here. This was almost like she's scaling back So, you know, if you look at your route, it's almost like it was who goes perfectly away from us Maybe you can do And I'll play try to play around with maybe a bit more to the side with a slight wire rotation So she hits this on one but cheek and then as she rests here Then she puts the second but she gone to be flat on us anything so it's not always super flat during movements That's not too bad. Could you also next time submit? Which I can totally do here. Sorry, I just opened them separately in the program, but What's the word like one after the other I can open them in quick time do it myself never mind I can do it myself But those are the notes for this guy and then this one That feels a bit fast Right there That over feels a bit rushed Like she comes down stops moves over stops and then starts the line if you can Like this is all cool. I love all this But even her arms down are fast whoop like she's trying to get them off screen And also intersecting a lot That's cool. I like that that off-screen grab though. That's great But then she gets very simple where she has that Move back with the head that seems mostly in here not much in here And then it's just kind of nothing there, you know So I think you're definitely headed in the right direction. It's just but you're inching there You got to take some bolder steps in terms of You can start, you know offsetting things even like shoulder stuff is not offset You can start that in your initial in your passes to put offsets think about Wait if she leans over how that head might lean on this not just Piece of straight you want to feel contact through here? I mean she does all this here imagine That grabbing here that might still be a slight pivot off the root of her bunzees She could rotate and kind of not inch around and scoot around but some things with does it's not just Translate down now. I'm done. I'm doing nothing with the root anymore because that's just all in here. So I'm not sure how you Do processes if you kept shooting reference or if you have new reference for this, you know I would always reshoot reference like now you're in this stage Well, let me shoot reference with this this angle and and that's exactly what you're gonna shoot You find something where you lean against it and you do all those moves and you do those moves 20 times Just to see what happens and you can pick up things here and there for complexity So yeah, I would make sure that you start offsetting things that this down is not as simple like she comes down And that's kind of it so and then transitioning into this not so it's not so one two and Then this here fills with simple to this that that nick the head back feels like it's just a translate back It doesn't involve any of this and any of this So just keep going with mechanics. All right. Thanks All right There's an email you can sign up you can start whenever you want you can submit whatever you want You get 16 submissions either way a like and subscribe would be awesome. All right. Thank you