User talk:Quilbert

Welcome to Wikipedia

Hello, Quilbert, and welcome to Wikipedia! Wikipedia is one of the world's fastest growing internet sites. We aim to build the biggest and most comprehensive encyclopaedia in the world. To date we have over four million articles in a host of languages. The English language Wikipedia alone has over one million articles! But we still need more! Please feel free to contribute your knowledge and expertise to our site.

If you need help see:

Help contents - the main help page.
Cheatsheet - a listing of the main editing commands.

Here are a few more good links for newcomers:

We hope you enjoy editing here and being a Wikipedian! Please sign your name on talk pages using three tildes (~~~), or four (~~~~) if you want date stamp; this will automatically produce your name and the date. If you need help, check out Wikipedia:Questions, ask me on my talk page, or place {{helpme}} on your talk page and someone will show up shortly to answer your questions. {{{1}}} Again, welcome! Herostratus 06:45, 17 January 2007 (UTC)

Ladonia

Hello and thank you Quilbert, Yes, you can see "Nimis" and "Wotan’s tower" in the aerial images available thru the links. Click on the coordinates in the "Ladonia" article, which takes you to the GeoHack page, then the link to "Sweden" and "map". Click on "Flygfoto", and zoom-in. I did not see "Gene" in the aerial imagery but it would not be far away. truthdowser (talk) 13:36, 7 February 2008 (UTC)

Proposed merge of isotope tables

As someone who has maintained Isotope table (complete) and/or Isotope table (divided) in the past, your input is needed. User:Greg L is proposing (and prematurely executing) a merge of the two tables, each about 50k, into one table of over 100k. I am opposing it, and no other editors have commented yet. Please come to Talk:Isotope table (complete) and offer your opinion. Thanks, JWB (talk) 00:27, 20 February 2008 (UTC)

Merger

Quilbert: I see you voted for what is now option #2 on the vote page. What do you think about option #3, which would keep the best of both worlds and would leave only one article? In case other options get added and the numbering gets changed, here is a historical version to show which option I’m talking about. Greg L (my talk) 20:45, 20 February 2008 (UTC)

Hi, I didn’t vote for that. You just moved my suggestion away from my vote! With a soft merge, the single venue for maintaining and discussing would be the template containing the data. --Quilbert (talk) 20:57, 20 February 2008 (UTC)

I am sorry. I didn’t mean to do that at all! Greg L (my talk) 21:02, 20 February 2008 (UTC)

No problem. By the way, if both methods are merged to one article, you could still use my suggestion. --Quilbert (talk) 21:06, 20 February 2008 (UTC)

I just don’t know how I managed to do that. Are you sure that the data is stored in a single template and that if it is changed in either of the two articles, the change will appear in both? I once changed a color code for the isotope half-life in one and it didn’t appear in the other. Did I just not wait long enough for the change to propogate or did I fail to refresh or something? Greg L (my talk) 21:09, 20 February 2008 (UTC)

Upon further reading, it appears you’re saying the data can be stored in a single place, just that both articles need to access it differently to take advantage of that. Is that right? Greg L (my talk) 21:12, 20 February 2008 (UTC)

Yes, that is right. Just as I stored the data for elements 0 to 29 in User:Quilbert/IsotoneRows. --Quilbert (talk) 21:14, 20 February 2008 (UTC)

I like what you’ve done at your proposal User:Quilbert/Experiment. Couldn’t your single-template method be implemented in a dual-view page like Isotope table (complete) currently is (which your Experiment page effectively replicates)? By combining both (your single data source, and the single page with both views), it would fix both my objections to the status quo: Having two places to edit data (errors) and having two venues to discuss issues (poor coordination). Greg L (my talk) 21:20, 20 February 2008 (UTC)

Yes, of course, that could be done as well. But, as stated above, coordination problems could also be solved by discussing data issues on the template’s discussion page and framework issues on the respective article discussion pages. --Quilbert (talk) 21:29, 20 February 2008 (UTC)

Yes, it’s true that discussions can be directed to a single place and one way or another, that should be done. I guess there is a third issue that needs to be addressed: usability and convenience. When I added a link from Kilogram to these articles, I had to choose one article or the other. At the time, I chose “complete” because “divided” was hard to navigate. Of course, as has currently been done, advisos can always be posted within the articles providing a link to the alternative article. My reasoning was as follows: Why have two alternative places to go to? Many readers turn on their brain-filters and skim body text in order to quickly advance to the meat of the article; they don’t notice the availability of an alternative view.
Then I quickly got frustrated with all the two-axis scrolling required on “complete” so I modified it—as you’ve seen. Now, if the user starts to scroll, they immediately end up in the über scrolling world. If they use the TOC, they end up in a real handy segmented area with the new “ ← Previous | Next → ” navigation aids and other quick links (like to the periodic table where users can then hit their browser’s “back” arrow when they’re done with the periodic table). In the “segmented” section, users never have horizontal scrolling and have fast navigation to the periodic table and adjacent sections, and also have multiple color legends whereever they are (alll of which JWB copied the crap out of in only one day). With this method, users are immediately aware of the availability of both views and have handy access to both.
I very much like your single-database template. I’d propose that I add a hybrid option to the discussion page. I would dump my original vote and instead support the hybrid option. Would you be willing to support that new option too? Alternatively, we can keep our original votes and post an additional vote on the alternative option. Greg L (my talk) 21:57, 20 February 2008 (UTC)

