The FORMAL chain is as follows. Sound Pressure is in Pascal. Symbol Pa

Take 20 times the base 10 log and you get Sound Pressure level (Para 3.3 in IEC 62672). It is expressed in decibel (dB) and the symbol is L_p.

Now, frequency weight it (A, B, C, D or Z) and you get Sound Level. However, in IEC 61672 to avoid confusion, because it is exponentially integrated we called it "time-weighted sound level" (para 3.8) to differentiate it from the linear integral of time-average sound level. Symbol L_AT(t) but it is usually just called L_eq or L_Aeq(t)

In earlier standards sound pressure level was correctly specified but then some said "usually called sound level"; hence for all practical purposes "sound level" and "sound pressure level" are used interchangeably although strictly speaking they are different.

The chain for the linear integral is:-

Sound pressure in Pascal

sound exposure, the time integral of the time-varying square of frequency-weighted sound pressure in Pascal-squared-time. Symbol E_A, units either Pa²hr or Pa²hr (para 3.12)

time-average sound level20 times the base 10 log integrated over the whole period. (para 3.11)

The main confusion people have with the linear integral is they think of it as a re-integration of the exponential integration of sound level - as given by the dc output of a sound level meter - and therefore ascribe a time constant to it; indeed some German laws even say "Fast Leq" or "Slow Leq". This is simply a mis-understanding of the maths - or "math" as Americans quaintly say.

All these are scalar quantities with the 'dimension' of pressure, but Sound Intensity is a vector quantity. (It has direction as well.)

24malbec09 (talk) 11:24, 12 March 2008 (UTC)[reply]

Hello 24malbec09, thanks for the note.

I agree, and would summarise as: Sound level (SL) and sound pressure level (SPL) are different quantities that are sometimes (incorrectly) used synonymously. My feeling is that the difference between SL and SPL should be explained in the article. Thunderbird2 (talk) 15:19, 12 March 2008 (UTC)[reply]

How did you get 218dB from 80kPa in the Pistol Shrimp article? The ratio 80kPa/1uPa is 180.6 dB on my calculator. Even adding 6dB to turn it into a peak value (which itself also baffles me) still does not get it over 200dB. —Preceding unsigned comment added by Spinningspark (talk • contribs) 16:23, 4 October 2007 (UTC)[reply]

Whoops! Sorry! just realised which wrong button I pressed my calculator which is clearly far more intelligent than me!Spinningspark 16:32, 4 October 2007 (UTC)[reply]

No worries. I had typed this reply anyway, so I include it here for the benefit of anyone else who happens to come along with the same question :)

The calculation goes like this: 10 log₁₀ [(80•10³ / 10^-6)²] =~ 218.

I haven't read the article recently, so I'm not sure which 6 dB you're referring to, but it may be a conversion between zero to peak and peak to peak levels. Does that answer your question? Thunderbird2 16:52, 4 October 2007 (UTC)[reply]

The Decibel article has far too much on acoustics - aside from mentioning why a decibel is a useful unit in acoustics, all the discussion there should be in some other article. --Wtshymanski 22:10, 23 March 2007 (UTC)[reply]

Hi! I noticed that you're changing the nm abbreviation for nautical miles to nmi whenever you see it. I asked WP:SHIPS what they thought about it here, but didn't get much of a response. I'd like to ask if you'd be willing to stop making this change, because nm is by far the most common abbreviation for nautical miles. It is essentially impossible to read a range in nautical miles and confuse it for nanometers, because they differ by a dozen orders of magnitude. In addition, I always link my first use of nm to the article for nautical mile and I provide metric conversions following all nautical mile figures. TomTheHand 14:36, 9 August 2007 (UTC)[reply]

Hi Tom. Thanks for your interest, and for pointing out the brief project discussion in the Ship Project. I was wondering when someone would notice. There are a number of reasons why I disagree with you on this.

1. I don't accept that nm is the most common abbreviation. If you tell me it is common in the USA I believe you. But I live and work in Europe and it is not common here, or at least not in my field of work (sonar).

2. While it may be difficult to confuse a nautical mile with a nanometre, that does not make it impossible. Just the very fact of using the same symbol for two different units is by its nature confusing. I once witnessed a demonstration of radar software that showed detection ranges in units of "nm" and asked (tongue firmly in cheek!) why it was the ranges were so short :-) The response came back straight away "Oh, that's a typo. The nm should read km". To this day I am unsure whether his screen was actually in miles or kilometres. And perhaps the demonstrator is as well.

3. I'm sure you're aware that the nautical mile is accepted for use alongside the SI system, and also that there is no internationally accepted abbreviation for the nautical mile. I believe that one day a symbol will be chosen, and when this day comes, I am certain that symbol will not be nm, because that would never be accepted by SI.

