User talk:NickyMcLean

Welcome!

Hello, NickyMcLean, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few good links for newcomers:

• The five pillars of Wikipedia
• How to edit a page
• Help pages
• Tutorial
• How to write a great article
• Manual of Style

I hope you enjoy editing here and being a Wikipedian! Please sign your name on talk pages using four tildes (~~~~); 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. Again, welcome!  Cheers, Tangotango 05:18, 27 April 2006 (UTC)

Floating point example

Greetings. I have made significant changes to your pi-as-computed-by-Archimedes example. It's a really good example, but I think that doing it for both the inscribed and circumscribed polygons is somewhat redundant and confusing. (It wasn't redundant for Archimedes -- he needed error bounds. But we already know the answer.) The fact that the numbers get close to pi and then veer away is a nice touch. I also used exact 64-bit precision, since that's "standard".

Anyway, I thought I'd give you a 'heads up' on this; I don't know whether this is on your watchlist. Feel free to discuss this on the floating point talk page, or my talk page. William Ackerman 00:54, 27 July 2006 (UTC)

Floating point -- edit conflict!!!!!

I just made a major edit to reorganize the page. (Basically, I moved the hideous "accuracy and misconceptions" section down next to the equally hideous "problems" section, so that they can all be cleaned up / butchered together.) Unfortunately, I got a notice of an editing conflict with you, apparently covering your last 2 changes: 22:03 30 Aug ("re-order for flow") and 22:08 30 Aug ("accuracy and common misconceptions"). Since my changes were much more extensive than yours, I took the liberty of saving my changes, thereby blowing yours away. I will now look at yours and attempt to repair the damage. Sorry. Someday this page (which, after all, is an extremely important subtopic of computers) will look respectable. :-) William Ackerman 23:07, 30 August 2006 (UTC)

It looks as though I didn't break anything after all. I got a false alarm. William Ackerman 00:16, 31 August 2006 (UTC)

No worries! I got into a bit of a tangle with the browser (Firefox), realising that I had forgotten a typo-level change (naturally, this is observed as one activates "post", not after activating "preview") and used the back arrow. I had earlier found via unturnut uxplurur a few days earlier that back arrow from a preview lost the entire text being edited so I didn't really think the back-arrow to add a further twiddle would work but it seemed worth a try for a quick fix but no... On restarting properly the omitted twiddle could be added.

I agree that floating-point arithmetic is important! I recall a talk I attended in which colleagues presented a graph of probabilities (of whatever), and I asked what was the significance of the Y-axis's highest annotation being not 1 but 1.01? Err... ahem... On another occasion I thought to use a short-cut for deciding how many digits to allow for a number when annotating a graph, via Log10(MaxVal), and learnt, ho ho, that on an IBM360 descendant, Log10(10.0000000) came out as 0.99999blah which when truncated to an integer was 0, not 1. Yes, I shouldn't have done it that way, but I was spending time on the much more extensive issues of annotation and layout and thought that a short cut would reduce distraction from this. In the end, a proper integer-based computation with pow:=pow*10; type stepping was prepared. And there are all the standard difficulties in computation with limited precision as well.

Floating Point cancellation

Nicky,

Why not align the calculation? And, despite JakeVortex's earlier statement, the round is AFTER the subtraction.

It would be fine for the example to cancel further (if that is what you are asking). I was trying to tie into an earlier example. Maybe we need to name the values. But I was trying to show that if you compute z := x + y (rounded to 7 digits) then w = z - x doesn't give you y back. And I don't understand your comment about the round AFTER the subtraction. The subtraction is exact, so the "rounding step" doesn't alter the value of the result. Thanks for the continued help with the page. ---Jake 21:16, 16 October 2006 (UTC)

Jake, Earlier I had appended an extension

Nearly all of the digits of the normalized result are meaningless. This is cancellation. It occurs when nearly equal numbers are subtracted, or numbers of opposite sign but nearly equal magnitude are added. Although the trailing digits are zero, their value could be anything.

This is the point that we need to tease apart. From the point of view of the floating point subtraction operation the trailing digits aren't meaningless at all. They have to be zero since the result of subtracting the two inputs is exactly representable. The issue that you are getting at shows up when trying to analyze the error introduced in an algorithm that involves a subtraction after some earlier operation which required rounding. Any this is why I say it isn't the subtraction that is at fault. if you can prove that the inputs to the subtraction are exact, then the result is also exact and no error has been introduced. What is happening with cancellation is that if you have some absolute errors in the inputs you might have up to twice the absolute error (or, more tightly, the sum of the absolute errors) in the result. Why this can be alarming is that the relative error can become very much larger, up to the point of being 100% when the returned answer is zero but the desired value is not.

The way you introduce here is close to significant figures analysis, or could be done more formally with interval arithmetic, but neither of these are what floating point arithmetic actually does.

My adjustment was to append "Although the trailing digits [of the result] are zero" etc, not wanting to mess with the previous author's words. I should have added the [...] part, but the example calculation with the ??? seemed to me to be a clear demonstration irrespective of any word tangles. NickyMcLean 20:14, 17 October 2006 (UTC)

The numbers entering the calculation are presumably not known to be exact values, so the calculation might have been described as

  e=1;  s=3.141600??????...
- e=1;  s=3.141593??????...
----------------
  e=1;  s=0.000007??????... 
  e=-5; s=7.??????...

which someone has whacked. Your text goes

  e=5;  s=1.235585
- e=5;  s=1.234567
----------------
  e=5;  s=0.001018 (true difference)
  e=2;  s=1.018000 (after rounding/normalization)

In this, clearly the subtraction has been performed, then there is the rounding/normalisation. Your edit comment "It is not the subtraction which is the problem, it is the earlier round" is unintelligible unless "earlier" is replaced by "later" (thus my remark), though I was wondering if you were meaning to put blame on the rounding that went into the formation of the input numbers (the 1.235585 and 1.234567) which if they had been held with more accuracy would mean that the cancellation would be less damaging except of course that there are only seven digits allowed.

Excatly, I was meaning to put the blame on the rounding that went into the formation of the input numbers.

In these examples, there is no rounding after the subtraction only the shifting due to normalisation. Thus I erred in saying that the round was after the subtraction since there is no round. After an operation there is the renormalisation step, which in general may involve a round first, thus the order of my remark. With subtraction, only if there was a shift for alignment would there be rounding of the result, and if there is shifting the two values can't be close enough to cause cancellation! A further example would have operands that required alignment for the subtraction (as in the earlier example demonstrating subtraction) and then rounding could result as well as cancellation. (Thimks) But no.

  11.23456
 - 1.234561 (both seven digit, and, not nearly equal)

  11.23456o (eighth digit for alignment)
 - 1.234561

  10.000009  (subtract)
  10.00001   (round to seven digits)

So, cancellation doesn't involve rounding. Loss of Significance (which does involve rounding, but that's not the problem), and Cancellation are thus two separate phenomena. Clearly, cancellation occurs when the high-order digits match (which requires the same exponent value) while rounding works away at the low-end digit.

The one exception to the usual finding that subtraction which results in cancellation does not involve rounding is if you have an operation which can accept inputs of wider precision than the result (or put another way, can round the result to shorter precision than the inputs). In such a case you can have both cancellation and proper rounding. The Intel X87 does this if you operate in short rounding but load 80-bit values onto the stack (or change the precision control with values already on the stack). But this is a nuance best left for a different page I would think.

The provenance of the input numbers is no concern of the subtraction operation and indeed would open up a large discussion belonging to numerical analysis. The action of loading high-precision numbers and then rounding to a smaller precision would be to me an additional operation separate from the subtraction operation, effected in pseudocode by Single(x) - Single(y), rather than say Single(x - y), though the compound operation would be the example of both cancellation and rounding as you have supplied. (I do precision abandonment in progs. that store data in vast volume as real*4 because the source data is known to be good to only one in 10,000 or so, but work in real*8 - the rule is of course round only the final result, not the intermediate calculations)

Undiscussed (as belonging elsewhere?) is the practice of "guard bits" in the hardware performing arithmetic. In the case of the 8087et seq which has THREE guard bits, it has never been clear to me where these might be stored (as on a context switch), but I've never had the patience to chase this bunny over the horizon when there are so many others to pursue. If these bits are not saved, then a computation will vary depending on what should be irrelevant: the execution of other tasks while yours is running. If they are saved, then there is a new floating-point format, of 83 bits.

