User talk:Glrx/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 ← Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10

April 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Invention of the integrated circuit may have broken the syntax by modifying 1 "()"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:
  • ?. |title=Semiconductor Circuit Having Isolation Means |country-code=US |patent-number=3150299) |issue-date=1964}}</ref>

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 22:57, 5 April 2014 (UTC)

Fixed. Glrx (talk) 23:02, 5 April 2014 (UTC)

Talkback

Hello, Glrx. You have new messages at Qwertyus's talk page.
Message added 22:04, 27 January 2014 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

QVVERTYVS (hm?) 22:04, 27 January 2014 (UTC)

... and one more. QVVERTYVS (hm?) 22:26, 27 January 2014 (UTC)

No high E field

"Corona Discharge Pinwheel" or "Electrostatic Pinwheel" are not the same as "Crookes radiometer", but they seem to behave similarly.Xb2u7Zjzc32 (talk) 04:34, 24 April 2014 (UTC)

Gilbert/Jones Cell

Please do do attempt to undo my correct account of the Gilbet Cell on the Barrie Gilbert page until you have at least read the reference http://users.ece.gatech.edu/~rincon/classes/ana_history.pdf - Page 46 and Googled for "Gilbert cell" "Schematic", compared the cross coupled differential pairs shown with the Jones patent, and noticed that there are no Gilbert invented logging diodes.Kevin Aylward 17:05, 30 April 2014 (UTC) — Preceding unsigned comment added by Kevin aylward (talk • contribs)

Discussion at Barrie Gilbert#Jones invented the "Gilbert" Cell Glrx (talk) 00:21, 1 May 2014 (UTC)

Changes to citation format in Electronic oscillator

Do you really find the citations more readable that way? I usually format it in the one-field-per-line style because I find the other way the citations are difficult to locate and read in the dense chunks of text. Just wondering, I'm ok with it either way. --ChetvornoTALK 20:16, 19 May 2014 (UTC)

I used to do citations one line per field because that's the way I first saw citations done. The problem is adding a multiline inline citation wrecks looking at ¶x¶ diffs: the original paragraph is divided into two part paragraphs, so the diff will cover at most the first or second part. It may also put the diff out of sync for following paragraphs. In the above example, both chunks were large, and I wanted to see the changes.
Compare these diffs (your edit; your edit after my edit):
I don't have any trouble reading an all-on-one-line citation. When editing, I often search for "{{cit" or "author".
If I have another reason to edit the page with other all-on-one-line citations, then I may make the citation consistent. The edit in question had something like {{cite book |last=Larmor |first=Joseph, Ed. ...}} which I changed to {{cite book |editor-last=Larmor |editor-first=Joseph ...}} without line breaks.
For non-inline references at the foot of the article (e.g., using Harvard referencing), there's little difference between single line and multiline. Either style does not break up a text paragraph.
Glrx (talk) 21:03, 19 May 2014 (UTC)
I see what you mean. That's too bad; the "diff" engine should ignore paragraph breaks inside a template. I still like the open style, though, have to think about it. Glad you updated that author field. I just paste citation templates by hand, and the copy I have on my personal page is a little out of date. I was wondering, have you ever used the automated citation tools onHelp:Citation tools? I was going to give them a try. --ChetvornoTALK 21:44, 19 May 2014 (UTC)
I don't use the automated citation tools. Glrx (talk) 21:50, 19 May 2014 (UTC)

Torque wrench

You recently undid a edit i did to a the wiki page on Torque wrench saying my citation in not a buyers guide. if you scroll all the way down on the web page given as a citation you will see that it is in fact a buyers guide and it is in facted cited correctly.

The section that describes the Torque wrench is on the very bottom of the page.

Nerdypunkkid (talk) 06:21, 31 May 2014 (UTC)

About this edit to Torque wrench
The addition was about an unusual device that is bulky compared to a conventional torque wrench. The addition seemed to be WP:UNDUE and it essentially advertises a product. The buyer's guide comment is that Wikipedia is not intended to be a buyer's guide. Adding buyer's guide material, especially such narrow information, does not seem to meet the charter. Glrx (talk) 20:36, 31 May 2014 (UTC)

Thanks for help with Lead zirconate titanate!

I appreciate your help with Template:cite on this page! Kragen Javier Sitaker (talk) 00:56, 21 June 2014 (UTC)

Kelvin bridge

Why?Freshman404Talk 20:22, 23 June 2014 (UTC)

There was no citation to that book in the body of the article. The reference section is not intended to be a bibliography of every book that mentions the topic. Feel free to add some text to the article and use the book as source (and provide page numbers). Glrx (talk) 01:35, 25 June 2014 (UTC)
I add no more text because same explanation is written in that book-In my book it is in chapter 5, page 113. Please let it remain.(And use PING to notify me.)
Thanks--Freshman404Talk 06:31, 25 June 2014 (UTC)

