User talk:NicM/Archive 2

From Wikipedia, the free encyclopedia

Contents

[edit] PMRC

Excellent job revising Parents Music Resource Center. The only change I disliked was combining the Senate hearings section by removing the section headings. I found that the third-level headings, which don't break up the page with a horizontal line, made the text easier to read by grouping it into chunks. Additionally, the subheadings allowed readers to go directly to the subheading for a certain person from the table of contents.

Here's the old version for comparison. Thanks, Λυδαcιτγ 01:24, 3 February 2007 (UTC)

There were too many subheadings for the amount of text. If it could be split into two subheadings (supporters and opposers?) it might work, although IMO the whole section reads too much like a boring list, it would be better to summarise the two sides and the outcome rather than just listing who spoke and what they said. Ditto the next section as well: it hardly seems necessary to list every band that mentioned the PMRC, it might be better just to cover 3-4 really notable or interesting ones in more detail (probably the most interesting are the first one to do it, Aerosmith who made a real point (that they weren't mentioned) rather than just swearing, and Rage Against the Machine because their protest was novel). I might have a look at it again if I have time. NicM 14:04, 3 February 2007 (UTC).
All right, I split it up into "Supporting witnesses" and "Opposing witnesses". I agree about the Tipper sticker section, and I'll pare it down at some point. Λυδαcιτγ 17:49, 3 February 2007 (UTC)

[edit] Stop putting irish on UK towns

Stop putting irish on UK towns —The preceding unsigned comment was added by Stopirishonukpages (talk • contribs) 14:38, 15 February 2007 (UTC).

Newtownards is both in the UK and on Ireland. Nearly half of the population of Northern Ireland identifies with the Republic of Ireland, everybody born in the province before (IIRC) 2001 is automatically entitled to Irish citizenship as well as British, and Irish is officially recognised as a minority language. Including Irish names on Wikipedia pages for towns on Ireland, north or south, is perfectly appropriate. Unless you can provide a good reason not to? NicM 15:08, 15 February 2007 (UTC).

[edit] Apology

My apologies for reverting this edit to Sudo. I had it backwards, my mistake. —Remember the dot (t) 17:48, 9 March 2007 (UTC)

No worries. NicM 17:54, 9 March 2007 (UTC).

[edit] Join the discussion on Wikipedia talk:Attribution/Community discussion! : )

Hello! Since you were the person who originally impressed upon me the importance of sources, I thought you might be interested in this. So, here's an official please join the discussion template:

There has been an extensive effort to combine Wikipedia:Verifiability and Wikipedia:No original research (together with much of Wikipedia:Reliable sources) into a new policy called Wikipedia:Attribution, and its FAQ, WP:ATTFAQ.

Recently, on Wikipedia talk:Attribution and on the Wiki-EN-l mailing list, Jimbo questioned whether the result had adequate consensus, and requested:

You are invited to take part; the community discussion should be as broad as possible. If you wish to invite other experienced and intelligent editors, please use neutral language. This message, for example, is {{ATTCD}}.

— Armed Blowfish (talk|mail) 19:20, 25 March 2007 (UTC)

I am interested, thanks for letting me know about this. NicM 22:19, 25 March 2007 (UTC).
 : ) Armed Blowfish (talk|mail) 00:32, 26 March 2007 (UTC)

[edit] Malloc

In your edit summary of Malloc you asked if anyone could read. Actually, the previous editor had vandalized the page by changing malloc to calloc. wrp103 (Bill Pringle) (Talk) 11:24, 24 April 2007 (UTC)

I doubt it was vandalism, much more likely he or she didn't read the sentence properly before changing the word. This is the second time someone has done this, perhaps the paragraph should be rephrased. NicM 11:54, 24 April 2007 (UTC).

[edit] Foresight

Thanks for reducing the screenshot size - i tend to forget how big 300px is since I've been on a widescreen - ElLinuxPenguin 11:57, 11 May 2007 (UTC)

[edit] Foresight

Thanks for updating the foresight article to include a caption for the screenshot. ElLinuxPenguin 09:17, 12 May 2007 (UTC)

