Talk:Binary prefix/Archive 13

Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 18

Floppy disk sizes

Moved from the article. An anon added the following wording (bold) to the floppy disk section:

The last widely adopted diskette was the 3½ inch high density. This has twice the formated capacity as the 720 KB diskettes, 1,474,560 bytes or 1440 KB. The drive was marketed as 1.44 MB when a more accurate value would have been 1.4 MB (1.40625 MB). Some users have noticed the missing 0.04 MB and both Apple and Microsoft have support bulletins referring to them as 1.4 MB.[1][2] The 1200 KB 5¼ inch diskette was marketed as 1.2 MB (1.171875 MiB) without any controversy. Note that in fact, the manufacturer were really building 2MB floppy disk and clearly rated them to be able to hold 2MB of unformated data. The only reason they also used the number 1.44 MB (which really was 1440 KB), is for marketing reasons as it was the usable amount of data when formated for DOS, the most common OS at the time.

This was reverted by Shreevatsa (talk · contribs · deleted contribs · logs · filter log · block user · block log) with the following comment:

revert. That might be true, but it's uncited and besides it's not relevant to the main point

Finally, Tripodics (talk · contribs · deleted contribs · logs · filter log · block user · block log) added the word "formatted" back and added a comment with the accompanying summary:

I think this REVERSION is wrong. I want to revert the reversion, but don't want to risk being accused of vandalism. The reverted revision is accurate as well as NPOV, and should be restored!

I've reverted this last change as articlespace isn't where our opinions go. However, it should probably be discussed further. Chris Cunningham (not at work) - talk 10:03, 24 October 2008 (UTC)

I agree with the reversion. The whole article needs to be more carefully written to distinguish between the unformatted capacity as specified by the drive and media manufacturers and the formatted capacity as delivered to the system by the various controller manufacturers and then reported by the various OSs - it is a mess but this doesn't help. The reverted edit touches on the subject ("unformatted capacity") but IMO is POV ("market reasons") and should remain reverted Tom94022 (talk) 18:36, 24 October 2008 (UTC)

Consumer Confusion

Why is the triple discrepancy in the three images not explained (or clearly enough) in this section? The discrepancy between the second and third images is not even mentioned. Nsteinme (talk) 18:54, 9 January 2009 (UTC)

Usage_notes incorrect, OR, and uncited..

In the Usage_notes[1] section, we read:

Certain units are always understood as decimal even in computing contexts. For example, hertz (Hz), which is used to measure clock rates of electronic components, and bit/s, used to measure bit rate. So a 1 GHz processor performs 1,000,000,000 clock ticks per second, a 128 kbit/s MP3 stream consumes 128,000 bits (16 kB, 15.625 KiB) per second, and a 1 Mbit/s Internet connection can transfer 1,000,000 bits (125 kB, approx 122 KiB) per second, assuming an 8-bit byte, and no overhead.[2]

But it is not always assumed that the frequency in hertz of bits/second is in decimal. That claim is not true. For example, you've heard of all the RS232 speeds like 2400, 4800, and stuff, but what about 56K? Go look in your RS232 speed settings dialog and just try to set it to 56K -- you will find that there is no such thing as 56k listed, but rather the nearest speed is 57600. You will note that 56.25*1024=57600. Go ahead - go look! Also, see: http://www.urisp.net/urisp_glossary.html Also, go find any modem manual to see that "56K" really means 57600. There is no 56000. The best way would be to find the RS232 specification, but I couldn't in the short time I tried. And probably it wouldn't do any good anyway, considering what happened.

And here's where it gets funny: The other day I had seen the error and added a little note which read:(Note however, that "56K" really means 57600 bit/second, when talking about RS232.[3] 56.25*1024=57600. )

And somebody reverted it saying "It may be true, but a more WP:reliable source is needed."

But look at the source that the Usage_notes section does cite! ([4])

Said source says that a "56K modem" works at a maximum speed of 56,000 bits per second, not 57,344.

Well that's easy enough to disprove - go try setting your RS232 port to 56000. You won't find it. You will find 38400, and you will find 57600, but there is no 56000! Alternatively, download a manual for a modem like this [5] and see that there no 56000 speeds mentioned - but 57600 sure is!