FPGA

g'day, how are you today? I noticed that you deleted my edits saying "power and speed comparisons not complicated by LUT" and thought I reach out. please, find below some links that help you understand better:

https://www.youtube.com/watch?v=_oHNvJTWX3Q

http://www.eecg.toronto.edu/~jayar/pubs/kuon/kuontcad06.pdf

http://books.google.com/books?id=0S1Y8modSrMC&pg=PA666&lpg=PA666&dq=different+LUTs+for+power&source=bl&ots=w__AjMePtC&sig=CrMAPWu9jXNv41erBg3XKbe9bIg&hl=en&sa=X&ei=it2hU5elKMqcqAaP6IAo&ved=0CFIQ6AEwBQ#v=onepage&q=different%20LUTs%20for%20power&f=false

so, I hope that helped and it seems best if you make your deletion of my edits undone yourself. best beaki — Preceding unsigned comment added by Beaki (talk • contribs) 04:10, 19 June 2014 (UTC)

@Beaki:
This discussion is about the insertion of this material. The material describes 3 manufacturers' current approaches to FPGA architecture; it includes a URL link in the body to chippath.com, and it adds chippath as an EL. I removed the material again. The material is unsourced; it does not even cite to the sources listed above.
We don't know what type of comparisons are being made in the paragraph. The previous (sourced) paragraph was about speed, power, and functionality (area). Such comparisons are easy to do in a specific context. Which FPGA is suitable? How fast does it go? How much power does it draw? Those are not difficult questions. For a particular problem (and particular design tools), different FPGA logic blocks may be better, but custom designs are not constrained by fixed architectures..
The primary links inserted into the article were for a chippath.com comparison tool. WP is not a buyers guide. WP need not advertise chippath's tools.
WP does not consider youtube a reasonable source.
The first paper is a primary source. It points to significant (x35 down to x18 predict x5) area penalties for FPGA vs ASIC, x3 to x4 time delays, and x14 with power. The material I removed does not make these claims and does not cite to this source. The paper also goes for a hybrid approach: hard blocks can be useful for gaining performance -- except when the task doesn't need the hard block and then it just wastes area.
The book appears to be a primary source because it reports the author's findings rather than surveying the field.
The sources above do not seem to be saying the comparison is hard. They say things can be better.
The main statement of the material is not a clear one. It's not clear which LUT architecture is better. But WP does not need to say that one company uses this LUT architecture, another a different one, and it's not clear which is better.
If you want this material in the article, then you should follow WP:BRD: bring it up on the talk page and get a consensus for inclusion.
Glrx (talk) 03:48, 30 June 2014 (UTC)

July 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Numerical Electromagnetics Code may have broken the syntax by modifying 1 "[]"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:
  • diameters better than NEC2 and probably NEC4;<ref>http://www.cebik.com/content/a10/model/fd.html]</ref> this includes different diameter parallel wires, different diameter wires joined at an angle,

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 18:39, 2 July 2014 (UTC)

Constant folding and string literal concatenation

Hi Glrx, in this edit, I’ve taken another shot at discussion string literal concatenation in the context of constant folding. I’ve kept the main text brief, focusing on the similarities (it’s solving the same problem), and relegating the C-specific details to footnotes, so it’s less distracting. How does it look?