So, where does that leave us? My suggestion is that we both temporarily refrain from changes in either direction and try to find a rational solution to our difference. I know WP is keen on consensus, and you have tried that path already, with little success. Personally I prefer to find a solution that you and I are both comfortable with, as no one else seems to even care. Can we agree on that? Thunderbird2 15:24, 9 August 2007 (UTC)[reply]

I hope you don't mind, I'd like to continue to discuss this on the talk page for WP:SHIPS so we can seek a wider consensus. Please see here. TomTheHand 18:07, 9 August 2007 (UTC)[reply]

I noticed that you wikilinked the unit "nautical miles" in the article on Fisheries Management? Not implying any criticism, what was your reason for doing so? Some sort of emphasis? Howard C. Berkowitz 22:20, 12 September 2007 (UTC)[reply]

No, not for emphasis. My intention was to make it easy for someone reading the article to look up the definition if they want to know how the nautical mile compares with a statute mile or whatever. Do you prefer not to have such links? Thunderbird2 22:25, 12 September 2007 (UTC)[reply]

I'd rather not, because I think it draws visual attention away from the number. When, for example, I need to look up the relationship of the Becquerel, Gray, and rem, I look them up with a few keystrokes. Perhaps I am getting oversensitive ahout the metric versus customary unit matter, but I am getting of the opinion that the units are getting more emphasis than the values. It's certainly nothing you have done, but I've gotten the sense that when I write something in a nautical knowlege domain, where, for example, knots and nautical miles are customary in UN documents, an editor will quickly swoop in to supply a conversion. There are many knowledge domains where customary notation is not easily accessible to a nonspecialist, such as the use of Greek letters in much of physics. When I write software involving such variables, I give them mnemonic names, but I don't see a widespread controversy over special symbols. The controversy seems to overemphasize units, ironically since metric usage still often can't decide on mass vs. moles (chemistry), CGS vs. MKS (physics), etc. Howard C. Berkowitz 23:56, 12 September 2007 (UTC)[reply]

I agree it would be inappropriate to convert to a metric unit in an article like this one. If a reader wishes to learn about matters nautical, they will need to understand the nautical mile. So, why not make it easy for them? I suppose it is a balance between improving the flow of the article (few hot links) and minimising the number of key strokes required to access definitions (many hot links). For me one more link doesn't detract from readability, but this is subjective, and I don't feel strongly about it either way. Please feel free to change it back the way it was. You will notice from the discussion above your comment that I *do* feel strongly about avoiding the use of "nm" as an abbreviation for the nautical mile. If you are interested in contributing to that debate you may wish to take a look on the SHIPS talk page. Thunderbird2 06:17, 13 September 2007 (UTC)[reply]

Thunderbird, I see that the aviation discussion seems to indicate that "NM" is the best abbreviation for nautical miles with aviation. I have no problem with using this abbreviation for ships as well; should we start using it across the board or do you think that'll need further discussion? TomTheHand 17:21, 24 September 2007 (UTC)[reply]

Thanks for the note on my talk page, I changed the references from nmi to nm as in all the reference books in aviation then NM (or nm) is the accepted term. I have official RAF and UK CAA documents that use NM sometimes nm so the compromise of using NM is probably supportable. Didnt mean to disrupt your good work but nmi just didnt look right. MilborneOne 17:28, 24 September 2007 (UTC)[reply]

Consistency is an important consideration, which is why I've been happy to accept NM (as opposed to nm) as a compromise all along. If the ICAO guidelines do indeed recommend use of NM (remember all that we have so far is an Australian memo referring to the guidelines - not the guidelines themselves), then it makes sense for the aviation articles to follow that. Given the apparent dearth of clear *international* guidelines on maritime matters, I see no good reason for not adopting NM for SHIPS also. My main objective from the beginning was to avoid the clash with the nanometre. Lightmouse said he was going to move the B2 Spirit discussion to the MOS page though. If he does that we will undoubtably get some new opinions. In the meantime I will start using NM for ships and aircraft. Happy editing :) Thunderbird2 17:48, 24 September 2007 (UTC)[reply]

Sorry, thought I read somewhere that they weren't needed. my bad. I won't object to them being put back in. — BQZip01 — ^talk 21:21, 22 September 2007 (UTC)[reply]

OK, thanks. I try not to add too much clutter by linking only on first use :-) Thunderbird2 21:41, 22 September 2007 (UTC)[reply]

Hi,

I see that you are making the symbolic form 'N m'. The Wikipedia style guide says "It is abbreviated Nm or N·m". Is there a particular reason for the format that you are using? Regards Lightmouse 20:11, 28 September 2007 (UTC)[reply]

Hello Lightmouse. My reasoning for these changes is that Nm is not permitted by SI, so when I see it I change it to N m. I have no objection to N·m as this is also accepted by SI, except that I don't know how to make the dot (except using copy-paste). Perhaps the style guide should be changed to state a preference for N·m though (over Nm). Thunderbird2 20:23, 28 September 2007 (UTC)[reply]

The SI authority (the BIPM) states that 'Nm' is permitted. The relevant section is:

