Talk:Body mass index

Latest comment: 11 days ago by Cagliost in topic Why height squared?

Wiki Education Foundation-supported course assignment

edit

  This article is or was the subject of a Wiki Education Foundation-supported course assignment. Further details are available on the course page. Student editor(s): Hkim188, Gpechero.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 18:12, 17 January 2022 (UTC)Reply

Wiki Education Foundation-supported course assignment

edit

  This article was the subject of a Wiki Education Foundation-supported course assignment, between 2 September 2021 and 14 December 2021. Further details are available on the course page. Student editor(s): Drostinatorr.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 18:12, 17 January 2022 (UTC)Reply

Wiki Education Foundation-supported course assignment

edit

  This article was the subject of a Wiki Education Foundation-supported course assignment, between 28 May 2019 and 2 July 2019. Further details are available on the course page. Student editor(s): Yeeeshanb.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 16:02, 16 January 2022 (UTC)Reply

Boundaries between categories

edit

Several times edits have been made that leave gaps between the categories. For example if one ends at 24.9 kg/m2 and the next starts at 25 kg/m2, what is the category if one measures 24.95 kg/m2? The boundaries should be single numbers. In the practically impossible case that the measurement is exactly 25, one can exhale once and be under that value.−Woodstone (talk) 05:08, 15 July 2021 (UTC)Reply

@Woodstone: Unfortunately, what you changed it to has incorrect ranges and is unsupported by the cited sources. BMI categories with overlapping ranges doesn't exist anywhere that I could find, and for good reason since it can cause confusion. I found and fixed many pages that spoke about one BMI category with an incorrect end value similar to your version and not the WHO's version. I wouldn't worry about some gap of .999 and just keep it the way the source presents it, which they felt was good enough to present to the entire world. When it was .99, you complained at that time too about gaps and excessive pressicion, even though the source had the same. Also, most people understand if the table has one decimal point precision, then do a lookup in that regard. Just present what the source has without changing it to what you personally want. Jroberson108 (talk) 06:32, 15 July 2021 (UTC)Reply
Dividing a continuous scale into categories requires a single number between two adjacent categories. The number itself can be arbitrarily assigned to either. This has been stable in the article for quite a long time, by having two columns "from" and "up to" (not including), with full clarity and no gaps between the intervals. That other sites dumb down the display is no reason to follow an unscientific presentation. At very absolute minimum there should be a remark how to solve the gaps after measurement.−Woodstone (talk) 10:54, 15 July 2021 (UTC)Reply
@Woodstone: Your claim of stability is unfounded. Also, the original table did not have an "up to" (not including) column as you claim, but a "to" (inclusive) column. What is clear is that what was being maintained was very wrong from the sources until I fixed it in this edit on 02:19, 9 July 2021, which you blindly reverted in this edit on 13:58, 9 July 2021‎ without checking the changes or sources. Ex. The "Underweight" categories were very wrong in both name and range, and put a BMI of 16 as the start of underweight when it should be a BMI of 17. The entire Singapore BMI table was wrong. My second attempt was to reduce the precision as a compromise from .99 (what the source has) to .9 in this edit on 01:38, 15 July 2021, which you again reverted, ignoring the edit summary yet again with a false claim of "using popups" and started this discussion. Giving your opinion about other sites that aren't sourced is unnecessary; just stick to the sources. Your presentation based on your opinion/interpretation that it is "unscientific" or otherwise is unfounded and appears to be against Wikipedia policy. WP:REPUTABLE: "...we publish the opinions only of reliable authors, and not the opinions of Wikipedians who have read and interpreted primary source material for themselves." Jroberson108 (talk) 14:04, 15 July 2021 (UTC)Reply
The main category table in this article has had category boundaries without gaps since more than ten years (with very few exceptions). First simply by stating from-to, later by dividing in columns. Why do not consider that "stable"?. Looking at the differences, it seemed that the edit was purely introducing gaps between the categories. If there were also corrections to the category boundaries themselves, I apologise for reverting too hastily. The task of an article is to explain as clearly as possible what the sources mean, not the literal text in them. Leaving gaps between categories makes some BMI values undefined. However, by interpreting the sources correctly, it appears that the intervals are meant to be low-inclusive and high-exclusive (but a measurement will in practice never exactly hit the boundary value). It would be good for the article to show that clearly. Indeed the heading used to be "to" (with implied "not including"). That might be added. −Woodstone (talk) 15:09, 16 July 2021 (UTC)Reply
@Woodstone: I don't feel like we are getting anywhere with this discussion, so I asked for a 3rd party opinion. WP:3O Jroberson108 (talk) 15:52, 16 July 2021 (UTC)Reply
(here from WP:3O) My initial reaction is that there are likely enough reliable sources on BMI that we could cherry pick a solid set of citations in support of either inclusive or exclusive upper boundaries. In other words: per WP:CALC and a bit of artistic license, I'm sure it's technically fine to play with the numbers a bit within reason, but it shouldn't be necessary to diverge from WP:RS in this case. I also don't see a fundamental problem with ending at 24.9 and the next one starting at 25.0. If it's clear that we're doing 1 decimal point, I don't think it's worth worrying about that someone might be confused about 24.9X. Perhaps it needs to explicitly say "bounds are after rounding to nearest 0.1" or some such. Leijurv (talk) 16:30, 16 July 2021 (UTC)Reply