I don't know just how http://www.dewassoc.com/kbase/hard_drives/binary_v_decimal_measurement.htm qualifies as a WP:Reliable source - they are just a seller or manufacturer of computers. They just have a nice faq for folks - but they have an error on it.

Anyway, I know better then to revert a revert so I'll just leave it here.

Somebody else can fix it - if there is another soul alive who cares.

But we gotta realize that with this terrible practice of protecting incorrect information from corrections and deleting correct information we're doing everybody a disservice!

Thanks,

jesse 64.146.180.232 (talk) 04:35, 13 January 2009 (UTC)

Cite to Wikipedia policy

There's a cite to Wikipedia policy WP:MOSNUM in the body of the article, in the Usage notes section.

Such cites are contrary to policy, so someone needs to figure out a better way of phrasing that. Studerby (talk) 00:11, 10 February 2009 (UTC)

I think, based on discussion at Wikipedia Talk:MOSNUM, that the information here was actually incorrect; so it has been fixed by changing what it says (instead of rephrasing). Shreevatsa (talk) 00:48, 10 February 2009 (UTC)

SI prefixes are never binary

Clear consensus was reached long ago in editing this article, never to describe binary prefixes as SI prefixes. The names of the SI prefixes are sometimes used to designate binary multiples, but then they are not SI prefixes. −Woodstone (talk) 18:00, 30 July 2009 (UTC)

The SI prefixes (kilo, mega,...) are formally defined by SI, nowhere else, therefore these names are always SI prefixes. The article in the relevant context uses the term 'SI prefixes in binary use' which is absolutely proper way of describing it, it uses the SI names for binary interpretation, it is used in that context to distinguish from just any prefix, or from the binary prefixes. There is hardly another way to refer to them, one section header used the term 'traditional' prefix, but that is completely vague, and has no definition whatsoever. You removed the SI qualifier form the table heading, making that table heading applicable also to the first column, which also describes binary use (but using the official binary prefixes). The binary prefixes indeed cannot be described by SI prefixes, your statement of this is pointless. Kbrose (talk) 18:10, 30 July 2009 (UTC)
Before you simply revert again, please offer a name or phrase (replacing the term 'SI prefix in binary use') for the concept of using SI prefix names in a binary interpretation, other than 'prefix in binary use'. This term should clearly specify that the SI prefix names are involved only, and not any other type of prefix. Kbrose (talk) 18:20, 30 July 2009 (UTC)
This issue has come up several times before, but I don't think any clear consensus has been reached, only awkward compromises have been suggested like "metric prefix", "greek prefix", and (most recently) "traditional prefix". See /Archive_9#Basic_English, /Archive_11#Not_SI_Prefixes_Prefices, /Archive_11#We_need_a_name_for_the_SI_prefixes, and /Archive_12#Terminology. The issue at hand is the contention that although "SI prefix" seems a good name to describe the prefixes "kilo", "mega" and "giga", when used with a binary meaning the same prefixes are no longer "SI prefixes". Shreevatsa (talk) 18:29, 30 July 2009 (UTC)
I also have failed to find the consensus that was mentioned. The argument, that the SI prefixes are no longer SI prefixes when qualified as 'in binary use', is circular (non)logic somehow, because the whole point of the exercise of qualification is to make that distinction that it is not the SI definition of value that is implied. If one manages to use a hammer to pull out a screw, it doesn't change the meaning of hammer. The reason for the arguments about this here on WP are that the SI-only proponents insist on proper usage of SI unit only to denote decimal multiples, and insistence by binary use (SI) prefix proponents that when bytes and bits are involved the only proper way of interpretation is the binary sense as has been the tradition in CS/EE for some time. The only sensible modification I can see is to use the term 'SI prefix names in binary use', which makes the term rather long, and probably not much more meaningful. Kbrose (talk) 18:53, 30 July 2009 (UTC)
You say it yourself above: "The SI prefixes (kilo, mega,...) are formally defined by SI, nowhere else." However SI defines them to have exclusively a decimal meaning. So whenever the same names and abbreviations are used in a binary sense, they cannot rightfully be described as SI prefixes. −Woodstone (talk) 01:21, 31 July 2009 (UTC)

