Fpu dev #849
Fpu dev #849
Conversation
|
Chiming in after using this for the past two weeks eating LCHF. Before I'd pre-bolus the protein and end up a bit lower but nothing dangerous. Then I'd end up what I consider high a few hours later and loop wouldn't be aggressive enough. This seems to solve both issues. |
|
@rsilvers129 have you been continuing to work on this? We’ve been using it for some months now with good success. Wanting to update to the latest dev but the merge conflicts here look pretty intimidating :) |
|
I’ve done my best to bring the changes here with FPU and IRC (#726) in line with dev on my branch here: https://github.com/mitchellhenke/Loop/tree/mitchell-rsilvers129-fpu-irc |
|
The direction Loop needs to go is towards requiring less of the user in terms of input. I think an updated carb absorption algorithm that accounts for fat & protein based on the three main choices (lollipop, taco, pizza) or something similar, would be acceptable. Adding something like this should replace duration. Finally, the algorithm updates should be integrated into the carb absorption model in a thorough way; not 'hacked' in, like using the FPU terms to modify number of carbs or duration terms. |
|
Hey Pete, in that line of thinking would we still be having users input "fake" carbs for protein (as carbs) in a more simple carbs + protein/2 or whatever ratio they determine? Or would it be worth it to try to just categorize meals as S M L XL (and display a number next to them possibly)? It seems doable but I don't know the impact of letting Loop have that level of control. |
|
Yeah, I'm not sure if there is a way to have users enter a meal simply and still account for fat & protein separately. That's why this interface is tough. Many users already just swag their carb estimates. I would need to look more into the modeling that Robert's work is based on, but if, by selecting a meal size of some sort, and something that indicates roughly the proportion of fat, protein, and carbs (like lollipop, taco, pizza), it's possible that the model works out better, and is still convenient enough to use many times a day. |
|
Interesting. I guess my point for the new carb model in future releases is to factor in meals w/low (or zero)carbs but lots of protein and fat....there will be a spike hours later. I am not confident high temping will always work. Or, if carb entries (or meal entries) are required like fpu does right now? Do you see the new direction addressing this concern? Think ribeye steak, some pork belly, and avocado boat? How do we use loop now to account for that w/o fpu. |
|
In my experience a high temp can deal with protein just fine. All FPU really does as far as Loop is concerned can be though of as: https://youngandt1.com/how-to-bolus-for-fat-and-protein/ Is the most friendly way to read it. So for a steak example (where we'd choose the steak icon) and maybe put in what we assume to be our fake carb amount that I eyeball as 60g protein or 30g carbs we would consider that as "large" and then absorb the 60g over the next 6 hours, assuming it starts in 1 hour. The real trick here is fat is the bigger player in absorbtion time because FPU is based on calories and fat is 9cals a gram and protein is only 4cals a gram. I think, if we want user friendly, we magic away the fat and just have that known from icons or size of meal. It might also work if Loop allows you to add food icons together. I don't know if it already does that but if you could, for your example, choose steak and also a pat of butter to signal this is a fatty steak, not a lean steak. If someone can point to a more technical doc (class workflow would be amazing if it exists) on how loop absorption works I can see what I can test on myself. I don't know swift or iOS but it's enough like C# and python that I can maybe hack out something. Looking at the slider that got implemented for override maybe something like that for meal size? Is that enough input? I guess there's an easy way to find out. |
|
Ok but if you are only eating steak and Fat for your meal and you plug 30-35 grams of carbs Loop will still give you an upfront bolus. In my experimentation I do not need an upfront bolus, the rise is usually 3-4 hours after eating. This is where I have seen the fpu be more of an automatic, less thinking tool. I suppose I could push the 30 carbs to start 2 hours later but again just not sure. I guess we need some real world testing to really prove the point. |
|
Well how about this, three checkboxes (there's got to be a prettier way) for carb, protein, and fat. Check the ones that are relevant to your meal and that would dictate what FPU considers the delay factor. Each also has a slider for (1-5 rating) for how much of it you ate. If you don't check carb you don't need anything up front. The actual math isn't something I can speak to how we make it work right but I do think the point that having people input three macros correct isn't user friendly when most already eyeball the first. Loop should be smart enough to figure it out, that's half the point of an APS. I've used loop with FPU shortcut and this branch and we can do something more friendly. |
|
Agree with Jacob2877. |
|
That would a great idea actually. Love it.
|
|
@gwelda FPU abstracts that math away from you in a friendlier way but it is still operating in the confines of what carb absorption you could, as a user, already do. What we can do is further hide it because the less user input, or the friendlier the input, the better. FPU is to what we can envision as an APS is to bolusing and high/temp based on your own human ideas. You can already do everything Loop does for you manually, but Loop is able to hide all the math. FPU was an amazing V1, now let's focus on making V2. And I say all this as someone who eats almost purely protein and fat. |
|
Loop’s FPU does not match the research exactly around the duration in particular, but the math isn’t too bad relatively speaking 🙂 The algorithm is based on the total amount being eaten as well as the ratio between carbohydrates and fat/protein. An interface that provides the “size” could be sufficient, though the sizes ultimately have to become a number in Loop. Getting that approximately correct may work though given the longer timeframes. Happy to discuss with anyone that has ideas/feedback or wants to develop on Zulip. Have a thread going here: https://loop.zulipchat.com/#narrow/stream/144182-development/topic/FPU |
@ dyaks |
|
@mitchellhenke @ps2 |
|
@ps2 @Jacob2877 A food triangle. Not sure how many tiles but I think (hope) the idea is intuitive. If you eat a straight carb meal there is an icon there, the tip, that is only carbs. Same for fat (butter) and protein (egg whites) with example foods all throughout. Nobody wants to look up the macros for a doughnut to configure the slider correctly so let's just do that for them. A force touch of any item shows a high level of what Loop would do so if it's not what you're looking for you can move on. Then we have the meal size, XS, S, M, L, XL. This is where I'm stuck. Ideal would be user configured based on calories. That then makes the FPU algorithm easy to go off of. Problem is, people underestimate calories and there is some physiological issues even thinking about them. So how do we determine what is S and XL? If I/we can answer that then users are just needing to pick a food that is close and a size, Loop does the rest. Feel free to tear this apart. In fact please do, I would build it with sliders because I'm front end challenged and making it would take far more ability than I have. :) |
|
"The direction Loop needs to go is towards requiring less of the user in terms of input." "I think an updated carb absorption algorithm that accounts for fat & protein based on the three main choices (lollipop, taco, pizza) or something similar, would be acceptable" "Finally, the algorithm updates should be integrated into the carb absorption model in a thorough way; not 'hacked' in, like using the FPU terms to modify number of carbs or duration terms." Please, add it with a toggle in settings or else it will take years to be done another way. Low-carb people need it. People who are precise with nutrition apps want it. I know you said that the beauty of open source is that people can use any branch they want, but having it not be in the main branch is basically death for this feature. |
It doesn't exactly match because I had a conversation with the research paper's author, and she said that it was coded for a manual pump with programming limitations. She gave me guidelines about how the duration should be coded for a computer, and I implemented those. She couldn't tell people "In an hour start a square wave" but a computer can do that. |
|
MY $0.02. Feature toggles in production are a recipe to unmaintainable code. One toggle is two code paths, two toggles make four, three make eight, it escalates very quickly. If there were to be a toggle it be something to have manual input of P/C/F vs meal guesstimate via icon input but both should execute the same math. |
|
It could be the same code path, but the fat and protein fields would be hidden on the meal screen - leaving fat and protein filled in as 0. |
|
That doesn't get around the bigger issue outlined here: Preserving input and presenting accurately and clearly to the user would be needed as well. So in the end it's back to having to reclassify how loop thinks about food and decays that food. Not about just imputing food and losing (as well as splitting) meal state. |
|
I made a poll to see if the actual users wanted more control or more simple: https://www.facebook.com/groups/TheLoopedGroup/2262841400599180 |
|
Two things on that:
I'm happy to provide my help on user scenarios but I will not code that because that is a design flaw. |
|
The easy thing to do would be to just delete the equivalent carb entry and be no worse off than the current version of Loop where one goes high if they eat that much fat and protein. Or edit it to a smaller amount - about half would be good. While I use a gram scale and nutrition app, most people estimate these macros anyway - so they can estimate their edit as easily as they can estimate the initial entry. I mean yes, coding in editable fat and protein is better, but not if no one does it. After all, I coded this to begin with because no one else would do it. But if you want to do it "right" and make fat and protein editable, that would be great - it would be better than what I did, and more perfect. But that is not what Pete said. He said that he doesn't want people to be able to enter fat and protein in the form of grams. The poll shows that people do want to enter fat and protein in the form of grams. There are a ton of low-carb/keto eaters and I am very aware of them. And it has allowed me to eat half of a large pizza and stay in range. How great is that? I made this because I thought it would help people and be popular, but it has no chance if it is only in my obscure branch. We have an opportunity here for another innovative feature in Loop that will keep it as being a forward-pushing leader, as this is not in other systems yet. Adding editable fat and protein would make it perfect, but it is beyond my ability. |
“If I had asked people what they wanted, they would have said faster horses.”
Also they way you phrased your poll was heavily biased. The question is more "do you want Loop to have more user interaction or less". Nobody there really cares what goes on behind the scenes as long as blood sugars are nice and flat. This discussion is now on three fronts: here, zulip, and FB. I vote for keeping it here or zulip. Before any public discussion happens, because it gives false hope which is why FB was not the right place), on getting some kind of FPU feature into Loop it needs to be decided on how it is presented to users and how Loop will be modified for it from an algorithm standpoint. What we do know now, which thank you very much for, is how important it is for an APS to understand fat and protein. How it handles that is the question. |
|
I am not a developer although I am interested in DIY programming. I guess for me, the most important point regarding FPU is that my diabetes care doesn't work the best with a carbohydrate only model. I am guessing this is typical for the people who responded favorably to the pool, Robert posted. Regardless of me being low carber or not, fat and protein are very important in metabolism and how type 1 diabetes needs to be managed.
I like the idea that Shawn wants to innovate and make FPU or the idea of including fat and protein easy and simple. Shawn reminds me of the late Steve Jobs at Apple. However, with this being a DIY open source software, I am a little confused as to the problem. If there is a person within the community that knows how to integrate fat and protein into the carbohydrate model, why not allow that with innovative changes during refinement?
I guess if the argument is to keep it on a dev branch and not on a major release, I can live with that. But, using fat and protein in the metabolism model of food is so important that I think that is why Robert is bringing it up again. I have seen much better results with incorporating Fat and Protein into my loop settings than without it. I think one of the takeaways with all this happening on here, facebook, and zulip is that this is something important and many people agree. How to get there or what it looks like? Not sure. FPU is a starting point.
On May 13, 2019 at 10:28 AM, Shawn <notifications@github.com> wrote:
The poll shows that people do want to enter fat and protein in the form of grams.
“If I had asked people what they wanted, they would have said faster horses.”
Henry Ford
This discussion is now on three fronts: here, zulip, and FB. I vote for keeping it here or zulip. Before any public discussion happens, because it gives false hope which is why FB was not the right place), on getting some kind of FPU feature into Loop it needs to be decided on how it is presented to users and how Loop will be modified for it from an algorithm standpoint.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'd like to give credits and thanks to @rsilvers129 who brought up front the need to address protein+fat dominated meals in Loop, and also developed a working branch demonstrating one possible approach. The branch has been tried by a number of people, and anecdotal feedback has been positive, I as far as I've seen. How to properly account for protein+fat, while at the same time keep the user interface simple, clean, robust, and effortless is a problem worth discussing. Here, zulip or FB are all public forums, and there is nothing wrong with having this type of discussion in the open. FB is messy, so I suggest we keep it here or better yet on the original issue #702 opened by @rsilvers129, just so we try to keep as much as possible in one place. |
|
Sounds good to me - |
|
I think maybe a starting point could work like this: Then, as a toggle (even though I hate them) enable the ui as Robert already did. The big change would be on the code side where we have a single start point of absorption we’d have two but they’d tie to the same entry. When you modify that entry if you have the toggle on you can modify all macros. Never do we show “carbs” to be edited, users change protein carbs and fat. The math for absorption time and carb equivalent are all dealt with behind the scenes. |
|
True that Facebook is not useful for the implementation methods, but it was useful to see if people want to enter fat and protein exactly, with guesstimate buttons, or not at all. We learned that (so far) 13.5x as many people want direct fat and protein entry vs a pizza button (216 vs 16 people). We also learned that no one wants it the way it is now (with no consideration for fat and protein). I created this on the cusp of people being macro conscious, and the response this time was even a lot larger than when I first coded this. Pete is the decider and he didn't want this, even with editable fat and protein, so I am hoping he changes his mind. Others seem to instead be debating only if this is good enough with FPU converted to carb, or if protein and fat need to be editable. I am going to agree that editable protein and fat is the "correct" way to do it. But is perfection the enemy of good enough if it means that the feature dies entirely and no one gets to use it just because 1% of the time someone will have to delete the entry and start over? I am not sure. If it were my call, I would put it into dev, and then let it evolve inside dev to eventually have editable fat and protein. The second option, that most of you seem to insist on, is to get protein and fat editable before adding it to dev. That is the kind of thing that Pete and developers more involved that me get to decide. I am fine with anyone's code, but don't want it to die as a feature - and I can't code that myself. It's not that I didn't think of it. It was beyond my ability. |
|
The elephant in the room for this is if it gets into dev, which is main, what does that mean for Tidepool? As I understand it the base code will be the same which I’m sure is a heavy factor into not only what gets pushed but how the underlying code is built. I’d yolo modifying fpu to use fat and protein like it should but not without a hope of it making it in. I just started a new job so my time is already limited. |
|
Did this go anywhere? While I understand the desire to keep things simple from a user's perspective, it really seems to me that, long-term, integrating fat/protein data into Loop's data input is a must-have. Can you imagine a day when machine/deep learning is used to analyse local historical data and even crowd-sourced data, to extrapolate how to best behave in a particular situation, for the most likely optimal outcome? The more relevant data is fed into such algorithms, the better they usually perform. And we don't necessarily have to assume that all such data is manually entered by the user every time. For example, Loop could:
So I hope that the fat/protein effect is not ignored in Loop, as it can really be significant, and ultimately users would benefit from better blood sugar control if it is implemented in a way that is user friendly. |
|
This still lives on here: But I don't think there is any intention of it getting into mainline loop. Perhaps some kind of floating carb and UAM/IRC/something new kind of approach could do it since the deviation is small enough. I dunno. |
|
See my comments on the LoopKit ticket for this for information on what needs to happen to make this land in Loop |
|
Hi, Can I use this changes in last version 2.2.4 !? |
|
@fmb787 It won’t work, no. I am thinking about taking another look after the next major release, which includes some bigger changes to meal entry. |
rsilvers FPU modifications.
Adds in support for fat and protein.
See Wiki:
https://github.com/rsilvers129/Loop/wiki/Fat-Protein-Unit-Branch-(FPU-dev)-of-Loop!-With-IRC-and-Spike.
See video:
https://www.youtube.com/watch?v=OvpRUlD0acU