BMI values and categories are only a rough guide. If we say that normal weight is 18.5–25 and overweight is 25–30, that's perfectly fine and easily understandable. Anyone with a BMI of precisely 25 is obviously on the cusp (and may benefit from losing a few pounds). The idea of overcomplicating things by adding decimal places, and introducing gaps, overstates the specificity of BMI categories. If you do have a BMI of precisely 25 and then you use the toilet, you may drop to 24.99 or whatever but you're still on the cusp of being overweight. (Fun fact: My brother once weighed himself before and after using the toilet and he'd lost 2 pounds! That's a BMI drop of around 0.3. True story.) nagualdesign 17:53, 16 July 2021 (UTC)Reply

@Leijurv: Thank you for your prompt and in-depth response, which I agree with. @Nagualdesign: Thank you for your response and the example that I can't un-read/un-imagine. I will add that there are industries that use strict BMI cut-off values that deny life insurance or a doctor's ability to recommend help with eating disorders just because you don't quite meet the requirements, and I have never seen any BMI examples more than two decimal places long (maybe researchers who already know this stuff). I did find an odd presentation of the ranges where they added a less than symbol in front of the range's end value like so: "25 to <30". Yet another option? I still prefer using "25.0 – 29.9" or "25.0 to 29.9", which most everyone uses, but "25 to <30" may work, although odd in my opinion? Would like to hear more opinions. Jroberson108 (talk) 21:36, 16 July 2021 (UTC)Reply

@Cinadon36: The source for the first table is The SuRF Report 2. The one you provided is for the BMI Prime column, which I don't know why that column is there to begin with since it is an alternative to BMI. Sticking to RS would mean the ranges need to change to values like this: "25.00 to 29.99". Jroberson108 (talk) 18:20, 20 July 2021 (UTC)Reply
@Jroberson108: Yes, I hadn't look at the chart. The same problem arises at intro as well. At intro, the ref is webpage of WHO [1] but is not a paper and I am not sure if we should consider it a RS. So, I would suggest we review the literature and observe what is the most common way to separate categories. The burden of doing so falls on the users who want to change the stable version, I guess. Cinadon36 19:15, 20 July 2021 (UTC)Reply
@Cinadon36: At the very least, the ref you pointed out in the lead doesn't appear to have any information related to the statement it supports, just a bunch of links to articles. It seems a lot on the page needs to be verified. As for the discussion in this section, it is more about whether the categories in the table should display BMI ranges as they appear in the The SuRF Report 2 source (e.g. "25.00 to 29.99", "30.00 to 34.99"), or as most websites present it with one less decimal precision (e.g. "25.0 to 29.9", "30.0 to 34.9"), or rounded up as it is now to prevent gaps like 29.999 (e.g. "25 to 30", "30 to 35"). Rounding up, in my opinion, creates possible confusion with a BMI of 30 in two categories. So far it seems the majority, you included, are in favor of repeating the source values. If that is so, then shouldn't it be adjusted? I've tried twice only to have it reverted as described above. Jroberson108 (talk) 20:18, 20 July 2021 (UTC)Reply

Having sleep on it, I find the problem on the category table, is not that it could confuse those on the margin, but it is not accurate. A number can not exist in both groups, that is a logical fallacy. Wikipedia should be accurate. I see the solution of followed by most websites, most suitable. Cinadon36 06:03, 21 July 2021 (UTC)Reply

A single number logically separates two adjacent categories. That precise number can be arbitrarily assigned to either category (in a systematic way, such as left-inclusive), but will in practice never occur as result af a measurement. On the other hand, having different bounding numbers between adjacent categories leaves the measurements that fall in beween them undefined in all cases. −Woodstone (talk) 13:08, 21 July 2021 (UTC)Reply
@Woodstone: The consensus is to stick with WP:RS and that one decimal precision (e.g. "25.0 to 29.9", "30.0 to 34.9") is good enough. To address your concerns about gaps, @Leijurv: suggested adding a footnote to that column, which I agree with. Jroberson108 (talk) 17:20, 21 July 2021 (UTC)Reply
@Woodstone: you have a good point, nonetheless, other editor also has a good point. Since this is a Style issue, maybe it should be addressed at Wikipedia:Manual of Style. If there is no guidance at MoS, we should follow RS. If you are too strong minded about it, I would advice you to take it to Wikipedia talk:Manual of Style, since your proposal could be applied elsewhere as well. Cinadon36 06:57, 22 July 2021 (UTC)Reply