We are agreed over what is happening (once we've been though through the details!), the difficulty is to phrase matters so that there will be clear, unambiguous, not misleading and misconception-crushing communication of that understanding to persons not already having it, all in the one sentence. Misunderstanding is easy; I misunderstood your remark's usage of "round" because it was the subtraction operation under discussion, not the origin of the numbers going in to it. NickyMcLean 20:14, 17 October 2006 (UTC)

The bit about z:=x + y; w:=z - x; relates more to the Kahan Summation algorithm, which I have also messed with though to less disfavour: perhaps WA hasn't noticed. I seem to have upset him.

This certainly is a step in the Kahan Summation algorithm, but my point was intended to clarify the more elementary observation that in floating point we do not have the distributive law: (x + y) - x == y

--Jake

Yep. I had even refined some of the details on the violation of axioms of real arithmetic (like, introducing the text x(a + b) = xa + xb for those who don't quite recall what the distributive axiom is, or maybe it was for the associative axiom), though as I type now, I don't know exactly what survives the current ferment. NickyMcLean 20:14, 17 October 2006 (UTC)

Interprocedural optimization

Hi. I noticed you were the original author of the Interprocedural optimization page. I didn't see any external references or sources to other websites. Perhaps you could put a note on the talk page if it is your original work. Thanks -Hyad 23:36, 16 November 2006 (UTC)

As I recall, there was some reference to interprocedural optimisation in some article I had come to, that led to nothing - a red link, I think. So (feeling co-operative) to fill a hole I typed a simple short essay on the spot. The allusion is to the Halting Problem (Entscheidungsproblem) which I didn't elaborate upon but otherwise the text is mine. A much larger article could be written on details, especially along the notions of "invariants" or other properties that a procedure might require or not, create or not, and advantage be taken or not in code surrounding the procedure invocation, but I stuck with brevity and the basics. NickyMcLean 01:51, 18 November 2006 (UTC)

Thanks so much for your response and for writing the article. It seems like an interesting topic. Too bad no one has touched it months; oh well. -Hyad 08:11, 18 November 2006 (UTC)

TeX

Hello. Please note that TeX is sophisticated; you don't need to write

$a<=b\,$

(as you did at trial division) if you mean

$a\leq b.\,$

Michael Hardy 15:32, 7 July 2007 (UTC)

Well... if it was so sophisticated, might it not recognise that <= could be rendered as a fancy symbol? And a further step might be that the "preview" could offer hints to those such as I who (in the usual way) haven't read the manual. Also, I now notice that in the "insert" menu below shown during an edit, there is a ≤ symbol. My editing is usually an escape from work-related stuff, that doesn't often involve TeX. But thanks, anyway. NickyMcLean 22:31, 9 July 2007 (UTC)

IBM 1620 operating procedures

Yes, few people these days have had contact with the old machines and therefore have not had to punch cards, interact with control panel lights and switches, typed on a console typewriter to patch a program, don't know the difference between 9-edge and 12-edge, etc. However detailed procedures along with the full rationale for every step of the procedure get tedious to read (much worse than actually doing it, which quickly became an automatic motor skill after you had done it a few times). Also one could go on endlessly with operating procedures. There were also multiple different ways of doing a procedure (e.g., There are actually 3 different "clear core" instructions for the Model I: the TFM version you listed, a TF version, and a TR version - plus variants of each of those) that were used by different sites. A short summary is probably more likely to be read and understood at a basic level than long detailed procedures with expanded "commentary". If someone wants more detail they can go to the online references given.

I am thinking of putting some limited implementation specific operating procedures in the IBM 1620 Model I and IBM 1620 Model II articles. However let me have a few days or weeks to think through an organization for the material to avoid getting it all cluttered. I also don't want to just copy procedures from the manuals that are already online and can be looked at if a person is interested. -- RTC (talk) 23:31, 25 February 2008 (UTC)

Ah, bury Mr. Watson "face down, nine-edge leading". One imagines that a "cladistics" approach could be used to trace the family tree of each method and deduce which site was the descendant of which, and follow the trail of the peripatetic researchers that spread each method! What I was thinking of was a "modern" reader who would have no idea that such a procedure is being followed under the hood of their quick-running pc (with its flickering disc drive light being ignored), and in reading a description of a fundamental and frequently-followed procedure would idly wonder why each step was required but not strongly enough to chase references. The youth of today... have missed out on so much fun. NickyMcLean (talk) 04:13, 26 February 2008 (UTC)

BTW, looking at the IBM documentation for the Model I, the only clear core instruction they give is the TF form 260000800009, so it is the original. One of the non-IBM textbooks on the 1620 gives all three forms. -- RTC (talk) 00:07, 5 March 2008 (UTC)

Proposed deletion of off-topic section in Extended precision

Please see Talk:Extended precision#Hyperprecision. -- Tcncv (talk) 02:35, 19 May 2008 (UTC)

Tide

Hello NickyMcLean. Thank you for your improvements on the Tide article. I noticed that some of your edits concern the national varieties in spelling, e.g. analyse and analyze. As I understand from the Manual of Style, see WP:ENGVAR, the intend is to retain the existing variety. Best regards, Crowsnest (talk) 21:12, 28 May 2008 (UTC)

Hi ho. I'd noticed the appearance of analySis (from lysis) and suchlike forms, which caused me to twitch at analyze rather than analyse. Oh well. I have idly imagined a html twiddler (such as The Proximitron) that would interconvert spellings automatically but alas, this sort of ploy fails in general. Imagine a web page discussing variations in spelling and how it would be fiddled, wrongly.

Yes, that would be funny. Happy editing, Crowsnest (talk) 14:56, 29 May 2008 (UTC)

Binary chop or Binary search

I only recently visited (i.e. stumbled across) this article and I am astounded by the apparent complexity of such a simple (and in my day ubiquitous technique) that seems almost an afterthought in today's programming world.

It is almost suggested that this technique is only a little better than sequential (i.e. mindless) scanning and sometimes worse than generating a hash table.

There are even better techniques such as indexed branch tables (using the searched for value as the index in the first place which is a perfect hash technique - effectively requiring no hash table building) that are not even mentioned! Locality of reference is also a vastly overstated issue.

What is even more astounding is that "professional" programmers can have a serious bug outstanding (and copied) for 15 years in a what is a truly ridiculously simple procedure!

The over exuberant use of mathematical formula obscure the utter simplicity of this method which is almost entirely encapsulated in the first paragraph and needs little more explanation.ken (talk) 21:30, 1 July 2008 (UTC)

Hi Ken. I have myself struggled with confused implementations of half-remembered binary search procedures in various computer languages, so I refer you to the quote from Prof. Knuth that getting the details right is "surprisingly difficult", simple though the method is. After one struggle in the 80s just resulted in frustration and failure (there are two objectives: that the search work and be fast yes, but also, that the expression of it be brief and lacking repetitive or special case code), I remember giving up and referring to Prof. Knuth's text to attain a working version, written in PL/I. Or so I thought. When I needed a version afresh a two years ago, I referred back to my old listings (the memory of the pain lingering still), and when later I checked, was bewildered to see that my version was not his. Perhaps this was due to a change in the revised edition of his compendium? No, his version is the same in a friend's copy from the 80s. The exclusive-bounds version I had is to be preferred for the reasons I give in the article, but I cannot now recall its provenance.

With regard to the astounding persistence of a fundamental error (discovered only after databases etc. had gathered more than 1,000,000,000 entries), I recall using the form p:=(R - L)/2 + L because I had used that on an IBM1130 (in assembler) and was well aware of overflow, but when I converted to using Victoria University's new Burroughs 6700 my fellow students insisted that I use the form p:=(L + R)/2 to save one operation and stop worrying, because the computer used 40-bit signed integers and so there was no chance of any array or file record indexing overflow given the storage capacities of the time. This incidentally means that we were using the inclusive-bound form of the method.

You might care to investigate the past history of the article: as with the QuickSort article, and I think with computer code generally, there is only a chance that code presented in a wiki article will work, not a likelihood. The continual revision of example code is what prompted me to present a flowchart, since it is less simple to fiddle with.

I too am puzzled by the assertions that a linear search would/might be faster, but they are due to some other author who (one hopes) is speaking from experience, hopefully well-analysed. Index calculation from the key works wonderfully with keys that happen to be as nice as say values 1 to 90000 with no gaps, but for irregular keys, I'm not so sure. There is an article on Interpolation_search which gives a horrible implementation that except in very special cases would be outrun by binary searching, and indeed I have remarked upon that in the article but haven't got stuck in to the details even though I have played with interpolation searches a bit. I may be misunderstanding what you have in mind though. You can of course make your own improvements to lay forth your insights!

There don't seem to be a lot of formulae to me, as the results are simple. But again, often misstated in detail, thus the graphs. Are you grumping about the proof of the method? I think it is needed even for so simple a method, precisely because mistakes are so easily made.NickyMcLean (talk) 22:42, 1 July 2008 (UTC)

Hello Nikky, There seems to be much too much emphasis on particular implementations of the 'technique' and catering for overflows etc. These should be part of the specific programming language/ hardware restrictions rather than covered at length in an article of this nature. As for detecting special cases caused by such restrictions, of course they should be part and parcel of the normal testing procedure in the anticipated environment. I recognize that many things are not 'anticipated' by programmers but this only goes to demonstrate their lack of adequate training (or ability).

You mentioned two languages that I am 100% familiar with (Assembler and PL/1). I worked mostly with IBM 360/370 architecture and to illustrate a point about indexed lookup (if it can be called that!), please see "Branch Tables" section in the WIKIbooks article 360 branch instructions. For short keys (or first part of longer keys) of one to two bytes, an extremely effective technique is to use the first character itself (or first two characters) as the actual 'index' to a table of further index values (i.e. for one byte key ,256 bytes table - giving extremely good locality of reference if table is close, or 32K/64K, at worst, for a two byte key). [1] I used this technique (multiple times) in almost every single program I ever wrote because most, if not all, of my programs from the early days after I discovered the technique, were table driven and in effect 'customized 4GL's' specific to a set purpose. My programs consisted of tables pointing to other tables that controlled and performed most of the required logic. The table processing code itself was fairly standard and so once written could be re-used over and over again without change (or bugs) until a special case occurred that was not covered in the existing tables. Any 'bugs' would be in the table specifications, not the programming. Parsing was a particularly fast and efficient process as it was usually simply a case of changing a few values in an table copied from a similar table used many times earlier and tested. I used the technique in my 370 instruction simulator which provided 100% software simulation of any user application program (written in any language) and included buffer overflow detection and single instruction stepping (animation). It had to be fast and the reason it was was that it used one and two byte indexing to the point of obsession. Its simulation 'engine' had zero bugs in 20+ years of use in multiple sites around the world executing time critical on-line transactions for customers. Similar techniques were used in the "works records system" I wrote (1974 spreadsheet for ICI) - it had zero bugs in 21 years of continuous use:- See [2] Bear in mind that for these and similar techniques, in general there were no 'stacks', recursive calls to sub-routines / 'memory leaks' or 'stack overflows' or similar. Many of today's languages use more instructions 'getting to the first useful instruction' than were used in the entire validation/lookup scenario (frequently less than 5 machine instructions in total). As far as I know, C for instance, does not have an equivalent technique that does not (ultimately) demand a sub-routine call in most cases(Please advise me if I am wrong on this and provide an example of code generated and instruction path-length!

Naturally my binary chop routines were generic and built around tables too. Once one table was tested thoroughly it could be re-used and invoked "ad infinitum" with any known limitations of the hardware and field sizes etc. already known.

Cheers ken (talk) 13:51, 4 July 2008 (UTC)

Aha! I detect a hard-core bit gnasher! My main usage of assembler was on the IBM1130, then the PDP11/PDP18, with some twiddles on a B6700 (we extended the Algol compiler to recognise B6700 assembler op-codes, ahem) and messes with the IBM360et al (I couldn't resist modifying BALR into BALROG when perusing assembler listings...), and finally with the intel crapheap, as seldom as possible. On the occasions I look at code provided by compilers, especially for intel systems, I wonder that this verbose drivel actually works. The productive instructions related to my computation (add, subtract, fsin, etc) are lost in an ocean of stuff that appears to be dealing with address space matters, but I haven't had the patience to look further. I'm not surprised that the progs. from Gibson Research (written entirely in assembler) have such good performance.

Once liberated from the IBM1130 or more precisely its its 64KB memory limit (32KB on the system at Victoria University), I too have used branch tables, sparing 256 elements of an array here and there. Thus to determine if a character is a digit, one can mess with if c <="9" and c >= "0" or similar, or, try if isdigit(c) where isdigit is a 256-element array. A bit painful for digits, but more useful for istokenish when scanning names that might include letters (caps or lower case), digits, and certain odd characters. Likewise to convert lower case into upper case (and only that) when not dealing with a restricted subset of the character collection. This sort of trick is frowned on by language purists who say that a character type is not usable as an array index and insist on type-conversion formalisms as their offering to free you from your sin.

As for proper branch tables, on the IBM1130 with 16-bit words and addressing I'd have a series of addresses, not branch instructions with that address (requiring two words), and use the indirect form of the branch op code with an index (as I vaguely recall, the indexing was done before the indirection but some other cpu might have been the other way around) to select the desired destination, though I have also used address computation, whereby to a branch instruction (in the ACC+EXT for 32-bit) was added the desired offset, and the result stored in the position of the following op code, whence it was executed. OH NO! Self-modifying code! Horrors!

So far as I know, only Algol68 includes such notions as procedures being manipulable. It offers arrays containing procedures (that is, an array containing the addresses of the procedure's entry point) so that this sort of trickery is supported, as in ProcedureNumber(i); as an executable statement, though I've forgotten the syntax and how parameters might be offered. But that sort of syntax is very convenient for simulations, where value 1 means "Load", value 2 means "Store", etc. Unfortunately, a great deal of past knowledge and experience was ignored by the devisers of C et al, even if they were aware of it, and the horde on the bandwagon remain unenlightened, murmuring that a case statement is all you need. I despise C, which means that I am out of step, and liable to rant. I have wondered whether with languages that supply a case statement, the compiler 'notices' whether the case selections come close to filling out all possible values of the selector variable (or a nearly contiguous portion of its range), and in that situation would generate code involving a branch table rather than a succession of "if" tests. Probably a dream, as go to-ish notions are frowned upon.

In a word-counting prog. (scan text, identify and count occurrences of words) I first converted the text by packing three characters into one 16-bit word (because there was no distinction between caps and lower case, and only a few extra symbols such as apostrophe and hyphen needed), but thinking that the occupancy of the 16-bit spread would not be high, used a hash table scheme. One hash table for one-word words, a second for two-word words, and nearly all English words will fit into a three-word package of nine symbols, so the five-word table was for words of thirteen letters and higher.

With regard to the article, the various implementations are not mine, indeed a while back my version, not being in C but in pseudocode, was promptly rewritten, and the error introduction/correction/re-introduction continued indefinitely. I must admit I was surprised to see a version that deferred noticing equality in order to avoid the double comparisons forced by the lack of a three-way test, so I suppose that its presence is worthy. I notice that the C versions use the (L + R)/2 form, without warning. This is safe only so long as the constraint is not forgotten, which alas, it usually is. When the section "Testing" was added a while back, I was not encouraged. Yes, testing will detect blunders, but it will not likely detect the annoying edge problems, nor be applied to monstrous collections (more than 1,000,000,000 elements for 32-bit variables) as surely, there is no need. Thus, the problem lurked unnoticed for decades. I'll bet that no-one's library examplar, despite being thought "fully documented" bothered to mention the constraint on N of max/2 if the form (L + R)/2 was used. This is not good practice, but the modern way seems to be that slackness prevails.

Regards, NickyMcLean (talk) 03:53, 5 July 2008 (UTC)

I have been trying to get my hands on a section of compiled 'C' generated code for actual examples of CASE/SWITCH statements but I haven't found anyone who can comply after months of asking around. It's no good asking me to compile my own because the complexity of setting up my PC to configure/download something I could actually recognize - that didn't also come with about 500 optional 'nuances' (of library x and DLL y thingies) this implementation v. that implementation, etc etc - all much too 'three letter acronymish' for me to want to fathom. If I want to use a word processor or a spreadsheet I download t and away I go - but to play with a language like C? I need a combined first degree in acronyms, knowledge of HTML ,XSLT, W3C (nth revision) WinZIP, LooseZAP, Tar, feathers, crunch, bite, pango, glib, Gnome, GDA, python, AJAX, DAZ and "baby bio" - you name it - just to get the source of the compiler for 'C', then I (think) I need to know how to install the 'C' compiler, compile it, before I can build my program to compile - or at least that's how it appears to me!

By the way:-

1) what is BALROG?

2) if you look at the branch table example I quoted, you will also see a 2nd example using two byte offsets achieving exactly the same purpose (but requiring one extra machine instruction).

3) self modifying code - I am sure I recently added a section to wikipedia article about this very subject but it has mysteriously disappeared along with its history of me putting it there! - a sort of self-modification or 'cosmic censorship' I think. Cheers ken (talk) 05:24, 8 July 2008 (UTC)

A Balrog is of course one of the monsters from the Lord of the Rings. I should have noticed the address-only table; I also have used a table of branch instructions. I imagine that ALGOL68 also includes arrangements for an array filled with addresses for a "go to" to select, in some syntax that didn't sink in from my glance through the language's description. I have considered augmentations of the article on self-modifying code; perhaps the purists are on the prowl and have a very limited tolerance for these improprieties. Actually, if you consult http://www.wikitruth.info/index.php?title=Main_Page you will see that editorial misbehaviour is common, starting from the top.

During a period of unemployment, I thought I should grind my teeth and develop some claim to C-experience (all part of mental prostitution), so I bought (mumble) a copy of "Teach Yourself C in 12 Days" (I forget the exact number) with the CD for installation on a pc belonging to the friend I was staying with. To my vexation, the book was with errors, both typographical and textual, even in the source code snippets and astoundingly, the instructions for setting up the compiler options for the test progs. using the dialogue box interface, were WRONG! Even so, I got the setup to work (on wunduhs98se), and my loathing of C was deepened thereby. Such stupidly error-promoting syntax! In the event, the whole debasement was unnecessary, as I found a job at the Culham Science Centre for JET, the Joint European Torus, this being a tokomak device for investigation into controlled thermonuclear fusion, and furrytran rules for serious numbercrunching. About as high-tech as one can get! And the CD is now lost.

As for the free compiler world, especially in the linux style, there is a maddening collection of stuff that has to be dealt with before you can even compare one to another. After using the B6700, I have an especial hatred of the gibberish in "makefiles" as just one example. Installation of working compilers produced by enthusiasts involves altogether too much mucking around. I specifically do not want to start with a simple C compiler to compile the source of improved C compiler that then is used to compile additional libraries and utilities to support the full installation, or similar exercises in vexation. Do your investigations require C itself? I can supply/direct you to various Pascal compilers, and their installation has not been troublesome. Mostly (at work) I use a fortran compiler (engineering/technical crunching) that however is closely connected to the C universe, since these days, everyone deals in C only, and so this must be right. There is a project for compilers for all (or most!) computer languages; its main ploy is to translate language x into C, sigh, and then compile that. Sigh. Care to guess how fortran's three-way IF statement might be handled?

I don't currently have an installation of some sort of C compiler, which suits me. Even if it is C++ that I don't have, or C# either.

Cheers, NickyMcLean (talk) 21:41, 8 July 2008 (UTC)

"If god had intended us to use modified code, he would have allowed the genome to evolve and permit Epigenetics" quote 9 july 2008 - you heard it first on Godpedia! The 'Works records System' (first interactive spreadsheet) had the bare bones of Fortran at its heart. I took Fortran and manually 'cut out all the crap', creating new code segments of a clean, re-entrant and "concatenate-able" nature which executed significantly faster than the original on extremely 'late binded' (bound?) data. It is entirely true to say that the resultant optimized code could not have been produced faster by a very competent assembler programmer - because I was that assembler programmer - and speed was my middle name! ken (talk) 20:10, 9 July 2008 (UTC) Afterthought. You might enjoy this link [3] I did and agree with most of it!ken (talk) 05:30, 10 July 2008 (UTC)

Years ago I recall an article about the DNA code for a virus in which the DNA sequences encoding the necessary proteins were overlapped. Thus the virus capsule, otherwise too small to contain the full DNA sequence if not overlapped, was adequate. It seems that assembler-style cunning is not a new trick. I also have become bitter about the ever-growing encrustations of crud in the computer world, but when I mutter loud enough to be heard, all I get are fish-face looks of puzzlement. After messing with assembler, and especially after using a stack-based cpu such as the PDP11, I look with suspicion at compiler language syntax and wonder what code will be generated, as opposed to what code might be generated. The B6700 had an unusually close relationship between hardware design and Algol software (procedures within procedures, in particular) but most modern cpus are ghastly. And progress is not delivering on the excited speculation. As a comparison, a while back I recompiled and ran a computation of e to 132800 decimal digits, written in Pascal, and roughly comparable to the assembler version I had written for an IBM1130 in the 70s. The calculation took 11 minutes, and with bound checking off, 6 minutes six seconds.

    Minutes taken
 Checking  No Checking
              900     IBM1130 (using assembler)
    24.96      18.83  Pentium    200Mc L1 I&D 16k        Wunduhs98
    32.7       20.4              266                     Wunduhs95
    11          6.1   Pentium 4 3200   L1 12k, L2 1024k  WunduhsXP

So, 15 hours on the IBM1130 in the 1970s are now worth 20 minutes on an IBM pc clone running at 266Mc with no SETI@home or other calculation also in progress during the test, but, under the control of wunduhs 95, a dark pit. This is a factor of 45, and not much for thirty years of development...

Advancing from 266Mc to 3200Mc, a factor of 12, reduced 32 to 11 for a factor of 2·9, or 20·43 to 6·1 for a factor of 3·5. The computation ran in one only of the four available cpus, the others remained idle. So much for seven years of Moore's law.

A Divide op code on the IBM1130 took about 20 microseconds as I remember, whereas the 266Mc ibmpc is about a thousand times faster, at a guess. So a lot of cpu power seems to have vanished. The IBM1130's operating system consumed no cpu time when a programme was running, except when invoked for some service such as disc I/O. This programme is not written in assembler however, but is the product of a modern compiler, and is afflicted with the inabilities of modern computer languages (Therefore, having to use mod and div to get at the 16-bit parts of a 32-bit result whereas in assembler, accessing the ACC and EXT registers achieved this)

"No matter how good the hardware engineers are, the software boys piss it all away" - thus spoke an IBM engineer...

Oh, and prompted by your remarks about self-modifying code, I added an example to the article because the existing example was not very exemplary, and lo! Both my and the existing example have been expunged.

Wairakei

Hello - could you please provide references for your addition? Thanks and happy editing. Ingolfson (talk) 06:42, 3 July 2008 (UTC)

A month or two ago, I was reading a paper on Waikato river water quality and it mentioned that the arsenic concentrations from natural sources (springs under lake Taupo, springs drowned by hydro dams, springs draining to the river) was such that the limit for human consumption was at times breached, and that Hamilton downriver treated its water with the addition of passing it over copper sheets (?) to capture the arsenic. There are also other nasty elements. I shall try and find it again. Ah well, not the actual article, but there are many others.NickyMcLean (talk) 21:01, 3 July 2008 (UTC)

Binary search

I tried to remove self-reference through the redirection — the Binary search algorithm contained links to Binary search article's sections, while the latter is a #redir to the former one. However your problems discovered to me the inconsistency in those links: some of them were capitalized, while actual section titles are all–lower case. In some magic way that makes a difference when addressing the same article's part and does not for cross–page links.
How does it work now? I changed all section links into a lowercase. If it is still bad, revert my last changes. --CiaPan (talk) 05:53, 18 September 2008 (UTC)

Works! I hadn't thought to check the case of the reference and the target. The "Exclusive" link continued to fail, but when I looked in the template and compared it to the article, there indeed was a difference in the case so I twiddled the reference to match. Possibly, someone had changed the case in the article, as I vaguely recall that it used to work... So we get there in the end. Thanks, NickyMcLean (talk) 21:38, 18 September 2008 (UTC)

Matlab SVG images

Hi Nicky!

Could you export your tide plots (and perhaps other plots you might have made) in SVG format and use them instead of the PNG versions in the articles? This is generally the preferred format for plots on Wikipedia. I think here's a free SVG exporter for Matlab: http://www.mathworks.com/matlabcentral/fileexchange/7401 Morn (talk) 01:55, 11 November 2008 (UTC)

Looks interesting, and I'll have a sniff around when work doesn't press... There would be less trouble if the facility were a part of MatLab itself, of course. As to the plots of tide heights as generated, the article I wrote on A.T. Doodson contains the MatLab script that I used to generate the plots so if you have access to MatLab, you can plot at will.

I'm using Matplotlib, which is Python-based, free, and very similar to Matlab in output quality and usage (if you use the pylab interface). It does all kinds of formats like SVG out of the box and migrating Matlab code to Matplotlib should not be that difficult. I think there's even an automatic conversion script somewhere.

As for the Doodson article, I think longer scripts and source code are probably better suited to Wikisource. If WP articles contain code as an example, it's usually just a few lines like "Hello World." So perhaps you should remove the code from the article, put it somewhere else and link to it, or pair it down to the essentials. As it is, the code on that page is only fit for computer consumption, but doesn't prove any obvious point that merits inclusion in the article. After all, the basic equations are explained in the preceding section, so IMHO there isn't any real reason to include source code... Morn (talk) 02:18, 12 November 2008 (UTC)

mathematical notation

In orthogonal analysis, I changed the first form below to the second, which is standard:

$<a,b>=\sum _{i=1}^{n}a_{i}b_{i}$

$\langle a,b\rangle =\sum _{i=1}^{n}a_{i}b_{i}$

TeX is sophisticated; there's no need for such a crude usage as the first one.

Also, one should not write a₂. The correct form is a₂. Digits, parentheses, etc., should not be included in these sorts of italics; see WP:MOSMATH. This is consistent with TeX style. Michael Hardy (talk) 15:53, 25 April 2010 (UTC)

Ah well, I don't use it often enough to be au fait with its sophistication, so thanks for your attention. Entire books (and well typeset!) are available on the subject, which I haven't perused. I see that "mediawiki" uses a subset of AMS-LaTeX markup which is a superset of LaTeX markup which is a superset of TeX markup. I haven't the patience to peruse these thrashings. For dabblers, a menu of TeX example formulae available via the "help" would ease the mental strain and could proclaim orthodoxy. As for the subscripts, I was thinking that the subscript is associated with its symbol and so should be in the same italicised style. And the subscript glyphs should be smaller too, but computer displays with about ninety dots per inch do not render such squiggles all that well compared to paper, such as F.B. Hildebrand's Numerical Analysis and many others. Staring hard, I see that indeed, subscript digits are not italicised. Humm, I've now decided that everyone else is out of step on this! For example if such a term is to be squared, the superscript should not be italic, but the subscript should. A theological dispute! See! I can split hairs with the best! NickyMcLean (talk) 21:06, 25 April 2010 (UTC)

Proposed deletion of Orthogonal analysis

The article Orthogonal analysis has been proposed for deletion because of the following concern:

No sources are given and much of the material seems to already be in other articles, e.g. Inner product space, Fourier series. A Google book search did not turn up results for the term 'Orthogonal analysis' used in this way so it appears that the meaning given in the article was created by the author. The style is unencyclopedic and reads like a personal reflection.

While all contributions to Wikipedia are appreciated, content or articles may be deleted for any of several reasons.

You may prevent the proposed deletion by removing the {{dated prod}} notice, but please explain why in your edit summary or on the article's talk page.

Please consider improving the article to address the issues raised. Removing {{dated prod}} will stop the proposed deletion process, but other deletion processes exist. The speedy deletion process can result in deletion without discussion, and articles for deletion allows discussion to reach consensus for deletion. RDBury (talk) 18:07, 29 April 2010 (UTC)

Why 365?

In the example here and mentioned in the current talk page? Thanks. --Paddy (talk) 03:17, 7 July 2010 (UTC)

Being as much as possible an actual example, some number had to be chosen rather than waffle about with "N" or somesuch. In 1970 the annual NZ death count due to road accidents was about 360, or an average of one per day. At the time I wondered about the probability of all deaths occurring on the same day, a Poisson distribution calculation that required 365! which of course immediately overflowed the capacity of IBM1130 floating point arithmetic (32 bit), thus leading to the computation of log(365!) via Stirling's formula. Then I wondered about accuracy, and wrote a prog. to compute factorials via exact multi-precision arithmetic. Thus the 365. Cheers. NickyMcLean (talk) 21:24, 7 July 2010 (UTC)

Thanks. --Paddy (talk) 06:14, 8 July 2010 (UTC)

License tagging for File:Geothermal.Electricity.NZ.Poihipi.png

Thanks for uploading File:Geothermal.Electricity.NZ.Poihipi.png. You don't seem to have indicated the license status of the image. Wikipedia uses a set of image copyright tags to indicate this information; to add a tag to the image, select the appropriate tag from this list, click on this link, then click "Edit this page" and add the tag to the image's description. If there doesn't seem to be a suitable tag, the image is probably not appropriate for use on Wikipedia.

For help in choosing the correct tag, or for any other questions, leave a message on Wikipedia:Media copyright questions. Thank you for your cooperation. --ImageTaggingBot (talk) 23:05, 23 August 2010 (UTC)

Oops, an oversight.

Tides

The centre of mass of the Earth Moon system is at about 3/4 of the radius of Earth. So if it played a role in determining the tidal forcing, the effect on the back side (7/8 from it) would have to be much different from the one the front (1/4 distance). In reality the only thing that counts is the gradient of the gravity field. This is only slightly different on front and back.

You are right in commenting that the horizontal component is even more important. There are two circles on the surface where the tidal force is parallel to the surface, leading to direct flow. It is difficult to work that in without interrupting the flow for the reader. −Woodstone (talk) 14:59, 18 January 2011 (UTC)

IBM 1130

Nice post-edit. I am uncomfortable with the large text that you moved, as the motivation for LIBF should come at the start and not merely be explained at the end. "Leapfrogging" is clever but I wonder if we really want to cover every technique to save words of code. Finally, the exclamation point doesn't look encyclopedic. Cheers. Spike-from-NH (talk) 12:43, 2 March 2012 (UTC)

Humm. I was thinking of the earlier flow, from the description of the op-codes to the consequences of the choices for that design, such as the contortions to save memory as represented by the LIBF protocol. In this regard, it seemed reasonable to describe the protocol, a seemingly normal arrangement, then, while the reader is still reeling in horror, show the payoff. I've been meaning to mention that integer division and multiply, though available as opcodes, could be effected via LIBF also. This complexity doesn't seem helpful in the introduction to LIBF as the parenthesis would expand. Further, I'd bet that the LIBF design came as a consequence of the machine code design, rather than being intended from the start - not that we have to follow the historical order, if it was so.

With regard to the style, I do feel uncomfortable about the intrusion of passive voice and pseudo-generality, hiding the actors and merely listing the results. I think it helpful to know who does what, thus the linkage loader does various things (with the assembler programmer conforming) because of certain consequences, not that merely various things happen and it be unclear whether the programmer of the assembler routine is doing the deed, nor why the various things happen the way they do. As for the exclamation mark, it is surely permissible to acknowledge some surprise that a function to compute OR does nothing of the sort! (now imagine that sentence ending .) There is no need to be drably mumbling in a monotone.

The leapfrogging for jumps to the return action was the beginning of an idea of explaining (as a further consequence of the op-code design) how code might be surrounded by data before and after, so as to remain within the -128+127 reach, indeed, code and data might alternate in a larger routine. Similarly, initialisation code might be placed in a work area that would be used later, as in the preparation for a double-buffered process. Though I never gained large benefits from this in my assembler routines. All a part of the memory squeeze. I first used the Auckland University's system that had 32K words, but on moving to Victoria University had much greater access to the 1130 with however 16K words. Many of us had progs. that only just fitted (after anguished reduction of arrays, messages, etc!) so that even a few words saved (as in my rewrites of the I/O drivers) made a very acceptable difference. NickyMcLean (talk) 20:56, 4 March 2012 (UTC)

Yup, I remember an assignment from Assembler class, to code a trivial routine in the absolute minimum numer of words, the solution being to put init code inside unused in-line parameters of a LIBF.

I've already post-edited such of your additions as I took exception to above, and this morning rewrote the example. If I added any unwarranted passives, please point them out or revert them, as I'm against them too. However, there is a middle ground between "mumbling...monotone" and stand-up comedy. Spike-from-NH (talk) 21:54, 4 March 2012 (UTC)

Ah, the close attention of the assembler programmer. I once re-assembled a prog. on noticing that a SKIP op-code was 0·3 microseconds faster than a B *+1 (by setting enough condition codes the skip became certain, thus +-ZOCE - also a useful pattern to spot during "trace" desperations) - not that I expected to notice the performance improvement, but on principle, and to acknowledge my noticing. I forget now the context where this was "useful" but I think it was within a prime number sieve. Just now I've looked afresh at the oddities of ZIPCO.

In the Digital PDP-10 stables, just after you learned that JUMPA (Jump Always) was what you should code rather than JUMP (which, with no suffix, jumped Never), you learned that the best instruction was usually JRST (Jump and Restore), an instruction that did a lot of miscellaneous things and, incidentally, jumped; as it had no provision for indirection and indexing, which was time-consuming even when null. These days, on the rare occasions I code in Pascal, I drop down to assembler only in the half dozen routines repeated most often; but once there, selecting the very fastest assembler code is still an obsession. Spike-from-NH (talk) 22:27, 21 March 2012 (UTC)

---

With regrets, I've reverted some of your most recent edit, including all of the details of the CARD0 routine. I think this section should be an overview of assembler programming, touching on the issues of working with device drivers but omitting details such as which bits are used for what and the sequence in which CARD0 does things. Also, as mentioned in the Change History, if a program is going to check for // before converting, then it checks the Hollerith code for /, double-slash not having a Hollerith code; I also restored "when simplicity is desired" (despite the passive!) as the general rule is that modern programming would not use asynchronous I/O. Spike-from-NH (talk) 11:30, 23 March 2012 (UTC)

Humm. I suppose I could have said something like the hole pattern of "/" in two columns, but thought that "//" requiring two columns did not need explanation. I still think that "hole pattern" is less obscure than the jargon "Hollerith". I was thinking of trying to explain that the fortran compiler used double buffering etc. and as a result it may not have been clear whether encoding had happened or not thus the test for both, possibly because the developers had encountered such confusions and rather than struggle with state marking and testing decided that to check both was simpler. I thought this an entertaining detail. Similarly, the CARD0 markings of not-yet-read columns. I'm not completely sure that ZIPCO honoured this though another, SPEED is described as doing so. If it did, then the ZIPCO invocation would make the loop testing that CARD0 reported "complete" unnecessary and indeed undesirable as the conversions of all but the last would have happened during the card input wait. But READ0 (for the faster card reader) did not do this pre-marking, not that I ever had access to one.

I don't agree with "when simplicity is desired" not just because of the passivity, but the concealment of just who is desiring what to whose convenience. That is, higher-level languages routinely do not provide any facilities for asynchronous operation, whether of I/O or computation. For I/O everyone is stuck with systems employing an unknown number of buffers at an unknown number of levels. On a Linux system I was greatly vexed by a prog. not writing debugging trace info to a file before the crash - it did write it, but to a buffer, and the crash did not entail a tidy flushing of buffers to disc IN FACT, so that when the trace file was examined... (After closing in on the suspect area, success was gained by writing stuff to the console, followed by a request for input (a blank line would do), which seemed the only way to be sure that the buffers for that output were flushed) Anyway, I have watched in annoyance while the FIND statement of fortran has vanished (asynchronously arrange that a file system buffer hold the indicated record, ready for a subsequent read), and the asynchronous I/O offered on IBM mainframe fortran (that I never got around to using) as such statements must have associated formalism to track progress. The Burroughs 6700 had such statements in its variant of Algol both for I/O and computation, but this was unusual.

In short, the near-universal provision of sequential I/O (but with hidden system buffering) is not a matter of the convenience of programme writers, nor simplicity, which is why I thought it better that the phrase not appear.

PS--But there is a factoid that belongs in the section on Asynchrony and performance, if it is true and if anyone can come up with a citation for it: Our computer center came to believe that if you simply coded a self-evident Fortran DO loop to read cards in the usual way, it would switch the card-reader motor on and off on every pass, so as to severely reduce its Mean Time Between Failures. Spike-from-NH (talk) 11:34, 23 March 2012 (UTC)

I'm not sure how that might reduce MTBF unless it had therapeutic effect. If say you think that z hours of motor running are between falures, then more motor-off time for the same number of cards would push the calendar point when z hours had been accumulated further away, and thus there be more calendar time between failures. However, I would suggest that the start/stop/start cycle would itself be wearing. As I recall, the card reader moved cards through various stages, with advancement being triggered by the cpu. A card being read meant that the next card was brought to the "ready" position, and as the motor rotated, the latch point to advance it through the read was just a few milliseconds behind. Once the motor had advanced past the latch-on point, no read action could begin until the rotation brought the next latch point around. There may have been additional modes, such as falling to half-speed rotation (I recall the pitch of the motor sound falling), but anyway, after a certain time as you say, the motor was turned off, only to restart on the next card read activation. I think there may have been two latch points per revolution of the card moving mechanism. Anyway, because of the ploddingly sequential I/O of fortran, a fortran prog. with its I/O formatting and etc. simply could not catch the latch and it did not take much number crunching for card reading to be so slow that the reader went into motor off/on/off/on cycling for cards.

One of my escapades after shrinking all the device drivers was to modify all the system I/O routines to include a parameter which caused them to test for complete, and if not, execute a WAIT op code then retest (which would be after an interrupt had dragged the cpu out of WAIT) - and yes, there did arise a very occasional WAIT after the interrupt had happened - once in a month of use that I heard of. This WAIT op code had an unused address field, into which I put a 1-bit in a position according to which device it was. The result was startling: during I/O the cpu lights were bright in the WAIT state (this is what prompted the voltmeter and other experiments) for surprisingly long. I had noticed similar "bright lights" when the IBM engineer was running his special tests and had enquired, and this prompted my initiative. This sight also inspired a friend/accomplice (Clive Nicolson) to further modify the I/O routines (with my WAIT stuff omitted to recover the saved space, and avoid the risk of an unfortunate WAIT) so that the card reader and line printer (needed by almost every user prog.) would employ unused memory as buffer space for I/O. Suddenly the card reader ran at full speed, as did the printer - until memory was full, and then matters proceeded according to the tide of battle between cards read, input consumption, output production, and lines printed. NickyMcLean (talk) 04:09, 24 March 2012 (UTC)

I concede your point on "when simplicity is required" and have removed the entire sentence that implies there is anything modern about unbuffered I/O. Also rearranged the previous paragraph, though it still has an excessive mix of strategy versus calling convention. Am disappointed you could not confirm my memory about the Fortran use of the card reader. It was indeed the rhythmic stop-and-start of the card reader motor that our guys and IBM engineers suspected was leading to so many service calls. Spike-from-NH (talk) 11:58, 24 March 2012 (UTC)

Humm, part of my urge is bitterness at the disappearance of overlapped I/O from "modern" systems, and annoyance at those who prattle on about old-time systems as being primitive compared to these wonderful modern incarnations. To puncture these inflations, I would like some remark about the options available to old-time programming being lost, but shall muse on a phrasing.

For the card reader, my point about passive constructions hiding causation and motivation arises afresh. I was unclear about your phrase and interpreted it back-to-front. I see now that you mean that the on/off operation did cause a reduced time between failures (that is, more failures per year, and also, more failures per hour of operation as well, probably), and suspect that the slow card reading provoked this. I wouldn't attribute schemery to the IBM designers to augment their company's income from engineer visits (or, by annoying the customer, provoke an upgrade to a more expensive computer) as being directly intended, perhaps it was another consequence of minimal circuitry price paring, and deemed an acceptable consequence amongst others. Well, not without explicit evidence, such as a deathbed confession from a designer. I don't recall our card reader being declared weak, and an annoyed engineer muttering about provocative on/off operation as such. But I do now recall card reader failures, and (when the system memory was suspect, so a reload was in order) hand-entering (via the bit switches) the bootstrap loader that could not be read from the card reader except that there was not a lot that could be done without a card reader - mess with APL for example. Entering jobs via the console keyboard was agonising because of the need for correct typing (all that stuff in specific columns!) ... this obviously happened often enough for there to be a number of occasions, and delay of much of a day (or more) before a fixit fellow arrived. So, come to think of it, there were many service calls for the card reader, it is just that no-one I heard ranted about the cause being on/off operation. Even though this surely would be a problem. I have a painful memory about killing an IBM1620 computer by fumbling the power switch on/off/on and damaging the power supply... Clive and I were unhappy about the on/off excessiveness, but more in the way of throughput impedance, and it being something we could do something about. I think we could remark now that the on/off operation did provoke an excessive failure rate for the reader. A definite support statement would require operational data from actual card readers in different environments, such as being attached to systems that maintained long surges of activity. IBM engineers might know this, possibly provoking their remarks to you, but our engineers made no such remarks to me that I can recall. Clive unfortunately died early this month from prostate cancer.

I don't accuse anyone of treachery when there is a simpler answer, I know how big organizations work, and IBM was always, famously, the biggest (outside the military). There would have been little ability of Card Reader Engineering to communicate to Fortran Development about the fact that the compiler, in its most typical use, would overtax the card-reader motor. (At DEC, managers hoped for interdisciplinary meetings at The Pub across the street for cross-pollination to detect problems outside the chain of command.)

If I confused you, it was not with a passive (in the technical sense), but you have just stuck one into the article, which I massaged.

We are both treading close to the line of being hit by the guy who slaps templates at the start of articles condeming "original research." We are not supposed to dump our own memories on these pages but document things the reader can verify, and go beyond, by reading the citations. The last time this happened to me, I decided that I did want to do engaging writing and not just Google searches and went to Uncyclopedia for a couple of years to write humor. Spike-from-NH (talk) 22:09, 25 March 2012 (UTC)

Yes, there is a principle along the lines of do not attribute to cunning what could just be bungling. As for my phrasing, the CARD0 routine is responsive to the action initiated by the card reader's interrupt (yes, previously initiated by CARD0) so I wanted the idea of CARD0 passively waiting for events, with the text following the chain of causation: interrupt - CARD0 recognises it (and adjusts an internal state) - subsequently, another query to CARD0 - because of that state it returns one step further on.

So far, the explications can be justified by wording in the various manuals, and as I remember there is even mention of speed shortage for faster card readers and the standard (shorter) translation routines though for the nitpickers, there is no statement contrasting the tradeoffs (as I have just done) that I recall. Reports of experience of on/off running and slow reading speeds are also a reasonable inference from the document that should fend off the "citation needed" obsessives, but a remark about on/off provoking frequent repair calls, which I now think is likely true, alas lacks explicit admission in the IBM documents I've seen and thus might be declared unsupported and thus "original research". I've been frustrated by these assertions elsewhere, especially in the Binary Search article since all the texts do not describe the better version ("exclusive bounds") or the reason to avoid (L + R)/2 and no amount of careful explanation, true though it may be, is allowable to these purists. In a related article ("Interpolation search") the method offered (itself without source) is clearly derived from the inferior "inclusive bounds" version, and has a bug, and all my careful explication of a much better version with examples was ejected as OR, even though the existing method is without reference. I was peeved enough to remove my corresponding OR from the Binary Search article, which is also a mess. Of course (and as was suggested), I could perhaps have a suitable article published in a recognised publication, and then all would be well. So I too have at times retreated from contention... According to the orginator of WP there is a principle that rules shall be ignored as needed, but any application of the overrule merely excites the purists.

It seems a pity that so much experience is being lost, even if the details are only of interest to those who attend to details. For instance, one of the code twiddling assembler provisions of odd functions was for XOR, and I noticed that the op code for XOR *-1 was /F0FF, oho. Now, if the bits that were zero were inverted (their on/off ness is an arbitrary hardware choice, so far as I can see) so that the op code became /FFFF then that would be the equivalent of a NOT, an operation not otherwise available, unless you reserve a word somewhere ALL1 DC /FFFF and use XOR ALL1 to do the deed in one operation. The only bit pattern constraint for opcodes is to have zero correspond to STOP (on the chance that unused memory will be zeroed, and a leap to a wrong address might more likely find a zero) so here we have a single one-word-saving trick that settles the bit pattern for the opcodes. Well, everyone agrees that floating-point numbers should represent zero with the same pattern as integers do. Anyway, I think I contrived to find an opportunity where XOR *-1 did what I wanted, as the lower eight bits were of interest only, thus acknowledging this minor discovery.

You have indeed devised an opcode that complements the low-order byte of ACC, though it takes an extra memory reference. The incantation I remember is LDD *-1 \ STD *, which even made the keyboard abort impossible and required a reboot.

It doesn't seem a pity to me that we are losing expertise at this (and the kindred expertise at fitting subroutines into 128-word pages on the DEC PDP-8), as the brainpower is now being applied to more useful things. My father once lamented the waning of American manufacturing and I asked him if he would prefer good American typewriters over his quadruple bypass.

Writing a paper and then citing yourself on Wikipedia is a solution, and one I think is used more often than some people let on.

I recently recoded my venerable BASIC interpreter in Pascal. The result executes statements faster than the 1130 could move single words, would never have trouble getting an algorithm to fit in 64K, and runs fine on a used laptop that costs $50. But it is not the best approach to any problem one would have nowdays. Spike-from-NH (talk) 21:53, 26 March 2012 (UTC)

XOR *-1 does take an extra memory reference as compared to a direct NOT op-code if there were one, though one could mumble about the cpu/memory interface possibly having a small buffer and noticing that it already held the word. Extra circuitry, though. As for LDD I did indeed scheme to arrange that a zero be stored at an odd address, so that LDD ZERO would get 32 bits for the cost of one word as a constant not two - possibly another opportunity for cpu/memory interface trickery. If I follow your LDD *-1; STD * correctly, and the LDD was at an even address, then a red carpet would be unrolled through following memory and wrap around from high to low as well. But if at an odd address, then the LDD would obtain two copies of LDD, store both of them at the odd address following the STD, execute the just-placed LDD (again from an odd address) and then there would follow whatever was in memory, no carpet. As LD *;STO * would also unroll a red carpet, possibly I'm misinterpreting your incantation. I recall some friends chortling over ploys for causing a pdp-16 to overwrite all of memory, and my suggestion of MOV -(PC),-(PC) elicited "You bastard!" from Bruce Christianson.

The loss of expertise still troubles me, and a lot of what Prof. Knuth wrote about is being ignored. (Yes, I know, my experiences are valuable, the modern generation's experiences (of wunduhs coding minutia, sneer sneer) are worthless) I feel that an expert knows a lot about some subject, but a scholar knows all there is to be known about that subject, so experience demonstrating principles should not be abandoned, especially if it gave rise to the statement of those principles. I'm reminded of J.W.Campbell's story Forgetfulness (~1935) in which some visiting aliens report 'His answers were typified by "I have forgotten the development-" or "It is difficult for me to explain-" or "The exact mechanism is not understood by all of us-a few historians-"'

In 1998 I recoded in turbo pascal the computation of e (to 132,800 decimal digits, essentially 32768! downwards) in binary using 16-bit words, that took fifteen hours on the IBM1130 with assembler, and later tried the pascal prog again on a still-faster pc:

 Checking    No Checking of array bounds
   minutes        900     IBM1130 (using assembler)
    24·96          18·83  Pentium    200Mc L1 I&D 16k        Wunduhs98
    32·7           20·4              266                     Wunduhs95
    11              6·1   Pentium 4 3200   L1 12k, L2 1024k  WunduhsXP

So, 15 hours on the IBM1130 in the 1970s are now worth 20 minutes on an IBM pc clone running at 266Mc with wunduhs 95 and no SETI@home or other calculation also in progress during the test, but under the control of wunduhs 95, a dark pit. This is a factor of 45, and not much for thirty years of development...

Advancing from 266Mc to 3200Mc, a factor of 12, reduced 32 to 11 for a factor of 2·9, or 20·43 to 6·1 for a factor of 3·5. The computation ran in one only of the four available cpus, the others remained idle.

Your red carpet beats mine, as it doesn't have the odd-address restriction. The guys who thought up my incantation wanted the red carpet to still be functional after it rolled out, but there's no need for that. Your incantation for the PDP-11 is the classic one.

Regarding amount of a corpus that one knows (or thinks one knows: No one can know all the applications of knowledge nor its effects in each application), your statements remind me of Donald Rumsfeld's widely ridiculed conundrum that "often you don't know what you don't know." Being troubled by the loss of expertise is part of what turns men unwilling to throw away anything and accumulate huge stores of tools and connectors. I still have lots of EPROMs, just in case. But I did part with my EPROM programmer.

A speed improvement of 45 seems low, but it's an improvement in only one dimension. Another dimension is the improvements that allowed us to own our own "mainframes" and operate them in dusty rooms without air conditioning. Spike-from-NH (talk) 22:50, 28 March 2012 (UTC)

Dedicated low addresses

My post-edit of you was because, regardless of whether what is at /0001 is XR1 itself or a copy, it is the existence of a memory address for XR1 that enables the register-to-register moves as described.

The table documented /0000, although it is dictated by convention not by hardware, because we refer to it in two other places. But the information you appended to the table strikes me as open-ended; we ought not set out to describe all the variables in the Skeleton Supervisor--though I'm contemplating gathering all the material about long Fortran programs together and mentioning the INSKEL common area. Spike-from-NH (talk) 02:22, 4 April 2012 (UTC)

I too was wondering about a "complete memory map"! One of the assembler options was to incorporate the SYSYM (or similar mnemonic), the symbol table for the system, that provided mnemonics for various addresses of various items. I recall that my punching a deck for the skeleton supervisor led to some actions so as to update that table. For example, some variables contained the address of the first free word of memory, another was the number of the first free sector of disc storage and their exact location might vary and in any case, are better referred to by name rather than absolute address. These and many more were maintained by convention. However, the 1132 printer scan area was a fixed area, scanned by hardware, and so seemed a suitable entry. I don't recall what was to be found in nearby memory nor what might be done if there was no 1132 printer. Low-address memory is always a candidate for oddities. The Auckland university system had a 1403 printer, and the scan area was unused, except for a PhD student who built a hardware floating-point arithmetic unit to attach to the IBM1130, that used this area for communication with the cpu. Suitable floating-point arithmetic routines then replaced the standard and used the fancy unit at a saving in storage space, and also a gain in speed though alas I recall nothing of the details other than talk of crystallography which was in vogue at the time thanks to the recent availability of number crunching to scientists via the likes of the IBM1130. Possibly, the communication area could be anywhere in memory, or possibly, the cpu hardware that had arrangements for such communication was specific to those addresses of the scan area only.

I'm uncertain about the hardware details as to whether the in-memory aspect of XR1-3 facilitated anything as such, since obviously, hardware can contain arbitrary circuitry. The design decisions would have included minimal circuitry costs but I know little of the options! Another part of this was the encoding opportunities allowed by the design of the opcode format, and compactness, and circuitry sharing, etc. so that MDM was an extension of MDX enabled by the format of the opcodes containing a two-word version, so, what might be done with this opportunity? Thus the opcode tag 00 meant IAR or XR0, and 01-11 ment XR1-3 in an obvious system, and opcode choices may open or close options. For instance, LDX 1 v loaded XR1 with the literal value v, not the word at IAR+v. So then, what of LDX 0 v? This would mean jump to the absolute address v, whereas the normal jumps were to an offset: IAR+v. Thus, when in low memory addresses (or high memory), special tricks of addressing might be possible. Similarly, is the B L x really a LDX 0 x? I'd have to look carefully at the bit patterns, not just the mnemonics.

I have a copy of R.K.Louden's book Programming the IBM1130 and 1800 and have been contemplating transcribing his 3-d noughts&crosses prog, since it included interesting information on memory utilisation (tiny!) and because I work with fortran at work, I could try it on a "modern" computer to see what code file size is produced, etc. for comparison. But actual work does get in the way...NickyMcLean (talk) 20:58, 4 April 2012 (UTC)

The B instruction is not really LDX L0 (6400xxxx) but seems to be a synonym for BSC (4C00xxxx) with no modifier bits set. Separately, I can't discern the difference between BSC and BOSC. Spike-from-NH (talk) 15:23, 8 April 2012 (UTC)

Op codes and mnemonics are intertwined in odd ways and I recall being puzzled at times and at other times noticing variant mnemonics delivered by the same opcode but with different tags, etc. I have been contemplating a schedule of bit patterns to resolve this detail, but I shall have to consult manuals. There are only five bits for the opcodes, so no more than thirty-two possibilities at that level. I think BOSC stands for Branch Or Skip on Condition, and BSC stands for Branch or Skip on Condition; in other words a synonym accepted by the assembler, though if so, why would it bother given the extra code needed to implement this equivalence? But again, close reading of manuals is needed. One thing to watch out for is the special return from interrupts, as it restores condition registers (overflow, carry, etc.) whereas the normal return from subroutine does not and again I'll have to peruse manuals.

I see no return-from-subroutine instruction in the 1130 Reference Card, and claim the writer of the interrupt service routine must have done it manually. But that's problematic too, as LDS is not the reverse of STS; the Reference Card defines only four opcodes (concerning carry and overflow), and the operand is immediate. Spike-from-NH (talk) 23:07, 9 April 2012 (UTC)

IAC

I don't know where I got this. Probably from some other processor, but I can't think which. Thank you for the correction (to IAR). Now, in my new section on "Large Fortran programs," is "phase" the correct term for a program that chains to another program to continue a single task? Spike-from-NH (talk) 00:24, 8 April 2012 (UTC)

I thought it was me that typed IAC (Instruction Address Counter) instead of IAR but no matter, I retire that guilt. Possibly PDP-related, except that the PDP-11 used PC. The use of "phase" for the compiler's successive stages was certainly found in discussion with Clive and probably based on some manual's usage, and was also used in the pl/i compiler on ibm mainframes, as I recall killing the compiler a number of times with the error message blah blah "in phase PI" which I thought might be somewhere between phase three and four. Whatever, the word was phase. In the case of user progs. the command was CALL LINK as I recall, but I don't recall how you named the prog. CALL LINK FRED2 perhaps? or CALL LINK('FRED2') seems more likely. As this was a matter for users, I don't recall there being an agreed terminology as might be introduced by the manuals. I'll have to peruse them...

Could have been your mistake, I don't know. I had assumed your Change Summary was accusing me, so I gracefully copped to it. "Phase" is indeed the term for one of the partial processes on the way to a compilation, but I don't know if it's the right term for a program that LINKs to another to complete the job. Spike-from-NH (talk) 23:07, 9 April 2012 (UTC)

Ah, the nuances of reading what was written and not what was thought to be meant. I though I was admitting to the mistake, not accusing anoyone else! Clearly, an inquisitor is needed to obtain a clear confession.

Trapped at /0

I think you are wrong to have deleted the alternative: "until an interrupt reset the machine". The average interrupt would not reset the machine, nor would prevent the infinite loop from resuming after return from interrupt. But I recall that it was usually possible after such a stuck job to use the interrupt key on the keyboard to cancel the job and seek through card input for the next job card. Spike-from-NH (talk) 20:50, 15 April 2012 (UTC)

Humm... In the case of say interrupts from the card reader, if a leap to zero had happened before a card had been fully read they would continue until the last column was read, followed by an operation complete interrupt, and in every case the return from interrupt would be to zero, because the interrupt would have been accepted after the BR *-1 had adjusted IAR to zero, but before the next BR*-1 had been executed. On the other hand, the console keyboard had a key "Int/Req" (that is "Int" above "Req") and when pressed it generated a level four interrupt (just as with other key presses) but was special in that the rest of the keyboard was dead. In this case the interrupt handler jumped instead to a location in the skeleton supervisor (/54 as I recall) which functioned as "end job, load the // interpreter". Thus, interrupts did not reset the system (though they would drag it out of a WAIT opcode), they were merely processed as normal providing that the relevant memory hadn't been scragged. Similarly, the IntReq key was intended to interrupt a long-running job (such as my calculation of e to 132800 digits, 15 hours) to cause it to activate code to produce a report and possibly unlock the console keyboard to obtain instructions for the particular job, perhaps some sort of process control, or other monster whose progress might be in doubt or in need of guidance. Thus, the IntReq might set a flag and return, but the running job would check that flag at convenient points, or, the enhanced interrupt handler might prepare a report (riskier, but entertaining: I started the console printer then prepared the progress numbers in the print buffer, knowing that the deeds would be complete before the characters were reached in the character-by-character console printer action, indeed if you pressed IntReq again before the line was finished, it would print "Piss off twit!", except on my first try I bungled the state changes and the system locked into a loop printing "Piss off twit!" and the computer science boss happened to wander in... IntReq would not of course stop this prog, so it was the "Immediate Stop" console button and I lost the accumulated computation effort in the mess). Anyway, nearly all applications made no use of this facility, so especially in a batch job state, its action was to kill the current job, as you say. This would fail if the current job had scragged the code of the skeleton supervisor! But unlike the other device interrupts, the IntReq key would only be pressed by a human operator. At Auckland university, I twice saw the Parity Error perspex square glow a beautiful red light, on two successive days (at ~3:15pm, light reflected from a neighbouring building's glass wall streamed into the computer room and fell on the cpu cabinet leading to overheating suspicion, however, on both occasions the same user prog. had been running, and it had died at the same point (printing the same line, at least) leading to suspicion that a particular word had been referenced with a particular pattern of bits in a particular cpu timing state, but although the operator protocol was to note down the pattern of lights on the console display to report to IBM, this wasn't done and nothing came of all the speculation and on the next day the same prog. at the same scheduled time ran, and it was cloudy...) and pressing IntReq flushed the job and all continued nicely except for the unhappy user.

Anyway, in the context of the article, it was the operator action that reset the machine, via a special and non-standard response to an interrupt, whereas ordinary interrupts had no such effect. Possibly further rephrasing would help?

Have now done so. Indeed, it was not "an interrupt [that] reset the machine" because most interrupts wouldn't; it was the Int Req key, and thank you for remembering its legend. Incidentally, the thing about the "red carpet" we discussed that really conferred bragging rights is that it wiped out the service routine for Int Req and forced the operator instead to remove the cards from the reader, manually identify the offending job, and reboot. Spike-from-NH (talk) 00:43, 17 April 2012 (UTC)

SUBIN

As with transfer vectors, it looks as though I am about to learn something new about the 1130 that they tried but failed to teach me in 1973. But I want to remove a great deal of technical detail from your contribution. Most notably, you walk us through how a Fortran subroutine could be coded--except that, apparently, it's not. Presumably, it's coded as a bunch of LD *-* and STO *-* ready for patching by SUBIN--and never an ADD instruction referencing a parameter, as your hypothetical code suggests. Given the state of the 1130 in current computing, no one needs such a detailed walk-through of the operation of SUBIN, nor of an error message you say almost never occurs. The only point of looking so deep under the covers is as another example of self-modifying code. We need a clearer summary of what the goal was: I infer that it was the replacement of hypothetical, triple-memory-access indexed instructions by direct memory accesses. After my read, it is astonishing that, for typical subprograms, this autopatching ever resulted in savings of time or memory. It isn't clear where SUBIN gets called; I infer that the call is the first instruction of every Fortran subprogram with parameters. Finally, your text implies that IOR could not be written at all. Surely the answer is that IOR was written in assembler and thus was immune from the gentle mercies of SUBIN? Spike-from-NH (talk)

Hi Spike. I remember being bewildered at the usage of SUBIN, but there's a reason which I shall explain in yet more text that I omitted, and remembered as I walked off to the railway station. I must admit that I never scrutinised the code as produced by the Fortran compiler, as disassembly was not easy and I had no particular urge to pursue in that direction, though Clive certainly used the disassembler and growled about its inability to reproduce the names of the locations/variables in the original source (this could be done for B6700 code files) and I suggested that reproducing the original explanatory comments would be even better. He also devised a scheme that would allow the run-time concoction of fortran FORMAT statements (essentially finding the stored text of the FORMAT statement and replacing it with new text) because it turned out that the statement was saved as actual text (that had been checked by the compiler) that was interpreted from scratch when a READ/WRITE statement invoked it. With regard to IOR it did work, and would work in subroutines as well so long as parameters were avoided, or at least for the first argument for IOR's speific case, as its usage of supplied parameters would be zapped by SUBIN as with all other usages of the parameters. SUBIN was indeed the first call at the head of every subprogram (function or subroutine) unless unneeded (a function of a single parameter or no parameters) and it seems to me that SUBIN is a spectacular example of startling code zappery. I see from the WP source that there is a comment that "code modification" uses this as an example, so I suggest detail is worthy. But I shall adjust my text as mentioned.

I have tried to apply a smoother mount and dismount, and to use two subsections rather than one. I still don't think we need a complete walk-through of a routine, given that we had just slogged through the typical calling protocol in the previous section. Spike-from-NH (talk)

And thank you for your post-edits. I took issue with only one thing: No one should need more than the most cursory mention in the prose about what intermediate code the compiler produced before SUBIN patched it. Spike-from-NH (talk) 21:53, 6 November 2012 (UTC)

I've had a go at some rephrasings. I preferred the memory access count to be of those words to get at the operand, not including the word for the op code itself and the loading of the operand, so as to boost the difference between indirect and direct but that is only clear with the details. The whole SUBIN protocol still puzzles me, because although there would be a performance gain from direct accessing, it comes at the cost of fiddling all the addresses and, the increase in the table size to finger them all. Since memory was at a premium, that hurts! I think it would be satisfactory for usages on integer parameters (load/store/add/subtract?) to remain as indirect accessing, so that SUBIN need assault only those references where parameters were passed as arguments to other subprograms (such as the floating-point routines, though LIBF calls were also used for integer divide and multiply - I've read, but not followed the details) thus saving on space and fiddle effort. But the few references to SUBIN I've found and my faint recollections of verbal description of SUBIN never mentioned any discrimination between integer and fp parameters or references that were as arguments to further routines. Yet on the other hand, I have clear recollection of staring at the glowing lights, in particular the lights indicating usage of XR1, 2 and 3. XR1 would be dim but in use (as would XR3) and this was clearly understood to be due to Fortran code (XR1) and library functions (XR3), yet if SUBIN were adjusting all parameter references there would be little call for XR1 to be used as in the putative code that wouldn't exist, except for XR1 usage within SUBIN itself and any of the LIBF routines. Humm. Anyway, I made a point of having my assembler routines favour XR2 that was otherwise dark, so that I could gloat over its glimmer. If I had ever examined the code of a subroutine, then there would be definite recollections, but alas...

Whoops, this conflicted with your remark above. [--NM]

Sorry to walk on you (as they used to say in Citizens Band Radio). We are converging. But at the end of this section, we've done so much writing about heuristics and patching that I felt it necessary to say that the copying to a local variable is done by the subprogram's (human) author and not auto-magically. One other thing: I wrote "four in the case that the index register were not implemented as a memory location"--Is this the same thing as writing "four on the IBM 1800"? Spike-from-NH (talk) 22:36, 6 November 2012 (UTC)

At the risk of walking on you again: My other change is because it is outlandish to have Fortran code appear as the comment of a line of assembler, though your meaning was clear. Spike-from-NH (talk) 22:41, 6 November 2012 (UTC)

Index registers were not registers

One of the IBM1800 extras was that XR1-3 as well as XR0 were actual registers, not memory, but I didn't think that this needed mention in an article on the IBM1130, thus I just mentioned the extra memory access needed. As for SIMPL, I thought that it should be explained that here SIMPL did have a parameter since the simpler SIMPL previously mentioned did not. Your in-text mention is more appropriate than my in-assembler miscegnation. I've twiddled the text for the copying of a parameter to add mention of the possible need to copy it back, but I am not happy with its phrasing. This copy in/back has subtle implications that often do not arise, that are a bit lengthy to describe in the article. Basically, if a parameter is available in more than one way (being supplied more than once as in CALL FRED(X,Y,X), or, available via common storage (with its own name) as well as via a parameter) then there are disjunctions possible due to the local copy not being in sync. with the other availability. By reference (by actual address) means that any change to the parameter at once changes the other availabilities as they are all references to the same thing and thus necessarily in sync. Alas, the linked-to WP article is filled with turgid blather reflecting the influence of over-generality and languages used for theorising about formulae. Anyway, not to the taste to a furrytranner corrupted by assembler and machine code and memory and registers and bits.

Oh, I don't like this at all. The sentence gave advice to the programmer on a technique to coexist optimally with SUBIN, probably of benefit to no one ever again, even if a working 1130 is found, as that guy on the talk page asks. Your additional text gives the programmer the additional advice not to hurt himself doing so. I would prefer that you strike the entire sentence. It is all true, but such a detailed how-to on actually undertaking an 1130 programming project is excessive (and further temptation to the gadflies who patrol for Original Research). Spike-from-NH (talk) 20:44, 7 November 2012 (UTC)

Righto, I've abated the remark. I recall the advice expressed generally, by lecturers and so forth, though I don't have a written reference to hand. I'm off for some morning tea, so a pause...

Fine; I only added a comma. But declaring advice to be "the standard advice" is the type of language that impels some Wikipedians to demand a citation that I am sure you cannot provide.

Now, I have been perusing your other recent changes and, again, your insistence on specifying exactly how the index registers were implemented (register versus core) is too much detail for current readers. I understand you spent much brainwork figuring out how to save cycles in routines, a skill I too wish were as important as it used to be (though we both benefit enormously from the fact that it is not). But memorializing this, though it fits with my concept of Wikipedia as a global repository, does not fit with the dominant view of Wikipedia as an encyclopedia. More relevant to me, our article is also all there is on the instruction set of the IBM 1800, where the index registers were registers. Spike-from-NH (talk) 22:55, 7 November 2012 (UTC)

It seems to me that a "general reader" might be slightly surprised to read that a "register" was in fact not a harware register but a memory word and thus would gain information. These days, micro and picocode complicates discussion of "hardware" and introduces "firmware", and there's all the fun about various levels of in-chip memory and instruction memory buffers, etc. since the machine code is really being interpreted by the microcode with all manner of tricks. Making choices between constructions is much more difficult, and actual testing likewise, all complicated by what various compilers might do in various circumstances and with various options. Even so, in the past year I have secured a 25-30% speed gain in a data cruncher due to a discovery about some stunningly stupid compiler code that could be evaded by a slightly more complex but equivalent statement (whose appearance in other person's progs. had puzzled me: they had not alas documented the reason!), and a factor of three was recovered when a conversion to a more modern formalism (the use of a data aggregate with named components, rather than a collection of seprate components with similar names) turned out to involve passing an array not by reference but by copy-in, copy-out. In this case, inlining the not-so-large code for four binary searches enabled the use of the aggregate's organisational improvement but dodged the copy-in/out. I have yet to follow through in checking certain other usages similar to that. As ever, the compiler manual did not bother to describe the circumstances whereby copy in/out would (without remark) be used in place of pass-by-reference, contrary to the normal usage.

In other words, I am frequently in need of detailed descriptions, because advised by such details, significant gains are possible and significant losses may be avoided. Thus, I tend to want to see carefully-worded and detailed descriptions, which also constitute examples of general principles and demonstrations of the presence of subtle problems. I remember discussion of "revolver" code - this was a computer whose working memory was on a revolving drum of magnetic material, with multiple fixed heads. Op code execution was not sequential; every op code contained the address of the next op code, which would not be the following memory word (it already having rotated past the read/write head) but one cunningly chosen to be at such a distance related to the execution time of the op code, that the destination address would shortly be revolving into the reach of the appropriate read head. Similarly with the location of the working variables. There would be significant opportunities for cunning, and, exhaustion of patience. Whee!

More specifically, I tried a google search on SUBIN and copy parameters (and already, the article's mention of SUBIN was high in the results list!) but alas, no helpful references to quote. I think the "standard advice" phrase could be removed, just leaving the attribution vague. Indeed it is also implicit in the meaning of the text, given that the reader thinks of "local copy?" - but will this come to mind? I recall an ancient Indian proof of (a + b)^2 = a^2 + 2ab + b^2 via a diagram, and the annotation BEHOLD! Clearly, this author expected his readers to initiate their own thinking, though possibly he was gloating over his concise generality and brilliance. Too many WP articles seem to me to be written in this way. The discussion of the IBM 1800 is brief (I never used it, so no effusions from me!) and does mention three hardware index registers but does not mention this difference from the IBM1130. A casual reader would find the appearance of "hardware" there as superfluous, since surely, a register is always a register-in-hardware, otherwise it is not a register. I think the IBM1130 being unusual in this should be mentioned here and there, and "repetition is central to learning".

I see in other parts of this talk page I have twice quoted a comparison of an IBM1130 running an assembler prog. calculating e to 132800 digits equivalent, so I mutter darkly about how modern computer software pisses speed away. Oh well, wait another year and a faster computer will turn up for the same, or less money. But yes, I spent a lot of time twiddling the assembler routine, far more time than I spent twiddling the versions for later systems.

Very well--though I think the typical use of this article is to read about the 1130, not to learn how to program it (with such details as would let the reader write optimal code). Now, back at the last sentence of your SUBIN submission, the problem recurs in the newest wording that we can't tell who is copying that parameter into the local variable. I reverted it to approximately what we had on Tuesday. (This also reinserted the clause, "to increase speed and reduce memory requirements", to which I'm not especially attached.) Spike-from-NH (talk) 23:23, 8 November 2012 (UTC)

Ah yes, I'd forgotten that the agent of the change might be taken as the cunning compiler. I think the pretext ("to increase...") could reasonably be inferred from the text and so be omitted.

Then I will do so. Spike-from-NH (talk) 01:05, 9 November 2012 (UTC)

"Subroutine"

For our next trick: I see that the article is seriously sloppy about the use of the term "subprogram" (which, according to Fortran, comprises "subroutine" and "function"). I'd like to add this convention in passing and correct each use of "subprogram" and "subroutine" to be the correct one. Spike-from-NH (talk) 01:05, 9 November 2012 (UTC)

This is now done--but a second pair of eyes is always welcome. Spike-from-NH (talk) 23:58, 9 November 2012 (UTC)

Yes, that's bothered me also. Found one. I've always vacillated between "subroutine" which seems to me to be the general word that could be interpreted by a general reader, and the more fortran-specific "subprogram", though actually I prefer "subprogramme" just to be picky. Clearly, sub-something is desired, but the something could be a programme, or more vaguely a "routine". The trouble is that when talking about example subprogrammes, the actual word in the source file is "subroutine" and this would be a source of conceptual dissonance, thus elsewhere in the article, "subroutine" remains, as in the example program which contains an actual subroutine, and this is mentioned in the text, even though the subroutine is in fact an example of a subprogram. Yet on the other hand, function subprogrammes should not be excluded when they also are examples of being a subroutine. Agh.

Well-spotted! So, as we now say at the start of Section 3, "subprogram" comprises both "subroutine" and "function." "The actual word in the source file is 'subroutine'" only when that source file defines an instance of the subroutine type of subprogram. On other definitions, the actual word is "function". The US spelling seems appropriate, as US grammar is followed elsewhere in this article about a US product. Spike-from-NH (talk) 23:43, 11 November 2012 (UTC)

Jensen's device

If you don't have sources for a topic, then you should not be adding material to an article. Under WP:BRD, once you've been reverted, you shouldn't try to step the material back in, but rather you should bring it up on the talk page. Stepping the material back in runs the risk of edit warring and WP:3rr violations. My sense is you are puzzling exotic argument passing out for yourself. That's a good thing to do, but that does not mean the answer that you develop should be put in the article. Sadly, Jensen's device does not mention thunk (functional programming). Glrx (talk) 23:52, 26 June 2012 (UTC)

The original attempt contained different parts, all of which were reverted indiscriminately. I agree that the original and textbook discussions of this idea do not concern themselves with such details as what might go wrong when it is misapplied, obviously because they are concentrating on the advantages of correct application. Likewise, compiler manuals rarely discuss implementation details that can be quoted by those suspicious of the details, such details as by which I have many times been vexed. I don't have an algol compiler to hand or other language that features a call-by-name facility to try, and anyway, if I were to do so, that would be decried as Original Research as well as being restricted to that particular implementation. Both points could arise naturally in the mind of anyone who reads the article with attention to detail because indeed, the variable "i" is not initialised in the example calling routine (nor need it be), and, the usage with "i" shows a value being passed back by assignment to an internal variable "i", and "term" being another variable in the called routine, the same could be done to it, but surely with rather different results if it is attached to an expression. A decent compiler&linker might, might catch such usages: I can imagine it done and have dealt with compilers that did make obvious checks but also with compilers that do not check even the number of parameters. As you say, neither point is mentioned in the source articles. Similarly not mentioned is the point that variable "i" need not be passed as it is available as a global to the called routine. Why it should be a parameter would need further expansion. Likewise, how pass-by-reference would suffice for variable "i". All this would be apparent to the authors and experienced readers of the textbooks, who would not want to be impeded by such details. Is WP to aim for encyclopaedic coverage? Or, contain cryptic allusions to material found in textbooks; let those who go astray in ignorance or inattention educate themselves via their own Original Research. I can easily imagine a reader of the WP article going astray. Evidently, that is to be their problem. I had hoped that someone with access to an implementation might be able to clarify these details, maybe even with the authority of an approved source having described this. But it is easier to excise and ignore.

I hit ye olde university library, but could not find any decent explanation for formal variable assignment. I expected to see the variable "i" passed lexically rather than as an explicit formal argument, but contemporary sources have it passed as an argument by name. At least two sources gave the double summation example which only works with distinct variables. All the refs were clear about using thunks to evaluate the argument, but they all skipped over the assignment issue. There was complete agreement that assignment to variable passed by name was an assignment, but no description of the mechanism. Several sources pointed to a problem implementing swap(i,A[i]), but the exposition was not clear. They showed naive code failing by using the Copy Rule, but there was no claim that problem could be fixed by using two temporary variable (essentially a parallel assignment). Knuth in CACM 10 claimed increment(A[i]) could not be written, suggesting that the Algol 60 definition has a different view of assignments to expression -- and that there is a more fundamental problem with swap(i,A[i]). Glrx (talk) 20:09, 2 July 2012 (UTC)

Ah, university. I recall friends prattling on about pass-by-value and Jensen's device but never being clear on implementations. As my studies involved Physics and Mathematics and were untroubled by newfangled courses in computer science I did not have a lecturer to berate in a formal context where a proper response could be demanded. Pass-by-name was described as being as if the text of the parameter were inserted in the subprogramme wherever the formal parameter appeared. I saw immediate difficulties with scope and context (the expression may involve x, which was one thing in the caller's context and another quite different thing in the function: the equivalent of macro expansion would lead to messes) but never persuaded the proponents to demonstrate a clarifying understanding. As I was not taking the course and didn't use Algol, if they couldn't see the need for clarity I wasn't going to argue further. I was particularly annoyed by talk of the evaluation of expressions whereby parts of equal priority might be evaluated in any order; for me, order of evaluation was often important and fully defined by the tiebreaker rule of left-to-right (and also, I wanted what is now called short-circuit evaluation of logical expressions), so I was annoyed by Algolists. I can imagine an ad-hoc implementation involving special cases that would cover the usual forms as described in textbooks, but not in general. Thus, parameter "i" may be noted as being both read and written to in the function, and on account of the latter its parameter type could be made "by reference" and all invocations of the function would have to be such that the parameter, supposedly passed by name, is really passed by reference to deliver on bidirectional usage and that expressions would be rejected as being an invalid parameter manifestation. However, the second parameter, also passed-by-name by default, is seen in the function to not be assigned to, and so its type remains "by name" and thus all invocations within the function are effected by leaping out to evaluate the expression in the calling statement and returning (rather like coroutines!), even if the calling statement presented only a reference such as "i" rather than say "3*x*i^2" - in other words, the expression produces some result, an especially simple notion on a stack-based system. That is, some parameters are seen as expressions, even if having exactly the same presentation as parameters that are references and not expressions. In this circumstance, an expression such as inc(i) as the first parameter would be rejected. As a second parameter, it would be accepted, but there would be disruption over the workings of the for loop whose index variable is "i" - does the loop pre-compute the number of iterations, or, does it perform the test on the value of "i" against the bound every time? But Algol offers still further opportunities: it distinguishes between a variable and a reference to (the value of) a variable, and, "if" is a part of an expression. Thus, "x:=(if i > 6 then a else b) + 6" is a valid expression, the bracketed if-part resulting in a reference to either "a" or "b" to whose value six is to be added. Oh, and expressions can contain assignments to variables as a part also. I suppose this is where there starts to be talk of a "copy rule" for clarification, but it is not quite the style of "macro" substitution.