• "5.3.6 Multiplying or dividing quantity symbols, the values of quantities, or numbers"].

In any debates about SI, it is always worth going to the official website. The 'N m' option is also permitted but I was just curious as to the changes from one valid option to another. Regards. Lightmouse 10:36, 29 September 2007 (UTC)[reply]

I see what you mean. But now I'm confused. If I use those rules, how am I supposed to know whether ms means metre·second or millisecond? I usually use NIST guidelines (NIST Special Publication 811, Taylor 1995). I will check to see what they say. Thunderbird2 10:51, 29 September 2007 (UTC)[reply]

I just checked SP811. On p12 it says "Symbols for units formed from other units by multiplication are indicated by means of either ... dot or a space" and then "m·s^(-1) is the symbol for the meter per second while ms^(-1) is the symbol for the reciprocal millisecond". I have to say I am surprised to see this inconsistency between BIPM and NIST, but the NIST advice seems more sensible to me. Thunderbird2 11:01, 29 September 2007 (UTC)[reply]

I found an earlier version (7th edition, 1998) of that BIPM document that uses the Newton metre as an example to illustrate the SI multiplication rules. It gives N m and N·m as allowed options, but not Nm. That explains the inconsistency I guess, because NIST are still following the old rules. Frankly, I think BIPM have scored an own goal; I cannot see their new rules lasting very long, because of all the ambiguities they introduce. Thunderbird2 11:16, 29 September 2007 (UTC)[reply]

I've been reading through the 2006 BIPM document again. I think we are both been misinterpreting it. Got to go now. More to follow later ... Thunderbird2 12:13, 29 September 2007 (UTC)[reply]

Back again. This is how I see it: The relevant part to our discussion is on p130 (Sec 5.1, Unit Symbols) which says "Multiplication must be indicated by a space or a half-high (centred)dot (⋅),since otherwise some prefixes could be misinterpreted as a unit symbol." That means that N m and N·m are both permitted but Nm is not. The confusion arises because the letters a, b and c in Sec 5.3.6 do not represent units (eg N or m) but physical quantities (force or distance). Thunderbird2 13:38, 29 September 2007 (UTC)[reply]

Very interesting and excellent research. For SI, I always go direct to BIPM. I use NIST only for American units and their proposal to amend the FPLA for "Permissible Metric-Only Labeling" at http://ts.nist.gov/WeightsAndMeasures/Metric/mpo_home.cfm.

I was not aware of the ambiguity in 'ms' but you are right. I think you have persuaded me. Thank you for pointing it out and explaining it to me.

Incidentally, have you considered using my unit formatting script at User:Lightmouse/monobook.js. All you have to do is copy the source text to User:Thunderbird2/monobook.js, clear your cache (press ctrl-shift-R in Firefox). Whenever you are editing a page, you will only need to press the 'combined' tab at the top. Lightmouse 09:03, 5 October 2007 (UTC)[reply]

Hey Thunderbird! Just wanted to make you aware that in your recent edit to Trumpetfish, you linked some extra occurrences of "ft" and "in" in the infobox, even though the first use of each unit was already linked. I'm pointing it out because if you're doing this with a script or regular expression, it may have a couple of bugs in it. Have a good day! TomTheHand 20:07, 12 October 2007 (UTC)[reply]

Hi Tom, Thanks for the note. Actually that was a manual change. I just didn't notice the first links :) I'll go back and fix it.

By the way, I was surprised at the relative lack of interest after Lightmouse moved the nm vs NM vs nmi discussion to MOSNUM. It seems to have reached the same impasse as before at SHIPS. It's a pity because it would help if we could adopt a convention that we can all agree on. Thunderbird2 20:34, 12 October 2007 (UTC)[reply]

Finally I found the time to do a complete rewrite of the article on bioacoustics. Please check it and let me know what you think. Thanks, --Yerpo 10:46, 19 October 2007 (UTC)[reply]

That's a huge improvement on what was there before you started. I've made some minor edits, and may return for some more, but it looks good. One thing I did notice that needs attention is your use of the term "underwater microphone". This term is never used in underwater acoustics - instead it's called a hydrophone. Thanks for your efforts. Thunderbird2 18:25, 19 October 2007 (UTC)[reply]

Ah, of course. I'm not that familiar with this use of bioacoustics, as I already said. Will fix. --Yerpo 06:09, 20 October 2007 (UTC)[reply]

Hello, here you wrote "Good point, but the bit especially has other uses too (eg communications). How about "a unit of information used, for example, to quantify ..."

Why not stick to the common wording "is a unit of information or computer storage"? It is used on almost all pages like Megabyte and so on. The ", for example," looks unnecessarily eloquent for a disambiguation page and "to quantify" unnecessarily strays from the common wording. On the other hand, if you think "to quantify" is a worthful addition, it would probably be best to add this to the other pages as well. Then concerning "other uses", I disagree, because "information or computer storage" should cover all cases. If you transfer some data in "communications" what you transfer is "information". Or could you explicitly give some example not covered by this definition? --217.237.151.53 07:06, 6 November 2007 (UTC)[reply]

