Ounces vs fluid ounces and tracking in the app

Leoturi

So I am curious if the app is mislabeling things or if it is correct. Most foods that I have logged, wind up being in fluid ounces instead of just regular ounces. This is on items I've searched for or scanned in. Like my eggs this morning were fluid ounces. I weighed them, and just put that number in but I'm wondering if that is correct or not. I know those units of measurement aren't exactly a 1 for 1 ratio, other then water. So is the app just mislabeled, am I doing it wrong, or is there a better way to calculate it?

cwolfman13

Most entries in the data base are user entered and there are numerous erroneous entries...pick one that is actually applicable and correct.

CyberTone

There may be some (a lot, many?) solid food items in the Food Database that have fluid ounces (volume) along with [avoirdupois] ounces (weight), and vice versa. This was a result of MFP mistakenly running an algorithm two years ago that automatically converted items created in cups (a volume measurement) from 8 fluid ounces directly into 8 avoirdupois ounces and vice versa without regard to density for many food item database records.

Look for food items that have been entered with the correct type of measurement and verify entries using outside nutrition information sources, such as...

USDA National Nutrient Database at https://ndb.nal.usda.gov/ndb/search/list

SELFNutritionData at http://nutritiondata.self.com/

lynn_glenmont

CyberTone wrote: »

There may be some (a lot, many?) solid food items in the Food Database that have fluid ounces (volume) along with [avoirdupois] ounces (weight), and vice versa. This was a result of MFP mistakenly running an algorithm two years ago that automatically converted items created in cups (a volume measurement) from 8 fluid ounces directly into 8 avoirdupois ounces and vice versa without regard to density for many food item database records.

Look for food items that have been entered with the correct type of measurement and verify entries using outside nutrition information sources, such as...

USDA National Nutrient Database at https://ndb.nal.usda.gov/ndb/search/list

SELFNutritionData at http://nutritiondata.self.com/

@CyberTone
I'm curious, and you always seem so knowledgeable about these kinds of issues. Did they run the algorithm without backing up the pre-algorithm version of the database so they could restore it when it turned out there was a problem with the algorithm, or did they just never acknowledge that that the volume-to-weight and weight-to-volume conversions were a problem that required restoring the database to its pre-algorithm status?

CyberTone

lynn_glenmont wrote: »

CyberTone wrote: »

There may be some (a lot, many?) solid food items in the Food Database that have fluid ounces (volume) along with [avoirdupois] ounces (weight), and vice versa. This was a result of MFP mistakenly running an algorithm two years ago that automatically converted items created in cups (a volume measurement) from 8 fluid ounces directly into 8 avoirdupois ounces and vice versa without regard to density for many food item database records.

Look for food items that have been entered with the correct type of measurement and verify entries using outside nutrition information sources, such as...

USDA National Nutrient Database at https://ndb.nal.usda.gov/ndb/search/list

SELFNutritionData at http://nutritiondata.self.com/

@CyberTone
I'm curious, and you always seem so knowledgeable about these kinds of issues. Did they run the algorithm without backing up the pre-algorithm version of the database so they could restore it when it turned out there was a problem with the algorithm, or did they just never acknowledge that that the volume-to-weight and weight-to-volume conversions were a problem that required restoring the database to its pre-algorithm status?

I will start with a disclaimer. I have no inside information about MFP and how the program is structured. I am just a general, non-Premium user who has not even participated in any MFP beta testing. All of my knowledge about MFP is from observation, research, and a working knowledge of relational databases and internet html scripts. Beyond that, I do a lot of speculating about how the MFP program works, but I do try to provide context to my explanations in the forums for how I perceive the program works from a user's perspective.

Regarding the automatic conversion of units, I noticed a paragraph on the Help pages about the "new feature" that was going to be rolled out a few months before it was rolled out. I am not sure what type of testing and what use cases that testing entailed. I assume that there was testing underway prior to that announcement and testing was ongoing until the decision to roll out the automatic conversion feature.

I would guess that the unintended consequences (or the magnitude of them) seen by the users when it was rolled out were not identified in user acceptance testing, assuming that there was UAT, which I would hope that there was. Based on the amount of work MFP had to do to restore some of the popular older non-asterisk records for whole foods such as bananas, broccoli, et al., supposedly imported long ago from the USDA National Nutrient Database, I would guess that MFP was not able to roll back the new feature.

Sorry for being so long-winded, but thanks for asking!

lynn_glenmont

CyberTone wrote: »

lynn_glenmont wrote: »

CyberTone wrote: »

There may be some (a lot, many?) solid food items in the Food Database that have fluid ounces (volume) along with [avoirdupois] ounces (weight), and vice versa. This was a result of MFP mistakenly running an algorithm two years ago that automatically converted items created in cups (a volume measurement) from 8 fluid ounces directly into 8 avoirdupois ounces and vice versa without regard to density for many food item database records.

Look for food items that have been entered with the correct type of measurement and verify entries using outside nutrition information sources, such as...

USDA National Nutrient Database at https://ndb.nal.usda.gov/ndb/search/list

SELFNutritionData at http://nutritiondata.self.com/

@CyberTone
I'm curious, and you always seem so knowledgeable about these kinds of issues. Did they run the algorithm without backing up the pre-algorithm version of the database so they could restore it when it turned out there was a problem with the algorithm, or did they just never acknowledge that that the volume-to-weight and weight-to-volume conversions were a problem that required restoring the database to its pre-algorithm status?

I will start with a disclaimer. I have no inside information about MFP and how the program is structured. I am just a general, non-Premium user who has not even participated in any MFP beta testing. All of my knowledge about MFP is from observation, research, and a working knowledge of relational databases and internet html scripts. Beyond that, I do a lot of speculating about how the MFP program works, but I do try to provide context to my explanations in the forums for how I perceive the program works from a user's perspective.

Regarding the automatic conversion of units, I noticed a paragraph on the Help pages about the "new feature" that was going to be rolled out a few months before it was rolled out. I am not sure what type of testing and what use cases that testing entailed. I assume that there was testing underway prior to that announcement and testing was ongoing until the decision to roll out the automatic conversion feature.

I would guess that the unintended consequences (or the magnitude of them) seen by the users when it was rolled out were not identified in user acceptance testing, assuming that there was UAT, which I would hope that there was. Based on the amount of work MFP had to do to restore some of the popular older non-asterisk records for whole foods such as bananas, broccoli, et al., supposedly imported long ago from the USDA National Nutrient Database, I would guess that MFP was not able to roll back the new feature.

Sorry for being so long-winded, but thanks for asking!

Thanks for the informative response!

cross2bear

You may wish to consider weighing in grams rather than ounces as to reduce this confusion and to be just a tad more accurate. Then, when you are looking in the data base search feature, you add on the word "grams" to the item you are looking for, and that will narrow your options to those that are probably more accurate.

jkwolly

I've found entries by weight work the best. Just search for another one that is applicable.

I've created a few of my own entries due to lack of finding good quality entries as well.

Francl27

MFP automatically adds extra units too... so when someone makes an entry using volumes for solids, it automatically adds fluid ounces, which is ridiculous... that's why you're better off finding grams entries and using a food scale.

Leoturi

I will try adding grams into my search then. My scale can do that as well so I'll just switch the input on that. And cybertone, thanks for the detailed information about it. Gives me a better understanding how things work.