In the context of the article, I suppose there needn't be mention of what might go wrong (as with an expression for the "i" parameter) as we don't know what might actually go wrong only that surely it won't work, yet references are unclear. NickyMcLean (talk) 20:34, 4 July 2012 (UTC)

There is a pass-by-text, but pass-by-name avoids the accidental capture of scoped variable names; there is an environment/display. Call by name is not call by reference. Glrx (talk) 17:36, 4 July 2012 (UTC)

I'm well aware that call-by-name is not call-by-reference. I was trying to indicate the equivalence in the case of an actual parameter being a simple variable (and a simple simple variable: not an array reference such as a(i) where "i" might be fiddled) so as to enhance the contrast for the case when the actual parameter is an expression that returns a result, which in turn is different from a statement such as "increment(x)" which is not a legitimate parameter as it does not yield a value. Potentially, readers are familiar with call-by-value and call-by-reference and so could take advantage of the comparison. And yes, I do not have a text to hand where such a discussion exists in an approved source.NickyMcLean (talk) 20:34, 4 July 2012 (UTC)

Floating point error in Mathematical optimization

Thanks for your note. I was referring to 'minimization' as in 'optimization'. The specific problem I'm working on is from 5 up to 100 dimensional fitting of experimental data using a fundamental kinetic model - an error minimization problem. I'm using the BFGS method which needs a numerical derivative since my problem is far too complex to solve analytically. I was considering the accuracy of a four point solution since it may accelerate convergence but realised that since I was using forward differences, I could try central differences first to get the h^2 (better than h) error. This did not improve convergence and in fact slowed everything down by a factor of 2 (~double the number of function evaluations), so accuracy of the derivatives is clearly not the limiting factor in convergence. Clearly in this case a 4 point derivative estimate would simply be 4x slower than forward differences, but it would be great to see the error reduction in the graph.