The objective of the change I made was to move the debate about the prefixes away from the disambiguation pages and on to the articles themselves. For that reason the wording was carefully chosen to be innocuous. I agree that "a unit of information or computer storage" is more concise and I can’t think of any example not covered buy it. In fact, the bare “a unit of information” also covers everything, but I am not sure if it will be considered uncontroversial by others. If you make a suggestion along these lines on wp:mosnum I will not object. Thunderbird2 07:26, 6 November 2007 (UTC)[reply]

Please remember that it is possible to take offence at edit summaries, too.

The sentence was grammatical, intelligible, and informative. It was just not to your taste. It's ok that it isn't to your taste and it's fine that you've simplified it. I just was not keen on the edit summary.

Fiddle Faddle (talk) 20:08, 25 November 2007 (UTC)[reply]

The terse style of edit summaries can sometimes lead to misunderstandings. Looking at my edit again, I think my main objection to your choice of words is that while a knot is a unit of speed, knots is not. Could I have phrased the edit summary more carefully? Undoubtably, but my words were directed at the sentence, not at its author. No offence was intended :-) Thunderbird2 (talk) 20:51, 25 November 2007 (UTC)[reply]

I knew there was not an intent to offend. Interestingly, unlike the SI scheme where the plural is not present, "knots" does really seem to be the unit, with the singular only being used for the unlikey single knot, or perhaps the "unitary knot". Fiddle Faddle (talk) 22:55, 25 November 2007 (UTC)[reply]

Hi. I saw your recent edit to Fujitsu Eagle. Good work! May I make a suggestion, however? If you put something like "tidy up per WP:UNITS" in the edit summary, that gives other editors a direct link to where the correct style is documented. -- RoySmith (talk) 19:51, 27 November 2007 (UTC)[reply]

Thanks for the suggestion. I agree it would make it easier to understand the justification for the change. I'll try to follow it. Thunderbird2 (talk) 19:59, 27 November 2007 (UTC)[reply]

Hello! I'd like to invite you to take a look at WP:ALSO, a section in the Wikipedia Manual of Style which describes how "see also" sections are generally used. Since the purpose of these sections is to provide a place for relevant wikilinks that aren't yet included in the article, with the eventual intent being to integrate those links into the article and remove the "see also" section entirely once that's done, I've removed a number of redundant links from the articles megabit and gigabyte. If you wish to discuss these changes, I'd be happy to do so. --Dachannien^Talk_Contrib 11:31, 7 December 2007 (UTC)[reply]

I have followed your suggestion to look at WP:ALSO. Though I have not read it thoroughly, the presence in it of a "See also" section suggests to me that its authors have not thought through the implications of their own guideline. In what sense does the removal of (eg) bit from the "See also" of megabit improve the megabit article? Thunderbird2 13:29, 7 December 2007 (UTC)[reply]

Thanks for your response. A person reading no more than the introduction to the article would have already come across the wikilinked term "bit" and could have clicked on it if they were interested. Including a wikilink in the "see also" section merely clutters that section up, making it more difficult for users to pick out the terms that are both (a) related to the topic at hand and (b) didn't already appear elsewhere in the article. If "see also" were intended to be a handy summary of all the wikilinks in an article, it would have been made an automatic function of MediaWiki long ago. Hope this makes sense. --Dachannien^Talk_Contrib 17:02, 7 December 2007 (UTC)[reply]

If "See also" were used as a "handy summary of all the wikilinks in an article", I would agree with you. In megabit it is not used in that way, but as a summary of most directly related to the gigabit article (bit, megabyte, mebibit). Collecting the important ones in one place helps the reader by saying Reading these particular articles will help you understand the concept of a megabit. Thunderbird2 (talk) 10:41, 8 December 2007 (UTC)[reply]

Not really. If a reader begins reading the article and comes across a concept or word he or she doesn't understand, then that word will already be wikilinked within the article, and they can click on it then. If it's unclear from the context of the article that a particular concept is important as background to understanding the topic at hand, then the article should be revised to make that context clearer. In other words, repeating the links at the end of the article isn't particularly useful, because someone unfamiliar with the concepts of a topic don't skip to the appendix material first - they read the article from the beginning. --Dachannien^Talk_Contrib 14:33, 8 December 2007 (UTC)[reply]

It seems we disagree then. I have moved the discussion to megabit to seek consensus there. Thunderbird2 (talk) 14:45, 8 December 2007 (UTC)[reply]

Thanks for your comment, Thunderbird, which hit the nail on the head so squarely. I think Alvulus, and possibly another of the antagonists, had a hand in pushing for the system to be developed back years ago. It really hasn't turned out well, with several major disadvantages that make the compulsion to use it rather inappropriate. Yes, I'm proposing that it merely be optional, supported by rules in the manner of our guidelines for ENGVAR at MOS. Here's the proposal that shouldn't really be causing so much useless discussion. Tony (talk) 15:18, 16 December 2007 (UTC)[reply]