Softwar using IEC-prefices

Is there a reason, why KDE is not named in the software section? For relevance reasons? In my enviroment it is the most used linux desktop, but my enviroment might be exotic. I did not follow the discussion here, and since i don't want to sabotage any well ballanced compromise, i did not dare simply inserting it. --GlaMax (talk) 09:27, 7 September 2009 (UTC)

Usage_notes incorrect, OR, and uncited..

In the Usage_notes[6] section, we read:

Certain units are always understood as decimal even in computing contexts. For example, hertz (Hz), which is used to measure clock rates of electronic components, and bit/s, used to measure bit rate. So a 1 GHz processor performs 1,000,000,000 clock ticks per second, a 128 kbit/s MP3 stream consumes 128,000 bits (16 kB, 15.625 KiB) per second, and a 1 Mbit/s Internet connection can transfer 1,000,000 bits (125 kB, approx 122 KiB) per second, assuming an 8-bit byte, and no overhead.[7]

But it is not always assumed that the frequency in hertz of bits/second is in decimal. That claim is not true. For example, you've heard of all the RS232 speeds like 2400, 4800, and stuff, but what about 56K? Go look in your RS232 speed settings dialog and just try to set it to 56K -- you will find that there is no such thing as 56k listed, but rather the nearest speed is 57600. You will note that 56.25*1024=57600. Go ahead - go look! Also, see: http://www.urisp.net/urisp_glossary.html Also, go find any modem manual to see that "56K" really means 57600. There is no 56000. The best way would be to find the RS232 specification, but I couldn't in the short time I tried. And probably it wouldn't do any good anyway, considering what happened.

And here's where it gets funny: The other day I had seen the error and added a little note which read:(Note however, that "56K" really means 57600 bit/second, when talking about RS232.[8] 56.25*1024=57600. )

And somebody reverted it saying "It may be true, but a more WP:reliable source is needed."

But look at the source that the Usage_notes section does cite! ([9])

Said source says that a "56K modem" works at a maximum speed of 56,000 bits per second, not 57,344.

Well that's easy enough to disprove - go try setting your RS232 port to 56000. You won't find it. You will find 38400, and you will find 57600, but there is no 56000! Alternatively, download a manual for a modem like this [10] and see that there no 56000 speeds mentioned - but 57600 sure is!

I don't know just how http://www.dewassoc.com/kbase/hard_drives/binary_v_decimal_measurement.htm qualifies as a WP:Reliable source - they are just a seller or manufacturer of computers. They just have a nice faq for folks - but they have an error on it.

Anyway, I know better then to revert a revert so I'll just leave it here.

Somebody else can fix it - if there is another soul alive who cares.

But we gotta realize that with this terrible practice of protecting incorrect information from corrections and deleting correct information we're doing everybody a disservice!

Thanks,

jesse 64.146.180.232 (talk) 04:35, 13 January 2009 (UTC)

Copied from /Archive 13
Your post shows why we don't allow original research (specifically your original research) and in fact shows that whatever the motives of contributors, they were preventing the insertation of incorrect information by you. You appear to be confusing the baud rate of the serial port and the maximum reception speed of modems. The 56 kbit/s modem modem is indeed capable of a maximum reception speed (over a phone line) of 56000 bit/s. In reality it's very difficult impossible to achieve 56000 bit/s in the real word, negotiation speed is almost definitely lower because line conditions. All modems which use a serial or RS232 connection also had a baud rate between the PC and modem, which as far as I'm aware was largely unrelated to the modem reception speed. In fact most modems would just connect at the highest possible rate, usually 115200 bit/s because if compression was enabled you might need it anyway. For example my 28.8k modem (28880 bit/s) connected at 115200 bit/s IIRC (and yes 115200 bit/s was supported by RS-232 long before 56k modems existed). With 56k in fact 115200 was potentially not enough, since the theoretical maximum compression was 4x IIRC with v.42bis. I did have a Diamon v.90 modem supporting 230k but as I never had a serial port supporting that, it was a bit useless. With v.44 of course it gets even worse since that's capable of up to 6x or ~336k theoretically albeit that's unlikely although ITU-T V-Series Recommendations#Error control and data compression mentions 150k is definitely possible. Of course by that time most modems were winmodems anyway so it may have been a moot point. The urisp source was written by someone who has no idea what they're talking about. If you don't believe me, look at the v.90 specs or something, not the RS-232 specs. Nil Einne (talk) 17:24, 19 September 2009 (UTC)