I know all about the dangers of floating point, my solutions start to degrade in accuracy at h < 1e-7. If only they had thought ahead about the needs of technical / scientific computing when defining doubles. Intel has the build-in 80bit format but it is maddeningly difficult to work out when it will use it or not - at least in a C# environment. Changing one variable from function local to class local can completely change the accuracy & result of the optimization as it drops from 80 to 64 bit representation. Doug (talk) 19:14, 26 November 2012 (UTC)

Yes, the C-style was not devised with much attention to floating-point. In serious computation, fortran is capable of being very clear as to the precision for variables and computation (with clear type names such as REAL*10), and has special functions for recognising precision. But these notions are barely acknowledged in the modern world. There are also compiler optimisation features to worry over, such as reordering evaluation sequences, and misguided application of mathematical identities when floating-point doesn't quite follow mathematical axia. I accept that /2 can be replaced by *0·5, but not that /10 by 0·1, for example - unless on a decimal computer, I suppose. A special trick is register re-use recognition as in x:=expression; y:=x + expression; and similar. The expression might be calculated in REAL*10 but stored in x as REAL*8. In the next statement, possibly, the REAL*10 register value will be used for x (saving a load from x), or possibly, the REAL*8 value will be reloaded from x. Some compilers do not attempt this, others acknowledge an optimisation option.