Thanks for the link Tony. You and I don't always agree (and why should we?), but your proposal is carefully considered and well written. I can understand that some may suggest minor changes (though none spring to mind), but the outright opposition it has encountered is puzzling. I wish you luck. Thunderbird2 (talk) 19:28, 16 December 2007 (UTC)[reply]

Aha! I wonder whether he's responding to the activity at MOSNUM. Tony (talk) 00:53, 19 December 2007 (UTC)[reply]

T

Begin forwarded message:

From: bugzilla-daemon@mail.wikimedia.org Date: 18 December 2007 1:27:27 PM To: tony1@iinet.net.au Subject: [Bug 4582] Use date format preference on unlinked dates

http://bugzilla.wikimedia.org/show_bug.cgi?id=4582

Brion Vibber <brion@wikimedia.org> changed:

          What    |Removed                     |Added

---

            Status|RESOLVED                    |REOPENED
        Resolution|WONTFIX                     |

--- Comment #73 from Brion Vibber <brion@wikimedia.org> 2007-12-18 02:27:25 UTC --- Let's keep it open for now and see what happens...

I hope I have a solution to formatting numbers you approve of. Please see this update, as well as the post immediately preceding that one. Greg L (my talk) 01:01, 20 December 2007 (UTC)[reply]

Thanks for the heads-up. I'll read through all the new stuff and make my views known. By the way, in case you're interested in the history, there was almost unanimous agreement a couple of months ago to include a "no spaces to the right" rule. (See original edit and subsequent discussion). I opposed it though, and my views were respected - I think the others got tired of arguing with me and moved on to other things. In a nutshell that's why there's no explicit advice now. Anyway, now the proposal is the opposite one and I expect it to get a tough (but fair) ride. Thunderbird2 (talk) 08:11, 20 December 2007 (UTC)[reply]

Thunderbird2, Jimp and I went off on our own in an effort to resolve our differences and try to actually accomplish something productive. Please read my initial post to Jimp here, and then read what’s going on over on my talk page here. It’s a lot less frustrating of a forum than what’s going on over on Grouping of digits: New specific proposal using {{formatnum}}. At a certain point, in discussion forums, reaching any sort of consensus becomes highly unlikely and believe my proposal will not fare well there. I’ve chalked up the latest goings-on there as just another bug-splat on your windshield of life. I hope you join us on my talk page. Greg L (my talk) 18:36, 28 December 2007 (UTC)[reply]

Removal of KiB for disambiguation was discussed.

The argument goes something like this:

• KB is "ambiguous". Why? Because manufacturers sometimes use it is the decimal sense.
• The letters "KiB" can be used by manufacturers in the decimal sense in exactly the same way as KB has been. Therefore KiB is also ambiguous.
• KiB is claimed to be not ambiguous because it is defined by a "standards organisation".
• KB is defined by the JEDEC (a standards organisation) in the binary sense and therefore not ambiguous.

Conclusion: The only completely non-ambiguous disambiguation is expressing the exact number of bytes. Fnagaton 12:25, 26 January 2008 (UTC)[reply]

I can't find the precise text to which you refer, but if you tell me it was discussed I believe you. However, what I meant by "discussed" in my edit summary was "discussed and agreed". You can expect changes to the KB vs KiB text to be controversial, so I think the precise wording should be discussed first at WT:MOSNUM. Thunderbird2 (talk) 12:34, 26 January 2008 (UTC)[reply]

The point being why disambiguate with a unit like KiB or MiB which can be ambiguous. Which is why the discussion then got around to expressing the numbers of bytes in base two or base ten. Fnagaton 11:33, 27 January 2008 (UTC)[reply]

We both agree that disambiguation using explicit decimal or binary powers is a good thing. Where we differ is whether disambiguation using explicit binary definitions is equally good (my opinion) or not (your opinion). Thunderbird2 (talk) 11:38, 27 January 2008 (UTC)[reply]

Then why do you want to disambiguate using units which can be ambiguous? Fnagaton 11:46, 27 January 2008 (UTC)[reply]

I don't accept that the kibibyte is ambiguous. Thunderbird2 (talk) 12:20, 27 January 2008 (UTC)[reply]

Why? Fnagaton 12:25, 27 January 2008 (UTC)[reply]

Because I am aware of only one definition. Thunderbird2 (talk) 12:56, 27 January 2008 (UTC)[reply]

Definition where? Fnagaton 13:12, 27 January 2008 (UTC)[reply]

The definition introduced by the IEC (standard 60027-2, third edition, p121) and adopted by IEEE (Std. 260.1-2004, p12). Thunderbird2 (talk) 13:24, 27 January 2008 (UTC)[reply]