P.S. I went ahead and added the hybrid option (quick jump to voting page). I like the single database only too much. This will give others an opportuntity to throw weight behind it. Greg L (my talk) 22:13, 20 February 2008 (UTC)

209Bismuth

Quilbert: I stumbled across Table of nuclides, 73-96 and saw that ²⁰⁹Bi is listed as being a “stable” isotope. Its actual half-life, as you probably already know, is 19±2 × 10¹⁸ years via alpha decay. I was really close to just fixing this myself but have no idea what dependencies there might be on that cell so I decided to not take it upon myself to alter it.

The shear enormity of isotope data on the various Wikipedia pages boggles the mind. I can look up info on bismuth here at Isotope table (complete)#Isotopes for elements 75-89, and at Isotopes of bismuth (where the data is correct), and at Table of nuclides, 73-96 (where the data is incorrect).

Given that keeping all this data in synch is already a butt-itch*, I’m really rather astonished that there have been advocates who thought it was a good idea to maintain two identical articles (Isotope table (divided) and Isotope table (complete))—each with its own talk page! It seems that until you stepped up to the plate with a big bat, no one was willing to do what it really takes to keep all this data coordinated using a rational approach.

I suppose the thing to do now on Isotope table (complete), is just sit back and let it soak in for a while. Do you agree?

* Butt-itch n.: That nasty little problem that won’t go away on its own and which can’t easily be tended to in public.

Greg L (my talk) 18:13, 25 February 2008 (UTC)

It seems like the coloring is not yet optimal. Bi-209 is listed as unstable (compare to the stable Pb-208), and the template hasn’t changed since yesterday:

! 126	²⁰²Os	²⁰³Ir	²⁰⁴Pt	²⁰⁵Au	²⁰⁶Hg	²⁰⁷Tl	²⁰⁸Pb	²⁰⁹Bi	²¹⁰Po	²¹¹At	²¹²Rn	²¹³Fr	²¹⁴Ra	²¹⁵Ac

--Quilbert (talk) 19:09, 25 February 2008 (UTC)

I was wondering about all that extra repetitive text. It’s now 29,458 bytes. Talk about compact.
I’m not clear as to which article is supposed to appear like your above example. Is that what Table_of_nuclides,_73-96#Bismuth is supposed to look like? In your above example, I see a color-coded horizontal version of what one sees in a column on “complete”. Here’s what I see when I go to Table_of_nuclides,_73-96#Bismuth:

| 209Bi | stable | 9/2- | %Abundance=100 | | 210Bi | 5.013 d | 1- |%β-=100, %α=1.32E-4 |

As you can see, the 209Bi is listed as stable and there are no colors and it’s just a plain B&W tabular table. It appears that way using Safari, Internet Explorer, and FireFox on a Mac. Greg L (my talk) 20:30, 25 February 2008 (UTC)

Oh sorry, you are right. Somehow, I didn’t perceive that you were talking about that article. --Quilbert (talk) 20:35, 25 February 2008 (UTC)

I fixed it now. You can edit those tables, they have no dependencies. By the way, we have to include these articles in our considerations when renaming our article ... Actually, in my opinion, they should be named Isotope lists and our table should be named Table of nuclides. --Quilbert (talk) 20:44, 25 February 2008 (UTC)

Perhaps I’m not the best judge of the politics here. But it appears to me that opposition to what we’re doing here has largely collapsed since the advantages of what has been done are many and its disadvantages are non-existent. I would suggest the shortest possible filename for anything that repeats a hundred times in an article. As for the article name—“Table of nuclides”—if you think that is most technically accurate, then I would accede to your judgment. I would hope that you know how to simultaneously 1) handle the move so all the discussion transfer over, and 2) know how to simultaneously handle redirects on searches like “Table of isotopes (complete)”, “Lists of isotopes”, “Isotopes list”, “Table of isotopes”, etc.
On a separate subject, do you know how to add a colored border to one of the cells in Template:Isotope colour chart? In the introductory text, I’d like to specifically reference that example cell. Greg L (my talk) 21:16, 25 February 2008 (UTC)

You could use this code:

{|class="wikitable"
| {{Iso2|91|Nb|G|I}}
| rowspan=2 | nuclides with nuclear isomers<br/>in different half-life categories
|-
| {{Iso2|94|Nb|Y}}
|}

becoming:

⁹¹Nb	nuclides with nuclear isomers in different half-life categories
⁹⁴Nb

The moving of the talk pages won’t be a problem. But let’s wait for a while until the discussion is settled before we move the articles around. --Quilbert (talk) 21:52, 25 February 2008 (UTC)

Well, I tried this, but…

I tried placing this in the article but the resulting placement is left-justified. I’m no damned good with these things.

⁹¹Nb	Yellow border: Isomer half-life 10–100 days White border: Isomer half-life <1 day Lt. green border: Isomer half-life 100 days–10 yrs
⁹⁴Nb
¹⁰²Rh

Using this code:

{|class="wikitable"
| {{Iso2|91|Nb|G|I}}
| rowspan=3 | <p style="line-height:180%">Yellow border: Isomer half-life 10–100 days<br/>
White border: Isomer half-life <1 day<br/>Lt. green border: Isomer half-life 100 days–10 yrs</p>
|-
| {{Iso2|94|Nb|Y}}
|-
| {{Iso2|102|Rh|B|B}}
|}

…but it didn’t quite work out like I planned. The line spacing must be managed to get it to line up but if I use the full amount of line spacing to make it really line up well, I end up with this:

⁹¹Nb	Yellow border: Isomer half-life 10–100 days White border: Isomer half-life <1 day Lt. green border: Isomer half-life 100 days–10 yrs
⁹⁴Nb
¹⁰²Rh

You get the idea of what I’m after. Maybe we can try it later as you are frying bigger fish right now. Greg L (my talk) 01:41, 27 February 2008 (UTC)

try this

I see what you want. I suggesgt this code:

{|align="right" class="wikitable"
| {{Iso2|91|Nb|G|I}}
| Yellow border: Isomer half-life {{Iso/I/text}}
|-
| {{Iso2|94|Nb|Y}}
| White border: Isomer half-life {{Iso/-/text}}
|-
| {{Iso2|102|Rh|B|B}}
| Lt. green border: Isomer half-life {{Iso/B/text}}
|}

⁹¹Nb	Yellow border: Isomer half-life 10–100 days
⁹⁴Nb	White border: Isomer half-life < 1 day
¹⁰²Rh	Lt. green border: Isomer half-life 100 days – 10 years

--Quilbert (talk) 02:22, 27 February 2008 (UTC)

Placement control

That’s what I’m looking for. Thanks. I’ve taken your code and tried various layouts in a so-far vain effort to obtain a layout that looks good regardless of page width. There’s not a lot of text at top and the page flow makes for weird and ugly looking results in most cases. Is there a way to “join” the two tables so they can’t break?

Novices like me would think that the following code…

