![]() | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
This is the archive of the rewrite of the Units of Measurements section. This spanned over two months and gained consensus at 10 (11) vs. 2(3) on June 7, 2008.
For: Headbomb, Greg L, Fnagaton, Pyrotec, Marty Goldberg, SWTPC6800, MJCdetroit, Franci Schonken, Jimp, Rilak. Altough Dfmclean did not vote, he gave implicit endorsement by agreeing on every colour box.
Against: Woodstone, Thunderbird2. Altough he did not vote, Seraphimblade would probably have voted against considering his opposition to the deprecation of IEC units.
Reasons for opposition were opposition to the partial deprecation of IEC units. Opposition was asked repeatedly to provided examples of how deprecation went against the spirit of the MOS, but failed to provide any. Other than personal opposition to partial deprecation, previous votes were brought up to support "lack of consensus", but the reasons given for the previous votes failed to convince editors that deprecation of IEC units is unsound or that IEC units are compatible with the spirit of the MOS.
This was written after archiving, as a post-commentary to give newcomers a quick-recap. Headbomb (ταλκ · κοντριβς) 18:15, 7 June 2008 (UTC)
Since section for was becoming cluttered, I decided to rewrite (with lots of copypasta), incorporating the changes discussed in Wikipedia:Manual of style (dates and numbers)#Third attempt and Wikipedia:Manual of style (dates and numbers)#Skeleton proposal, and some additional changes. Other than chopping fat and reorganization, notable changes include
There is consensus that this proposal cannot be uploaded until there is consensus on the content of the Purplebox and Redbox
Headbomb
This section is presently reserved for eventual replacement with the contents of the Redbox. The below votes have been made on the condition that the redbox gains consensus and becomes part of this section. If the redbox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.
This section is presently reserved for eventual replacement with the contents of the purplebox. The below votes have been made on the condition that the purplebox gains consensus and becomes part of this section. If the purplebox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.
::* KB and kbit are to be preferred over kB and Kbit.
This section will be updated by the content of the bluebox, once the bluebox proposal gains consensus (if it is deemed to be fitting in section of units of measurement). If the bluebox does not gain consensus by the time the greenbox does, nothing will be placed here. Bluebox may be added to the current MOS regardless of the status of the consensus of greenbox and purplebox.
User | 5 | 4 | 3 | 2 | 1 | 0 |
Greg L (talk) 00:27, 3 June 2008 (UTC) | X[1] | |||||
Headbomb (ταλκ · κοντριβς) 20:27, 30 May 2008 (UTC) | X [2] | |||||
Jimp | ×[3] | |||||
Rilak | X | |||||
SWTPC6800 | X | |||||
Thunderbird2 (talk) 07:22, 6 June 2008 (UTC) | X[4] | X | ||||
Fnagaton 19:36, 25 May 2008 (UTC) | X [5] | |||||
MJCdetroit 15:12, 27 May 2008 (UTC) | X [6] | |||||
Woodstone (talk) 20:50, 2 June 2008 (UTC) | X [7] | |||||
Pyrotec 21:57, 5 June 2008 (UTC) | X | |||||
New user |
5 - Greenbox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard. I understand my votes reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
4 - Greenbox is a vast improvement over the current section 4 of MOSNUM and while I may or may not have some minor objections to this version of the greenbox, I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
3 - Greenbox is an improvement over the current section 4 of MOSNUM. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
2 - Greenbox is an downgrade over the current section 4 of MOSNUM. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
1 - Greenbox is a severe downgrade over the current section 4 of MOSNUM. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
0 - Greenbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. I may or may not understand my vote should reflect my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content should be voiced at the purplebox
Greg L's vote: It is neither schizophrenic nor an attempt to "game the system". It is an attempt to make the rest of the MOSNUM go forward EVEN IF the IEC prefix debate is in a deadlock. Bizzare how one who was so prone to accused others of "radical extremism" has become a radical extremist himself. Bizzare how one who was so prone to denounce the total opposition votes of the "Follow current policy" is now totally opposing this version of things. - Headbomb (ταλκ · κοντριβς) 03:39, 21 May 2008 (UTC)
For reference, here are the main points of the FCL, the rest being a ton of examples, or long-winded explanations.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).
Headbomb (ταλκ · κοντριβς) 05:35, 21 May 2008 (UTC)
Greg L and DPH's vote: Your votes are still at 1. I tried to figure what your opposition was to this version of the greenbox, but all I heard is a bunch of stuff about the IEC prefixe debate thing, which is irrelevant to this proposal. You did mention that you were concerned that removing the FCL section would yield chaos, but I pointed out how everything in the FCL is already included in the greenbox, so that cannot be an objection. You've been silent on this issue ever since. Please update your votes, or clarify the reason(s) of your opposition. Headbomb (ταλκ · κοντριβς) 15:49, 24 May 2008 (UTC)
SWTP's vote: Everyone is aware that the greenbox does not address the IEC prefixes, that's what the purplebox, which will be merged with the greenbox upon reaching consensus, is for. Headbomb (ταλκ · κοντριβς) 13:55, 25 May 2008 (UTC)
Update of Greg L's vote: Sigh. I'm really getting tired of hearing about IEC prefixes in the greenbox. The greenbox is for changing everything that does not touch the IEC prefixes debate. AKA does it deal with unit conversion appropriately? Does it deal with proper formatting of units? Is it clear that unambiguous units are preferred? Is it clear that familiar unit are preferred? Did the merging of non-IEC prefix FCL content in relevant sections removed redundancy? Purplebox will be the IEC-prefixe solution. If you don't think purplebox tackles the history of IEC prefixes appropriately, voice your concern there. If you think that the solutions proposed by purplebox are not the best possible, mention it there. If you think that IEC-prefix content of the FCL is not appropriately merged with purplebox, voice your concerns there. If you want to wait for the purplebox to reach consensus before we upload the greenbox so there's no "gap" between the time the greenbox is uploaded and the time the purplebox is—fine with me. But say that you want to wait for the purplebox to be complete before uploading the greenbox; not that you oppose the greenbox on the grounds that it does not do things it was never meant to do.Headbomb (ταλκ · κοντριβς) 01:22, 26 May 2008 (UTC)
You’re making progress here. Like SHEFFIELDSTEELTALK wrote on a Wikiquette alert on Omegatron: “Consensus is not all editors in 100% happy agreement, and never has been.” It would have been exceedingly unrealistic of you to have set out to tackle what you’ve tackled and believe you could get literally everyone to support it. Part of developing a better consensus entails writing better guidelines, and part of it entails debate and discussion that changes some editors’ opinions along the way. I think you are doing fine so far. Given the magnitude of the task, you need patience. Greg L (talk) 03:31, 26 May 2008 (UTC)
In my opinion, you will be frustrated in the final analysis if you insist on being so ambitious and tackling so much at once. It was only a little more than a day ago that I convinced you that you were in the drivers seat and had to take the “IEC prefix” bull by the horns and propose text that could reach a consensus; no one else looked forward to getting a belly full of all that discord and effort. I think the same effect applies to a lot of the rest of your greenbox; it is so ambitious, no one really looks forward to hammering away at each of these issues. Why? In part, because of the latent fear that there are editors who simply don’t want to wade into their pet issue (scientific notation or whatever) right now because it’s ‘all for not’ at this juncture. The circular fear is that the “other” editors will just weigh in on their pet issues later if this gigantic thing were to actually “go to press.” So why bother now? It’s a self-referential physiology thing that effects financial and commodities markets.
My recommendation to you is to partition each one of the issues touched upon in your greenbox so they can be addressed separately. This will fix the “mass physiology” effect and get other editors better engaged. The perception will instantly be that if an editor gives a crap about a particular issue, they better well get into the saddle on it or it will be posted to MOSNUM. As for the IEC prefixes and “Follow current literature”, FCL is a very broad principle and a clear majority of editors who voted on it believe it is indisputably wise because it brings Wikipedia’s practices into alignment with those of professionally edited encyclopedias. We reject the notion that we volunteer editors are somehow smarter than professional editors with journalism degrees. FCL wouldn’t even be a point of contention were it not for the fact that it sweeps up the IEC prefixes along the way. I see you has having two options if you want to make rapid progress: 1) tackle the IEC prefix issue first, or 2) tackle it last. Either way, you need to completely split this stuff up. That’s my 2¢. Greg L (talk) 21:28, 26 May 2008 (UTC)
However, I suggest you revise or jettison the “calorie” example so we can make rapid progress. Again, we editors are rather up to speed on the science underlying gram or kilogram calories. A scientist would simply call it a kilocalorie. That’s also the way English-language food labeling handles it in Europe (I was there last year). But just what sort of readership do you think will be going to an article on diet and food? Some wouldn’t know the difference between a kilocalorie and a picocalorie—to them, there both just “different” calorie. All any American sees on a food label is “calorie.” And now, on an article on a general-interest article on nutrition, a reader is supposed to understand that “large calorie” is the same thing as “calorie”. Many would simply assume that the additional specificity is actually supposed to signify a difference. This confusion is so unnecessary since “calorie” could be linked to an article on “kilocalorie” if we wanted to. The extra specificity (disambiguation) that is being called for is simply unnecessary unless it was for some sort of mixed-use, chemistry-related article.
This is just one example of why it might be wise to further break up this huge green box into separate topics. It’s also yet another example of why we need to closely follow FCL; do you think Encyclopedia Britannica uses “large calorie” when talking about the nutritional energy content of an apple? How about most (or virtually all) diet books? Greg L (talk) 00:26, 27 May 2008 (UTC)
The text contains the bullet
Where did this come from? I don't recall it ever being discussed and don't agree with it.Thunderbird2 (talk) 16:01, 1 June 2008 (UTC)
To Woodstone: re Still object to statement about "familiar units". Familiar to whom? I interpret this statement as favouring units likely to be understood (or at least recognised) by the average WP reader. I agree that sometimes that's not obvious, but often it is. For example, many readers will feel comfortable with power in MW because they have been taught the SI system as school, but are unlikely to have heard of MWt. Yes, I know that example would be covered by the preceding bullet, but I see it as a different principle. Another example, if I can pluck up enough courage to mention it, is the megabyte (a familiar unit) vs the mebibyte (an unfamiliar one). With that in mind, can you suggest a way of rewording the bullet that would result in your support? Thunderbird2 (talk) 20:23, 3 June 2008 (UTC)
- When there is a conflict between two (or more) guidelines, then take things to the article's talk page and seek a compromise that satisfies the spirit of the conflicting guidelines.
- When you depart from these guidelines, it would be a good idea to give the reasons for doing so on the article's talk page, as there are bound to be people that will blindly apply the MOSNUM.
It should be "inspired by" not "inspired from". Why the parenthetical UK after National Physical Laboratory when there's no parenthetical US after NIST? Why abbreviate the first items but not the third? Why exactly is ths sentence here? The MoS derives its authority from consensus not from the authority of outside bodies. If we mean to point editors in the direction of these bodies when MOSNUM doesn't cover a particular case, let's come straight out and say so. JIMp talk·cont 02:48, 22 May 2008 (UTC)These were mostly inspired from the rules used by the CGPM, NIST, and National Physical Laboratory (UK).
I think you could well be wasting your time here with Thunderbird2. It is my experience that he will suggest that he will support a proposal of yours if you make concessions on verbiage he is asking for. But in the end, the promised support doesn’t somehow materialize. On at least two points (and if I can dig far enough, I may be able to come up with a third), I have done precisely what Thunderbird2 asked for, but his support vote simply never materialized. Whether intentional or not, it is my well-supported belief that the end result of caving to Thunderbird2’s wishes in hope of meeting his objections will only result in ambiguous language in a guideline that can be interpreted any way someone likes. It seems to be an issue of passive resistance. For instance, he once wrote here on B11, that “Something isn't working. I have attempted to apply Greg's new guideline on a number of different articles, but the success rate is patchy. One example is Mac Pro, where I cannot make head or tail of the various footnotes. The article is a mess. I will continue to try, but I fear this problem will not go away.” and further complained “Take a look at the disambiguation footnotes. I think there are 6 in all. They are necessary because the article doesn't stick with one use for longer than about 2.3 milliseconds at a time, but in the end I fear they just serve to confuse - kinda defeats the object.”. But if you actually look at what he did (his version of Mac Pro here), it didn’t appear to me that he really had his heart in doing as good a job as an experience editor really could. In short order, I was able to disambiguate the article using the techniques used in current, general-interest computer magazines; check out my version Mac Pro here. At the time, it just struck me as one of those teen-age-like stunts of “see what a crappy job of mowing the lawn happens if you make me use that old lawn mower?” Sorry T-bird, I simply believe you are far better of an editor than that to have not been able to solve the Mac Pro article on your own; it was just too simple. The objective of this post is not to denigrate you; it’s an attempt to help some other poor editor from wasting enormous amounts of time for no reason whatsoever. That’s an extremely important objective and it’s worthwhile doing. I’m beginning to feel that the way you deal with other editors—whether intentional or not—simply isn’t fair treatment in the end.
Headbomb, you started out here with a “4” vote on FCL and after seeing how easily and sensibly it resolved an issue of nanometers v.s. angstroms, you upgraded your vote to a “5” vote. And you managed to get the spirit of FCL fairly intact into your green box. As you can see though, one aspect of FCL—the binary prefixes—has proven to be a sticking point. I think you will find that after negotiating with T-bird long enough, you will come away feeling that it is “pretty to think” that you’ve arrived at wording that seems to be clear enough, but you’ll have this nagging feeling in the back of your mind that it’s a little ambiguous and m-a-y-b-e someone could exploit that ambiguity. I don’t think that will have been by accident. If you are willing to accept ambiguous guidelines that can be interpreted any way an editor desires, be my guest. But note that FCL is currently rather clear that the IEC prefixes are not to be used on Wikipedia because the average reader doesn’t know what they are, hasn’t seen them elsewhere, and won’t ever see them again after leaving Wikipedia. Call me “mean” or “uncivil”, but just pardon me all over if I believe that Thunderbird2 likes the IEC prefixes and his objective of being able to continue using them underlies all his dealings with you. I would suggest that if you want to see what the future portends for you, just ask him directly if he wants to continue to use the IEC prefixes in computer articles—either as a primary unit, or as a parenthetical “disambiguation”. Greg L (talk) 04:00, 24 May 2008 (UTC)
That could probably be done in less than 10 lines. Not a lot of work, but you seem to be very reluctant to do it. If you don't want to do the work, don't complain that it's not done. Headbomb (ταλκ · κοντριβς) 21:53, 24 May 2008 (UTC)
As for how Thunderbird interacted with all of that process, it’s a matter of record. Like all off all the editors involved here, I listened to his input because he wrote directly to me that incorporating certain text he desired (mentioning how the IEC prefixes had meritorious virtues) and deleting still other text he opposed (mention of the uno) was necessary for his being able to support the proposal, and after doing what he asked, he still didn’t support it in the end? You call that an “attack” “without being given proper rebuttals and counter arguments” that shouldn’t be allowed on talk pages? I reject that charge as utter nonsense; I call my statement as simply stating a relevant fact that is very, very germane to trying to obtain a wide consensus on a proposed guideline. Further, he and others have every opportunity to rebut my statement if it is untrue or incomplete.
You may enjoy wasting your time but I don’t. I tend to be goal oriented. You’ve stated here that you’re only writing ‘what you’d like to do if it were you’, not necessarily what you hope will necessarily be adopted on MOSNUM. If that’s still the case, I don’t understand why all the effort; you need wide consensus to accomplish anything here. Are you expecting that you’re going to be taken seriously if you’re really just writing what you would personally like to see on MOSNUM and not what you think really has a chance of achieving a consensus? Greg L (talk) 06:37, 24 May 2008 (UTC)
... delete it. This is far to general to be in a section of a MoS subpage. Words to this effect may have their place at the top of the main MoS page. JIMp talk·cont 00:07, 21 May 2008 (UTC)These are guidelines, not unbreakable laws. No set of rules could ever be written in a few lines that can cover the scope of all the topics of Wikipedia. A blind application of these principles will yield good results in most cases, but for the rest, use judgment. If you feel there are good reasons to depart from MOSNUM, then go ahead and depart from it.
I prefer the order produced by DRHamilton:
This seems to be in the right order of importance. We would not be right to prefer SI if it were not broadly accepted, so broad acceptance should come first. Septentrionalis PMAnderson 23:39, 20 May 2008 (UTC)
I disagree. The focus of any MOS is to avoid ambiguity and to ensure uniformity (consistent usage within articles and wikipedia as a whole), everything else is details. As such, emphasis should be on those two point first, with the rest being the agreed upon means to achieve unambiguity and uniformity.Headbomb (ταλκ · κοντριβς) 23:52, 20 May 2008 (UTC)
For example, kyr has this to say.
We have the following from myr. (Note the lower case "m".)The symbol kyr was formerly common in some English-language works, especially in geology and astronomy, ...
Modern, ISO 31-1 recommended usage is ka for kiloannum, which avoids the implicit English bias of "year" by using a Latin root.
Next we have Byr with this. (Note that Gyr is a disambiguation page.)The symbol myr was formerly used in English-language geology and astronomy ...
It is an abbreviation for 'million years' and lower case is usually used.
In English-language technical literature in these fields, the term 'Ma' is preferred, as this conforms to ISO 31-1 and NIST 811 recommended practices. ...
The correct ISO 31-1 usage is megaannum or Ma which unambiguously denotes a duration of 106 years. To denote a date one would add ago or bp to denote before present.
In non-SI usage, Ma was used to denote a specific number of millions of years ago, but it was not properly used to describe a duration, so: the Cretaceous started 145 Ma and ended 65 Ma, but it lasted for 80 myr (or 80 My). More often, the term "mya" (million years ago) is used in these contexts.
I say we ditch "yr" altogether: it's finished. Use "a", "ka", "Ma", "Ga", etc. to express a duration add "ago" or "BP" to express "years ago". Where precision is important the year is taken to be a Julian year (unless context clearly indicates otherwise). If other types of year are meant, the meaning should be clarified. JIMp talk·cont 06:45, 28 May 2008 (UTC)Byr was formerly used in English-language geology and astronomy ... The "B" is an abbreviation for "billion" ... Today, the term gigaannum (Ga) is also used, but Gy or Gyr are still sometimes used in English-language works (at the risk of confusion with the gray).
Because a billion means 1000 million in some countries but can mean a million million in others its use is deprecated in favour of giga- ...
I thought of this the other day.
Work is .
The unit of work is therefore the N·m .
Torque is .
The unit of torque is therefore the N·m.
I haven't heard of any convention at all to distinguish between the two. I suggest we combine scalar multiplied units with dots and vector multiplied units with crosses. A.k.a.
Work is .
The unit of work is therefore the N·m.
Torque is .
The unit of torque is therefore the N×m.
Headbomb (ταλκ · κοντριβς) 00:59, 28 May 2008 (UTC)
I'm losing tract of what exactly we're talking about. My concern is this: Under current rules, N·m can refer to either torque units or Joules. While not de facto problematic, it is ambiguous. Should the rule that dot products (scalar product) are to combined with middots, and cross products (vector product) units with crosses be made for non-ambiguity's sake? Headbomb (ταλκ · κοντριβς) 10:40, 28 May 2008 (UTC)
Sure, let it be the rule that the scalar product of two vectors be denoted with mid-dots and the vector product of two vectors be denoted with a cross. However, units are not vectors. Suggesting "ft×lbf" for the unit of torque is a dead-end. JIMp talk·cont 15:52, 28 May 2008 (UTC)
The units are not identical. If the two units were identical (as current rules imply), the joule (J, or N·m, or kg·m2·s-2) would be a unit of torque (N·m, or kg·m2·s-2). If we distingish between scalar and vector combination, then the units become distinct (which they are), a joule (J, or N·m, or kg·m2·s-2) would not be a unit of torque (N×m, or kg·m·s-2×m) Headbomb 20:26, 29 May 2008 (UTC)
I'd say that if there were a need, someone would have addressed it already. The outside world is getting along without this kind of thing, we can follow suit lest we leave readers completely baffled. JIMp talk·cont 04:08, 30 May 2008 (UTC)
I want to mention a few more things and then we should consider this matter closed. It is true that units are not unique, Headbomb. Any combo of units that is equivalent to "m N" can be a Joule or torque or what-have-you. When you specify that a combination of units are work or torque, you are giving the context under which the units are being used. This is part of the power of the current seven fundamental unit SI system and not a flaw. It gives every physical quantity an equivalence class of units based upon the physical units of the defining equation for that property. (There's sort of an analogy here between the SI system using a base-10 number system verses a vector-unit system giving every number its own unique character.) In any case, you guys are really arguing against the SI system and Wikipedia is not the place to start new conventions. Since there still seems to be some confusion regarding the scalar and non-vector nature of units, let me be more explicit. Lets examine torque and work:
I've grouped the debates in two. Resolved issues are above in the thingamajig (click and it'll display), as well as those no one seem to care about anymore. Feel free to move things from here to there and there to here (please keep some sort of order in things). Headbomb (ταλκ · κοντριβς) 19:29, 27 May 2008 (UTC)
Conversions to and from SI (and SI-related) units and US units should generally be provided.
To me this seems rather unnecessary in most instances. Generally, you'll be dealing with measurements which are already approximate. Conversions of measurements are, by nature, approximate. The "~" therefore tells you nothing that common sense has not already told you. This is not how things are now being done. There is no need to require the addition of this symbol, moreover, it would be a logistical nightmare. This proposed rule would affect tens (hundreds maybe) of thousands of conversions. The process of adding the "~" would likely never be completed, leaving us with some conversions with and other without the "~". The job half done would lead to a great deal of confusion ... "Why does this conversion have a '~' whilst that doesn't?" However, I can see a sensible use for such notation. Suppose it is an exact figure you start with and your conversion is an approximation, then the addition of the "~" might give the reader something he doesn't already know. JIMp talk·cont 03:36, 26 May 2008 (UTC)When giving a non-exact conversion, indicate it with a '~' ...
- When part of a full sentence, write "approximately" in full, do not use "~" or "approx." (e.g. do not write "Earth's radius is approx. 380,000 km" or "Earth's radius is ~380,000 km).
- When giving approximate quantities and conversions, you may indicate it with a "~" or "approx." (e.g you may write "Earth's radius is approximately 380,000 km (~240,000 mi)" or "Earth's radius is approximately 380,000 km (approx. 240,000 mi)").
I recall reading some popular science book, The Emperor's New Mind by Roger Penrose if my memory serves me correctly, in which there was something like a dozen exclamation marks per page (if I eggagerate, it was a decade ago). Perhaps I'm a punctuation pedant but I tend not to end anything but an exclamation with an exclamation mark but this book was crammed with them. After a while the exclamation marks began to loose their impact and served as nothing more than an irritatingly shaped full stop.
Over-use of a symbol dilutes its meaning. Let's not allow "~" to be liberally thrown around at just any conversion. The symbol should be reserved for values/conversions where there is less precision than would otherwise be assumed.
"since it is up to judgement," as you write "and that judgement part was already invoke by 'it may be appropriate to...'." Fair enough, but I have argued that good judgement is to follow this removed point and would therefore object to the addition of examples which go against it. A measured quantity is, by nature, approximate. Conversions from approximate values are necessarily approximate. We need not mark them as such. I argue that we should not mark them as such. Look around at the thousands of conversions on WP & you'll see that we do not mark them as such. We'll end up missing the mountain for the mole hills. There is included an example where it would be appropriate to note the conversion as approximate (the gross register ton example being in reference to a defined and therefore exact quantity). Let's have the examples where this would be inappropriate omit the "~". JIMp talk·cont 08:13, 3 June 2008 (UTC)Where the level of precision not singnificantly lower than expectable for the quantity or conversion in question it need not be noted as approximate.
The current advice is to spell approximately out in full sentences. Again I pose the question "How about connecting it to the way that the unit is written instead?" The MOSNUM advice is generally to spell units out in full when they appear in prose. However, allowance is made for symbols/abbreviations. This is useful when there are many instances of units or when the unit names are long (e.g. "pounds force per square inch" vs. "psi"). Would it not make sense to treat approximation in parallel? How about we allow (or even recommend) "~" and "approx." whenever the unit is written in abbreviated or symbolic form? JIMp talk·cont 08:36, 3 June 2008 (UTC)
The dinosaur units are rarely used outside of food energy discussion where it's the big calorie refered to. Can we not just drop the example altogether? JIMp talk·cont 01:28, 28 May 2008 (UTC)
Unnecessarily redundant or not?
This whole proposal is being shepherded by someone who declared above that “As a matter of fact, yes, I am more enlightened ON THIS TOPIC [choosing units of measure] than the professional, paid editors at all the general-interest computer magazines and print encyclopedias.” I respect that Headbomb had the courage to state the logical consequences of his position; he doesn’t have to resort to utterly fallacious arguments to make his case. And that attitude fully explains why Wikipedia is all alone on various articles in the use of units no one else uses in those disciplines. It is the judgment of the clear majority of editors here that the desires of the pro-SI/pro-IEC prefix crowd is thoroughly unwise and they rejected this minority position with the effective conclusion of ‘Well… Duhhh, we should be observing the practices used by all the other professionally edited encyclopedias like Encyclopedia Britannica and World Book rather than off doing our own thing.’ And in my opinion, the hurdles this vocal minority has forced us to jump through in listening to their objections has risen to the level of galactic-grade absurdity. We don’t have to accept any of this; this issue has had a more than fair hearing. To those editors who are thoroughly more humble: I know two ways I think we can put end to this charade. I’m heading down for more work on an FDA animal trial and will be back on the weekend. I’ll run it by some of you over the weekend. Greg L (talk) 04:55, 22 May 2008 (UTC)
Well I guess it's a good thing that THIS PROPOSAL IS NOT CONCERNED WITH THE IEC DEBATE. How many times do I have to say it? Will we need 20 archives of "Declarations made by headbomb to the effect that the rewriting of section 4 is not concerned with the IEC debate."? Headbomb (ταλκ · κοντριβς) 05:06, 22 May 2008 (UTC)
Similarly when the IEC uses a word they can mean whatever they want by it. Since we are not them, though, we are not bound by their definition. We are, of course, free to adopt their definition. However, were we to do so, we'd be setting ourselves apart from general usage of the terms in the English language. This, as I read it, is Greg's big concern with the current proposal under discussion. JIMp talk·cont 07:11, 22 May 2008 (UTC) ... P.S. Who are you, 217.87.60.244? JIMp talk·cont 07:12, 22 May 2008 (UTC)'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'
The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, editors should write “He was 1.83 meters (6 foot) tall”, not the reverse. However, wherever a discipline has an English-language, world-wide practice of consistently using its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline. For articles that cover several disciplines, which use diverse units, find units shared by all the disciplines; failing that, use SI units. For guidance, look towards current literature for any given subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, and number notation typically employed in reliable periodicals directed to a similar readership.
The following section could be summarize into 3 bullets. In order of importance, they are:
User | 5 | 4 | 3 | 2 | 1 | 0 |
Headbomb (ταλκ · κοντριβς) 20:52, 5 June 2008 (UTC) | X[1] | |||||
Jimp | ×[2] | |||||
Woodstone (talk) 08:25, 2 June 2008 (UTC) | x[3] | |||||
Greg L (talk) 00:24, 3 June 2008 (UTC) | X[4] | |||||
Fnagaton 08:17, 3 June 2008 (UTC) | X[5] | |||||
Pyrotec 21:57, 5 June 2008 (UTC) | X[6] |
5 - Redbox is a must have addition to the greenbox, it is as if a benevolent deity (which I may or may not believe in) came down on earth and wrote it for us. Anyone who disagrees is a retard.
4 - Redbox is a great addition to the greenbox. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Redbox is a good addition to the greenbox. However, I still have some major concerns that are not addresses by this version of the redbox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Redbox is a bad addition to the greenbox. I have some severe objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Redbox is a deeply flawed addition to the greenbox. I have some nearly irreconcilable objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Redbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.
Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere.
However, wherever a discipline has an English-language, world-wide practice of consistently using its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline.
For guidance, look towards current literature for any given subject and level of technicality.
When in doubt, use the units of measure, prefixes, unit symbols, and number notation typically employed in reliable periodicals directed to a similar readership.
If your sources use the imperial system, use those units as the primary units and convert to metric (& US customary where needed). I'd even go so far as saying that even if the sources are demonstrably unrepresentative of the literature on the subject (assuming that we've been able to pin that "literature" down after all), we can still follow those unrepresentative sources. For example, if our article on some Albertan oil well gets its information from some source which gives oil volumes in cubic metres, we should not give barrels as the primary unit, we should give the original cubic-metre values first with the barrel conversions in brackets.
Just follow the sources, damn simple. That way we can even forget about that US-related and UK-related clause as well. By nature, the sources for a US-related article will generally be based in the US customary system. Follow the sources and the US-customary system is the primary system for the article. Similarly with UK-related articles. Indeed this catches stuff like pre-metrication-Australia/Canada/etc.-related articles too. Clear-cut & to-the-point a simple rule such as this might not fill a whole section. JIMp talk·cont 05:31, 28 May 2008 (UTC)
As for demonstrating that it is easy to determine what constitutes current literature (and the counter-argument that this is impossibly difficult task), that’s simple. First, we apply common sense. FCL says “ Wherever a discipline consistently uses its own terminology, units, and symbols…”. Let’s take an obvious example: computer-related subjects. Whether you want to call it “balkanization of units” or “decay of modern society”, we do no good whatsoever by ignoring current literature on that subject and using using unfamiliar terminology like “gibibytes” rather than the infinitely more familiar “gigabytes”. It isn’t hard to figure out that virtually unused terms like “gibibytes” are only used when writing for highly advanced programmers and software developers. It’s also not hard to figure out what a “general-interest readership” is. If it’s really hard to figure out what “current literature” is for computer-related subjects, then you look towards reliable periodicals like PC World and Mac World. That’s what FCL calls for. If one follows FCL and looks to reliable periodicals, one would quickly find what is the proper units to use so as to not confuse readers coming to Wikipedia.
Another example where FCL is of great facility in resolving dispute is in an example Headbomb participated in recently. It was over whether angstroms should be used in discussing U.V. spectroscopy instead of nanometers. As Headbomb saw firsthand, simply looking towards current literature demonstrated that there was no consistent practice; it was more complex. That made a believer (at least at that time) of Headbomb. MOSNUM can’t possibly have a specific rule for every conceivable unit of measure. Many conflicts would have—and will be—settled by simply following FCL’s guiding principle.
It is not Wikipedia editors’ role to debate the virtues and shortcomings of units of measure in wide use on subjects; it is our job to follow the practices widely observed in current literature so readers don’t have a WTF?!? reaction when they land here. Anything else just amounts to a minority subset of editors who fancy themselves as cadet members of the BIPM and the IEC (and any other standards organization that comes up with a good idea) hijacking Wikipedia to help promote the adoption of some new standard. In case any of us here haven’t figured it out yet, that is not a suitable role for any contributing Wikipedia editor. Greg L (talk) 19:53, 1 June 2008 (UTC)
P.S. to Woodstone: The proper reaction to my taking the time to give a full response to all your comments isn’t to seemingly react as if “I don’t like his response” and fly off and strike the text with an edit summary of “remove undiscussed addition”. In case you haven’t noticed, 1) over a dozen editors had a hand in crafting FCL, 2) Elements of FCL had originally been in the greenbox but very, very, slowly (incrementally) got erroded until nothing was left of the basic principle, 3) we’re discussing it here and haven’t provided nearly enough time for its effect on votes to become clear and for sufficient discussion to occur. Who do you think you are? In case you haven’t noticed, this is a collaborative writing environment. I’ve pretty much kept my hand off the greenbox the entire time it was crafted. This is my contribution to it now; something that over a dozen editors worked on, liked a great deal, and voted on. Just how about we give it a try for more than the god-damned 18 hours you seem to be willing to give it? Huh? 20:52, 1 June 2008 (UTC)
Insisting that the SI unit (or some compatible metric unit) be included (at least as a parenthetical conversion) is nothing akin to abusing WP to promote the SI. It is merely ensuring that our articles are comprehensible to those who think in metric ... and we do exist. Assuming that all the literature on crude used barrels exclusively never converting to metric, should we just follow suit? Why should we not have articles make sense to those who don't think in barrels? As for the arugment that no-one can grasp a million cubic metres anyway ... 1 E+6 m³ is a good place to start ... that's a small lake. Do we have a 1 E+8 bbl article? Of course, it's not so black and white with crude ... there might be some literature out there using metric. Greg writes "the conversion is fine by me". Good to hear, this seems to me a bit of a change in tune but never mind. So conversions are fine & yes, they're quite common on WP at present. The allow us to put the conversion back into the example on FCL. Don't make it contingent on the unrelated issue of the presence of a "disputed" tag. That particular part of FCL "doesn’t address details like conversions", no, but we've argued that it should exemplify then lest it imply that they be proscribed. JIMp talk·cont 01:14, 2 June 2008 (UTC)
User | 5 | 4 | 3 | 2 | 1 | 0 | |
Headbomb (ταλκ · κοντριβς) 20:40, 27 May 2008 (UTC) | X[1] | ||||||
Greg L (talk) 19:23, 25 May 2008 (UTC) | X[2] | ||||||
Thunderbird2 (talk) 08:26, 31 May 2008 (UTC) | X[3] | ||||||
Woodstone (talk) 19:50, 29 May 2008 (UTC) | X[4] | ||||||
Pyrotec 22:26 05 June 2008 (UTC) | X[5] | ||||||
New user |
5 - Bluebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard.
4 - Bluebox is a vast improvement over the nothing current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Bluebox is a improvement over the nothing current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the bluebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Bluebox is an downgrade over the current nothing section 4 of MOSNUM offers. I have some severe objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Bluebox is a severe downgrade over the current nothing section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Bluebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.
(break)
((val|4.535|e=2|u=u/atom)) × ((val|6.02|e=23|u=atom)). Headbomb (ταλκ · κοντριβς) 23:20, 20 May 2008 (UTC)
Multiple-byte units | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Orders of magnitude of data |
When measuring bits and bytes, there are two different de facto standards for defining the symbols "k" (often written "K"), "M", and "G": one follows the International System of Units (SI) prefixes convention using powers of 1000 (103); the other uses powers of 1024 (210). The use of the prefixes "K", "M", "G",... to represent both decimal and binary values of computer memory originates from earliest days of computing. In 1986, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) formally ratified the binary usage, making units of measure such as “kilobyte” officially mean 1024 (210) bytes, “megabyte” to mean 10242 (220) bytes, etc. However, these prefixed forms of the byte and bit were still ambiguous because the IEEE/ANSI resolution failed to reverse the practice of taking the same unit symbols (KB, MB, GB, etc.) to mean decimal values for hard-drive capacities.
In an effort to resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced distinct binary prefixes in 1998. Kibi-, mebi-, gibi- (symbols "Ki", "Mi", "Gi",...) to replace kilo-, mega-, giga. These would exclusively mean powers of 2. In 2005, the IEEE adopted the IEC proposal after a two-year trial, thus reversing its previous position. While the IEC proposal has seen a gradual adoption in the scientific literature, virtually all general-interest computer publications (both online and print), computer manufacturers, and software companies continue to follow the long-held practice in which SI-prefixed versions of byte and bit have the binary meanings for solid-state memory, and the decimal meanings for most spinning-disk mass storage. Consequently, the IEC-prefixed forms of the byte and bit, such as "kibibyte" and "mebibyte", and their unit symbols ("KiB" and "MiB") are unfamiliar to the typical Wikipedia reader.
After many years of debate, it was agreed that the prefixes "K", "M", "G",... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS was better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.
User | 5 | 4 | 3 | 2 | 1 | 0 |
Headbomb (ταλκ · κοντριβς) 05:30, 2 June 2008 (UTC) | X[1] | |||||
Greg L (talk) 15:16, 30 May 2008 (UTC) | X[2] | |||||
Fnagaton 19:08, 25 May 2008 (UTC) | X[3] | |||||
Woodstone (talk) 20:42, 2 June 2008 (UTC) | X[4] | |||||
SWTPC6800 (talk) 18:01, 30 May 2008 (UTC) | X | |||||
Seraphimblade Talk to me 05:42, 26 May 2008 (UTC) | X[5] | |||||
MJCdetroit 19:50, 27 May 2008 (UTC) | X [6] | |||||
Thunderbird2 (talk) 07:28, 6 June 2008 (UTC) | X[7] | |||||
Dfmclean 19:00, 28 May 2008 | X[8] | |||||
Pyrotec 22:35 05 June 2008 | X[9] | |||||
New user |
5 - Purplebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM.
4 - Purplebox is a vast improvement over what the current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Purplebox is a improvement over what the current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Purplebox is an downgrade over what the current section 4 of MOSNUM offers. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Purplebox is a severe downgrade over what the current section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Purplebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are silly enough to adopt this version of things.
Arguments that Wikipedia should be off all by itself doing its own thing with terms like “3 GiB of RAM” (while still other articles are using the well recognized “3 GB of RAM” so some readers who notice this different usage are left wondering “WTF”), make no sense whatsoever. Such arguments amount to nothing less than saying “Hell yes; I am much, much smarter than all the professional, paid editors at PC World and Encyclopedia Britannica and want Wikipedia to be “different” and use units of measure that haven’t seen any real-world adoption and are therefore totally unfamiliar to the typical reader. No. I reject such an attitude as arrogant and utter nonsense. It violates the most basic principles of technical writing.
Its a damn shame that Wikipedia’s dispute-resolution process and policy-setting process allows itself to be hijacked by a vocal, extreme minorities. Like it or not, the rest of the computer and publishing world will be using the conventional binary prefixes decades from now. This three-year-old experiment where some articles on Wikipedia use the failed IEC prefixes is coming to and end. I won’t rest until I’ve done my part to help put an end to this hogwash. Greg L (talk) 20:53, 31 May 2008 (UTC)
Gerry: After reading your above post, I’m not sure what you intend to do now with your vote. I ask that we all argue and vote in good faith and not react to frustrated writings of others with equally frustrated votes. I really want to know how everyone here feels about this issue. All I’ve wanted in the purplebox is unambiguous text so we all clearly know what the effect of the purplebox would be. I see trying to make it ambiguous so editors can do whatever the hell they want is just a continuation of the same old shit that has gone on for three years now; that’s no good whatsoever and must end. Greg L (talk) 23:35, 1 June 2008 (UTC)
T-bird: Do you really think that the outcome of all this is going to be the continued use of the IEC prefixes being permitted? I suggest that you come to grips with the reality of the situation and compromise. If I were you, I’d make peace with Fnagaton, agree that no more articles are to use the IEC prefixes, and hammer out wording on a policy regulating how the IEC prefixes will be deprecated from existing articles. I personally don’t think any such regulation is needed; Fnagaton knows these idiosyncrasies better than anyone and clearly has abundant energy to devote to correcting them and bringing them into compliance with the rest of the planet. Greg L (talk) 00:35, 4 June 2008 (UTC)
Headbomb (ταλκ · κοντριβς) 22:01, 24 May 2008 (UTC)
And in accomplishing that end, we would—in rare cases—permit the use of different, unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia, and further, have not even been endorsed by a standards organization and are unrecognized even by professional software developers since they are a wholesale, ad-hoc invention of some Wikipedia editors who were trying to find a work-around to the IEC prefixes?
That remedy would be worse that the illness. Simple solution: “The IEC prefixes shall not be used as a primary measure nor as a parenthetical conversion. Parenthetical conversions of the conventional binary prefixes should be given where appropriate and should generally also follow the practices in current literature on that subject.” Greg L (talk) 05:55, 25 May 2008 (UTC)
This second sentence, while not incorrect, is biased. For example, it implies that decimal prefixes were not used in the early days of computing (they were). It also suggests (taken together with the remainder of the purple box) that hard drive manufacturers who did not follow the early standards were wrong to do so, while today's semiconductor manufacturers who do not follow modern standards are faultless. Finally (again, taking it with the rest of the box), it implies that the IEEE recognises the binary use of the prefixes (it doesn't). Do you see the problem? Thunderbird2 (talk) 18:05, 28 May 2008 (UTC)
Would you agree to that? Thunderbird2 (talk) 16:50, 31 May 2008 (UTC)
On a separate note, the “2” votes the pro-IEC prefix elements have given can only be reasonably interpreted as an “oppose” vote; thus, no “consensus” can be called given the limited number of editors who give a damn on this issue. Most “moderate” editors who voted on various incarnations of “Binary prefixes in computer memory and storage” and “Fourth draft (Follow current literature)”, just aren’t as passionate about the issue to see any reason to spend half their free hours here endlessly debating this issue. These editors have previously voted with comments like “Looks like a common-sense guideline that solves a long-standing problem” and then they wander off to happier waters here on Wikipedia, rather than getting bogged down in endless debate, questing the parentage and mental prowess of the other camps here. Even if a consequence of your struck text is that the pro-IEC prefix crowd reduces their votes to a lower value, I don’t see that as as being a real problem; their votes are already an effective “oppose” vote. So…
I think we’re wasting our time here and see no further point trying to reason with this handful of editors; their positions are clear and it is unrealistic to expect them to substantially change after three long years. Notwithstanding that all computer manufacturers in all their literature and publications to end users don’t use the IEC prefixes, notwithstanding that all general-interest computer magazines don’t use the IEC prefixes, notwithstanding that all professionally edited print and Web-based encyclopedias (like Encyclopedia Britannica) don’t use the IEC prefixes, the minority pro-IEC Prefix crowd have apparently looked into the future using their tricorders and must know something about the future adoption of the IEC prefixes that isn’t apparent to the rest of us (and all the professional, degreed editors at “real” encyclopedias). Accordingly…
I think it’s time to stop wasting our time. As I proposed above in No no… let’s DO, I think it’s time to post a number of invitations on the talk pages of many of Wikipedia’s computer and technical-related articles and conduct a big vote on “Follow current literature”. From then on, only minor edits that don’t substantially change the spirit, intent, and basic effect will be permitted without an equally broad-based consensus. Greg L (talk) 19:44, 31 May 2008 (UTC)
The solution you propose here is remarkably compley and ambiguous. We have just had a vote on a consensus solution in the German Wikipedia and the result was to not use IEC but to do the following: Use the KB, MB etc. always as binary for data amounts, use them as decimal for data rates (data rate is basically a frequency). If refering to media that is declared in decimal values (i.e. DVD or harddisk) give the correct size in binary plus a remark about the usual capacity statement. To simplify this we have created a set of standard tool tips (showing the exact value) and footnotes. TheBug (talk) 12:19, 6 June 2008 (UTC)
Woodstone or Thunderbird, would you be so kind as to give us an example of a hypothetical (or real) IEC prefixe use that would be perfectly appropriate in the spirit of the MOS, but somehow prohibited by the unstruck version of the purplebox? We don't have a lot to chew on. It seems to me that the purple box would cover the use of a vast majority of article, and that if there is a need to use KiB and GiB in an article, that people can discuss it on individual talk pages and resort to "MOS is a guideline, not absolute law". Headbomb (ταλκ · κοντριβς) 22:09, 31 May 2008 (UTC)
The problem I see is that by far the easiest way to disambiguate is with IEC prefixes. Notice that I do not say best, just easiest. They make it possible for a knowledgeable editor to come along and, with very little effort, disambiguate an article or series of articles. Once that step is made it becomes possible for another editor, with (perhaps) less knowledge but more time, to improve the article still further by replacing the unfamiliar IEC units with a more familiar form of disambiguation. The end result? A better Wikipedia. The effect of forbidding the use for all but the most unlikely situations is to increase the difficulty threshold for that knowledgeable editor (a scarce resource), who as a result is able to improve fewer articles, if he bothers at all.
Thunderbird2 (talk) 19:01, 6 June 2008 (UTC)
prefix | Standard | IEC | %Standard | %IEC |
K | 267 000 | 3 540 | 98.7 | 1.3 |
M | 433 000 | 3430 | 99.2 | 0.8 |
G | 674 000 | 4 000 | 99.4 | 0.6 |
T | 283 000 | 1 100 | 99.6 | 0.4 |
P | 468 000 | 344 | 99.9 | 0.1 |
Z | 8 450 | 219 | 98.5 | 2.5 |
Yotta | 6 960 | 259 | 96.4 | 4.6 |
Total | 2 140 410 | 12 892 | 99.4 | 0.6 |
prefix | Standard | IEC | %Standard | %IEC |
K | 12,700 | 47 | 99.6 | 0.4 |
M | 35,400 | 29 | 99.92 | 0.08 |
G | 66,000 | 26 | 99.96 | 0.04 |
T | 18,700 | 11 | 99.94 | 0.06 |
P | 3,020 | 7 | 99.8 | 0.2 |
Z | 94 | 1 | 98.9 | 1.1 |
Yotta | 56 | 2 | 96.6 | 4.4 |
Total | 135,970 | 123 | 99.91 | 0.09 |
I think we are very, very close of gaining consensus on purple box. I suggest that we all take a good review of everything in the greenbox, bluebox, and purplebox to make sure that we're comfortable with them being uploaded and try to resolve our differences by that time. Make sure your votes are up-to-date in each section, and that they reflect the content of the box you're voting on. Greenbox will not be uploaded if there is no consensus for purplebox, so don't vote 1 in greenbox because you're not happy with purplebox.
We'll need to find a place to put the "These principles are not unbreakable laws" and for the "unecessary vagueness" section.
So let's give a push to polish those boxes as best we can for Sunday Wednesday. If no consensus is reached, then at least we'll be closer to that. If we have consensus when I wake up on Monday Thursday, I'll upload things and archive a copy of everything pertaining to the boxes in Units of Measurement Rewrite of (June 2008) (or something like that), leaving unresolved stuff behind so the bot may archive it in the regular archives as they get settled. Headbomb (ταλκ · κοντριβς) 04:01, 30 May 2008 (UTC)
During May, "(decimal)" was added: "A typical advertisement for a PC in 2008 might specify 2 GB memory (binary) and a 160 GB HDD (decimal)." I'm just checking that it means something; I have no idea. I guess I'll add non-breaking spaces between the units and values. TONY (talk) 03:40, 1 June 2008 (UTC)
At the moment, MOS requires words as words to be rendered in italics, not quotes. There's now a clash between this and the (disputed) point here that SI symbols must always be in roman face. This needs to be sorted out. TONY (talk) 04:47, 1 June 2008 (UTC)
In accordance with the rules of CGPM, NIST, National Physical Laboratory (UK), unit symbols are in upright, roman type.
I'm totally confused. I see things that need copy-editing in those boxes. Can someone tell me which ones are slated for inclusion? TONY (talk) 08:49, 3 June 2008 (UTC)
All of them, but hopefully redbox won't make it. Headbomb (ταλκ · κοντριβς) 16:01, 3 June 2008 (UTC)
A few questionable things has happened here in the last few days that are comprimising what we are trying to achieve here. Many discussion are made assuming bad faith and full of personal attacks. If you think this targets by this, you probably are right, so please stop arguing with little regards for civility. If you cannot keep your cool, then please take an hour or two before replying.
Amongst questionable practices are the addition of the FCL into the greenbox after a month or so of conveniently avoiding to answer why exactly should FCL be included as a separate section. An addition which was conveniently made one day before the target date. I can't say for sure that this was an attempt to hijack the vote/game the system/try to shove a disputed section at the last minute and ride on votes for a FCL-free greenbox (which achieved consensus immediately before the addition of FCL), but I certainly have my suspicions, especially since its proponents consider the rest of us to be retards. At best this was a very unorthodox addition made at a very bad timing, at worse it's exactly how things should not be handled. Regardless of what the intents were with the addition of FCL to the greenbox, the fact remains that its proponents do not address the concerns raised by the opposition. The same phenomena is present at the purplebox: opponents to the partial deprecation of IEC prefix avoid to explain why exactly they are opposing the partial deprecation of IEC units, and it seems they cannot to be convinced to give us examples of how this partial deprecation harms wikipedia.
If people keep saying "Nuh uh it's black" when people argue "We have all these reasons to think it's white, I'm not saying it couldn't be black, but could you tell us why our reasons are bad and explain to us why it's black?", I'll invoked the principles that unsubstantiated objections can be disregarded.
So I ask of everyone, please substantiate your opinions, and stop taking dumps on people with whom you disagree. Headbomb (ταλκ · κοντριβς) 19:15, 3 June 2008 (UTC)
And also, please keep your votes up to date, and please vote on every box even if you aren't overly concerned with it. Headbomb (ταλκ · κοντριβς) 23:20, 3 June 2008 (UTC)
Well it's June 4th has gone by and things haven't moved here in 3 or so days. I interpret this meaning that everyone said what they wanted to say on the issue for now.
Since there is a lot that was said, and that things have significantly progressed since the rewrite started, I suggest that we upload what represents the closest thing there is to consensus right now (click show on the Proposed text below), archive the box-related discussion and continue from there. This will clean up the talk page, MOSNUM will have a significant overall, and it'll be easier to talk about what the next steps to take are.
The reasoning for which text maximizes the level of agreement is this.
Greenbox: Greenbox has near universal support (9 for vs. 1 substantiated against), so greenbox is uploaded as is.
Redbox: FCL redbox has strong opposition (2 for vs. 3 substantiated against) and the concerns were not addressed. Fganaton mentionned that a summary was needed because one could lose perspective. I feel that a summary for the units of measurement section is a reasonable request, so I summarized things (Summary redbox). While few weighted into Summary redbox (2 for vs. 0 against), I do not think that anyone has strong opposition (if any) to a summary of units of measurements, and since Fganaton's views are usually aligned with Greg L's, I assume that Greg L would approve of the inclusion of a summary.
Bluebox: Bluebox concerns seems to be centered around the delimitation rules, the rest seems to have consensus (5 for vs. 0 against), so bluebox can be uploaded without the rules, and delimitation rules can be uploaded at a later date.
Purplebox: Purplebox has consensus from everyone that cared to give reasons for things (7 for vs. 3 unsubstantiated against). Opposition to purplebox is based on little to no arguments at all, unsubstantiated opposition may be disregarded.
The following section could be summarized into 3 bullets. In order of importance, they are:
If you have trouble balancing these three bullets, head to the talk pages to consult other editors and try to reach consensus. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea, especially if the problem is not restricted to a specific article.
Multiple-byte units | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Orders of magnitude of data |
When measuring bits and bytes, there are two different de facto standards for defining the symbols k (often written K), M, and G: one follows the International System of Units (SI) prefixes convention using powers of 1000 (103); the other uses powers of 1024 (210). The use of the prefixes K, M, G,... to represent both decimal and binary values of computer memory originates from earliest days of computing. In 1986, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) formally ratified such usage, making units of measure such as “kilobyte” officially mean 1024 (210) bytes, “megabyte” to mean 10242 (220) bytes, etc. However, these prefixed forms of the byte and bit were still ambiguous because the IEEE/ANSI resolution failed to reverse the practice of taking the same unit symbols (KB, MB, GB, etc.) to mean decimal values for hard-drive capacities.
In an effort to resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced distinct binary prefixes in 1998. Kibi-, mebi-, gibi- (symbols Ki, Mi, Gi,...) to replace kilo-, mega-, giga. These would exclusively mean powers of 2. In 2005, the IEEE adopted the IEC proposal after a two-year trial, thus reversing its previous position. While the IEC proposal has seen a gradual adoption in the scientific literature, virtually all general-interest computer publications (both online and print), computer manufacturers, and software companies continue to follow the long-held practice in which SI-prefixed versions of byte and bit have the binary meanings for solid-state memory, and the decimal meanings for most spinning-disk mass storage. Consequently, the IEC-prefixed forms of the byte and bit, such as kibibyte and mebibyte, and their unit symbols (KiB and MiB) are unfamiliar to the typical Wikipedia reader.
After many years of debate, it was agreed that the prefixes K, M, G,... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS was better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.
If this get no response by Saturday morning, or that only a minority of people feel that this does not maximizes the level of agreement, I'll upload this text as is (minus perhaps copy-editing) unless there are new developments, in which case I'll incorporate these developments as well. Headbomb (ταλκ · κοντριβς) 18:38, 5 June 2008 (UTC)
I, the undersigned, support the uploading of this text. While I may not be happy with everything in the text, I realize that my voice is only one of many, and I agree this text maximizes the level of agreement between all parties as of the time of my signing, and will facilitate later revisions of the MOSNUM.
I, the undersigned, oppose the uploading of this text. While I may not be happy with everything in the text, I understand that my personal feelings are inconsequential here and the reason of my opposition has nothing to do with my personal feelings on this. I simply do not think that this text maximizes the level of agreement between all parties as of the time of my signing.
I, the undersigned, support the uploading of this text, because I personally feel that this text is adequate. That this text does or does not maximize the level of agreement is inconsequential to me. I also understand that, because of my lack of concern for agreement between all parties, my vote will be disregarded.
I, the undersigned, oppose the uploading of this text, because I personally feel that this text is inadequate. That this text does or does not maximize the level of agreement is inconsequential to me. I also understand that, because of my lack of concern for agreement between all parties, my vote will be disregarded.
Headbomb, I leave for you to decide which box this fits in. I oppose statements that do not carry a broad consensus. I oppose guidelines that include such statements. Thunderbird2 (talk) 07:55, 6 June 2008 (UTC)
Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
Two points of order:
Thunderbird2 (talk) 07:40, 6 June 2008 (UTC)
:: Well if your computer can't handle 500 k of text... What’s that supposed to mean?
The following is from a recent archive:
So, here's some statements. Under each one, it would be useful if anyone who feels themselves involved in this debate indicate whether they agree or disagree with the statement. Hopefully, they';ll be no need in this section to say more than that; hopefully we can leave subtle distinctions for now, and caveats will be covered by the other points. However, if you really need to say more, then that could make sense; there's just no need to explain why you agree or disagree here. I've indicated my own views through these. If you want to add an extra statement, go right ahead. Just to note, this time I'm not asking people to judge where there is or isn't consensus, just to give their own views.
The rationale here is that I'm fairly convinced that we've gotten tangled up and don't realise which things we already all (or nearly all) agree upon. If you don't want to pick "agree" or "disagree", feel free to say "undecided". SamBC(talk) 18:17, 27 March 2008 (UTC)
Thunderbird2 (talk) 16:35, 6 June 2008 (UTC)
Tools & toys: Hacking the Nokia N800 "A lot can happen in a decade. You can hold the Nokia N800 in your hand, yet it’s a near-exact match for a high-end desktop PC from 10 years ago. It has a 320-megahertz processor, 128 megabytes of RAM, and a few gigabytes of available mass storage."
Wallich, Paul (April 2008). "Tools & toys: Hacking the Nokia N800". IEEE Spectrum. 45 (4). IEEE: 25. doi:10.1109/MSPEC.2008.4476441.
It appears that IEEE Publications does not appreciate the IEC binary prefixes. -- SWTPC6800 (talk) 00:01, 7 June 2008 (UTC)
I see a lot of people saying "we should not use IEC prefixes because readers are unfamiliar with them" or "we should use the ambiguous units because readers are familiar with them". But I don't think there's any merit to this argument.
Wikipedia is a general-purpose encyclopedia, not a computer science textbook. The vast majority of our readers don't know that "KB" is supposed to mean 1,024 in the first place. "KB = 1024" is just as unfamiliar as "KiB = 1024". This is especially true in metric countries (which is pretty much all of them except the US). Ask friends who are not from technical backgrounds or look through Yahoo Answers:
Regular people have no clue. :) There are certainly people on there who know the Microsoft definition, but there are many more who don't. I don't think we're confusing anyone any more by using IEC prefixes than we would using Microsoft prefixes. — Omegatron 16:04, 30 March 2008 (UTC)
The "IEEE" does not use the IEC binary prefixes. The IEEE Standards Association is just one part of the IEEE. The IEEE Publications have not adopted the IEC binary prefixes. The April 2008 issue of the flagship publication, IEEE Spectrum magazine has this article.
Tools & toys: Hacking the Nokia N800 "A lot can happen in a decade. You can hold the Nokia N800 in your hand, yet it’s a near-exact match for a high-end desktop PC from 10 years ago. It has a 320-megahertz processor, 128 megabytes of RAM, and a few gigabytes of available mass storage."
Wallich, Paul (April 2008). "Tools & toys: Hacking the Nokia N800". IEEE Spectrum. 45 (4). IEEE: 25. doi:10.1109/MSPEC.2008.4476441.
I guess the 385,000 technology professionals in industry, government, and academia that read the IEEE Spectrum each month[4] can deal with the ambiguous "128 megabytes of RAM". -- SWTPC6800 (talk) 01:33, 2 April 2008 (UTC)
The journals published by the IEEE and the ACM predominantly use MB and Mbyte. (You also see the occasional paper using MiB.) The current IEEE Computer Society Style Guide has this entry. MB: megabyte; use Mbyte (40-Mbyte hard disk, 12 Mbytes of memory) [5]
A common claim by the IEC advocates is that the IEC prefixes are use by organizations and "publications that strive to be unambiguous". Could someone name a few? (Other than standards groups.) Who is striving to be "ambiguous"? -- SWTPC6800 (talk) 00:57, 4 April 2008 (UTC)
I've just noticed this on Headbomb's talk page:
Headbomb: In the interests of helping to get the entire greenbox its much needed consensus, I've voted to support it and have given Fnagaton my permission to vote on my behalf. I just can't be watching over this frequently enough to adapt to rapidly changing events. I do ask that you make sure that what is going to MOSNUM has a proper consensus. Although Omegatron and Thunderbird2 complain that FCL didn't have a proper consensus when it was posted, outside, uninvolved editors agree that it did. And it is now on MOSNUM, where it calls for no longer using the IEC prefixes. If push came to shove, I'd organize a big-ass, Wikipedia-wide vote and FCL would have seriously deep tap roots. I would see it as a step backwards if the greenbox replaces everything--including FCL--only to be followed immediately by bitter complaints about how it didn't achieve a proper consensus. I'll very quickly take a strong stand that FCL goes right back in if some elements prevail in their claims that the binary prefix-related portion of the greenbox didn't have a consensus. Do things the right way. Good luck. Greg L (talk) 23:04, 5 June 2008 (UTC)
Headbomb: In the interests of helping to get the entire greenbox its much needed consensus, I've voted to support it and have given Fnagaton my permission to vote on my behalf. I just can't be watching over this frequently enough to adapt to rapidly changing events. I do ask that you make sure that what is going to MOSNUM has a proper consensus. Although Omegatron and Thunderbird2 complain that FCL didn't have a proper consensus when it was posted, outside, uninvolved editors agree that it did. And it is now on MOSNUM, where it calls for no longer using the IEC prefixes. If push came to shove, I'd organize a big-ass, Wikipedia-wide vote and FCL would have seriously deep tap roots. I would see it as a step backwards if the greenbox replaces everything--including FCL--only to be followed immediately by bitter complaints about how it didn't achieve a proper consensus. I'll very quickly take a strong stand that FCL goes right back in if some elements prevail in their claims that the binary prefix-related portion of the greenbox didn't have a consensus. Do things the right way. Good luck. Greg L (talk) 23:04, 5 June 2008 (UTC)
My arguments are weak? Let’s analyse yours:
Thunderbird2 (talk) 14:08, 7 June 2008 (UTC)
Headbomb (ταλκ · κοντριβς) 14:22, 7 June 2008 (UTC)
Thunderbird2 (talk) 15:55, 7 June 2008 (UTC)