So just because it's defined by your preferred "standards organisation" it isn't in your view ambiguous? Fnagaton 13:26, 27 January 2008 (UTC)[reply]

I don’t understand your point. All I am saying that a kibibyte is defined as 1,024 bytes, because I have never seen it defined any other way. It is you who are claiming the ambiguity, so the onus is on you to show there is a second definition. Thunderbird2 (talk) 14:07, 27 January 2008 (UTC)[reply]

I showed the potential for ambiguity above "The letters "KiB" can be used by manufacturers...". The JEDEC defines kilo as 1024 so because it is defined by a standards organisation it is not ambiguous, as you put it. So either you have to accept that KiB has the potential to be ambiguous or you have to accept that kilobyte is not ambiguous. If you accept the former then then you cannot use it for disambiguation. If you accept the latter then kilobyte does not need disambiguation. Fnagaton 14:13, 27 January 2008 (UTC)[reply]

By that logic, the metre is an ambiguous unit because someone somewhere might use the word to mean yard. In other words, it's not sufficient to claim that it might happen - you need to show that it does happen. Thunderbird2 (talk) 14:31, 27 January 2008 (UTC)[reply]

That's not the same as what I'm saying because the metre is defined by a standard and is mostly correctly used by the vast majority. If the real world consensus for using kibibyte was of a similar strength to that using metre then your point would be valid, but it's not. Kibibyte (or KiB) being used in the decimal sense does happen in the real world just because you have not seen it happen does not mean it doesn't happen and also kibibyte is used by less than 1% of the real world. So actually real world consensus is against using kibibyte and because it can be incorrectly used you therefore have to accept that it is ambiguous. Fnagaton 14:52, 27 January 2008 (UTC)[reply]

Your argument seems to read: “The kibibyte is not in widespread use. Therefore it is ambiguous.” That simply doesn’t follow. It is you who claims the kibibyte is ambiguous. The onus is on you to prove it. Frequency of use is irrelevant.

I guess it would be different if you were talking about the potential to acquire ambiguity. If, by widespread incorrect use of the term, it eventually becomes ambiguous (as happened with the calorie), then I will agree with you. Not before. Thunderbird2 (talk) 16:46, 27 January 2008 (UTC)[reply]

No you are incorrect because my argument does not read “The kibibyte is not in widespread use. Therefore it is ambiguous.”. My argument is as I've already said that in the real world KiB/MiB/GiB is used in the decimal sense, for example media that has been incorrectly labeled to use the neologisms without updating the actual numbers, and they are not commonly used prefixes. It is you who claimed you've not seen the other use but you cannot then claim that means it doesn't exist when it actually does exist. The "widespread incorrect use of the term" is fallacious because you know full well that the IEC prefixes are not in widespread use to begin with. Are you seriously trying to tell me you've never seen even one place where an IEC prefix is equated with a decimal base ten value? Fnagaton 18:34, 27 January 2008 (UTC)[reply]

Yes, I am. Does that surprise you? Use of the kibibyte and its cousins is rare, and when they are used it is usually by a specialist who has made a deliberate choice to avoid ambiguity. That combination is likely to make incorrect use very rare indeed. Your point will become more valid once (if?) these units are used by non-specialists. Time will tell. Thunderbird2 (talk) 18:52, 28 January 2008 (UTC)[reply]

Even specialists make mistakes. Note the bit which says "1 KiB = 1000 bytes and 1 MiB = 1000000 bytes". ;) Fnagaton 20:13, 28 January 2008 (UTC)[reply]

Amusing link (lol). Now I must reply "I have seen one example" but it doesn't alter my view that such incorrect usage is rare. Thunderbird2 (talk) 06:43, 29 January 2008 (UTC)[reply]

Excerpt from the linked mail: "The MiB (and its derivatives) was invented by hard drive manufacturers in a very lame attempt to make their drives capacity look bigger,". This guy is confused and it's easy to prove him wrong. It's not surprising though that people with that kind of fanatic view would sabotage or boycott it - even subconsciously. People are rarely good at things they hate. Fail causes hate and hate causes fail. It's a vicious cycle. --217.87.122.179 (talk) 21:28, 2 February 2008 (UTC)[reply]

Yes he is certainly confused, and was also soon corrected [1]. Still, we all make mistakes - and hopefully he learnt from his. Thunderbird2 (talk) 21:46, 2 February 2008 (UTC)[reply]

1 start bit + 8 data bits + 1 stop bit == 10 bits per byte.

Thus a 56 kbit/second modem == 56000/10 bit per byte == 5600 bytes per second (after the start and stop bits are stripped). ---- Theaveng (talk) 18:00, 28 January 2008 (UTC)[reply]

Hi Theaveng. Thanks for taking the trouble to explain this. I see you've also included a footnote in the article. I've learnt something today :) Thunderbird2 (talk) 18:47, 28 January 2008 (UTC)[reply]