At a higher level, I would need a fair amount of study to have anything specific to say about your problem. Leaving aside tricks such as over-relaxation, for my part my only attempt at a multi-dimensional minimisation problem follows F.S. Acton's "Numerical Methods that Work - Usually" in not attempting to follow derivatives when they are difficult to compute analytically. But also, he explains that the local "down", even if perfectly computed, is not going to point towards the minimum. The idea is that close to the minimum the function is going to be flat, and numerical calculations of the slope are troublesome, involving differences between nearly-equal values. The plan is to straddle the minimum, evaluate at three positions (not too close), x - h, x, x + h, fit a parabola (thus being equally-spaced positions along direction h) and locate its minimum, closing in untill there is no significant change in F (easy to say) or no significant change in x - in that case, the last h is still intended to be large enough for good differences, and the estimated minimum position is hoped to be good (and within +-h) but alas in in a region where more local evaluation will stutter, so it is not attempted. From the starting position to the straddle has to be organised, and the text describes a scheme. I added also a requirement of bounds on x, which means a fair amount of additional messing. My problem was choosing the optimum value of DC power transfer for DC links in an AC power network, so as to minimise the transmission loss: the DC links had of course limited capacity. In other problems, the function may not be smooth across arbitrary bounds but "explode" outside the bounds. Solving the AC power flow problem was itself a minimisation problem, with a (sparse) NxN matrix of nodes where power enters/leaves the network requiring a NxN F' estimate via [F(x + h) - F(x)]/h because analytic slopes were impossible. Fortunately, an entirely different method has been developed for that part of the problem. So my minimisation was for the DC connections only. Not the same dimensionality as your problem!