[edit] setcontext

You are correct that int main(); is not a function prototype in C, but main() doesn't need a prototype. In my opinion, the extra "void" between the parentheses only adds clutter to the code, and is just one more hurdle that has to be jumped by a reader who doesn't know (much) C. For the same reason, I removed the static keyword that had been in front of loop(), since loop() didn't need to be static.

As for putting function names and return types on the same line: that's just normal practice, and again, doing it differently serves no purpose except to confuse non-experts. The usual reason to put a function name on its own line is so that you can find it with grep ^foo when it's part of a large project; but that reason clearly doesn't apply here, to this tiny sample.

Maybe the typedef doesn't help; I won't revert it again if you still think it's a bad idea. My thought was, again, "Think of the newbies!" (void (*)(void)) is highly confusing (as is (void (*)()), my preferred syntax), because it bears no resemblance to the syntax of any other programming language (C++ excepted). I think that it helps to give that type a name that indicates that it's a function type, and simplifies the cast syntax to (type-name) at the same time.

You may be interested in browsing Category:Articles with example C code to see how other articles' example code is formatted, if you haven't already. Have a nice day! --Quuxplusone 17:00, 22 May 2007 (UTC)

You misunderstand, "int main()", is not a valid function definition (ie, not a valid prototype) for main (at least in C99), the choices are either "int main(void)" or "int main(int argc, char **argv)" (or *argv[]). "()" is not the same as "(void)". And if it was, I could equally argue that missing the void out (making it implicit) was confusing to some. Putting functions types and return values on the same line is not really normal practice, it is a style choice, and changing it is an unnecessary change, although it is probably more common so I don't really mind it so much. The typedef really doesn't help, it just moves the potential confusion around and adds yet another piece of additional terminology (typedef), better a nice comment above the line explaining the cast is unimportant but required by C syntax. I'm not even sure if the cast is necessary, although compilers may warn if it is omitted.
This example is (perhaps of necessity) long and involved, I don't think any of these changes make any difference to its comprehension to C newbies or non-C programmers, and if it does, it really depends on what style they prefer. There is a mixture of example code format on Wikipedia and so long as articles are consistent within themselves I don't think they need to be conistent with other articles (like spelling). NicM 17:21, 22 May 2007 (UTC).
On looking again, I think I am wrong and main is special with regard to "()" ("main()" is permitted even though it is not equivalent to "main(void)"). Even so, I think it is inconsistent and I don't see it as less confusing, so I still reckon leave it as it is. NicM 18:00, 22 May 2007 (UTC).
Yeah, I'm wrong, the function definitions are equivalent and so it's fine. My bad, sorry. I'd still prefer to leave it though, it was the existing style and most everyone does include the void these days. NicM 18:23, 22 May 2007 (UTC).
The example as a whole is too long, I'm leaning towards the notion that the article would be better without it. Example code is easy to find for any function, we don't need to fill half an article with it. The man page linked to already has example code anyway. What do you think? NicM 18:12, 22 May 2007 (UTC).

I think examples are nice, but definitely this example is too long. I'd like to see a shorter version of this example, with fewer lines of code. IMHO it would also help to get rid of some of the inline comments in favor of longer, more grammatical explanations after the example, in the text of the article itself. --Quuxplusone 18:58, 22 May 2007 (UTC)

Yeah, a longer prose explanation would be good, although it has the disadvantage that it is further away from the code (use of "/* (1) */" "/* (2) */" can help with that though). Just so long as the code is explained somewhere. Removing the comments and merging a few lines makes the code take about 3/4 of a page at 1280x960 which still seems a bit much, not sure what else could be trimmed though. NicM 19:24, 22 May 2007 (UTC).

[edit] de Raadt

Please stop changing Theo de Raadt. It may be incorrect in Dutch, but this is the English WP and either style is acceptable in English, so there is no need to make this unnecessary change. NicM 11:22, 2 September 2007 (UTC).