Used for Wikipedia?

Should they be used in Wikipedia articles? Is there a guide line for that somewhere? 124.171.159.237 (talk) 14:16, 18 October 2009 (UTC)

They are not sufficiently familiar to the general reader yet, so they should not be used in Wikipedia articles — unless many sources for the article use these prefixes, etc. However, if the kilo/mega/giga prefixes are used, then it must be clearly specified what meaning is meant. The guideline is at WP:COMPUNITS. Shreevatsa (talk) 14:31, 18 October 2009 (UTC)

Silly Pronunciation

Hi. No-where on this page is the silliness of the pronunciation mentioned. I added a small note about it (with references) but apparently the sources weren't reliable. I'm not sure how to get around this because the statement they were supporting was the fact that 'opponents feel that the pronunciation sounds unprofessional', and the refs were the very people saying that.

Anyway my point is that this is definitely a reason the units aren't really used (other than by open-source and wikipedia zealots). Here are some links I've collected where people (strongly) express this opinion:

[11] "They sound ridiculous." [12] "if you buy a hard drive in the future, it feels like you order it from the Teletubbie-hill" [13] "Unfortunately, these sound bloody stupid." [14] "they have not caught on yet, and sound silly, so I don't think they ever will."

We all know that these people are right, or at least that their opinion is widespread, but what's the best way to get this mentioned in the article? It would be nice if there were a peer-reviewed article on attitudes to binary prefix pronunciation but some facts just don't have nice neat references.TimmmmCam (talk) 15:18, 23 September 2009 (UTC)

Yes, as widespread as the opinion about a ridiculous sounding of bit, byte, floppy or other computer related terms (leaky bucket, data highway, pots, etc). I recon me amongst those people. IEC prefices may sound like gibberish. Which makes them quite suitable for computer sience, in my opinion ;-) But since none of the articles of other computer terms looses one word to silly sounding, I consider this aspect maybe to be to minor to mention it in the article. --GlaMax (talk) 14:55, 19 October 2009 (UTC)
None of those *sound* silly to pronounce (e.g. floppy), they are just mildly amusing uses of existing words. Another thing that distinguishes binary prefixes from your examples is that the silly pronunciation (which your examples don't have anyway) is a factor hindering their use. I don't think anyone ever really resisted 'bit', 'byte', or 'data highway' on the grounds that they sound like childish gibberish. Prove me wrong. TimmmmCam (talk) 16:59, 16 November 2009 (UTC)
For my part, floppy sounds extremely ridiculous; children's talk comparable to gibi. And that's after three decades of getting used to it. At least in academic environment, especially when writing, I refrain from using byte and use octet instead. You'll never see floppy or data highway from me in that environment, too. Thus, there is at least one person who resists using some of them sometimes for that reason. Proof by witness statement ;-) Not much of a proof anyway; that's of course my personal opinion which of course has no relevance to the respective articles and thus is of course not named there. Even if I know that my opinion is shared by most of my direct professional environment. Likewise, your citations are also only a bag of opinions. Don't get me wrong, surely some are prevented from using iec-prefixes due to a silly sounding. No doubt about that. But I am in doubt whether this exceeds the usual amount thus far that it's worth mentioning it. Prove me wrong ;-)--GlaMax (talk) 16:53, 23 November 2009 (UTC)
So do you have any references for people thinking they *sound* silly (i.e. not just that their use is amusing as it is for floppy)? Besides, the key is that pronunciation is a possible reason that mebi, kibi, et al have had trouble with acceptance. Floppy and byte are clearly already the most common terms so it isn't relevant there. TimmmmCam (talk) 17:58, 26 November 2009 (UTC)
Maybe you should simply accept that for me, the use of floppy is not only amusing but the word floppy sounds at least as silly as gibi. I am well aware of the differentiation you intend to make. You are right, floppy, byte and my opinion thereon do not matter here and pronunciation in fact might be a reason that iec-prefices lack acceptance. For mentioning the issue pronunciation in the article, according to wiki standards we need a) an appropriate source confirming that they are considered sounding silly to a relevant extent, and b) relevance of the issue per se. The latter may be given, if there is an impact of pronunciation on acceptance. Don't you think the next step is to find an appropriate source for that impact? A survey or anything better than an opinion? Or to find other (sourced) arguments for relevance? Imho, your citations are mere opinions on pronunciation, being of more importance than my opinion on floppy, but not much. I think, they alone neither suffice a) nor b). And I think we are running in circles. Don't you agree? --GlaMax (talk) 21:10, 1 December 2009 (UTC)
Yeah a survey or poll would be good. I will try to find one, but I suspect none exists. Maybe I should suggest one to slashdot! TimmmmCam (talk) 12:31, 7 December 2009 (UTC)