Proposed deletion of Gavin Smith (author)

The article Gavin Smith (author) has been proposed for deletion because it appears to have no references. Under Wikipedia policy, this newly created biography of a living person will be deleted unless it has at least one reference to a reliable source that directly supports material in the article.

If you created the article, please don't be offended. Instead, consider improving the article. For help on inserting references, see Referencing for beginners, or ask at the help desk. Once you have provided at least one reliable source, you may remove the {{prod blp}} tag. Please do not remove the tag unless the article is sourced. If you cannot provide such a source within seven days, the article may be deleted, but you can request that it be undeleted when you are ready to add one. Lakun.patra (talk) 18:21, 19 March 2015 (UTC)

If you read the rather small amount of text in the stub that I initiated, you'll see that Gavin Deas is the pen name for the collaborative works of two actual authors and thus not a "living person", even in bold colour. Via Google there are many chatty articles mentioning this collaboration to be found, and there is information on the blurb pages of actual books. Which I don't have to hand to refer to. Further, the stub names both authors individually via W. links, so they have entries in W. and those entries both refer to Gavin Deas via W. links. I provided the stub as a placeholder for the triangular links to clarify the relationships between the two actual authors and their works and their collaborations; my own understanding of the minor tangle is now clear. Anyone could edit it to add further details, or, not bother to add value and just delete it. NickyMcLean (talk) 01:44, 22 March 2015 (UTC)