{{isotope colour chart|}}{|align="right" class="wikitable"
| {{Iso2|91|Nb|G|I}}
| Yellow border: Isomer half-life {{Iso/I/text}}
|-
| {{Iso2|94|Nb|Y}}
| White border: Isomer half-life {{Iso/-/text}}
|-
| {{Iso2|102|Rh|B|B}}
| Lt. green border: Isomer half-life {{Iso/B/text}}
|}
{{for|an overview of available representations|Table of nuclides}}
The various isotope tables below (scroll down) show the known [[isotope]]s of the [[chemical element]]s.
<ref>The data for these tables came from [[Brookhaven National Laboratory]] which has an interactive
[http://www-nds.iaea.org/nudat2/ Table of Nuclides] with data on ~3000 nuclides.</ref> They are
arranged with increasing [[atomic number]]s ([[proton]] numbers) from left to right and increasing [[neutron]]
numbers from top to bottom.

For convenience, two different views of the data are available here: ''“Segmented tables,”'' and a single 
''“Unitized table (all elements).”'' Choose…

…would put your little three-row table below the colour chart. But here’s what I get:

**Half-lives** (example: most stable isotopes)
²¹⁰At	< 1 day
²²²Rn	1–10 days
²⁵⁸Md	10–100 days
²⁵²Es	100 days–10 a
²²⁶Ra	10–10,000 a
⁹⁷Tc	10 ka–700 Ma
²³⁸U	> 700 Ma
¹²C	Stable

{|align="right" class="wikitable" | style="background:#ffee66;" title="Half-life – Isotope: 10–10,000 years; Nuclear isomer: 10–100 days" |

⁹¹Nb

| Yellow border: Isomer half-life 10–100 days |-

| style="background:#ffffff;" title="Half-life – Isotope: 10k–103M years; Nuclear isomer: < 1 day" |

⁹⁴Nb

| White border: Isomer half-life < 1 day |-

| style="background:#BF7;" title="Half-life – Isotope: 100 days – 10 years; Nuclear isomer: 100 days – 10 years" |

¹⁰²Rh

| Lt. green border: Isomer half-life 100 days – 10 years |}

The various isotope tables below (scroll down) show the known isotopes of the chemical elements.^[1] They are arranged with increasing atomic numbers (proton numbers) from left to right and increasing neutron numbers from top to bottom.

For convenience, two different views of the data are available here: “Segmented tables,” and a single “Unitized table (all elements).” Choose whichever one you need from the table of contents, below. The unitized table allows easy visualizion of proton/neutron-count trends but requires simultaneous horizontal and vertical scrolling. The segmented tables permit easier examination of a particular chemical element with much less scrolling. Links are provided to quickly jump between the different sections.

Note the example color legend shown at right. These legends are provided alongside each table below. Cell color denotes the half-life of each isotope. If you’ve scrolled so a color legend is not in view, allowing your cursor to dwell over a cell will cause a pop-up text box to indicate that isotope’s half-life. If a cell is two-colored, dwelling over it will also disclose the half-life of the most stable nuclear isomer state.

[1]
The data for these tables came from Brookhaven National Laboratory which has an interactive Table of Nuclides with data on ~3000 nuclides.

It looks like the colour chart has “administer privileges” that gives it priority to be at the top. So I just moved your new three-row table as far down as I can go. Check out Table of nuclides (combined) to see what I’ve managed so far. I’m not entirely happy with the way the page elements flow but can live with it. I’m hoping you know of a way to keep that three-row table below the top one and nailed against the right edge.

18:14, 28 February 2008 (UTC)

New suggestion

I have slightly modified the Isotope color chart to allow for extensions. Maybe this is what you’re looking for?

**Half-lives** (example: most stable isotopes)
²¹⁰At	< 1 day
²²²Rn	1–10 days
²⁵⁸Md	10–100 days
²⁵²Es	100 days–10 a
²²⁶Ra	10–10,000 a
⁹⁷Tc	10 ka–700 Ma
²³⁸U	> 700 Ma
¹²C	Stable

{{Isotope colour chart|
PLUS = {{!}}-
{{!}} {{Iso2|91|Nb|G|I}}
{{!}} Yellow border: Isomer half-life {{Iso/I/text}}
{{!}}-
{{!}} {{Iso2|94|Nb|Y}}
{{!}} White border: Isomer half-life {{Iso/-/text}}
{{!}}-
{{!}} {{Iso2|102|Rh|B|B}}
{{!}} Lt. green border: Isomer half-life {{Iso/B/text}}
}}

--Quilbert (talk) 20:04, 28 February 2008 (UTC)

or so:

**Half-lives** (example: most stable isotopes)
²¹⁰At	< 1 day
²²²Rn	1–10 days
²⁵⁸Md	10–100 days
²⁵²Es	100 days–10 a
²²⁶Ra	10–10,000 a
⁹⁷Tc	10 ka–700 Ma
²³⁸U	> 700 Ma
¹²C	Stable

{{Isotope colour chart|
PLUS = {{!}}-
{{!}} {{Iso2|91|Nb|G|I}}
{{!}} rowspan=2 {{!}} Yellow border:<br/>Isomer half-life {{Iso/I/text}}
{{!}}-
{{!}} &nbsp;
{{!}}-
{{!}} {{Iso2|94|Nb|Y}}
{{!}} rowspan=2 {{!}} White border:<br/>Isomer half-life {{Iso/-/text}}
{{!}}-
{{!}} &nbsp;
{{!}}-
{{!}} {{Iso2|102|Rh|B|B}}
{{!}} rowspan=2 {{!}} Lt. green border:<br/>Isomer half-life {{Iso/B/text}}
{{!}}-
{{!}} &nbsp;
}}

--Quilbert (talk) 20:22, 28 February 2008 (UTC)

Great. I’ve revised “(combined)” with this. The new legend no longer resembles the actual ones used below and is much wider now. However, I’ve confirmed it works well on 800-pixel monitors. I’ll keep it here for a while and see if I warm up to it. Do you like the new look? We can easily go back to what I had. Sometime, I wish you’d explain how you got so good at templates. Is there a place on Wikipeida to read up on this? If so, I haven't found it yet. Besides, I’d never have the patience to try to learn all the tricks. Thanks so much. Greg L (my talk) 01:10, 29 February 2008 (UTC)
P.S.: I compacted the isomer text some (no need to name the colors). In a two-step process, I also changed to 198Au, so the border now progresses white, pink, yellow and the resulting “V” text takes up less room. I’ve really warmed up to the new look quite a lot now that it’s more compact. Do you like? Greg L (my talk) 01:47, 29 February 2008 (UTC)

Yes, that looks reasonable. Maybe we could even leave out “Border” and “half-life”?

I have been programming for quite some time. That is learning by doing. Once you get to know how computers “think”, such things are learned easily. If you want to learn more, the natural place to go would be Help:Template. --Quilbert (talk) 01:47, 29 February 2008 (UTC)

You’re right. None of the other cells had the words “half-life.” I substituted “is.” I left the words “Border” and “Isomer” because we authors get darn familiar with these articles and it’s easy to think that all new readers must do is read a little body text. A picture of a colored border is a huge help for first-time readers; of that, I’m certain and I’m very appreciative you took the time to modify the template to support this feature. It takes imagination, but I try to pretend I’m a new reader visiting the article for the first time (which isn’t hard because I can still remember almost everything that initially confused me). I don’t think I’m unusual in my reading habits and know I’m horrible about skipping over introductory text and going first to pictures, captions, and the ‘meat & potatoes’ of articles. This is a byproduct of the Internet where one can quickly explore a lot of information. If I can get a caption fully self-explanatory and tight, that’s good. If I can get a caption fully self-explanatory and really pithy and tight, that’s great. Greg L (my talk) 02:19, 29 February 2008 (UTC)

Category:Isotope tables templates

Re: Table of nuclides

Barnstar

User:142.33.207.9

Drip lines

"the important thing is that usage should be consistent"

Re: My request

RfC

I agree that this is less a debate about Greg’s conduct but about IEC prefixes.

It's entirely about Greg's conduct. Yes, we are involved in a dispute about SI prefixes, but it's the conduct of the users involved that's preventing us from reaching a consensus. Several users avoid the talk page altogether because of the hostile atmosphere, so Greg ignores their opinions and tries to drive off the rest who oppose him with personal attacks and mocking. Aluvus and SMcCandlish attempted informal mediation but gave up in disgust.

So I decided to go after the root of the problem, which is Greg's incivility and disregard for the opinions of others, instead of wasting my time on the talk page repeating the same arguments over and over to people with their fingers in their ears. If he was cooperative, we could reach a real consensus, instead of just spending all our time trying to prevent him from pushing through new policies based on stacked 7:5 votes. Should I behave like him and notify only the 20 people who originally voted in favor of IEC to override his votes? Of course not. This sort of thing needs to be decided based on good reasons and consensus. The guideline should only make a recommendation on this issue if that recommendation has wide agreement among all editors. If it does not have wide agreement, it should be removed, as I have repeatedly tried to do. — Omegatron (talk) 15:29, 7 June 2008 (UTC)

OK, whatever that RfC is about … it is my honest belief that consensus is unreachable in that matter. Whether Greg is around or not. Sadly, enwiki seems to have no polling mechanism that would enable a poll with at least a hundred participants. So what can we do? I as a pro-IEC candidate will always dislike the “current literature” practice, as current literature is being inconsistent. Others will never get used to the “Kibi kindergarten”. How is that ever to lead to a consensus? --Quilbert (talk) 18:00, 7 June 2008 (UTC)

Well, I still have faith that consensus can be reached, but not without Greg changing his behavior. This is not a case in which there are two "sides" that must battle each other to the death, and then the side with a 1% majority gets to run all over the other. There are several different positions here (pro-SI, anti-IEC, pro-IEC), and a variety of different solutions, and they aren't necessarily mutually exclusive. But when Greg refuses to consider the viewpoints of others, declares that he'll "stop at nothing" to push through his agenda, pisses people off and polarizes the discussion, he prevents any progress from being made.

You say, "I am really sure that he only fights for the better of Wikipedia and should not be accused for his temper in this way." I agree with you 100% that he's only fighting to improve Wikipedia; we all are, and I agree that he's sometimes a productive editor, but being belligerent to other users is never acceptable, no matter what you're fighting for. That's the whole point of Wikipedia:Civility. "Participate in a respectful and civil way. Do not ignore the positions and conclusions of others. ... avoid upsetting other editors whenever possible." Calling other editors "extremists" or "space cadets" is never acceptable on Wikipedia, no matter how spacey and extremist you might think they are. — Omegatron (talk) 22:28, 7 June 2008 (UTC)

Of course I understand that your intentions are good, too. You are trying to fit the disucssion into a more well-regulated consensus-finding process. But you must excuse my not believing that the RfC will achieve that goal. Although I have no spontaneous idea what to do. I am a little hesitating to join the discussion (or should I say war). Maybe I will. At any rate, I promise to contemplate over the situation and possible methods of relaxation. If only one could set up a somewhat more structured discussion venue than WT:MOSNUM … See you then --Quilbert (talk) 21:13, 9 June 2008 (UTC)

Hello Quilbert. Thanks for your attempt to start a proper discussion about IEC prefixes. It is unfortunate that the atmosphere at MOSNUM remains such that it is not possible to debate it calmly there, but I would be pleased to participate in a constructive debate going through the advantages and disadvantages of different methods of disambiguation, including, but not limited to, the use of IEC units. My feeling is that such a discussion could eventually lead to consensus.

As you concluded, there is no consensus now either for promotion or deprecation of their use, so the wisest policy would be for MOSNUM to do no either (Greg L, who forced through the present deprecation, has made precisely this point in the past, but seems to have conveniently forgotten). But the present version of MOSNUM was pushed through without make any attempt to address the concerns of those of us arguing against deprecation.

My own view is that it does not matter how disambiguation is carried out provided that the raw “megabyte” is disambiguated somehow and is agreed by consensus on the article talk page. My concern is that the present deprecation is so strong that editors use it as a justification to replace unambiguous units with ambiguous ones, thus destroying the information that someone somewhere took the trouble to include in the article. I am considering constructing a list of articles damaged in this way so that at some time in the future they can be restored. Would such a list be a useful addition to your discussion sub-page? Thunderbird2 (talk) 16:36, 11 June 2008 (UTC)

TB2, stop writing things you know are not true. There is consensus, no matter how many times you claim the contrary it doesn't make it true. Also your baselss untrue accusation against Greg needs to be retracted at once. Also you failed to address concerns by refusing to answer questions, the fault rests entirely with you. I remind you that your continued efforts at misrepresentation actually weaken whatever arguments you do make. Fnag aton 23:22, 11 June 2008 (UTC)

Of course, feel free to edit that page just as you like. It is now at User:Quilbert/IEC. I think a list of articles that are touched by this will be very useful. There are possibilities of disambiguation even without IEC prefixes. If you understand German, see de:Vorlage:MB10 (and de:Kategorie:Vorlage:Datenmenge). Those are the templates I created after we had “lost” the poll on dewiki. It makes at least clear what is meant. --Quilbert (talk) 16:59, 11 June 2008 (UTC)

Quilbert, Thunderbird2’s above don’t post quote lacks out that of necessary context virtue T-bird of “truthiness.” He wrote above that “there is no consensus now either for promotion or deprecation of their use”. You should know that the “consensus” is amply evidenced by this lopsided vote, which is the most recent one that lead to the current contents on MOSNUM. Further, he fallaciously wrote above as follows: “…Greg L, who forced through the present deprecation”. He knows full well that is untrue since the entire contents of MOSNUM were entirely the product of Headbomb’s efforts at mediating the discussions. My efforts were to get Follow current literature into MOSNUM, which Headbomb’s efforts replaced. Besides, what is this “forced through” garbage? No one, not Headbomb, and not me, can “force” anything upon nine other editors. To allege otherwise is pure horsecrap.
Also, any intelligent parsing of what he further wrote above will demonstrate that his post is internally inconsistent. He states that he doesn’t care how disambiguation is done (“My own view is that it does not matter how disambiguation is carried out provided that the raw “megabyte” is disambiguated somehow and is agreed by consensus on the article talk page.”) And then he followed right up with “…the present deprecation is so strong that editors use it as a justification to replace unambiguous units with ambiguous ones…”. This wording of his, “ambiguous” units v.s. “unambiguous” ones, has consistently been his buzz words for advocating the continued use of the IEC prefixes; there can be no mistaking that this is his agenda. I think that if he is going to solicit you to help him advocate his position, that he could be a little more forthright with you and fully articulate exactly what it is he hopes to entangle you in.
The rest of us understand that the world is not using the IEC prefixes and this is why all parties to this dispute agreed on one critical point: that the word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader. And why would this be the case? Because…

All the computer manufacturers, when they communicate to the general-interest customers via their advertisements, brochures, Web sites, product packaging, owners manuals, etc., use the conventional prefixes.
That’s why all general-interest computer magazines like PC World and Mac World use the conventional prefixes. And they see no need to disambiguate terms like “comes stock with 2 GB.” Such wording is clear enough to their readerships. In fact, the computer magazines don’t even bother to disambiguate hard drive capacity unless they are really splitting hairs on critical file-size issues; simply writing “500 GB hard drive” is close enough.
That’s why all professional encyclopedias like Encyclopedia Britannica and World Book (both their print and on-line versions) use wording like “megabyte” in their computer articles, and not “mebibyte.”
That’s why the edit page of MOSNUM says “This page is 64 kilobytes long.”
That’s why my library’s Microsoft Dictionary of Computer Terms doesn’t even have entries for “mebibyte” or “kibibit.”

The editors who voted for the current contents of MOSNUM simply feel that we volunteer, hobbyist editors are not somehow more… “enlightened” than all the editors at the world’s computer magazines and professional, print encyclopedias, all of whom are professional, paid editors, and most of whom undoubtedly have advanced degrees in journalism. We continue to believe that the wise thing to do is follow the time-tested, consistent practices observed by the computer manufacturers and the rest of the publishing world, rather than strike off doing our own thing.

Way back at the beginning of Wikipedia’s three-year experiment with the IEC prefixes, Ben Arnold wrote this when he voted against permitting their use:

“

Wikipedia is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.

”

Those word are as true today as they were three years ago. Greg L (talk) 00:30, 12 June 2008 (UTC)

To be honest, I am not really keen on taking a stand here. There are different interpretations of the word “consensus”. The rest is personal conflict between you two. It seems like all have heated up here so much that whenever you touch something you run the risk of making it explode.

You know that, although I can fully comprehend your position, I am mostly pro-IEC. For a physicist, there is no other way. We never trust so much in what the rest of the world says … Well, but I’ve already had enough of being yelled at, so I better relax now and maybe come back when it seems suitable.

Remember: Nothing is worth a war, and this not in the slightest.

Have a nice day. Here it is sunny, and we are going to win in soccer today! --Quilbert (talk) 11:21, 12 June 2008 (UTC)

Quilbert. See the below posts. Those are my current feelings and I’m sorry for having “yelled” at you. I certainly hope you don’t feel that any of the above that may seem harsh had been directed at you in any way. I hope you had a good time playing socker today. It’s great weather here in Washington state this morning. We had a huge thunderstorm last night, whith monster lightning strikes well within a 100 metres of the house, and this morning, it is bright and sunny. Later. Greg L (talk) 16:42, 12 June 2008 (UTC)

No no, don’t worry, it’s alright. It was just the atmosphere over there that made me uneasy. See you soon. --Quilbert (talk) 20:10, 12 June 2008 (UTC)

Thanks

request for comment

ZIP drive capacity

IEC sub-page

Hello Quilbert, I’ve been reading through your IEC sub-page with the intention of adding my views, but I find it hard to relate to the page as currently layed out. I think the most relevant question is not whether we should use IEC prefixes but under what circumstances. In particular, the present deprecation to be found in MOSNUM is controversial, and for that reason doesn't belong on a page that is supposed to reflect consensus. Perhaps it is worth listing the arguments for and against deprecation. I have in mind something like this

for

IEC prefix is rare and unfamiliar to many readers
etc

against

IEC prefix is unambiguous, simple to use and simple to understand
IEC prefix is supported by national and international standards bodies
the alternative (binary use of SI-like prefixes) is deprecated by the same standards bodies
etc

What do you think? Thunderbird2 (talk) 14:16, 21 June 2008 (UTC)

I don’t fully understand what you say. Isn’t “for deprecation” the same as “pro IEC prefixes”? What do you want to change? I mean, of course the question only is whether or not to use IEC prefixes in case we relate to the binary meaning. Using SI prefixes to express the decimal meaning is undisputed, as far as I can see. Maybe the page has to be reformulated to make that clear. Is it that you meant? --Quilbert (talk) 14:35, 21 June 2008 (UTC)

Sorry, I sometimes forget that I am dealing with non-native speakers (your English is so good that most of the time I can't tell). To deprecate something means to advise against its use. In very simple terms "for deprecation" means "anti-IEC prefixes". My objection to the MOSNUM wording is that it includes a near-prohibition of the use of the IEC prefixes, despite their many advantages. Does that make it clearer? Thunderbird2 (talk) 14:45, 21 June 2008 (UTC)

It is not about being "anit-IEC" at all, it is disingenuous to say that. It is actually about following Wikipedia policy regarding not putting something into articles that is rarely found in the real world. In this specific case IEC prefixes are rarely found in the real world so we don't keep on putting them into articles. If there are "many advantages" to using IEC prefixes then Wikipedia must wait for that to be reflected in the real world sources first. This is because it is entirely personal point of view that "there are are many advantages" and we don't add personal point of view to articles in Wikipedia. The advise against using IEC prefixes in articles reflects the position of the real world and because we have a tiny minority of people who ignore consensus and push their personal opinion about IEC prefixes into articles. Fnag aton 14:52, 21 June 2008 (UTC)

OK, sorry, I mixed it up. So “for deprecation” is the same as the “contra IEC prefixes” position on my sub-page? I actually meant that position to include prohibiting their use. Please explain in what way you’d like to change the sub-page. --Quilbert (talk) 15:05, 21 June 2008 (UTC)

I think it can be improved by adding more context. Imagine an article describing the speed at which data can be loaded to memory from a computer hard drive. Should the article

use MB (and MB/s) and disambiguate using MiB
use MB (and MB/s) and disambiguate using exact numbers of bytes
use MB (and MB/s) and not disambiguate at all
use MiB (and MB/s)
use MiB (and MiB/s)?

I don’t mean to suggest that you consider all possible uses in all possible articles (a thankless task!), but that the question be changed from “should we use MiB” to “is MiB better or worse than a specified alternative or alternatives” Thunderbird2 (talk) 15:22, 21 June 2008 (UTC)

I had initially planned to limit such detail to the “Solutions” section, but maybe I think it over and reformulate the page. On the other hand, the page isn’t used anyway. I will consider it. --Quilbert (talk) 15:30, 21 June 2008 (UTC)

Thanks for your reply on my talk page. I would never have known where to look for that (although I think the problem is an ongoing one and should not have been closed). By the way, I noticed the recent change to your IEC sub-page. It seems to me that the table has outlived its purpose. Would you like me to remove it now? Thunderbird2 (talk) 19:33, 26 November 2008 (UTC)

I leave that up to you. I just stumbled over the page once again and then updated the notice. On my behalf, the entire page could be deleted. —Quilbert (talk) 19:40, 26 November 2008 (UTC)

OK, I've removed the table. You may also wish to read this. Your comments are welcome. Thunderbird2 (talk) 19:49, 26 November 2008 (UTC)

AWG v.s. “sane” way

Copied from Fnagaton’s talk page (archive).

I enjoy watching you two discuss this. I respect you both and hope you two don’t alienate each other while you engage in this mental thrust & parry. I agree with you both by the way. It seems to me that Fnagaton is correct that you divide binary quantities by binary quantities, and shift the value and meaning of the prefix when the measure is data rate. It also seems to me that Quilbert is correct that dual meanings for the same prefix is asinine and the convention totally blows. But then, the entire U.S. Customary system of measurement is asinine too and we Americans are still using it (I don’t though; I have a 1-meter tape measure in my pocket at all times).
You want an example of über asinine? The U.S. system of wire gauges is beyond asinine; it is totally brain-damaged insane. How many wires of what gauge can you get into a wire nut? With the wire-gauge system, you have to have a lookup chart on the box, like so:

3 #16
5 #18
1 #14 + 1–2 #16
1 #14 + 2–3 #18
etc.

This is profoundly simple with the Euro way of doing things: the wire nut is good for up to 5 mm² of conductors. That means the above translates as follows:

3 of 1.5 mm² (4.5 mm² total)
5 of 1.0 mm² (5.0 mm² total)
1 of 2.0 mm² + 1–2 of 1.5 mm² (3.5–5.0 mm² total)
1 of 2.0 mm² + 2–3 of 1.0 mm² (4.0–5.0 mm² total)
etc. where you simply add your conductors and don’t exceed 5 mm² total. You need no lookup tables on the box.

You have to really know your conductors when you design fuel cells (where everything is a conductor). Every bit of resistance (there are all types, including proton resistances in the membrane separators) must be known and minimized.

So how insane is American Wire Gauge? Totally. And what can I do about it when I write an owners manual for one of our designs. Nothing. So we live with certain things, including “megabyte”, which is ambiguous. But who gives a damn, the errors of 2.4 to 7.4 percent don’t mean much except to us crazy Wikipedia editors. Greg L (talk) 04:15, 21 June 2008 (UTC)

Funny stuff. I see your point. But what keeps you from explaining it the “Euro way”, as you entitle it, in the owners’ manual? It makes perfect sense and is much easier to understand. I for one would do it that way and include a table that maps the AWG number to the metric cross section. By the way, I find the formula quite amusing … --Quilbert (talk) 13:29, 21 June 2008 (UTC)

If I used the “sane” way of discussing wire sizes in an owners manual (e.g. 2 mm²), it would baffle American owners of the device just as much as it would if I mentioned “AWG 14” to a European readership. Besides, there is no equivalent to AWG 14 wire in metric. For instance, here in America, you can easily get the following wire sizes:

AWG 10 (5.261 mm² would be the nearest metric equivalent)

AWG 12 (3.309 mm²)

AWG 14 (2.081 mm²)

AWG 16 (1.309 mm²)

To my knowledge (and I’ve had to redesign and certify American industrial products to IEC compliance for sale in Europe, so I kinda know this stuff), European wire sizes come standard in the following near-equivalent sizes:

6 mm² (9.43 AWG would be the nearest metric equivalent)

4 mm² (11.18 AWG)

2.5 mm² (13.21 AWG)

1.5 mm² (15.41 AWG)

Fortunately, I have a spreadsheet that makes all this easy. Plus, my spreadsheet has the temperature coefficient of copper and it has “knowledge” of the heating rate of wires for different currents, so it can calculate what the actual, in-circuit resistance will be when things heat up. And it can calculate the maximum permissible current for NEC raceways (American household fixed wiring), and IEC 60335-1 (European industrial product wiring), as well as current-carry capacities to other standards and conventions. It’s a good spreadsheet. But the bottom line is that in reality, (I had to “cheat” to make the point in the wire nut example), there are are no direct equivalents anyway.

If I were president of the U.S., I’d simply put a federal 10% tax on everything that was non-metric. Overnight, every damned nut and bolt going into any product would be metric. Metric tools to turn the fasteners would become popular. And they’d be 10% cheaper too. Every piece of wire being sold would be metric. Everything would slowly become metric in only a handful of years and the federal deficit would be reduced in the mean time. Do you know what buyers do at companies when someone tells them they can beat some other supplier by 10% and all they have to do is go badger an engineer about whether 1.5 mm² wire can be substituted for 16-gauge wire? The engineer gets badgered; that’s what happens. Plumbing would change. Machine tools would change (does it have an inch-based Acme screw in the table? Yes? Tax it.)

Besides, the bigger point here is that even though there are superior ways of doing things, Encyclopedias must use the language and terminology commonly used within any given discipline so we don’t confuse our readers. Made ya smile. ;-) Greg L (talk) 05:14, 22 June 2008 (UTC)

Yes, I see. I noticed that 92^1⁄17.9 is very close to ${\sqrt[{3}]{2}}$ , so from a higher viewpoint (not entirely serious here) it would be best to express the cross-section area in the binary system, with 1.00000₂ being AWG 40 and 1.00001₂ × 2¹³ being AWG 1. So one would only have to calculate modulo 3 and use the mantissas 1.00000₂, 1.01000₂ $\ \approx {\sqrt[{3}]{2}}$ , and 1.10011₂ $\ \approx {\sqrt[{3}]{4}}$ , depending on the modulus. But (serious again) even if there is very little reality in my veins, it suffices to see that no one would buy that.

But I still believe that people would easily understand that SI prefixes are no longer used in the binary but in the usual decimal sense. But that is my personal opinion. One can discussion about advantages and disadvantages (like I tried to explain to Fnagaton why the current system inflicts fundamental damage to logic), but in the end maybe that is a question of opinion and cannot be resolved objectively. Maybe we can have a really big vote some day. I still believe that is the easiest way to calm things down. --Quilbert (talk) 17:05, 22 June 2008 (UTC)

User talk:Quilbert

Ladonia

Proposed merge of isotope tables

Merger

209Bismuth

Well, I tried this, but…

try this

Placement control

New suggestion

Category:Isotope tables templates

Re: Table of nuclides

Barnstar

User:142.33.207.9

Drip lines

"the important thing is that usage should be consistent"

Re: My request

RfC

Thanks

request for comment

ZIP drive capacity

IEC sub-page

AWG v.s. “sane” way

Invisible Pink Unicorn

It Gets Better Project

Might you tell me how to get a "Russian integral" symbol in tex?

Re: Piecewise linear manifold

Orphaned non-free image File:Invisible pink unicorn.svg

Orphaned non-free image File:Invisible pink unicorn.svg

ArbCom elections are now open!

Nomination for deletion of Template:Isotope lists headings

Penguin diagram

File:Invisible pink unicorn.svg listed for discussion

Einstein problem

Related Articles

		The Tireless Contributor Barnstar
		For your huge effort on all the “isotope” templates (like Template:Isotones to name just one), which are used in articles such as Table of nuclides (combined), Table of nuclides (complete), Table of nuclides (segmented, narrow) and Table of nuclides (segmented, wide). Template authors are the unsung heros of Wikipedia. Thanks. Greg L (my talk) 02:33, 29 February 2008 (UTC)