—Nils von Barth (nbarth) (talk) 17:38, 6 July 2014 (UTC)
Nils, the addition is off topic; it is not about constant folding; it is about the syntax of constants. Even you made the comment "implicitly" concatenated. (The article you link also has Python considering deprecating the operation.)
The idea of constant folding is the language allows expressions that an operation (e.g., a + b, 2 * c, 3 + 4, 2 * 7) be done at runtime, the compiler recognizes the operation can be done at compile time, and the compiler does it. In C, there is no explicit string concatenation operator for runtime. Some languages have an explicit string concatenation operator that expects to be done at runtime. The user might write "Hello "+strWorld or "Hello " || strWorld, and the compiler will emit code to allocate the string and do the concatenation. If the compiler knows that strWorld is a constant, then the compiler can do the operation at compile time and just emit the constant result.
A C/C++ example is not doing that because no runtime concatenation operator involved. Neighboring quoted strings are just the syntax of specifying long strings (or building up a string).
Glrx (talk) 20:04, 6 July 2014 (UTC)
I understand that there are differences between constant folding and string literal concatenation, as you note – they are distinct concepts and accordingly have distinct articles.
However, the similarities are also striking – in both cases, during compilation, string literal tokens (generated separately and evaluated during tokenization/evaluation) are then combined at a later step of compilation, and these two distinct mechanisms satisfy the exact same purpose: allowing a complex value (here a long string) to be built up in a complex way (perhaps using functions or, in the case of C/C++, preprocessor macros) but still evaluated at compile time.
With CF, you might write:
foo(x) { return "foo:" + x }
foo("bar")
…while in C you'd write:
#define FOO(x) "foo:" x
FOO("bar")
…but these both fulfill the same goal in very similar ways.
Thus it would be useful to give readers some way to learn about SLC when reading about CF. It would be possible to just put a link to SLC in the “See also” section, if that’s necessary to avoid distraction, but it’s generally preferred to try to incorporate these into the text, hence my proposed edits.
How would you suggest that readers learning about CF should learn about SLC?
—Nils von Barth (nbarth) (talk) 04:08, 7 July 2014 (UTC)
They are separate ideas, and there's a lot of ugliness in the examples above. If an operation is never intended to be executed at runtime, then it has no business in an article about compiler optimizations. If it could never run, then there is nothing to optimize.
The C preprocessor is an expedient hack that is far away from any compiler optimizations. In the old days, it was a separate pass, so the C parser would never see the defines or their invocations -- just the results. As for instances of SLC, I'd expect them to be handled during parser reductions. A remark about C in the CF article seems headed for confusion.
I have seen programs where programmers use string concatenation operations on literal strings as a convenient method of building up a longer string. The use was esoteric. One would like to see the compiler optimize the string, but there's no great penalty if it doesn't.
I want things to be clear.
In a somewhat related matter, code optimization of string concatenation will not be a big benefit in most situations. As I understand it, the big benefits of code optimization were with array index calculations: lots of mundane index arithmetic could be saved. The same opportunites for optimizing string concatenation probably are not there.
Glrx (talk) 17:10, 7 July 2014 (UTC)
Understood – the C preprocessor is a part of compilation (broadly speaking) that’s not relevant these days outside of C/C++, and is generally confusing and baroque, though these later are still in widespread use (avoiding the preprocessor as much as possible). (Historically it’s part of the transition between macro assemblers and proper compilers.) To avoid disrupting the flow of the article, shall I put a link to SLC in the “See also” section, perhaps with an (HTML) comment to the effect of “please don’t conflate this with CF”?
—Nils von Barth (nbarth) (talk) 02:08, 8 July 2014 (UTC)
BTW, for reference: discussions of removing SLC from Python and D specifically mention replacing it with constant folding, as in:
—Nils von Barth (nbarth) (talk) 04:45, 10 July 2014 (UTC)
In this proposed edit (diff), which I’ve reverted (it’s a proposal), I’ve given a very brief mention of SLC:
“A superficially similar feature is string literal concatenation, which concatenates adjacent string literals during lexical analysis, for example replacing "abc" "def" with "abcdef".”
This shows the similarity, but clearly flags it as distinct and how, and avoids any technical discussion of C.
How does it look?
—Nils von Barth (nbarth) (talk) 04:45, 10 July 2014 (UTC)
I'm opposed to the edit. Your sources do not say the operations are superficially similar. I don't consider them reliable sources about CF. What they say is that SLC may make bugs difficult to detect. I'm not sure I buy into that premise: spotting - instead of + is also difficult. One source also did not want to make CF a required optimization.
The sources don't say what you want. They say SLC is dangergous and could be replaced with explicit concatenation. SLC does not belong in the CF article because it is language syntax rather than a compiler optimization.
I think you like the parallel, but don't talk about it in CF article.
I'm copying this discussion to CF; I should have moved it there earlier.
Glrx (talk) 15:29, 10 July 2014 (UTC)
Copied to: Talk:Constant folding#Constant folding and string literal concatenation
—Nils von Barth (nbarth) (talk) 04:32, 11 July 2014 (UTC)

Your revert in Euclidean algorithm