I wanted to give you a heads up that I’ve transplanted the most important parts from my talk page to here at Talk:MOSNUM. Hope to see you there. Greg L (my talk) 20:07, 29 January 2008 (UTC)[reply]

T-bird, it looks like the voting at Talk:MOSNUM is going well enough that it’s logical to wonder how one actually implements the basic desire. It appears from Jimp’s posts that numeric values with more than 12 digits (rare but possible) won’t work with a template. Also, he appears to be expert only in templates and it appears that {delimitnum} will require a parser function (magic word). Those are apparently written by “developers” (the programmers who make Wikipedia’s magic all possible). Do you know how we go forward? Is there someone at MOSNUM who tends to such matters and sees to it that “developer issues” are kicked up the ladder and addressed? Greg L (my talk) 22:05, 13 February 2008 (UTC)[reply]

Hi Greg. Yes, you've done a fine job and the consensus has shifted in your favour. Persuading Tony is especially valuable because I think he knows how to contact the developers. If I were you I would ask him. Thunderbird2 (talk) 22:15, 13 February 2008 (UTC)[reply]

Will do. Thanks. Greg L (my talk) 22:52, 13 February 2008 (UTC)[reply]

• T-bird, I contacted Random832 yesterday (request here). Things have rapidly progressed since that posting. Within eight hours, he had written up the Talk:MOSNUM {{delimitnum}} proposal and presented it to a developer via bugzilla:13025. My question to you is whether and when and how to notify the others that further debate is not required and the proposal is moving forward to development. Would it be premature to post such a notice now? Things seem to be going smoothly so I don’t see the point of kicking a sleeping dragon. I’m not a regular contributor to MOSNUM and don’t know 1) what is expected of me (or someone else?) under these circumstances, and 2) what is the wise thing to do at this juncture. P.S. I do know that the proposal’s current (unarchived) location is being used as a reference source during the developer’s efforts. So if the proposal is marked as “resolved,” it would be helpful if it wasn’t archived until the developer is finished. Greg L (my talk) 06:11, 16 February 2008 (UTC)[reply]

• I also asked Random832 this same question. Greg L (my talk) 05:09, 16 February 2008 (UTC)[reply]

• Awe… never mind. Random832 answered my question first and said ‘do it.’ So I posted the notice of going to development here. It ain’t over ’till it’s over though. I’m curious as to how long it takes for these things (parser functions) to be made. Greg L (my talk) 06:11, 16 February 2008 (UTC)[reply]

• • Good luck with the parser development. And thanks for keeping me posted. Thunderbird2 (talk) 07:29, 16 February 2008 (UTC)[reply]

I just wanted to make you aware that I made a post here on Talk:MOSNUM regarding the new {{delimitnum}} template. See you there. Greg L (my talk) 22:07, 14 March 2008 (UTC)[reply]

Sorry T-bird. If I had read the goings-on better at Talk:DEC 3000 AXP and understood your position on the matter before I started typing, I would have just stayed out of the fray. I figured out your position after I had a head of steam going on my typing and so went ahead anyway. I hope you understand (why I posted anyway, as well as my position on that matter). Cheers. Greg L (my talk) 22:37, 16 March 2008 (UTC)[reply]

Hey, no worries - you're entitled to your opinion and anyway I agree with what you wrote. In other words I see no conflict between the choice of the most appropriate nomenclature (say KB, MB, GB) and the need to define that nomenclature. I will be happy with any outcome that permits an unambiguous definition of these terms, on that or any other page. What did annoy me though was Fnagaton's exploitation of your comment as if it supports his case. I've just been reading his beloved JEDEC standard and it makes interesting reading. Keep a watch on Binary prefix for details :D Thunderbird2 (talk) 22:49, 16 March 2008 (UTC)[reply]

It is against Wikipedia policy to use your talk page to misrepresent another editor. The fact is that the units you prefer do not have consensus for use, so do not keep on pushing for them to be used. If you are really interested in reducing what you think is ambiguity rather than pushing for certain units to be used then disambiguate using the exact number of bytes with power notation, like it says in MOSNUM. By the way, Greg's comment does support my case because it is basically the same as my position on this topic, i.e. use the most appropriate nomenclature which is to be found in real world sources relevant to the topic. Fnagaton 08:04, 17 March 2008 (UTC)[reply]

• I think Fnagaton might have demanded for a retraction because I lead him to an erroneous conclusion by stating “No one like’s to have another editor wade in and change someone’s work without so much as a “hello” on a talk page.” I didn’t immediately realize the distinction between “no consensus" and “no discussion.” No worries then. I’m looking forward to a solution that makes sense and that everyone can abide by and feel comfortable with. Greg L (my talk) 00:25, 20 March 2008 (UTC)[reply]

• Oh, I see now. I didn't understand what you meant by it at the time, but it seemed that you were trying to help, so I just moved on. Don't let it bother you. If the debate gets too hot we always have the "real world" to escape to. That's the beauty of Wikipedia :D Thunderbird2 (talk) 07:26, 20 March 2008 (UTC)[reply]