Reverted ranges back to single decimal precision w/o overlap and added a note to each table to address gap concerns per consensus. Jroberson108 (talk) 17:57, 23 July 2021 (UTC)Reply

I do not see any consensus here. Moreover I find it quite objectionable that the instigator of contested changes to a ten-year stable display takes it upon himself to declare a conclusion. And the wording is wrong as well: there never was an overlap, just touching between categories.−Woodstone (talk) 13:12, 24 July 2021 (UTC)Reply
@Woodstone: It's inappropriate for you to change my comment just because you disagree; it has been reverted and is there for all editors. Protocol was followed for dispute resolution between two editors on a discussion started by you; a neutral third opinion was asked for and two different editors from that platform gave their opinions. Consensus (wide acceptance) was reached among all involved editors on what the content should be as well as a solution to address your concerns, which both were implemented and editors were informed. You are welcome to escalate in accordance with dispute resolution. Jroberson108 (talk) 15:43, 24 July 2021 (UTC)Reply
I agree with Woodstone. There's no clear consensus here. Nor do I think it's inappropriate to remove a prematurely placed {{resolved}} tag. I can understand you taking exception to having your post edited but the tag needs to be removed. nagualdesign 21:46, 24 July 2021 (UTC)Reply
Since you both feel the issue hasn't been resolved, I removed the resolved template; although, I disagree with your opinion that it was premature or that consensus hasn't been widely agreed upon to resolve all issues. Achieving consensus: "A consensus decision takes into account all of the proper concerns raised. Ideally, it arrives with an absence of objections, but often we must settle for as wide an agreement as can be reached." Note that total agreement isn't required for consensus. Three of the five editors, myself and two neutral editors from WP:3O, are of the opinion that we should stick with WP:RS and feel one decimal precision is good enough. Two of the same editors (myself and @Leijurv:) suggested adding a note to the tables to address gap concerns, which no one objected to. Nagualdesign at first wanted rounded numbers, but then later agreed ("I couldn't agree more.") with @Cinadon36: opinion in favor of sticking with RS and never offered any opposition later on. In the end, Woodstone is the only one opposing single or double decimal precision from RS out of concern for gaps, which the unopposed table notes address. Maybe you both can elaborate on why you feel consensus hasn't been reached and/or raise any additional concerns that haven't already been discussed? Jroberson108 (talk) 00:43, 25 July 2021 (UTC)Reply
Firstly, re. "Nagualdesign at first wanted rounded numbers, but then later agreed ("I couldn't agree more.") with Cinadon36 opinion in favor of sticking with RS and never offered any opposition later on." - I clearly explained why I favoured rounded numbers but perhaps I wasn't clear that I was simply agreeing with Cinadon36's comment that the article focuses too much on numbers and variations, instead of the history of the term, meaning, interpretation, significance and associated conditions. I also agree with Cinadon36's earlier point that there are likely enough reliable sources on BMI that we could cherry pick a solid set of citations in support of either inclusive or exclusive upper boundaries, which means that WP:RS is somewhat moot, and also that this is a style issue that might be addressed at WP:MOS or taken to Wikipedia talk:Manual of Style. Perhaps you already did that? (sorry I haven't checked) but in this discussion I see no clear consensus to change the status quo.
There's another option here, and that's to remove the table altogether since it's ambiguous, contentious and arguably not very helpful. The article prose is a much better place to explain exactly where categories begin and end (we can use phrases like "upto but not including"), and we also have File:BMI chart.png in the infobox that sums things up nicely (even if I do say so myself).
Please bear in mind that there's no rush to change the article, and quoting policy to experienced editors may bludgeon the process. If you feel very strongly about it you may wish to start an RfC (then take a step back). Regards, nagualdesign 17:03, 25 July 2021 (UTC)Reply
Thanks for clarifying your opinion; your agreement to Cinadon36's initial comment did come across as blanketed. As far as Leijurv's initial reaction, it would be nice if a RS was found in favor of rounded overlap (exclusive upper boundaries); otherwise, it is a moot point, but I agree with his conclusion that it isn't necessary to diverge from RS in this case. If a rounded overlap RS is found, I wouldn't conclude RS is moot, it may be that one is more reliable (e.g. primary source), especially since the content is data from a well established organization.
re: "I see no clear consensus to change the status quo" In reading the entire discussion of each editor, I find their preferences clear and a wide consensus reached (4:1, now 3:2) in favor of sticking to the RS with a preference for single decimal precision due to the two 3O editors' concluding remarks. Leijurv: no need to diverge from RS in this case; no fundamental problem with ending at 24.9; 1 decimal point clear, no need to worry about 24.9X confusion. Cinadon36: we should stick to RS; overlap not accurate and logical fallacy; website version most suitable solution ("25.0 to 29.9"). Granted, each person understands information differently, I can understand the difference of opinions on whether a consensus has been reached. If you feel I implemented the changes too hastily, then I apologize, but I still see wide consensus.
Regarding taking style issues to WP:MOS, that suggestion was directed towards Woodstone and his overlapping ranges, and I see no need for myself to pursue something that can potentially cause confusion. I agree with Cinadon36: if there is no guidance as MoS, we should follow RS. I did look to see if there was any guidance/discussion on the topic, but found nothing. Maybe Woodstone can let us know if he found anything or will pursue it? For the record, there were at least 10 attempts from various editors to fix/explain the overlaps, all reverted by Woodstone, indicating an obvious desire for clarity for many years. Not sure why a discussion was never started, but at least there is one now.
Removing tables, moving table data to prose, and/or replacing a table with your image doesn't seem like a fitting solution to the potential confusion of overlapping ranges, which can exist in all formats. Tables/Lists generally work best for simple data, where tables are best for more structured data, which both allow readers to quickly scan when compared to prose. Prose can still exist for simple data, but can be difficult to read with more structured data. Images aren't very search engine friendly (indexable) as compared to table/list/prose (text) since the only indexable things in an image are the filename and file meta, not the presented data.
As far as rewording to keep rounded numbers without overlap, in an earlier comment I suggested the odd use of "25 to <30" (see my 4th comment) as a possible solution, but no one responded, so I didn't bring it up again. Using words like "25 up to but less than 30" or "25 up to but excluding 30" can work, but seems too wordy/lengthy for a table/list/image; however, might work for prose, but can take longer to comprehend. A shorter option, which is partially done in the RS and may only work in table/list/image, is to only list cut-off points ("≥ 18.5", "≥ 25"), which simplifies the data, but can look odd and requires common sense to know the next category ends the previous; or rewritten as ("18.5+", "25+"). In my opinion, all these options are acceptable since they don't create potential confusion from overlaps. I find "25 to <30" and "25 – <30" more ideal, concise, and comprehensive compared to the rest; just not sure if it follows style guidelines? Just to be clear, I'm still most in favor of a single decimal precision ("25.0 to 29.9" or "25.0 – 29.9") that better matches RS, which appears to be more commonly used online and probably in print media too. Jroberson108 (talk) 09:10, 26 July 2021 (UTC)Reply

Regarding the last paragraph in my previous comment about rounded ranges without overlap. I looked at MOS:RANGES and MOS:COMMONMATH (didn't look at discussions) and saw no recommendations, but, if it were discussed, I would assume a recommendation for "25 – <30"; although, it can be argued that it isn't needed in this case of a consecutive (unbroken) set of ranges and should stick to "25.0 – 29.9". As far as the format recommendation goes, here is the logic. It says change "to" to an en dash; without spaces unless either element has a space. I would assume convert "less than" to "<", similar to "to". It says add spaces around "<", but the application here is more like the unary operators that are up against the number due to the dash. Unary operators are preceeded by a space, so add a space around the en dash. The first ("< 16") and last ("≥ 40") catch-all ranges remain spaced since no en dash, not used as unary operators, and binary operators are spaced.

A recommendation of only cut-off points ("≥ 18.5", "≥ 25") might be possible, but still has the common sense factor, looks odd, and only works with a consecutive (unbroken) set of ranges, which is the case in the table, but not the case in prose if categories are seperated by text (ranges too spaced out; appears broken; requires more reading) or only one category is discussed (broken set; works for first/last catch-all ranges). Jroberson108 (talk) 07:35, 27 July 2021 (UTC)Reply

Several editors keep talking about "overlap" between categories. That is mistaken. The categories "touch" each other in the bounding value. No values should be left between categories by having the next one begin at a different value than the previous one ends. This is easy to show in a table where limits of a category are indicated by "from >=" and "to <". The signs can also be written in a second line under the "from" and "to". That way there is absolutely no doubt over which category applies. Alternatively words in small print like "inclusive" and "non-inclusive" could be used.
Category BMI (kg/m2)
from
>=
to
<
normal 18.5 25
Woodstone (talk) 16:10, 27 July 2021 (UTC)Reply
@Woodstone: I recommend sticking with MOS:RANGES and use an en dash without "from" and "to", whether they be inline or in column headers. Also, it is common to include both the lower and upper limits in a range: "pp. 1–2", "$1–2", "1–2%", "2001–2002", "M–F", etc. The same applies if "to" were used instead of an en dash with the optional "from". When you see "1–2" and "2–4", it is common to understand that "2" exists in both ranges (overlap); therefore, if you want to exclude, then clearly indicate it, or rewrite it as "1–2" and "3–4" (touching). The same applies to decimal point precision. As I indicated in my previous comment, MOS:RANGES doesn't have a style for exclusion and you would need to discuss it further there. Jroberson108 (talk) 02:34, 28 July 2021 (UTC)Reply
@Jroberson108: You are confusing rages of discrete numbers and ranges in a continuum. Pages and years are discrete. There is no page 2.5 or year 2001.5. In discrete cases it makes sense that the start of a category is one unit higher than the one ending. In case of a measurement of properties on a continuous scale, as is the case for BMI, categories much touch in a single value in order to define a category for all possible values. Your recommendation of "1-2 and 3-4 (touching)" makes no sense since there is a distance between 2 and 3, so they are not touching. If you insist on a single column, ranges like "18.5 to 25" followed by "25 to 30" can be made clear with a note stating (upper bound is non-inclusive). −Woodstone (talk) 05:25, 28 July 2021 (UTC)Reply
@Woodstone: As I mentioned before, it is common and "The same applies to decimal point precision", which even the RS uses "18.50 – 24.99", "25.00 – 29.99" (touching) without notes about further precision, which consensus was in favor of following the RS and that one decimal precision is good enough "18.5 – 24.9". It is also common to round according to the same precision of the ranges you check against (e.g. "24.9999" round to "25.00" or "25.0"). If you haven't noticed, it was also suggested that a note could be added to address your concerns about precision, which is presently there in the column header of each table and in layman's terms so everyone can understand if confusion arises. If you want to ammend the style guide to include range upper limit exclusion, then discuss it at MOS:RANGES. Discussing style changes here on the BMI page will not change the style guide. Jroberson108 (talk) 14:35, 28 July 2021 (UTC)Reply
You are misrepresenting MOS. It discusses only single ranges. There is nothing about how adjacent ranges are to be represented. Introducing additional numbers other than the real category boundaries does not promote clarity. Instead of the obviously conveniently round and easy numbers like 25, 30 etc, now the reader has to consider 24.9 and 29.9 without those have any significance in separating the categories. I just read the well hidden note and it is laughable in its internal contradictiveness. Imagine the reader frown when contemplating that the range "18.5 to 24.9 includes 24.9999".−Woodstone (talk) 15:12, 29 July 2021 (UTC).Reply

@Woodstone: I'm glad you reconfirmed my findings at MOS:RANGES that, although there is a style for a range of numbers, there is no style for a range that excludes the upper limit or the like. Feel free to discuss a new/amended style further at MoS. Until then, it is best to follow the current style for a range of numbers, whether it be a single range or a series of ranges.

As far as the footnote goes, I'm not attached to the text and put something together in layman's terms that I felt would accomodate your gap concerns. It can certainly be changed to the suggestion given by @Leijurv:, which is short and simple: "Bounds are after rounding to nearest 0.1". Jroberson108 (talk) 20:07, 29 July 2021 (UTC)Reply

I cannot bear to look at the utterly cluttered table with unnecessarily added digits where only round numbers are intended, and then hear that you call the clarification clutter. Such neglect of clarity is unbelievable.−Woodstone (talk) 08:40, 31 July 2021 (UTC)Reply
100% agree with every word of Woodstone's previous comment. nagualdesign 21:31, 2 August 2021 (UTC)Reply
@Nagualdesign:, yes, we are aware of your support for Woodstone's opinion(s). I was just in the process of requesting RfC when you commented, something either of you could have easily done just as I requested the same from WP:3O; although, I'm not sure it will change opinions. Jroberson108 (talk) 23:26, 2 August 2021 (UTC)Reply
FWIW, I posted this about 24 hours ago, as Cinadon36 suggested you do. As you're aware, the onus is really on the person who wishes to change the status quo (that's you), but regardless, you're welcome. Good idea starting an RfC too. It may not change individual's opinions but it does tend to result in a clearer consensus. nagualdesign 00:21, 3 August 2021 (UTC)Reply
@Woodstone: since you still feel strongly about your opinion, I requested further comments in the section below. I've added a summary as neutral and straight to the point as I could while covering major concerns related to content, policy, and style from all editors along with some of their preferred vernacular (e.g. gap, touch, overlap). I added the "policy" and "style" topics so people following those topics are informed. Since you tend to use mathematics to argue your points, I included the "sci" topic, which covers "Maths, science, and technology". Jroberson108 (talk) 23:26, 2 August 2021 (UTC)Reply

Same comment I had when this was raised at WT:MOS: There's a self-contradictory argument inherent in this. If x.99 is so precise it's like weighing a fart, then it cannot be said that x.99 (versus something much more precise like x.9999999) leaves gaps in any meaningful sense. This is much preferable to having overlapping and directly contradictory values as in ”18.5 – 25” and ”25 – 30”, which results in the reader having no idea how 25 is classified.  — SMcCandlish ¢ 😼  01:12, 4 September 2021 (UTC)Reply

It's just opposite to what is said above. The point is that a category division on a continuous measured value needs a single number to separate adjacent categories. On which side that single value is included is irrelevant because of measurement inaccuracy and it can arbitrarily be defined to be in the upper category by a footnote. On the other hand, introducing numbers like 29.9, where only the round number 30 is needed is just clutter and makes that the readers think they must remember all these extra numbers, or decipher how they have been created.−Woodstone (talk) 05:55, 4 September 2021 (UTC)Reply

I don't mind leaving the charts as they are, but can we at least have some kind of a footnote? I know it's not precise, but I'd still like to know when I can celebrate going from obese to overweight. Is the convention to round to the nearest tenth before looking it up on the table, meaning that the boundary between overweight and obese is 29.95? Or do you ignore everything after the first decimal place and round down? I've been googling around and I can't find anything on where the actual boundary is. — DanielLC 09:00, 25 August 2024 (UTC)Reply

RfC on boundaries between categories

edit

BMI categories are defined by ranges of numbers per this reliable source (The SuRF Report 2, p. 22), which uses two decimal precision (e.g. Overweight: 25.00-29.99; Obese I: 30.00-34.99). Some feel "29.999", etc. are "gaps" unaccounted for that can cause confusion and feel it unscientific and want to include all numbers by rounding the upper limits/boundaries (25-30; 30-35) implying ranges that exclude the upper limit (30 and 35 respectively) and barely "touch" the next category's lower limit. Others feel worrying about "29.99X" unnecessary, MOS:RANGE includes the upper limit, "30" in two categories is inaccurate and a confusing "overlap", and we should stick to WP:RS with one decimal precision being clear enough (25.0-29.9; 30.0-34.9). The latter is presently on the article page (see Categories) along with explanatory footnotes (efn) with text of "After rounding." added to each BMI table in their column headers to accommodate "gap" concerns. The opinions have not budged after discussion. Jroberson108 (talk) 23:26, 2 August 2021 (UTC)Reply

You really think that's neutrally worded? As has already been pointed out, there are many reliable sources, some of which use "18.5 to 25" while others use "18.5 to 24.99", etc. and we can cherry pick our sources for the article. Cherry picking one source for an RfC that suits your preference is a bit cheeky. Please can we just follow established procedures, explaining our personal preferences without POV pushing, otherwise it's all rather tedious. Cheers. nagualdesign 00:32, 3 August 2021 (UTC)Reply
@Nagualdesign: Not one other RS was provided, so I referenced the only one we have, which is used on the article. You refer to a hypothetical comment that the same editor denounced as not needed in this case, as I responded to you on the 26th, which you never responded to. You should read the discussion thoroughly. Chill out, we have already discussed everything we could and it isn't changing our opinions. Now let other editors give their opinions, which any one of them can and should read the entire discussion. It's just a summary of major content concerns. Jroberson108 (talk) 00:54, 3 August 2021 (UTC)Reply
This nit simply not worth picking. BMI levels are not scientific concepts, they're general guidelines, and controversial ones at that. Nor is it practical to even calculate BMI to more than one decimal point. Let it go. — Isaac Rabinovitch (talk) 03:42, 3 August 2021 (UTC)Reply
The proposer conveniently forgets to mention that a version with only round boundaries like 25,30, 35 has been in the article for more than 10 years with very occasional exceptions and that he is the one who recently changed it. It must be clear that everyone agrees that the real boundaries between categories are these round numbers. The discussion is about how to represent this towards the reader as clearly as possible.−Woodstone (talk) 13:07, 3 August 2021 (UTC)Reply
The history of edits was ignored since it is irrelevant when discussing actual content. Jroberson108 (talk) 19:50, 8 August 2021 (UTC)Reply
@Isaac Rabinovitch: Thank you for taking the time to comment. I agree that we don't need to worry about "29.9X" and one decimal precision is practical enough. BMI guidelines do seem unscientific and controversial as you say. Jroberson108 (talk) 19:50, 8 August 2021 (UTC)Reply
That is the point. The category boundaries are rough and round numbers like 25, 30 etc. Therefore it makes no sense to burden the table with numbers such as 24.9 and 29.9, which are not category boundaries, because clearly 24.95 is still not meant to be seen as overweight. −Woodstone (talk) 13:13, 9 August 2021 (UTC)Reply
@Woodstone: The point is that you don't need to worry about "24.95" or any further precision, which it appears four editors (myself included) now agree is unnecessary and that one decimal precision is clear enough. Also, you are forgetting that MOS:RANGE doesn't have a style to exclude the upper limit as you want, nor is there a need in this case. If your only argument is that it burdens the table, then go with consensus. Jroberson108 (talk) 15:20, 9 August 2021 (UTC)Reply
Please read WP:RFCBRIEF. That aside, I have never seen BMI done to more than a single decimal place. [2][3][4] A very brief search reveals one place seems to be the standard. BSMRD (talk) 22:56, 9 August 2021 (UTC)Reply
The MOS:RANGE also does not have a section of how to classify values that do not fall in any of the given ranges, so that argument is void. A fundamental requirement is that all measured values should fall in a range. Leaving a gap between ending at 24.9 (or 24.99) and beginning at 25 makes the list incomplete. On the other hand, having 25 both as end and beginning does not create overlap, since in that cases it is fully arbitrary which category is chosen, because of measurement uncertainty. A repeated more accurate measurement could break the tie. For simplicity (not necessity) one could specify all categories to be left-inclusive only. For the reader the point is to see and remember only the simple round 25, 30 etc numbers without being distracted by intervening meaningless and unnecessary 24.9 and 29.9 etc. −Woodstone (talk) 07:46, 10 August 2021 (UTC)Reply
@Woodstone: Your argument against using MOS:RANGE for a range of numbers makes no sense; a number (20) outside a range (1–10) is simply the number (20). We have ranges, so follow MOS:RANGE for each range regardless of their relations. One decimal precision is clear enough ("18.5–24.9", "25.0–29.9"). If you have a BMI with further precision (24.9999), then you naturally round it (25.0) to match the same precision of the table. There are no gaps due to the obvious precision restriction. Since ranges are inclusive, ending a range and starting the next with the same cut-off point (25) is both inacurate and a confusing overlap. I understand you don't see it that way and your intentions are to exclude the upper limits, but your intended usage is not supported by MOS:RANGE and you should discuss it further at MoS, as many editors have repeatedly said. Jroberson108 (talk) 17:42, 10 August 2021 (UTC)Reply
@BSMRD: Thanks for taking the time to comment. Keeping it brief was difficult, but I see now the details could have been a followup post. Regarding the standard, I agree that most websites, and possibly print media, use one decimal precision. Jroberson108 (talk) 17:42, 10 August 2021 (UTC)Reply
Use only one decimal, and make no mention of “rounding”. That seems the norm. I think typically measurements and BMI reports are only able to do one decimal. Besides, the measurements of height/weight are not 5 digits precise, two measurements in a row might vary by a pound or quarter inch. Having it to 3 digits is already tiny - about +/- a tenth of a percent. Cheers Markbassett (talk) 00:09, 11 August 2021 (UTC)Reply
@Markbassett: Good point about the precision of weight and height used to calculate BMI. Usually one or two decimal precision is used, but not more. A BMI with one decimal is precise enough. I also feel mentioning "After rounding." isn't needed. It was only added to console gap concerns. Jroberson108 (talk) 02:45, 11 August 2021 (UTC)Reply
I believe that including any special discussion (even just a few words or mathematical symbols) is downright silly for this topic. This article is about body mass index, not mathematics. Fine details of the theory of quantization are not necessary. The above discussion of adding ("rounding to nearest 0.1") doesn't even resolve it, because the nearest 0.1 for 24.99 is 25, not 24.9, but that is clearly not what is attempted to be expressed. BMI is only a rough guide anyway, and fluctuates for everyone, and the difference is swamped by the measurement error of the weight scale and the height measurement as well. For our purposes, I think it's fine for the upper bound of one interval to be equal to the lower bound of the next interval, or to use "X.9" as an upper bound (without adding any special further explanation) if that's what authoritative sources tend to do. —⁠ ⁠BarrelProof (talk) 22:55, 13 August 2021 (UTC)Reply
@BarrelProof: Thanks for your comment. If I understood correctly, you are neutral (rounded or X.9) as long as reliable sources use it, but see no need for the "After rounding" explanatory note. Jroberson108 (talk) 00:53, 14 August 2021 (UTC)Reply

BMI imperial/american units

edit

Well, you should add more conversions if 'isolated conversion' was the problem. Username142857 (talk) 12:24, 9 February 2022 (UTC)Reply

The conversion makes no sense since nobody uses that unit. It does not help any reader.−Woodstone (talk) 07:54, 10 February 2022 (UTC)Reply
Believe it or not, America STILL hasn't converted to metric so... Username142857 (talk) 09:15, 10 February 2022 (UTC)Reply
Except for BMI, which is universally metric. Can you show any sources That use these units? −Woodstone (talk) 13:54, 10 February 2022 (UTC)Reply
No, but it would help Americans to do less math. Having to convert your height to inches, then dividing mass by height, then having to multiply your output by 703 is harder than just dividing mass by height. Username142857 (talk) 11:54, 11 February 2022 (UTC)Reply
Why is BMI universally metric? Username142857 (talk) 11:59, 11 February 2022 (UTC)Reply
@Username142857 and Woodstone: I agree with Woodstone that it seems unnecessary since the units are commonly metric. I haven't seen any sources that use imperial/American units. Under Body mass index#History there is info on converting it, which uses "in". Perhaps "ft" can also be added to accommodate your concerns? Jroberson108 (talk) 06:56, 11 February 2022 (UTC)Reply
They are useful because it is easier for Americans to calculate their BMI in lb/ft^2, so it would help them do less math! Username142857 (talk) 11:50, 11 February 2022 (UTC)Reply
You just multiply by 703/144 Username142857 (talk) 11:54, 11 February 2022 (UTC)Reply
For a calculation in feet one would need to measure in decimal feet, not feet and inches. But anyway, the borders of the categories are given in kg/m2, so the values in lb/ft2 or lb/in2 are not useful to know. Remark also that the conversions show too many decimals and throw a very peculiar light on the gaps between the categories.−Woodstone (talk) 16:22, 11 February 2022 (UTC)Reply
What's a decimal foot? Username142857 (talk) 02:26, 12 February 2022 (UTC)Reply
The feet and inches problem can be solved if we switch to duodecimal, or my personal favorite, senary! Using the formula lb/(ft+in/12)2 can help as well! Username142857 (talk) 02:29, 12 February 2022 (UTC)Reply
That's like saying that if you know the height of a building in feet, its height in meters is not useful to know. Username142857 (talk) 02:30, 12 February 2022 (UTC)Reply
I fixed the 'too many decimals' problem. And what kind of 'very peculiar light on the gaps between the categories' does it give? Username142857 (talk) 02:36, 12 February 2022 (UTC)Reply

Units of the BMI

edit

It is much repeated that BMI is expressed in kg/m² which is scientifically not correct, it associates a weight to a surface, like for example paper thickness is associated and expressed as g/m², where this unit makes better sense, as its actual thickness is rather difficult to measure or comprehend, and as it is distributed evenly over the surface (See also Paper Thickness and Weight Explained - Action Press (action-press.co.uk)). And even with paper, you have to differentiate between types of paper (see link)

However, we are not expressing the body surface with the measurement, (look at duBois formula for that: Body Surface Area Calculator)

but making up a number that helps us understand roughly how the relation of bodysize and bodyweight is situated, (with all its shortfalls - see body-builders BMI) this number roughly fits for adult men between 20 and 40 Years with median bodysizes, it won't fit tall or small, women, children and elderly people...

It is NOT an exact measurement. In Pediatry we use percentiles adapted for age and sex to make up for some of the shortfalls. However we should abandon the Unit for it which ist not the correct one.

I hope that this becomes clear when for example using the following Measurements for a woman:

body height: 161cm 
body weight: 66.5kg
BMI : 25.7
Skin surface after DuBois formula: 1.7m²

In the above link (Body surface calculator) the BMI is also expressed as kg/m² with the table above quoting the surface area as 1.7m² calculating the weight of the person would be:

1.7m² * 25.7kg/m² = 43.69kg 

which is misleading bullshit. 188.94.98.93 (talk) 10:14, 19 October 2022 (UTC)(triple5)Reply

The units of BMI are kg/m2. This is a fact and inarguable. That area the weight is divided by is not equal to the skin surface area is irrelevant. It's also not equal to the bone, eye or teeth surface area, but that does not mean the units are anything different. 2A02:8071:680:3F00:9D5C:8CCC:E5F6:9F (talk) 14:02, 13 June 2023 (UTC)Reply

BMI & Racial Bias

edit

Hi all, I was curious to see that there was no section on racial bias in the BMI and the eugenicist history of the BMI. I was considering adding a subsection to this page to discuss this topic, perhaps under the History section or as a new section. I would like to cite Sabrina Strings' highly influential book "Fearing the Black Body" in this subsection, as well as other topics. Please let me know if anyone has any objection to this addition. SarahLalevee (talk) 19:01, 2 January 2023 (UTC)Reply

Honestly, this part should just be removed. For example the last sentence ("[...]the BMI is largely inaccurate for black people especially, disproportionately labelling them as overweight even for healthy individuals.") might imply that black people can be healthier at higher body fat percentages. This impression is also supported by the reviews and summaries of the book I found online, e.g. it talks about the perception of black female slaves by a white man as "plum", and all-in-all seems to support the fat-acceptance movement. Looking up the primary sources in Sabrina Strings book might be more relevant, however, and I don't have it.
The section send me down a pubmed rabbit-hole to research if there really are relevant medical differences for obesedy between what is perceived as races. Spoiler-alert: There is not. There are differences in the US, but the causes are unknown, and probably environmental. E.g. a pubmed search found "Why are there race/ethnic differences in adult body mass index–adiposity relationships? A quantitative critical review" (https://doi.org/10.1111%2Fobr.12358), which indeed finds be a small but real difference between BMI in ethnic groups, more specifically Non-Hispanic black subjects seem to have a lower body-fat-percentage. Now this information is more specific and might be interesting in itself, but also is only relevant for the US, and might have little to do with the work of the book.
Again, the primary sources the book itself used might be more enlighting, and I might be wrong. But then these primary sources should be used. This looks more like US-centric activism and intersectionalism in an article about a serious medical topic of international relevance. 84.153.156.47 (talk) 22:19, 2 February 2024 (UTC)Reply

Wiki Education assignment: Science and colonialism

edit

  This article was the subject of a Wiki Education Foundation-supported course assignment, between 9 January 2023 and 24 March 2023. Further details are available on the course page. Student editor(s): Edarden1 (article contribs).

— Assignment last updated by Edarden1 (talk) 03:49, 28 February 2023 (UTC)Reply

Why height squared?

edit

Why did Quetelet divide by height squared? Surely he knew height cubed would work better. cagliost (talk) 08:23, 19 December 2024 (UTC)Reply