Hi there, I think that there is a misunderstanding here. The issue is not the fact that this is the English Wikipedia; I'm fully aware of that. :) However, De Raadt's name is Dutch, regardless of his nationality. There are many South Africans with Dutch names due to its past. Afrikaans is actually essentially a slightly old form of Dutch. Names in South Africa that are of Dutch origin, such as De Raadt's, are spelled in a certain way that may be a bit confusing or awkward to people unfamiliar with it. You can find examples of this at Dutch_name#Tussenvoegsels (the "de" part of his name is called a "tussenvoegsel", and this is the part I'm talking about). The only exception is when people explicitly change their name to use the "tussenvoegsels" as middle names, but this is uncommon and I have not been able to find any indication that this is what De Raadt did.
Therefore, I would like to keep the version that I created, because it is simply the way that Dutch names are spelled, regardless of the language that's used. If you have any questions about this rule (which I can understand, since it's completely foreign in English), please let me know. :) —msikma (user, talk) 12:16, 2 September 2007 (UTC)
Yes, I understand that it is in the rule in Dutch, but I don't think it applies equally when writing English. I looked at this before, and couldn't find anything conclusive. For "de Raadt". a quick survey of interviews and articles with him are pretty inconclusive: Linux.com[1] and Peter Wayner[2] and some others[3][4] use "de Raadt", but the weighty Forbes[5] uses "De Raadt." The few style guides I found online are a little vague too, some of them don't mention it, some of them mutter about South African names and other exceptions. I'm pretty sure either is acceptable, in which case I don't see a huge reason to change (unless WP has a policy on this, but I can't find one :-/). NicM 12:44, 2 September 2007 (UTC).
Yes, it's unfortunate that WP doesn't have some kind of policy on this. It should. I still think that my explanation is correct, though. While De Raadt himself is a South African, he is also of Dutch descent, judging by his name. The name itself is a typical Dutch name, and the rule for Dutch names is as I have explained it. I believe that these rules are used in English by default when there is nothing in English that overrides it. In that sense, it would be similar to the plural of Tortellino, which is Tortellini, rather than "tortellinos".
Anyway, instead of guessing away, I'll just try to find whatever I can to see if there is some kind of rule that supports either of our arguments. :) —msikma (user, talk) 12:59, 2 September 2007 (UTC)
Interesting, there was a discussion about this on the talk page of Talk:Van_(Dutch). Ironically, the article itself mentions absolutely nothing about capitalizing it such as "De Raadt", while on the talk page, a strong case is made for this version. Specifically, the Greek Booklet is mentioned as a source that explicitly states that a so-called "tussenvoegsel", such as "de" or "den" or "van", is capitalized when it is not preceded by a name or initial. The Greek Booklet is the official guide to writing Dutch, and it is published by the Dutch Language Union. —msikma (user, talk) 13:13, 2 September 2007 (UTC)
Well, perhaps it is true that these rules should be used in English too, but to me it looks very odd and it certainly seems that lots of others use the current form (don't capitalise except at the start of a sentence) when writing English. Most people would instinctively do it that way. English does tend to be defined by how it is used, but maybe there is an absolute rule (Oxford Style Manual?). NicM 15:26, 2 September 2007 (UTC).
I just did a search for "manual of style dutch name" and found this: The Chicago Manual of Style Online 8.13: Dutch names (you need to register to see the contents, but you don't need to verify your e-mail address). What it states, though, is that the Dutch rule should be maintained in English when using Dutch names. —msikma (user, talk) 06:12, 3 September 2007 (UTC)
Well, that is at least one firm indication on one side or the other. Although it remains that lots of people do seem to do it a different way, and the Dutch way looks very odd and unintuitive to native English speakers, although that isn't a great reason not to do it.
I really don't know now; I have access to a lot of stuff through the open university library but couldn't find anything useful, so we really have only one link. With sorting (Wikipedia:Categorization_of_people#Ordering names in a category), the general thrust seems to be to follow the foreign language conventions although some of it seems a bit of a fudge ("Dutch/Flemish/Belgian/South African names are especially unpredictable." Heh.); there have been discussions on sorting all over the place, although mostly about "van" (1 2). However, there is evidence that lots of writers don't follow the Dutch convention for names in English text—although they could of course all be wrong. It is certainly unintuitive to native speakers, but I don't think that is a good reason to stick with the current form if it is actually incorrect. I'm a bit surprised there is nothing at all in the MoS about names, although I suppose this doesn't come up all that often. It may be worth bringing up somewhere else... not sure where (one of the MoS talk pages?), but at least to have more people's opinions on whether the English for it really is acceptable or definitely a no-no. NicM 12:28, 3 September 2007 (UTC).
Well, to me personally, the Chicago Manual of Style stating that this is correct is definitive. In Dutch, one also always keeps parts of the foreign grammar when using foreign words. Some reputable sources that I've read use the Dutch way of spelling names, since that's really just the way they're meant to be written. Yes, lots of people don't use the right style; I've seen some Dutch people do it wrongly as well. However, to me it matters that all sources that I've found so far that explicitly try to explain the issue will use the Dutch form. The Chicago Manual of Style does. The Forbes article that you linked to did. There's a blog about the English language that writes: "This is a Dutch name, not an English name, but the Dutch writing system doesn't use any characters that aren't found in English. Should I "transliterate" Harry van der Hulst to *Harry Van Der Hulst if I'm writing about him in English? Nonsense! I should spell his name the way he does, and if I don't, then he has every right to correct me. He should correct me gently, because I am contending with an unfamiliar spelling, but if I insist that I have a right to capitalize him against his will and custom, would he not have a "legitimate grievance"?" [6]. Truth is, I haven't found that many style guides that explicitly specify this rule (although I've found plenty of reputable sites and sources that use it properly), but I've not found one single style guide claiming the contrary to be true. As such, I'll bring this up at the village pump first (there's probably more activity there than on the MoS pages). —msikma (user, talk) 06:22, 5 September 2007 (UTC)
I'm not really convinced by the general he's-Dutch-and-it's-the-way-they-do-it argument, there are lots of names that are formatted or spelt differently in different languages (Londres vs London, for example, and Irish and Russian names are frequently reformatted and have spelling changed to English equivalents or to fit into the Roman alphabet). We aren't talking about changing the spelling of his actual name, merely the formatting style when the surname stands alone. I do agree the lack of style guides and newspapers/journals which use the English form is very indicative (the BBC does it too, and although I couldn't find many using "de", something like http://news.google.co.uk/news?&q=%22van%20Nistelrooy%22 is also heavily on the side of using the Dutch form), so I think you are right that it is the technically correct choice at the moment. I'm not wholly convinced the other way is actually incorrect: as lots of people do use it, it is at least de facto acceptable... style guides, dictionaries and suchlike do very often lag some way behind actual real-life English usage; the language is largely defined by how it is used, there is no central "authority" like the Académie française. In any case, since I agree it is technically correct and it is most likely better to be so in an encylopedia, if nobody at the village pump comes up with any objections, we might as well change it. OpenBSD needs to change too. NicM 09:21, 5 September 2007 (UTC).
To continue the discussion, I've started a new topic in the Village Pump. Hopefully we'll get some clarity then. :) —msikma (user, talk) 13:22, 8 September 2007 (UTC)

[edit] Straw poll to merge "Alternative terms for free software" to "Free and open source software"

Can you please comment at Talk:Alternative_terms_for_free_software#Survey. Thanks. --Karnesky (talk) 18:43, 23 January 2008 (UTC)

[edit] Branch Table

I only recently noticed that you had removed an IBM Assembler example of Branch table "because you didn't understand the code" and thought it didn't add anything (if you couldn't understand it, how would you know?).

Not understanding the code is presumably because you don't know IBM assembler language. This is hardly a valid reason for deletion. I don't know C too well, but I don't go around deleting examples of that on Wikipedia.

The example was demonstrating just how few machine instructions were required to achieve a considerable amount of processing in a very neat way that was aided by the Assembler to reduce errors.

Compiled languages don't illustrate this too well because the function calls often involve additional (hidden) processing such as push/pop of stacks that actually consume considerable CPU cycles themselves. Kdakin3420 (talk) 05:33, 4 February 2008 (UTC)

Looking at my example again today, I fail to see how you cannot understand it - since there are essentially only 5 Assember/machine instructions in it! The rest are either labels or simple data definitions, neither of which require much brainpower to understand. Not only that but each of the 5 instructions carry with them a clear and precise comment, on the same line, illustrating just what each instruction does (lacking in the C example) for the uninitiated.

My 2nd example illustrated a 2nd method of using 'branch tables' with a greater range of branching (64K compared to 4K) with half the memory usage in table size (2 bytes per entry instead of 4 bytes).Actually it allows a branch range of 256K if the labels are forced to be on a word boundary - which is accomplished by the Assembler very simply.

"Thrown out with the bathwater" was also a significant comment on compression of raw data to coded values (3 byte colour code representing 16 million colours). Also thrown out was the fact that indexed values can be used as record numbers for retrieval from a file instead of using a "key" which requires search/lookup. Kdakin3420 (talk) 05:59, 4 February 2008 (UTC)

My comment was, in fact, "i barely understand that code from the explanation and it doesn't seem to add anything substantial so rm it". You seem to have overlooked the second part of that comment. The code was:
  • extremely long (more than 3/4 of the article!). essentially five instructions is no good when it needs 29 lines of support
  • poorly commented
  • poorly explained in the text
  • did not substantially add anything to the article that a short, well commented example, such as the one I added, did not

Wikipedia is not a code repository, examples should be short, clear and to the point. Remember that most readers are not even programmers let along assembly programmers or IBM assembly programmers! I don't think we need extra examples to illustrate different types of branch tables, a simple note in the text somewhere would be sufficient, if it is a common or very different use—which the second example wasn't: we don't need to include things just because they are clever or efficient, Wikipedia is not a code implementation guide. The last history paragraph did not even mention the words "branch table"—there is no requirement that raw data be used to index into branch tables, it can as you say be used to index into files, but what does that have to do with branch tables? This article is about the assembly construct, it is not a general article on raw data or indexing. Someone has now added another big history section that is a bit more to the point but could do with a good tidy up (for a start, it doesn't include much actual history). Maybe you could look at this, but bear in mind the article is specifically about branch tables. Information just about other things (even if they are related) like indexing into files, or general coding of raw data, is not relevent. NicM (talk) 08:35, 4 February 2008 (UTC).

    • Never mind, I had a quick run through and merged/reformatted most of the content up into the main section. NicM (talk) 08:45, 4 February 2008 (UTC).
I totally disagree with what you are saying here:-
  • 1. Since the article is about branch tables, it follows that only people who understand Assembler level code would be interested.
  • 2. For the same reason, code examples for more than one single platform are useful
  • 3. It should be pointed out that the same technique , once learned, can be extremely useful in other instances.
  • 4. I do not believe I said that only raw data need be "input" to branch tables as you implied
  • 5. The second example (which had no earlier example code of yours) showed use of offsets rather than a branch table per se - but it is the same technique nevertheless and overcomes the limitations of a pure branch table in that a much larger range of code can be "branched to". Your example would have a limited branch range I am sure.
  • 6. I am incredulous that you say my code was poorly commented!
  • 7. Your comment "5 instructions no good when needs 29 other to support them" shows that you do not understand how to make Assembler that is self "correcting" (i.e. finds its own mistakes or avoids mistakes) and anyway most of the other (so called) "instructions" would be there anyway (labels, data definitions, branch instructions etc). See point 9 also on limitations with your example which didn't show how to construct the index and validate it at the same time (with a single instruction in my example!). The (translate) Table could have been created as a single string of hex code for simplification in my example but I chose to show instead a way to avoid errors in transcription by use of the ORG (Assembler) instructions to overlay the index values at appropriate places in the table based on their character values (A,M,D) -(i.e. these are not executed but resolved at Assembly time). All other places being filled with a null value (= invalid), giving a 100% failsafe validation and execution.

Your comments also demonstrate that you are not clear on the real significance of the 4/5 instructions - they are the ones that are executed for performance reasons. Even if it required 100 lines of what you describe as "supporting instructions" - the end result is better performance each and every time - which is precisely the goal.

  • 8. The point about branch table indexes being useful after having being utilized for the indexed branch was, I believe, worthwhile and may not be fully appreciated by many programmers.
  • 9. Your example does not validate the data at the same time as converting the raw input to an index

(my Assembler example does this - all in the same 5 instructions!, 4 if you exclude the final branch)

  • 10. Although you (now) mention limitations in some languages, you don't explain why or ways around this problem to enable its use and the limitations of those too, in ANSI C for example.
  • 11. It was I who added the new history section described by you say is "that is a bit more to the point" - that you have now also removed (I forgot to sign before adding it)

Perhaps it is your own lack of understanding that is providing your difficulties Perhaps the changes I made should be left for a while for others to see and debate upon rather than being deleted by you within hours of being posted. Kdakin3420 (talk) 11:45, 4 February 2008 (UTC)

  • 1. General programmers, students, people who are learning assembly and would like an intro, people who just happen to be interested? (Seriously, that is a ridiculous point. Are you saying only historians should be able to understand Nazi Germany?)
  • 2. No. A single example sufficient to demonstrate the concept is enough. This is not a textbook or a code repository. (By all means 2 or 3 good external links with some examples in other languages could be appropriate.)
  • 3. Wikipedia is not a textbook. If this should be included a couple of sentences could do it but I don't really see it as necessary.
  • 4. The old history section was entirely about raw data in general. It did not mention the phrase "branch table" or refer to them at all.
  • 5. This is irrelevent. Wikipedia is not a textbook or code repository. It may be worth adding a sentence saying something like "Different implementations may have different limits on table size" but another huge example is not necessary.
  • 6. Your comments may be fine for an experienced assembly programmer. They are poor for a newbie or unacquinted reader who would be better with a shorter example with much longer comments in proper English. This article is not teaching an assembly language, it is explaining a construct that is used in many assembly languages. Concise, code with clear English comments are better. Even my comments could do with improvement. Let's take a few things a newbie might ask:
    • "CLEAR REGISTER used for input value." What register? Why is this register never mentioned again in the comments after V1 is put in it? Why is "CLEAR REGISTER" in uppercase?
R1 is quite common equated register name -it is actually referenced a further 4 times in the next 3 instructions! If you are really picking on me for simply using upper case you must be quite desperate!Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
The comment does not say anything about R1. NicM (talk) 08:30, 5 February 2008 (UTC).
    • "CONVERT" value (to 0,4,8,12 etc)" What? Why 0,4,8,12? "etc" - we only have four? How does it convert it?
If you knew IBM Assembler you would know! "Etc" implies and so on ....of courseKdakin3420 (talk) 19:35, 4 February 2008 (UTC)
You do not need to explain this to me, you need to explain it to all the people reading the article who not not know IBM assembly language. NicM (talk) 08:30, 5 February 2008 (UTC)
I know what "etc" means, I do not know why you would choose to use it in an example which has only four items. This makes it unclear to the reader. NicM (talk) 08:34, 5 February 2008 (UTC).
    • "DS 0H" What is this?
If you knew IBM Assembler you would know! Its a quite common halfword aligned label Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
You do not need to explain this to me, you need to explain it to all the people reading the article who not not know IBM assembly language. NicM (talk) 08:30, 5 February 2008 (UTC)
    • "12 GO and DIVIDE V1 BY V2" Again, 12? Why? Is GO different from a branch?
I think you are being quite stupid here quite deliberately picking on petty differences
No, I am deliberately picking on petty differences that may confuse a newbie assembly language programmer. NicM (talk) 08:30, 5 February 2008 (UTC).
    • "DC 256AL1(0) TABLE of index values (set to "Invalid" = 00)" This is totally unclear.
not to an IBM Assembler programmer. It simply means define 256 x one byte length fields each with value 0!
Did you read the bit above where I pointed out not all readers are IBM assembler programmers? NicM (talk) 08:30, 5 February 2008 (UTC).
    • "V1 DS C Input value 1" Why C? Ditto for PL6, PL2 on the next two lines.
now I know you are being stupid!Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
No. Do you raelly miss the point this much? NicM (talk) 08:30, 5 February 2008 (UTC).
    • Why are sometimes ***, sometimes *, and sometimes no marker used for comments?
This is irrelevant - it makes sections of code stand out of course! In IBM Assember comments can be added on any line after leaving a blank or any line beginning an asterisk is a comment irrespective of how many other astersiks are on the same line.

If I were to explain the entire IBM Assembler language the example would be much longer stillKdakin3420 (talk) 19:35, 4 February 2008 (UTC)

The problem is that someone ignorant of IBM assembly language may well be unable to tell this. It is no use telling me, it needs to be clear in the example. You have hit on the exact problem: the example is already too long, and it is still not obvious enough! NicM (talk) 08:30, 5 February 2008 (UTC).
  • 7. This is rubbish. Please look at my example which demonstrates a branch table in 17 lines including verbose comments. Oddly, I managed to leave out all the stuff that would be there anyway. Probably because it demonstrates a branch table and only a branch table, not any other assembly feature or technique, no matter how useful or interesting. That stuff is not important for this article. This is an example, it is to demonstrate the basic concept of a branch table to anyone unfamiliar with it. It is not meant to be bulletproof, to demonstrate advanced features, or to be used in real code. It is meant to be short, clear, and easy to understand. Do you really not see this?
I think you are being deliberately stupid! bulletproof code is VERY highly desirable. I am not familiar with the code you used either. The important aspect is the efficiency of the algorithm whatever you pretendKdakin3420 (talk) 19:35, 4 February 2008 (UTC)
No, no, no! This is an example, what is desirable is not the same as production code. The important thing is that it is easy to understand, not efficiency or reliability. NicM (talk) 08:30, 5 February 2008 (UTC).
  • 8. Again, this is not a textbook. However, by all means put the point in prose if you feel it is useful and you can express it succintly. I don't really object to short explanations of useful points, but I don't think we need two 30+ line examples to demonstrate them.
your spelling is atrocious, you are generally unnecessarily rude and clearly believe your own publicity!Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
I think it is is pretty hypocritical for you to complain about either my rudeness or my language. NicM (talk) 08:30, 5 February 2008 (UTC).
  • 9. Validation is often good practice but in this case it distracts from the main point which is to illustrate the mechanism of a branch table. They work the same regardless of validation and in many cases it is unnecessary.
validation that is built-in is a design criteria for me. Most of my code has existed for 30+ years entirely bug free. You say it "works the same regardless of validation" but if your INDEX contained say "27" what effect would it have on your code execution?Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
I don't care about your design criteria, I care that the example is easy to understand. My example is just that, an example. It is not meant to be used in real code, it is meant to demonstrate the concept clearly to the reader. Which it does, and yours does not. If you had spent some of that 30+ years teaching or writing prose instead of coding you would understand this. NicM (talk) 08:30, 5 February 2008 (UTC).
  • 10. This is not a language textbook. I am quite happy to put in another sentence explaining the limitations of one language where they are notably impossible, but we need to be careful it doesn't snowball until we end up mentioning half a dozen languages. Branch tables are possible in C using arrays of function pointers.
yes, but are they as efficient, do they carry the new function housekeeping which I had explained?Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
It is not necessary to carry out the housekeeping to demonstrate the concept of a branch table. NicM (talk) 08:30, 5 February 2008 (UTC).
  • 11. I did not remove it, I trimmed it and merged the useful content up into the lead-in. I have included my comments on the points you think I have missed above and some of them I am happy to add. Are there any other points you think should be included?

Pretending I have a lack of understanding is not going to make my points less valid or your code examples any more suitable. NicM (talk) 18:37, 4 February 2008 (UTC)

You removed all the headings I inserted which broke up the free form rambling text of yours into more logical chunks.Kdakin3420 (talk) 19:35, 4 February 2008 (UTC)
Have you even read any other Wikipedia articles (try WP:FA), or even any other prose? Your sections were too short, they were badly titled, the grammar was poor and there was too much padding and some irrelevent/POV comments. You don't need section headings to break up paragraphs of two sentences or bullet points to show four one-sentence points, it's just wrong. The current article may ramble, but at least it is a step in the right direction. NicM (talk) 08:30, 5 February 2008 (UTC).
Its no use trying to persuade you on many of these issues, you are just plain WRONG.

I accept that I could always improve the comments a little but that would be at the expense of the length of the article and since it is likely to appeal mainly to Assembler programmers, this was I believed (and still believe) unnecessary. If I am at fault for my short sections in the History section, it is that I did not re-write the entire article to include more points from the rather long winded definition within those new headings. I had thought about that but thought I would leave it for the time being. However, your bombastic approach has made this impossible as no doubt you will delete everything I do to make the article better and exclude my example in favour of yours which doesn't even include conversion or validation - two issues which are important in letting people know an efficient method create the INDEX in the first place and making sure there are no wild branches. It is no use having a fast branch table if you have lots of instructions performing lookup or verifying input strings first!.The issue of "branch range" (if I can call it that as a makeshift generic name) is also important and not addressed in your example but was in mine. As I said previously, the performance issues of external functions is not addressed either (the "raison d'etre" of a branch table).

I have said this multiple times: none of these things are relevent to the operation of a branch table. It is a simple construct, the PC is changed to a position in a block of branches. This is ALL that needs to be demonstrated. The other things you mention are side issues, either of the assembly language used, or depending on the requirements. How the index is generated or the validation used (if any) depend on the circumstances and the example is not improved by cluttering the article with one particular way to do it, efficient or not. The key questions are: does this improve the article? Is it understandable to someone who does not know the language used? Could someone who didn't even know any assembler make a reasonable guess? This article is about branch tables, it is not entitled "cool ways to do branch tables in IBM assembler", or even "the RIGHT way to do branch tables in IBM assembler". I have never said your code is bad or made any comment about your coding experience, merely pointed out that these particular examples are currently inappropriate for this article. Nor have I said I would object to a return if you had been prepared to take my points on board and prepare a more concise, well-commented example; indeed, I accepted that several of your points were worth including and even at one point gave example text. I have been polite enough to explain my reasoning several times but all you have done is make accusations of bad faith, ignore or try to misrepresent my comments, make claims about my understanding and experience you cannot possibly substantiate, and generally try to avoid dealing with my comments. I am not going to reply further to you after this as I do not think we are going anywhere. I suggest you spend some time looking at other articles (particularly the featured articles at WP:FA) until you have got a good feel for how good Wikipedia articles are written and formatted and are prepared to be more constructive in improving this one. NicM (talk) 19:04, 5 February 2008 (UTC).
  • Analyzing my own 38 lines of code further, 4 were "executable code", 8 were pure comments, 6 labels,3 input variables and 5 branch instructions (the branch table itself) and a further 9 data definitions (all of of the very important translate table).
  • In your 13 lines, 2 were "executable code", 3 were pure comments, 3 labels, ZERO input variables and 4 branch instructions (the branch table itself) and NO data definitions for the translate table and of course NO translation and NO verification.

All in all, I think my example, despite your criticism, holds water and covers all the main issues. d) contains too much code to deal with side issues. NicM (talk) 19:04, 5 February 2008 (UTC). By use of a single machine instruction that translates the input, verifies it and (effectively) multiplies by four (without costing any CPU cycles) shows how powerful the technique is when used properly. Since the entire article is essentially about performance and memory saving, the issue you have ignored (housekeeping) is definitely relevant and you obviously don't understand this. I spent 30 years involved in producing (mainly) automatic test/debugging systems that found bugs in other peoples non-bulletproof code by the bucketload. I also taught Assembler, debugging techniques, database and wrote perhaps one of the first interactive spreadsheets in 1974 using Just-in-time compilation. All my software used INDEXed tables throughout, not only for branching but also for internal logic. see http://www.editgrid.com/user/ken/HISTORY_OF_SPREADSHEETS —Preceding unsigned comment added by 89.241.217.125 (talk) 10:24, 5 February 2008 (UTC)