T-Bird, is this what you were hoping to see? Greg L (talk) 00:53, 20 April 2008 (UTC)[reply]

Yes, I like that. See you there. Thunderbird2 (talk) 05:40, 20 April 2008 (UTC)[reply]

• Woo-hoo! Greg L (talk) 06:02, 20 April 2008 (UTC)[reply]

Hi Thunderbird2,

I just wanted to ask whether you'd be willing to put the second survey on hold for a few days (temporarily deleting if you think appropriate)? My instincts are telling me that there's a chance that some approximation of a consensus might develop, if given the chance, but I don't think it can if we try to move on too quickly. My rationale isn't particularly compelling, I must admit, but it never hurts to ask! Jakew (talk) 20:03, 21 April 2008 (UTC)[reply]

Hello. I've done what you asked. I'm curious how you think it might help though. Still, I'm happy to wait & see. Thunderbird2 (talk) 20:14, 21 April 2008 (UTC)[reply]

Oh dear. It's taken a life of it's own now. (Take a look at the edit history). I don't think there's any harm done - the questions were intended to explore for compromise. Shall we just watch how it develops? Thunderbird2 (talk) 20:30, 21 April 2008 (UTC)[reply]

Ah well, such is the wonderful world of Wikipedia. I agree: no real harm done. Jakew (talk) 20:38, 21 April 2008 (UTC)[reply]

Please keep an eye on Bondwell. As the edit history proves, the original authors used KiB until User:Fnagaton converted them to KB. I reverted his edit and fixed the wrong case of the 'k'. Fnagaton promptly reverted my edits with his usual "rvv". This was clearly not vandalism. I would have talked to him directly but his talk page is semi-protected which makes a lot of sense because he would have removed my comment claiming either vandalism or harassment. --217.87.83.146 (talk) 21:52, 24 April 2008 (UTC)[reply]

You are wrong, I am not the one who is edit warring, you are. I reverted your change and have issued you with a 3RR warning for your four edit warring reverts and I've given you a chance to show you respect the rules by allowing you the chance to undo your edit. My talk page is semi-protected because an anonymous IP user from your ISP who has a habit of editing on the topic of binary prefixes vandalised my talk page multiple times in the past. [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] etc. Fnagaton 22:58, 24 April 2008 (UTC)[reply]

Fnagaton, just apologize kindly and I'll ignore your behaviour this time. --217.87.83.146 (talk) 23:25, 24 April 2008 (UTC)[reply]

The user 217.87.83.146 has been blocked from editing for a period of 31 hours. It's clear who has been revert warring here. Fnagaton 00:52, 25 April 2008 (UTC)[reply]

T-bird, here is the first version you supported, right after I had revised it to address your concerns and you had made a few tweaks of your own. Please compare that to the current version. I don’t see much difference of any significance in the portion that directy addresses the IEC prefixes. What is it you would like to see changed to meet your approval? As I was proofing this post, I just now noticed the above posts. Is that horseshit what is driving you crazy at the moment? Greg L (talk) 01:42, 26 April 2008 (UTC)[reply]

Greg, thanks for taking the trouble to drop by. The differences may all be subtle ones. I’m not sure because I find it hard to keep track of the latest version. The point about the uno is that by putting it alongside the IEC prefix you are tarring both with the same brush. In other words, the wording (last time I checked) gives the impression that the MiB is an equally pointless unit. To gain my support you need to make clear that the MiB *does* have a valuable role to play. I will be more specific about other concerns next time I visit MOSNUM.

The discussion on my Talk page does not bother me at all - if anything it amuses me that it attracts so much interest :-) Rather, my concern at MOSNUM is (mainly) about the frequency with which changes are made to the main page. I support the principle of WP:BRD, but for it to work you need to give consensus a chance during the R and D parts. It is the frequency of changes that are making this difficult. Like I said, it’s not my opinion that matters, but the consensus of a group. It’s not just about the green box either. The frequency of the changes makes it difficult for editors to monitor changes to the parts they are interested in. Picking out the one edit that interests them is like looking for a needle in a haystack.

You did a good job at Mac Pro, and I admire the effort and energy you put into your writing. There are times when the energy turns into passion. I guess you see it as the natural cut and thrust of lively debating, but not everyone sees it that way: the passion comes across sometimes as confrontation. On at least one occasion you have Jimp's subtle diplomacy to thank for avoiding an escalation.

Finally the size of the discussion thread at Talk can sometimes be a practical problem. I sometimes can’t load the page at all (which explains some of my quieter periods), and sometimes I can’t find the part that I want to edit because it’s too deeply hidden. There is a bot that is supposed to keep things neat and tidy by archiving threads older than 15 days, but if a single thread keeps growing and growing, the bot cannot accomplish its objective.

I hope this helps. Thunderbird2 (talk) 12:28, 26 April 2008 (UTC)[reply]