"Consumer confusion" image caption edits

Kbrose reverted my edit of 30Dec. I was attempting to clarify that in two separate places, Windows, by using the binary and decimal units in a confused way, displayed the capacity of same sized disk drives differently. This was in response to the prior edit removing one of the images, presumably because it was not clear that they were demonstrating this inconsistency. Rwessel (talk) 05:47, 31 December 2009 (UTC)

Oh, I see now, what you were trying to do. That may have worked better, if there were only a single caption for all images. Kbrose (talk) 15:59, 31 December 2009 (UTC)

Recent edits regarding IEC/ISO standards

It is the standards body that gets to say whether it is "proposed" or not; once a standard has been approved or accepted by their rules, if those rules say the then-proper terminology is simply "standard", so be it. In this as in the binary prefixes themselves, per WP:MOSNUM, WP should use the terminology used by the authoritative references in the field. A standards organization is, ipso facto, the authoritative reference for the standards it publishes. ISO's documents do not describe IEC 80000-13:2008 as "proposed," therefore WP should not either. It is true that IEC binary prefixes are not used very much, but that point can be (and is already) made in other places in the article. It is unnecessary and furthermore WP:POV to try to further press this point by misrepresenting the standards' body's position. Jeh (talk) 03:09, 28 January 2010 (UTC)