And now I'm confused. The Gavin Smith article has acquuired references via WordSeventeen, so much for that. It now looks like I misread "Gavin Smith" above as "Gavin Deas" (late at night), however when I created the article I accidentally used a hyphen instead of an underline and could see no way to delete that version. Which seems to have vanished, so much for that. NickyMcLean (talk) 10:48, 24 March 2015 (UTC)

An apology - quantum bogosort

As I stated at the bottom of ʘx's talk page, "sorry for dragging you into a discussion that is probably not in your area of expertise either."

Given how long the discussion has been, I am willing to guess you have not read all of it. There is no need to bother; I will summarize for you.

By directing you to ʘx's talk page, I was merely trying to centralize the discussion, as the discussion on the article's talk page was less active. I was also pointing out that the concern over quantum bogosort's theoretical validity does not stem solely from the physical barriers to destroying the universe but also from the underlying concepts of an algorithm and a function, which are often defined in ways that quantum bogosort fails to meet. ʘx made the point that a specific formal system would need to be chosen in which to resolve the ill-defined aspects of quantum bogosort; neither I, nor the single source in the removed article content, nor the sci-fi magazine you suggested had successfully done so.

The discussion was unnecessarily prolonged due to ʘx correcting various misunderstandings and technical flaws of mine. I struggled to respond to the technical issues while simultaneously steering the discussion toward Wikipedia policies and guidelines about the inclusion and organization of article content.