Hi I have reverted your revert for the following reason: Presently, MathJax rendering is buggy for formulas containing option ALT (<math alt=sometext> ...<math>. It displays "sometext" before the formula, as it would be a part of the formula. As "sometext" is not really useful, and most readers prefer to read the latex source than confusing descriptions of formulas, I have pushed "sometext" into a comment. This allows the MathJax users to read the formulas, and the rare readers interested in such comments to accede to them. For users of PNG rendering, both versions are equivalent. Thus, I do not see any reason for your revert. D.Lazard (talk) 13:29, 9 July 2014 (UTC)

Your edit is a bad idea. Presumably, MathJax was working last week. Somebody broke it; it no longer follows the spec. Instead of fixing MathJax, your solution is to insert a workaround on every article that uses an alt attribute in a math tag. That will tickle a lot of watch lists. We had a system manager who advocated that approach; he broke something and started to "fix" it by modifying every user's init file; it was the last straw; I fired him.
Furthermore, the math works fine for me because I'm not a MathJax user. My impression is MathJax is the minority. Glrx (talk) 15:21, 10 July 2014 (UTC)

Your revert on Captain Richard Winters

Binkleyz (talk) 15:10, 10 July 2014 (UTC) Curious why you undid my captialization of "Captain" (Richard Winters). Captain is a title and therefore a proper noun, and should be capitalized.

This is about edits on 28 and 29 May at Richard Winters. Your edit went through and capitalized all the ranks and positions. My revert restored the original lowercase. For the reason, see MOS:JOBTITLES. My immediately following editsmoved the picture you added out of the paragraph text and reinserted a clarification that you made. Glrx (talk) 15:43, 10 July 2014 (UTC)

A year and a half after you opposed my RfA

I am inviting you to leave me some feedback, 18 months after you opposed my RfA. Do you still believe I am not fit to be an admin? Do you believe I have been able to improve past the concerns you have brought up? Do not be afraid of being too harsh, I am specifically welcoming criticism as I believe it is the best way to improve and I am always looking to learn from my mistakes. I am particularly looking for feedback as to whether you have objections to myself lifting the self-imposed 1RR restriction I had agreed to towards the end of my RfA. If you don't have time to comment, don't fret it either, this is nothing I'll lose sleep over. :) ☺ · Salvidrim! · ✉ 19:48, 20 July 2014 (UTC)

RF connector

re this revert at RF connector

The edit you undid was not mine, it was User:Rfconnector's. Cluebot's choice was clearly wrong. I don't have an opinion on the content of the edit. jhawkinson (talk) 01:16, 14 August 2014 (UTC)

I'm mystified too: I don't know why or how Cluebot thought it was vandalism. Glrx (talk) 01:45, 14 August 2014 (UTC)

Lisp

I notice you reverted my edit. And you are not alone with that practice on the Lisp page. Please have a look at this. And I have changed the article to what the source says. -- Zz (talk) 20:15, 21 August 2014 (UTC)

your revert on Proximity Fuzes

I placed that video reference in the article along with a copy of the cover for the tape box because it seemed to me relevant that, as I described my entry, this was "in popular culture". We've (that is, Wikipedia) certainly got many, make that MANY, articles where such entries are common. Please reconsider your objection. wiki-ny-2007 (talk) 05:09, 1 September 2014 (UTC)

About my revert of wiki-ny-2007's edits to Proximity fuze and, indirectly, File:Fuze-102.png.
Including the image of the video's cover art appears to be a copyright violation. Copyrighted cover art can be used in limited circumstances, but this usage does not appear to be one of them. We don't need to see the cover to identify the work. Neither is the article about the video.
The information about where to purchase video is not relevant to the article. "Copies are available through the PBS clearinghouse" sounds in advertising; such a statement does not belong in an article's text.
You added a popular culture section with the video as the only item. Popular culture sections are not for documentaries about the topic. History is not popular culture. Popular culture sections are used when the subject of the article is used as a story item or plot device in a popular work such as a book, movie, or song. Compare Ark of the Covenant#In popular culture.
Documentaries are used to supply content for articles; in that case they are legitimate references. The video is not used as a reference for any content in the article.
Documentaries can also be included in further reading (watching?) sections if they supply content that is not currently in the article. Does the video offer content that is not available in the existing sources? Does it have interviews with principals?
If you think the video should go into the article, then bring it up on the article's talk page. See WP:BRD.
Glrx (talk) 15:56, 1 September 2014 (UTC)

Planimeter

What's the problem with the reference to the Lego planimeter. I found it really interesting. Nijdam (talk) 22:00, 9 September 2014 (UTC)

re Planimeter and my revert of external link to self-published planimeter made from Lego
@Nijdam: It's a cute hack, but the source is a blog. What content does the EL have that is not already in the article? Advice about using friction gears rather than crummy Lego gears with lots of backlash isn't germane to the article. The Pritz Lego planimeter is also cute, but accuracy claims for both (10 cm2 and 2 cm2) are not great. It's cute, but I don't think it belongs in the article. As an extreme argument, should every WP article about an object have a link to a Lego implementation of that object?
Why do you think it should be in the article? Glrx (talk) 15:57, 11 September 2014 (UTC)
Well, it amused me, and I see no harm in showing. The argument about "every article" is not very adequate. A colleague of mine argued: it should not be allowed to take the train to London, then suppose everyone would do so. Nijdam (talk) 20:42, 11 September 2014 (UTC)

September 2014

Hello, I'm BracketBot. I have automatically detected that your edit to Grill (cryptology) may have broken the syntax by modifying 1 "<>"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 02:21, 22 September 2014 (UTC)

Your revert on Van Gogh

I made a post on the discussion page regarding your revert of my edit. Uchiha Itachi 25 (talk) 14:09, 6 September 2014 (UTC) https://en.wikipedia.org/wiki/Talk:Vincent_van_Gogh#Starry_Night_is_his_most_well-known_work

I had replied at Vincent van Gogh#Starry Night is his most well-known work.
Uchiha Itachi deleted this talk page post saying he had fixed his error.[1]
However, it just changed the source of the best-known claim. I agree it is one of his best known paintings, but I don't think it should be labeled his best known. Glrx (talk) 15:08, 23 September 2014 (UTC)

Reference Errors on 1 October

Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:

Please check this page and fix the errors highlighted. If you think this is a false positive, you can report it to my operator. Thanks, ReferenceBot (talk) 00:22, 2 October 2014 (UTC)

A kind editor fixed this for me. I had used a ":" when I should have used an "=". Glrx (talk) 17:08, 2 October 2014 (UTC)

Statement by Glrx

At AE. You have lost me over there, the "The PHR report also showed that ninety four per cent of internally displaced persons (IDP's) had been victims of some form of sexual assault". is sourced to Women, Migration, and Conflict: Breaking a Deadly Cycle p50, "94% of displaced households", how are displaced households not displaced persons? The other point you mention is also confusing me, "215,000 to 257,000 victims of sexual abuse", is cited to Women Under Siege, Physicians for Human Rights estimates that during the conflict, between 215,000 and 257,000 of them were subjected to sexualized violence, how is it not accurate to what I have written? Darkness Shines (talk) 07:22, 4 September 2014 (UTC)

RE: Wikipedia:Arbitration/Requests/Enforcement/Archive156#Arbitration enforcement action appeal by Darkness Shines
We have tried to explain these distinctions to you. At AE, it was pointed out that a household is not a person but rather several persons. A displaced household is several displaced persons. If someone in your family was a victim of sexual assault, that does not mean that every member of your family was assaulted. The sexual assault figure is also absurd on its face. The AE discusion pointed out that the 94 percent figure was about violence. Murders are violence, but they are not sexual violence. The discussion at AE also pointed to specific pages in PHR report that gave vastly different figures. A page had a breakdown of the types of violence. We gave you a pinpoint citation in the PHR Report that had one-tenth of your figure for sexual violence. The figure of 94 percent of internally displaced persons were victims of sexual violence doesn't even sound right even when acknowleding 45% of the IDP population is male.
Nobody is disputing the 215,000 to 257,000 victims of sexual violence. That was also spelled out at AE. The problem was with your citation: it went to a page in the PHR Report that did not support the claim; other pages did. The figure also does not support your 94 percent claim. Do you know how many IDPs there are? For the 94 percent figure to make sense, the IDP would have to be less than 300,000. The PHR Report says the IDP population is 1.0 to 1.3 million; 257,000/1,000,000 is not 94 percent. (PHR Report page 4 fn5.)
I get the sense that you quickly jump to the conclusion that you are right and others must be wrong. Do you believe that Callanecc, Sandstein, and I are all wrong? You wanted me to apologize for my comments. You labeled Sandstein's comments a personal attack (even if Sandstein were wrong, a factual error is not a personal attack). If someone had challenged your edits at the Rape in Sierra Leone Civil War article, would you have reverted to keep your interpretation in or labeled those edits personal attacks?
Glrx (talk) 16:44, 4 September 2014 (UTC)
No, I would not have reverted, I would have asked for an explanation, which I have now gotten. Thanks. Darkness Shines (talk) 06:58, 5 September 2014 (UTC)

Dunning-Kruger Effect

I see you reverted my edits. I must admit that I'm confused by your comment (esp. "RS"). Could you elaborate?

On the content, it seems to be that Schneier's point is exactly that of D-K, namely, that those less skilled in cryptography think they have it licked because they can come up with a method that they themselves can't break, rather than one that others can't break. IOW, they overestimate their own skill in an area in which they are relatively uninformed. This was noted long ago by Poe, as the article on Schneier indicates. Is there a better section in which to put this observation?

Thanks. Eponymous-Archon (talk) 02:40, 13 October 2014 (UTC)

RE: this revert
If you look over the article history of Dunning–Kruger effect, you will see that many editors have found quotations that they believe appropriately illustrate the DK effect.[2][3][4][5] Finding a quotation and deciding it is relevant wanders into editors doing original research, and that is not what editors are supposed to do. We are supposed to find reliable sources that tell us such-and-so quotation illustrates the DK effect. If a statement does not have a reliable source, then it can be challenged and or removed. If you want the quotation in the article, then start a discussion on the talk page to include it; if you can get a consensus, then the quotation can go in. See WP:BRD. The statement may also have an element of synthesis: did Schneier make the observation about Poe, too? If I google the phrase with Poe, I only get 4 hits. What is the vague historical precedent with Poe? That lots of naive newspaper readers thought simple substitution ciphers were secure? Poe's July 1841 comments? The reverted text is opaque about Poe.
I like Schneier's quotation for what it says about how difficult cryptography is, but I don't think it is a good match for the DK effect. First, many skilled German cryptologists during World War II believed the Enigma was secure. Very skilled people can make horrendous narrow mistakes. Schneier's comment can apply to both the skilled and unskilled. Skilled people can miss a trick or a new technique; unskilled people are clueless over a broad area. Cryptography is full of such history as the field progressed: frequency attacks, polyalphabetic attacks, and group theory attacks.
Second, the section is about historical antecedents of DK. Even if Schneier's statement applies to DK, when was the statement made? Was it before 1999? Although you give the text of the quotation, you do not give a source that shows Schneier said it or when he said it.
Third, an article does not need an exhaustive list of quotations or examples. Experts on DK have provided us with several quotations, so why are more needed?
Glrx (talk) 04:10, 13 October 2014 (UTC)
A small tangential issue.... Regarding “many skilled German cryptologists during World War II believed the Enigma was secure. Very skilled people can make horrendous narrow mistakes”. Consider, the article “Cryptanalysis of the Enigma”, which states the following.

The Enigma machines were a family of portable cipher machines with rotor scramblers.[2] Good operating procedures, properly enforced, would have made the cipher unbreakable.[3][4] However, most of the German armed and secret services and civilian agencies that used Enigma employed poor procedures and it was these that allowed the cipher to be broken.

Thus, the German cryptologists assumed that the operating instructions would be followed.
TheSeven (talk) 12:53, 18 October 2014 (UTC)
@TheSeven: The problems with the Enigma were widespread and on many levels. A huge problem with the machine was its disjoint transposition; that flaw was extensively exploited throughout. The machine's limited rotor permutatoins were also a problem. I'm skeptical of the summary given of Welchman and Calvocoressi. Operator errors made the task easier. User errors (such as structured/stereotyped messages useful for cribs) also helped.
In the 1930s, the procedures were flawed due to the common encryption of the doubled key. The Poles used that flaw to reduce the indicator permutations to a couple thousand possibilities. The operators choosing weak keys allowed the Poles to quickly determine the correct possibility. Specified operating procedures were mostly followed with the exception of operators choosing poor keys.
In the late 1930s, the Germans stopped the common encryption, but the Poles still exploited the doubled key by using a machine to find the doubling. Operating procedures were followed, but the machine was still attacked. The procedure (not the operator) was seriously flawed.
The Naval Enigma did not have the doubled key mistake, but the Brits were still able to attack it. The disjoint transposition allowed crib alignments. That is, good operating procedures did not make the cipher machine unbreakable. It was breakable because the German cipher authorities thought the plugboard permutation offered more security that it did. The Germans knew the combinatorics of the rotors; they knew about plaintext attacks; they did not understand how to look through the plugboard.
Glrx (talk) 16:45, 25 October 2014 (UTC)

Francis Bashforth

This is an automated message from CorenSearchBot. I have performed a web search with the contents of Francis Bashforth, and it appears to include material copied directly from http://www.cyclopaedia.de/wiki/Francis-Bashforth.

It is possible that the bot is confused and found similarity where none actually exists. If that is the case, you can remove the tag from the article. The article will be reviewed to determine if there are any copyright issues.

If substantial content is duplicated and it is not public domain or available under a compatible license, it will be deleted. For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or printed material. You may use such publications as a source of information, but not as a source of sentences. See our copyright policy for further details. (If you own the copyright to the previously published content and wish to donate it, see Wikipedia:Donating copyrighted materials for the procedure.) CorenSearchBot (talk) 20:20, 3 November 2014 (UTC)

I copied the material from de:Francis Bashforth. When I copied the material I attributed that article in the edit comment. The cyclopaedia.de material clearly states its origin is de:Francis Bashforth. Glrx (talk) 20:53, 3 November 2014 (UTC)

Speedy deletion nomination of Francis Bashforth

A tag has been placed on Francis Bashforth, requesting that it be speedily deleted from Wikipedia. This has been done for the following reason:

non english article

Under the criteria for speedy deletion, articles that do not meet basic Wikipedia criteria may be deleted at any time.

If you think this page should not be deleted for this reason, you may contest the nomination by visiting the page and clicking the button labelled "Click here to contest this speedy deletion". This will give you the opportunity to explain why you believe the page should not be deleted. However, be aware that once a page is tagged for speedy deletion, it may be removed without delay. Please do not remove the speedy deletion tag from the page yourself, but do not hesitate to add information in line with Wikipedia's policies and guidelines. If the page is deleted, and you wish to retrieve the deleted material for future reference or improvement, then please contact the deleting administrator, or if you have already done so, you can place a request here. Avono♂ (talk) 20:26, 3 November 2014 (UTC)

@Avono: slow your tagging. Glrx (talk) 20:54, 3 November 2014 (UTC)
yeah sorry about that, couldn't be sure though that you were just planning to copy and paste the german article and leave it like that :/ Avono♂ (talk) 10:23, 4 November 2014 (UTC)

Disambiguation link notification for November 4

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Francis Bashforth, you added a link pointing to the disambiguation page St. John's College. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 15:24, 4 November 2014 (UTC)

Fixed in the current release. Glrx (talk) 21:13, 4 November 2014 (UTC)

Date format in Linux articles

Hello! Any chances, please, for you to have a look at Wikipedia talk:WikiProject Software § Date format in release history sections of Linux articles and possibly comment there by providing your point of view? The whole thing is pretty much poorly discussed with only a few editors actually discussing it, while it seems to be affecting more than a few articles (and the date format seems to be extending beyond the tables into references, please see history of the Linux distribution article). Any contributions to the discussion would be highly appreciated! — Dsimic (talk | contribs) 02:40, 15 November 2014 (UTC)

I looked at the issue, but I don't have anything to add. I'm a DMY fan in text, but I'm not big on it (and I speak MDY). If a date is in a sortable table, then ISO can make sense. I'm happy with any content as long as it makes sense. Glrx (talk) 03:55, 15 November 2014 (UTC)
Thanks! I totally agree on what's the most important, and that's the articles content that makes sense; formatting some garbage usually doesn't make it better. :) The whole issue about the date formats is actually diverting from that importance, that's why I've found it to be somewhat important. — Dsimic (talk | contribs) 04:08, 15 November 2014 (UTC)

Revert on Zygalski sheets

Hi, I noticed you reverted my edit to Grill (cryptology). To be honest I am not sure what the best practice is if you want to draw attention to another page that happens to be mentioned in a current version of a currently included template. Relying on the template to connect the pages seems brittle to me and doesn't make the close connection in subject matter clear. In this particular case I think there may even possibly be a case for merging the Z sheets page with Grill (cryptography) as the two accounts seem to discuss almost the same effort, but focussing on two different figures (and not mentioning the other in each case). Both ended up working (presumably together?) in the UK during the war. Some historian of Polish cryptanalysis may be able to help? Anyway, in the absence of confirmation that the two pages are in fact discussing different aspects of the same work, is there some other way of making the strong similarity and connection between the two explicit (that you would find acceptable)?— Preceding unsigned comment added by Theoh (talk • contribs) 18:49, 14 November 2014‎

RE this revert removing Zygalski sheets from See also section
Generally, if a topic (such as Zygalski sheets) is mentioned in an article's template, then mentioning it in the See also section seems superfluous. Z sheets are listed in both {{Cipher Bureau}} and {{EnigmaSeries}} templates. Also, all the efforts of the Polish Cipher Bureau were centered around Rejewski's characteristic and/or encrypted doubled keys. If one is going to mention Z sheets, then one should also mention the Polish Bomba.
I disagree with your claim of a "close connection". Merging Z sheets with Grill is a bad idea because the attacks are much different. Grills and Z sheets are not even superficially similar (e.g., slots v holes). The Grill used doubled indicators encrypted under the same key (Grundstellung) to extract permutations A B C D E F, and then it searched a small space for permutations P and Q; then Q was broken down and the ring settings were found. The Grill died in 1938 when new procedures (different Grundstellung for each message) prevented determining A B C D E F; the change forced the Poles to find other methods. The result was Z sheets and the Bomba. The Grill used complete cycles and did not need "females". The Z sheets and Bomba used doubled indicators encrypted under different keys, and the doubled indicators had to be 'females'.
If you are looking for similar methods, the Grill and the cyclometer are much closer. The cyclometer was a hash table lookup of the Grill's answer.
If you mean the Poles and Brits worked together in the UK during the war, that would be no. The Poles went to France and joined that service; the French (with the assistance of the Poles) collaborated with the Brits during the Phoney War (the Poles had destroyed their equipment and the French took them in; the British gave the French a set of Z sheets); the station in Algeria may have continued to operate after the Phoney War, but the main Polish cryptographers were either killed (e.g., Różycki and Palluth), captured (e.g., Langer), or fled. Rejewski and Zygalski made it to the UK during the war, but they were not involved with Enigma while there.
The connection between the two methods is not strong but could be mentioned in the article. Quite simply, the Grill and cyclometer methods died in 1938 and were succeeded by Z sheets and Bomba.
Glrx (talk) 20:03, 14 November 2014 (UTC)
OK. My assumption about the connection between the two was actually at the level of the name "grill" (and the page mentions vaguely that a physical grill had some part in the method) and the fact that Z sheets also have a relationship with Grille (cryptography). In terms of trying to add value to Wikipedia I am a linker more than a splitter, if you know what I mean, and therefore I think it would be informative to at least link the Z sheets page to the historical precedent for grilles in cryptography (actually this is already the case), and probably also explain and link the Grill (cryptology) page to the same Grille (cryptography) page. My edit was a mistaken attempt to respond to this perceived shortcoming by at least making the Z sheets -> grill(e) connection clear.
As far as merging goes, I'm sure you are right that the pages should remain separate. In a traditional encyclopedia I'd expect to find just one "Polish cryptanalysis of Enigma" article... in the absence of that it is a bit difficult to determine what the relationship and temporal sequence of the various techniques listed in the template are... it's just a bag of items, which forces the reader to poke around to find out what is going on. If there isn't going to be an overall narrative on any page maybe the individual pages could each say what methods preceded them and succeeded them in the evolution of the cryptanalysis effort?
(No idea how to indent this reply, sorry)
Theoh (talk) 19:42, 16 November 2014 (UTC)
You should not key on single words such as "grill"; the three articles involve much different operations. The Grille is even further afield than the others as it is steganography rather than a substitution cipher. The holes in the Polish grill just helped focus the user in his search for a consistent permutation; they did not perform any computation; the user had to do all the thinking. The Z sheet holes computed a multi-argument boolean "and" function on 576 parallel hypotheses; the computation was significant. The Grille just did simple selection.
The Enigma attacks were not just Polish attacks. The Poles needed help from the French in 1932 even if the French thought solving the Enigma was hopeless. The British needed help from the Poles, but then developed much more significant attacks. For the overview, see cryptanalysis of the Enigma (which is in one template under "Breaking Enigma").
Glrx (talk) 16:02, 17 November 2014 (UTC)

Selection sort - swap function in C

Hi, thanks for the edit. While I see your point, I changed the page for the following reasons: 

1. Function macros normally are typed in ALLCAP so swap should be SWAP(a[i], a[j]); and a comment should be added to make sure the user knows this is a macro.
2. A macro has file scope and I don't see the macro in the listing. On the other hand it is perfectly possible for swap(int *x, int *y); to link to a library function for which we don't have the code.
3. This is a case of macro abuse. Macros are an awesome, simple, useful things but for some reason people misuse them all the time. This is such an example. If I were to write this in C, I would not use a macro and I don't see a reason why the wikipage should promote a macro. If I were to see swap(a+i, a+j); I know what the swap function will do. If I saw swap(a[i], a[j]); then I would say that's either a bug or I don't understand how swap works.

Sss41 (talk) 01:49, 17 November 2014 (UTC)

Generally, WP wants pseudo code that explains the algorithm without getting lost in the details of a particular programming language. There are many algorithms that are expressed in specific languages, but even then the algorithm may be only a skeletion that omits parts (e.g., #include <stdlib.h>) required for actual compilation. Some actions may only be a function or macro name that implies the operation. Example code should also avoid language-specific idioms (e.g. ++ and +=).
From a coding aspect, I disagree with your viewpoint. If I see swap(a[i],a[j]), then I would read that as swapping the array elements. The statement swap(a+i,a+j) is something that is peculiar to C; if someone does not know a C-style pointer language, it is not clear. Furthermore, I would expect the former to be correctly interpreted by someone who is skilled in C; double-indirect swaps are not common.
The all cap macro convention is not strict; min() is almost always a macro. If we switched the language to C++, then swap could be a procedure without address-of operators. You might use a function, but somebody else might use a macro. For sorting integer arrays, a macro would not have the procedure call overhead. Saying it could be an unspecified function does not counter that it could be an unspecified macro. For an actual library sorting routine, the swap is much more involved because element size would be an argument, but such details obscure the algorithm. I'm not married to my revert, but swap() can be defined so that it swaps the array elements. Adding & adds a detail that may confuse; using pointer arith would obscure.
Glrx (talk) 16:45, 17 November 2014 (UTC)

Cowlishaw's article

FYI, Cowlishaw's article "Decimal Floating-Point: Algorism for Computers" is available from http://speleotrove.com/decimal/ as IEEE allows authors to publish their article under some conditions. However a direct link to the PDF may not respect these conditions (one has to re-read their copyright policy). — Vincent Lefèvre (talk) 18:08, 19 November 2014 (UTC)

I reverted my edits to IEEE floating point to restore the link. I'm not sure what the IEEE policy is, but my earlier revert of the speleotrove link was because it did not look like the author controlled the website; after your note, I checked again and found that it was his website. Generally, I'll believe that authors may publish their articles on their websites; I'll figure that the author knows the rules (but I have removed links where publisher's policies keep all rights). I removed the UC Davis link because I didn't see that Mike Cowlishaw (in England) would have any association with UC Davis. I'm agnostic on the deep link issue. Glrx (talk) 18:28, 19 November 2014 (UTC)
Author Posting of IEEE Copyrighted Papers Online], IEEE Glrx (talk) 18:34, 19 November 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Glrx/Archive_7&oldid=1146371373"