... hold on, I may have a different wording that will be more suitable. Jeh (talk) 03:12, 28 January 2010 (UTC)
These tirades by refuseniks is really getting very tiring. Even the so loved JEDEC definition clearly states that they only define these because of still common usage, and warn as to the possible confusion, and it accepts their standards status as deprecated, directly below their own definitions, and recommends IEEE documents for the binary prefixes as an alternate. JEDEC, it appears, clearly does not recommend or require the use of SI prefixes in binary interpretation, they only specify that if they are used, they should have a binary meaning in accordance with tradition. Kbrose (talk) 06:27, 28 January 2010 (UTC)
"Refuseniks" - That is enough of the personal attacks, or I will report you. Either make your point logically with valid debate or disengage. The job of an encyclopedia is to teach the real world and not give WP:UNDUE weight to minority points of view. You are also wrong because the JEDEC do not "accept their standards status as deprecated". You are also wrong because IEC prefixes are not recommended by the JEDEC standards documents. The evidence, none of the documents claiming compliance with the JEDEC standards (published by the JEDEC) use IEC prefixes. You're misreading and misrepresenting what is actually in the JEDEC standards documents. Fnagaton 06:37, 28 January 2010 (UTC)
I note that "if you do that again, I will report you" is among the "Arguments to avoid in edit wars" (WP:THREATEN). Jeh (talk) 07:20, 28 January 2010 (UTC)
I'm not edit warring, the other user is making personal attacks.Fnagaton 12:30, 28 January 2010 (UTC)
Kbrose, I agree. JEDEC spends one sentence defining MB as meaning "1,048,575 bytes" and then about ten times that much vertical space on the "Notes" disclaiming and deprecating that definition (complete with a table showing the recommended meanings of the SI and binary prefixes as per ISO 80000-13:2008). As such I feel strongly that simply removing all reference to those "Notes" does not at all reflect what JEDEC wants to say about the matter; in fact, in the context of an article describing binary prefixes, removing all references to JEDEC's "Notes", pretending that they do not exist, seems to me to be grossly misrepresenting the content, meaning, and intent of JEDEC's document, and of real-world support for binary prefixes in general... since JEDEC is, after all, "the leading developer of standards for the solid-state industry." The wording is pretty clear toward "deprecation"; if that was truly a minority view within JEDEC they would likely not have included those Notes at all. Now I think we can cite JEDEC's "Notes", but in the interest of accurately reflecting real world usage, we must also acknowledge the (undeniable) fact that said Notes have so far had just about zero effect on the RAM market, or even on JEDEC's other documents, etc. Well... my edit re "proposed standard" was apparently acceptable to all, so perhaps I can come up with acceptable wording on this point also... but it's a lot more work than the last one and anyway it's time to sleep now. See you all tomorrow. Jeh (talk) 07:20, 28 January 2010 (UTC)
It is only a footnote. It is not "pretending that they do not exist", it is more like not wanting to include minority irrelevant points in an article. This is because it is WP:UNDUE to try to draw so much attention to a footnote. The footnote doesn't mean the JEDEC claims KB is deprecated for example, the footnote clearly says some other party says it is deprecated. This is markedly different to what you claimed above. The JEDEC standard very clearly does not say "Use IEC prefixes", it very clearly mentions them only in a footnote which means IEC prefixes are not part of the standard requirements. If you think that the IEC prefixes footnote is part of the formal standard requirements and therefore relevant enough to be included in this article, which you seem to think it is, then you must prove it by providing links to lots of JEDEC produced standards documents that actually use IEC prefixes and not just mention them in a footnote. If you do not produce that proof then your claim is an unsupported theory and is actually WP:OR to try to apply so much WP:UNDUE weight to it. It is [WP:OR]] to try to claim the what you consider intent for the meaning of the footnote, especially when all the available evidence refutes that claimed intent. i.e. Any claimed intent is WP:OR unless you can provide reliable sources to support that theory. Providing your interpretation on a footnote is not a reliable source. The currently avaialble evidence from reliable sources means the footnote is not relevant to the JEDEC standards. WP:UNDUE means only when you prove that the footnote is significant enough to be included in the article can it be added at all. Basically, prove your claims with evidence from reliable sources. Fnagaton 12:30, 28 January 2010 (UTC)
Please stop throwing around NPOV/OR/UNDUE citations when your aim is clearly to inject your personal opinion only. The situation of the status of the prefix is already pretty clear in most articles and your insistence on even more emphasis is the only POV detectable. The meaning and intent of the JEDEC specification is also very clear, they explicitly state that IEC prefixes are an unambiguous alternative and that they accept the traditional use as deprecated. Any other reading of the text is rather absurd. Why would they even list the binary prefixes in a prominent table, if they reject them. JEDEC intent of defining K/M/G traditionally is to avoid even more confusion if they redefined existing unit symbols that are printed on every memory chip shipped in recent decades. After all they are an industry association in support of marketing and uniform practices for a narrow market segment that is highly depended on very competitive, clearly characterized and differentiated products and creating ambiguity would jeopardize the industry. They clearly endorse the use of the IEC prefixes, however. How this can be misinterpreted is puzzling. JEDEC is not a standards setting body for general purposes in trade, science, and society, as are the IS, ISO, IEEE, NIST, DIN, IUPAC, etc, etc. who ALL endorse the new standards. Reciting JEDEC in every possible context involving binary prefixes constitutes WP:UNDUE and WP:NPOV. Kbrose (talk) 17:28, 28 January 2010 (UTC)
Let it be known that JEDEC states immediately below the numerical specification of Mega the following in a NOTE, i.e. an explanation (not a minor footnote merely pointing out different usage): QUOTE:

The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states "This practice frequently leads to confusion and is deprecated." Further confusion results from the popular use of a "megabyte" consisting of 1 024 000 bytes to define the capacity of the familiar "1.44-MB" diskette. An alternative system is found in Amendment 2 to IEC 60027-2: Letter symbols to be used in electrical technology – Part 2.

The JEDEC specification then explicitly presents a table of the binary prefixes, which can only be interpreted as support of this system, not to reject it.
You are the one diminishing the IEC mentions as a minor footnote, it is not a footnote but an explanation why JEDEC still defines the tradition use. It is clearly an endorsement of IEC prefixes. The JEDEC document explains many of its definitions in NOTES immediately following the statement of definition, not to diminish or subordinate, but to distinguish the definition from explanation. Kbrose (talk) 17:52, 28 January 2010 (UTC)
You are wrong on all points. I am citing policy to help stop undue weight, original research and point of view (yours mistaken assumptions) being added to the article, nothing about my personal thinking at all. Do not write such rubbish personal attacks that misrepresent my argument. You are also wrong to claim the JEDEC supporets IEC prefixes because that is your mistaken personal claim, WP:OR. Prove your claim by providing evidence to support that claim, in this case the evidence would be reliable third parties that explicitly state or demonstrate that the JEDEC are using IEC prefixes in their standards. You have not proven that, therefore your assumption is unsupported. Your claim is also refuted by the vast majority of evidence that shows the opposite. Your assumption is also therefore wrong. Fnagaton 22:38, 28 January 2010 (UTC)
I have to disagree. The JEDEC document clearly states that they're defining the decimal prefixes only because of common usage, and that others, specifically the folks who *are* in charge of the decimal (aka SI) standards (at least in the U.S.), disapprove of the practice. They then describe a *single* alternative scheme, without reservations. This is clearly an endorsement of the binary prefixes (although perhaps not an unqualified one), while acknowledging the existence and usage of the (mis)use of the decimal prefixes. In addition, reverting the entire group of edits is uncalled for. Rwessel (talk) 23:02, 28 January 2010 (UTC)
If it is "an endorsement" then prove that claim by providing evidence to show that the JEDEC use IEC prefixes in their standards. The evidence provided so far shows the JEDEC continue to not use IEC prefixes, therefore the assumption they "endorse" them is unsupported, therefore it is WP:OR and WP:NPOV. If none of you can prove your claims about "endorsement" then you're going to have to accept that your claim is weak and unsupported so it shouldn't be in the article. I'll make this very clear, we do not insert out own personal opinions into articles. Fnagaton 23:40, 28 January 2010 (UTC)
It is very clear that you are the one who is editing personal opinion into the article, as you are the one that has removed (HERE) referenced statements in the JEDEC standard stating their position. Your position is completely unreferenced, while the article correctly identified its statement. Kbrose (talk) 00:51, 29 January 2010 (UTC)
You are wrong and don't try to make this a personal attack by questioning my motives. In the section below I have called upon you to provide valid reliable sources to support your incorrect assumptions. If you cannot provide valid reliable sources then your edits will continue to be WP:OR and can be removed from the article.Fnagaton 01:18, 29 January 2010 (UTC)


  • I think all edits by all interested parties should stop right now and stay at the last version by Jeh [15] as an interim version and discussion should continue on this talk page until consensus can be reached. Fnagaton 00:04, 29 January 2010 (UTC)
    • I protected for 24 hours , in the usual way without concerning myself over whether or not it was the wrong version. Kbrose asked me to take a look, and I chose to act as an admin rather than an editor giving a thrid opinion. DGG ( talk ) 01:02, 29 January 2010 (UTC)
  1. ^ Microsoft (2003-05-06). "Determining Actual Disk Size: Why 1.44 MB Should Be 1.40 MB". Article ID: 121839. Microsoft. Retrieved 2007-07-07. "The 1.44-megabyte (MB) value associated with the 3.5-inch disk format does not represent the actual size or free space of these disks. Although its size has been popularly called 1.44 MB, the correct size is actually 1.40 MB."
  2. ^ Cite error: The named reference Apple 800K was invoked but never defined (see the help page).