I am not entirely sure whether we will merely revert the removal, as Graeme Bartlett seems to suggest, or whether we will write a standalone article, as ʘx suggests. It depends on what sources we manage to find; more sources ought to be added in either case. I hope this helps. --SoledadKabocha (talk) 08:08, 6 November 2015 (UTC)

I've taken some days off as well. It is clear that the "destroy universe" notion for problem solution has wide usage in informal discussions (presumably to add some drama!), not just in the Analog magazine story I located (and read again) but also in serious books such as I named: Doomsday Device by John Gribben (Analog Science Fiction/Science Fact, February 1985), and Games, Puzzles and Computation by R.A. Heam and E.D. Demaine (2009), page 103-4. So evidently, this is not a notion confined to just some W. contributors but one that exists out in the world of proper publications. My study of Quantum Mechanics was indeed properly formal, with mathematics and all, and there was mention of the Many Worlds notion, informally, as part of describing the flavour of QM wierdness. It was not itself formally studied, nor was there any reference to the papers of H. Everett et al, to feed such a formal study. Nevertheless, there are many such papers, and there are many many papers/textbooks/popularisations on the interpretation of QM and various flavours of QM... My own opinion is that there should be proper attention to measure theory in trying to make sense of Many World blather, and if I don't see some sign of that, I don't bother reading much further - except for entertainment.

With regard to the criticism of ʘx, that the whole quantum bogosort article is insufferably informal, I say that first, W. is not a repository of formalism, it is not written by accredited formalists only, and we do not describe even formal notions using the formalism of Russel & Whitehead in Principia Mathematica even though that would be the proper basis, or stand on the Foundations of Arithmetic of Gottlob Frege, or Peano, or any other such absolutism, nor yet dive down a rabbit hole attempting to agree on the correct basis for doing so.

And secondly, there is the W. rule, "Ignore all rules" (including this one) which strikes me as applicable to this argument. It seems to me acceptable and even proper, to make some mention of Quantum Bogosort, given that it is treated as one of a variety of similar magic spells in many proper publications. Not just self-published speculations, but ones that an ordinary person might encounter in ordinary reading, wonder what is going on, consult W. and find --- what?

ArbCom Elections 2016: Voting now open!

Hello, NickyMcLean. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)

ArbCom 2017 election voter message

Hello, NickyMcLean. Voting in the 2017 Arbitration Committee elections is now open until 23.59 on Sunday, 10 December. All users who registered an account before Saturday, 28 October 2017, made at least 150 mainspace edits before Wednesday, 1 November 2017 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2017 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 3 December 2017 (UTC)

Undo Kahan

Can you elobarate on the reasons for undoing my edit on the Kahan summation? I found it clarified the algorithm quite a bit.Summentier (talk) 14:25, 6 November 2018 (UTC)

The problem with the computrerish specification of an algorithm is that there is no universally-agreed "language" in which to present it in exact terms, especially if there are important details. There was a time when Algol was widely-recognised, and I am in favour of algolish pseudocode. However, other people favour C-ish pseudocode, if not some actual variant of C, or for that matter, a version of some favoured recent language, such as Python. The point of a pseudocode is that it hides the often baroque detail of an actual computer language's specifications that can distract from the work of the algorithm, and which is not helpful for those who are unfamiliar with those details, they being adherents of some other language.

Thus, I object to the likes of var sum = 0.0 as is allowed by C because there is usually no need to declare ordinary variables in psuedocode, and the added facility of them being initialised in the same statement adds complexity to the reading for no gain in the exposition. I would suggest not declaring the variables, and simply initialise them at the start of the loop. The declaration of y and t within the loop is grotesque and distracting. Imagine what a non-user of such an arrangement would wonder about this. Further, is there to be inferred some hint to the compiler that y and t are temporary variables for use within the loop only, to be undeclared outside? This is an Algol possibility. Perhaps even that the compiler should produce code whereby they might be in hardware registers? Possible register usage that wrecks the workings of the method is discussed further down. But enthusiasts for "var" usages abound. Though your Pythonish code eschews them.

The change you introduced ("for term in terms", etc.) does indeed avoid the usage of "input.length" which, while valid in some languages is not at all universal. I'd prefer for i:=1:N or maybe use "to" instead of ":" so long as it had been made clear that "input" was an array of elements indexed 1 to N. And there is always the fun caused by those computer languages that insist that arrays always start with index zero. Enthusiasts of C had tried a version where the initialisation involved input(1) and the loop ran "for i:=2:N", failing to realise that this won't work well should N = 0, as well as complicating the exposition. The idea to be conveyed is that all the elements are to be added, and the details of the control for this, and especially possible tricks, are not important compared to the exposition of the algorithm.

Thus, I was objecting to "for term in terms", where it is not so clear just what "terms" might be. Unfortunately, the previous version was littered by "var"s but that had been what the rest of the community had settled on, the anti-vars faction having been worn down. Python and other languages do offer the notion of a for-loop working through a collection (possibly in parallel!), rather than just a sequence of integer values, but this seems to me to be overly advanced for the problem. Like, if the objective was to calculate an average, explicit knowledge of N would be required.

In other words, "de-varring" is a plus, but replacing a simple indexing of an array with "term in terms" I thought adds fog. NickyMcLean (talk) 07:53, 7 November 2018 (UTC)

Thanks for the clarification. FWIW, I don't think it is productive to revert whole changes when you simply object to a detail rather than simply improving *that* detail, particularly when that objection comes to taste.

E.g., I won't touch an article anymore if I know there it is likely that a difference in taste leads to my work being completely for nothing. --Summentier (talk) 16:11, 4 December 2018 (UTC)

ArbCom 2018 election voter message

Hello, NickyMcLean. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 19 November 2018 (UTC)

Prime number

Unique factorization does not "have to" speak of every integer larger than one. The convention for the empty product is (1) correct and (2) widespread among people with training at, say, the advanced undergraduate level, but the potential audience for prime number includes people whose mathematics education ended in primary or secondary school (or even at the college calculus level) who were never introduced to it, and it's potentially helpful to those readers to introduce 1 as a special case. --JBL (talk) 10:35, 17 May 2019 (UTC)

ArbCom 2019 election voter message

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vote. Users with alternate accounts may only vote once. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2019 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:05, 19 November 2019 (UTC)

ArbCom 2023 Elections voter message

Hello! Voting in the 2023 Arbitration Committee elections is now open until 23:59 (UTC) on Monday, 11 December 2023. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2023 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:23, 28 November 2023 (UTC)