Fruit in Food Database
39flavours
Posts: 1,494 Member
I've had a quick search for the answer to this but can't find anything, sorry if this has been asked many times before...
I've been eating a lot of bananas recently and I'm not confident that the listing I'm using is correct. I've been using a listing that says 'banana without the peel' and logging 90g of banana flesh as 80cal but have noticed other listings of just 'banana' as much higher for the same weight. Does this refer to a 90g banana weighed with peel, meaning the contents are going to be lighter and less calories? Are fruits with peels that you don't eat listed nutritionally as just the flesh or does the info also include the peel? It got me thinking as for example orange peel has oil in it, but little if any in the flesh so how is it represented in the nutritional info? What if I only wanted to eat the peel for some strange reason, surely the data would be different than for the flesh?
I've probably made a mess of trying to explain what I mean here 🤣 I usually use the USDA green tick listings where I can, I just want to be sure I'm doing it right.
I've been eating a lot of bananas recently and I'm not confident that the listing I'm using is correct. I've been using a listing that says 'banana without the peel' and logging 90g of banana flesh as 80cal but have noticed other listings of just 'banana' as much higher for the same weight. Does this refer to a 90g banana weighed with peel, meaning the contents are going to be lighter and less calories? Are fruits with peels that you don't eat listed nutritionally as just the flesh or does the info also include the peel? It got me thinking as for example orange peel has oil in it, but little if any in the flesh so how is it represented in the nutritional info? What if I only wanted to eat the peel for some strange reason, surely the data would be different than for the flesh?
I've probably made a mess of trying to explain what I mean here 🤣 I usually use the USDA green tick listings where I can, I just want to be sure I'm doing it right.
0
Replies
-
The green tick listings are not *necessarily* correct either...just three people thought they probably were.
Any food you eat is just for the portion you eat...I use the first one in the list when searching for "bananas raw" - it is the admin entered one, you can tell by clicking the drop-down menu on the portion sizes (there will be a long list of various portion choices)
3 -
Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
0 -
Whatever.
The one I posted is the Admin-entered from USDA entry. I don't know how the apps do searches, but I do know that, "bananas raw" (or any fruit vegetable - raw) will pull up the admin entered one somewhere in the results - HOWEVER you do have to search for the one with the different portion descriptors out of that list that comes up.
There are 17 choices in the "How much?" drop-down list....I've just learned to look for that in the "Apples raw" lists.
1 -
@cmriverside Thank you!
I didn’t know that the listing with the largest variety of measurements was the admin entered ones. That is useful info. I always look for entries with weights as measurements not volume and am surprised at how difficult that can be.0 -
@cmriverside Thank you!
I didn’t know that the listing with the largest variety of measurements was the admin entered ones. That is useful info. I always look for entries with weights as measurements not volume and am surprised at how difficult that can be.
You're welcome.
I wish I could get a screenshot of it, but it disappears when I click, ya know?
When searching for fruit and vegetables, always use "raw" as a qualifier first...then usually the admin-entered ones have many many upvotes (they'll have green checks, but also a high number member verification.) That helps. There are usually a lot of good entries and a lot of them do say, "USDA" or will have the lookup number from the USDA database. If it says, 'USDA' in its title or has the number, it's user-entered (not necessarily wrong, but I'm just pointing that out)
I just take the time to find the right one entered directly from the admin the first time and then it's in my "Recents" list. Much easier than having four or five "bananas" entries in my "Recents" list. I also get all the added micro-nutrients that way that aren't available in the member-added ones.0 -
Whatever?0
-
39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.1 -
https://www.healthline.com/nutrition/bananas-calories-carbs
I periodically use articles and information from this site0 -
@cmriverside Thank you!
I didn’t know that the listing with the largest variety of measurements was the admin entered ones. That is useful info. I always look for entries with weights as measurements not volume and am surprised at how difficult that can be.
IME the key to recognizing these from the serving sizes is that there are different *types* of serving sizes: Weight, volume, inch measurements, etc. There are lots of entries that have calculated alternative serving sizes (both mililiters and fluid ounces, plus multiples of those, for example). The USDA ones loaded at start-up to MFP have different types of measurements. You'll see that here in the top bit of the banana one:
Very often, the default measurement shown in the search will be in cups, even for things for which cups would be stupid ("Watermelon, raw", say - default is "1 cup, balls" 😆).1 -
lynn_glenmont wrote: »39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.
Ah ha! This is a great tip, thanks! I'll make sure I use this method next time, it's reassuring that this is consistent with the value for bananas that I've been using. I really hope that there isn't any scaling issues when I create a recipe as I usually take the weight of the whole meal and record it as that many serving sizes (eg. 2000g for the weight of the entire finished article = 2000 servings) then I enter the number of grams I eat as the number of servings. I hope they aren't rounding down all the ingredients and giving me an inaccurate value...
It would be helpful if mfp had a clean up and got rid of all the inaccurate and volume listings, should be a simple algorithm shouldn't it?0 -
39flavours wrote: »lynn_glenmont wrote: »39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.
Ah ha! This is a great tip, thanks! I'll make sure I use this method next time, it's reassuring that this is consistent with the value for bananas that I've been using. I really hope that there isn't any scaling issues when I create a recipe as I usually take the weight of the whole meal and record it as that many serving sizes (eg. 2000g for the weight of the entire finished article = 2000 servings) then I enter the number of grams I eat as the number of servings. I hope they aren't rounding down all the ingredients and giving me an inaccurate value...
It would be helpful if mfp had a clean up and got rid of all the inaccurate and volume listings, should be a simple algorithm shouldn't it?
I don't think there's a general rounding problem, in other parts of the app, at least not one that's reasonably significant. IMU, this error happened quite a long time back when they did some kind of data conversion. There has not been much responsiveness to the idea of fixing the incorrect database entries.
I suspect it might be a little tougher than the average user might imagine, programmatically. Some of them look obviously wrong to a human, and a program could identify ones where (say) the 1g x 100 doesn't equal the 100g, but I don't see how, programmatically (without AI) it easily decides which one is correct. That either requires a more complicated program (compare back to USDA, for example), or human attention. It would be possible, one way or another, though, if there were a will.1 -
Here’s the USDA database search page, if you want to really verify an entry in the MFP database. The “SR Legacy Foods” are the entries you want to look at.
Usually if you search for the USDA entry title word-for-word in MFP you’ll come up with an accurate listing. Usually. 99% of the time. There’s still an entry out there with 0cal broccoli, and 0cal Kale, so it’s not 100%.
https://fdc.nal.usda.gov/index.html
2 -
39flavours wrote: »lynn_glenmont wrote: »39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.
Ah ha! This is a great tip, thanks! I'll make sure I use this method next time, it's reassuring that this is consistent with the value for bananas that I've been using. I really hope that there isn't any scaling issues when I create a recipe as I usually take the weight of the whole meal and record it as that many serving sizes (eg. 2000g for the weight of the entire finished article = 2000 servings) then I enter the number of grams I eat as the number of servings. I hope they aren't rounding down all the ingredients and giving me an inaccurate value...
It would be helpful if mfp had a clean up and got rid of all the inaccurate and volume listings, should be a simple algorithm shouldn't it?
I don't think there's a general rounding problem, in other parts of the app, at least not one that's reasonably significant. IMU, this error happened quite a long time back when they did some kind of data conversion. There has not been much responsiveness to the idea of fixing the incorrect database entries.
I suspect it might be a little tougher than the average user might imagine, programmatically. Some of them look obviously wrong to a human, and a program could identify ones where (say) the 1g x 100 doesn't equal the 100g, but I don't see how, programmatically (without AI) it easily decides which one is correct. That either requires a more complicated program (compare back to USDA, for example), or human attention. It would be possible, one way or another, though, if there were a will.
I agree that it would be helpful if not mandatory for a human to look for errors that I have seen such as the 1 g option actually giving the values for 100 g, and that there is no will.
I used to report errors in admin-created entries whenever I saw them, and the process was so frustrating and fruitless that I quit.
Example - my issue would be marked as Resolved if they had replied to me, not actually resolved the issue
I have not noticed 1g x 100 doesn't equal the 100g value.3 -
Unfortunately, the green check marks in the MFP database are used for both USER-created entries and ADMIN-created entries that MFP pulled from the USDA database. A green check mark for USER-created entries just means enough people have upvoted the entry - it is not necessarily correct.
To find ADMIN entries for whole foods, I get the syntax from the USDA database and paste that into MFP. I always leave a tab opened for the the USDA database and another for MFP.
https://fdc.nal.usda.gov
Use the “SR Legacy” tab - that seems to be what MFP used to pull in entries.
Note: any MFP entry that includes "USDA" was USER entered.
For packaged foods, I verify the label against what I find in MFP. (Alas, you cannot just scan with your phone and assume what you get is correct.)0 -
cmriverside wrote: »Whatever.
The one I posted is the Admin-entered from USDA entry. I don't know how the apps do searches, but I do know that, "bananas raw" (or any fruit vegetable - raw) will pull up the admin entered one somewhere in the results - HOWEVER you do have to search for the one with the different portion descriptors out of that list that comes up.
There are 17 choices in the "How much?" drop-down list....I've just learned to look for that in the "Apples raw" lists.
thats how ive always done it ...0 -
39flavours wrote: »lynn_glenmont wrote: »39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.
Ah ha! This is a great tip, thanks! I'll make sure I use this method next time, it's reassuring that this is consistent with the value for bananas that I've been using. I really hope that there isn't any scaling issues when I create a recipe as I usually take the weight of the whole meal and record it as that many serving sizes (eg. 2000g for the weight of the entire finished article = 2000 servings) then I enter the number of grams I eat as the number of servings. I hope they aren't rounding down all the ingredients and giving me an inaccurate value...
It would be helpful if mfp had a clean up and got rid of all the inaccurate and volume listings, should be a simple algorithm shouldn't it?
I'm sorry -- I didn't word that well if it sounded like I was saying it was the scaling problem -- I was trying to be clear that you can see the error in the 1 g serving size if you scale it up to be equal to 100 g -- you'll see the difference in calories, etc. But it's not the scaling that's causing the problem. The problem is in the information associated with 1 g. I don't think you'll have a problem using the "number of grams = number of servings" for recipes. It's not a rounding issue.
And I would advise against hoping for a "simple algorithm" to clean up inaccurate listings, as my impression from watching things go kablooie several years back is that they thought they were running a simple algorithm to create options for people in both commonly used volume systems (milliters vs. fluid ounces/cups/tablespoons/teaspoons) and both commonly used weight systems (grams vs. ounces/pounds), and we ended up with all these inaccuracies.1 -
kshama2001 wrote: »39flavours wrote: »lynn_glenmont wrote: »39flavours wrote: »Thank you, that's interesting, this listing, if it's the same one you suggested, gives a value for banana even lower than the one I have been using!
For some reason (I blame MFP attempts to "clean up" or "enhance" the database by running algorithms on it), the 1 g serving size for that banana entry does not yield information that is comparable to the 100 g serving size (when you scale up by saying 100 servings of 1 gram each). There are many entries where some of these algorithm-created serving sizes are laughably wrong (I'm looking at you, 1 g of garlic at 149 calories), but at least they're easier to spot.
My advice for the banana would be to use that entry (bananas, raw), but use the 100 g serving size (and entering 0.9 in the number of servings). You can compare the nutrient information for the 100 g serving at the USDA nutrient database and see that it is correct -- 89 calories for 100 g or 80 calories for your 90 g banana.
Ah ha! This is a great tip, thanks! I'll make sure I use this method next time, it's reassuring that this is consistent with the value for bananas that I've been using. I really hope that there isn't any scaling issues when I create a recipe as I usually take the weight of the whole meal and record it as that many serving sizes (eg. 2000g for the weight of the entire finished article = 2000 servings) then I enter the number of grams I eat as the number of servings. I hope they aren't rounding down all the ingredients and giving me an inaccurate value...
It would be helpful if mfp had a clean up and got rid of all the inaccurate and volume listings, should be a simple algorithm shouldn't it?
I don't think there's a general rounding problem, in other parts of the app, at least not one that's reasonably significant. IMU, this error happened quite a long time back when they did some kind of data conversion. There has not been much responsiveness to the idea of fixing the incorrect database entries.
I suspect it might be a little tougher than the average user might imagine, programmatically. Some of them look obviously wrong to a human, and a program could identify ones where (say) the 1g x 100 doesn't equal the 100g, but I don't see how, programmatically (without AI) it easily decides which one is correct. That either requires a more complicated program (compare back to USDA, for example), or human attention. It would be possible, one way or another, though, if there were a will.
I agree that it would be helpful if not mandatory for a human to look for errors that I have seen such as the 1 g option actually giving the values for 100 g, and that there is no will.
I used to report errors in admin-created entries whenever I saw them, and the process was so frustrating and fruitless that I quit.
Example - my issue would be marked as Resolved if they had replied to me, not actually resolved the issue
I have not noticed 1g x 100 doesn't equal the 100g value.
bananas, raw
I didn't know that before today and this thread, as I tend to stick with the one serving size that I have verified and reuse it from my "recents," which, to the best of my observation, seems to pull up the values for that database entry that it had when you last logged it, rather than going back to the database for whatever data is currently associated with that entry. I've even had admin-entered entries seemingly disappear from the database but still be loggable from my recents or by copying from earlier diary entries that have aged out of recents.2 -
Thanks for all the advice and input, I'll try to stick to the USDA green tick listings that have the most number of portion descriptors and use the 100g serving size to calculate with...and stop worrying about fruit peel.0
-
If tracking carbs is a particular interest to you rather than just calories then as you are in the UK beware American food labelling is different to the way we do it - our carbs on food packaging are net carbs.0
Categories
- All Categories
- 1.4M Health, Wellness and Goals
- 391.3K Introduce Yourself
- 43.5K Getting Started
- 259.7K Health and Weight Loss
- 175.6K Food and Nutrition
- 47.3K Recipes
- 232.3K Fitness and Exercise
- 388 Sleep, Mindfulness and Overall Wellness
- 6.4K Goal: Maintaining Weight
- 8.5K Goal: Gaining Weight and Body Building
- 152.7K Motivation and Support
- 7.8K Challenges
- 1.3K Debate Club
- 96.4K Chit-Chat
- 2.5K Fun and Games
- 3.2K MyFitnessPal Information
- 22 News and Announcements
- 909 Feature Suggestions and Ideas
- 2.2K MyFitnessPal Tech Support Questions