Talk:Algorithm/Archive 1

message: :Okay, I haven't gotten any responses yet.  So I'm either guessing that everyone has either dismissed me, or has their own idea an algorithm differing from the standard.  Anyway, I don't wish to rely on the Knuth books as a primary reference.  Here is what the U.S. National Institute of Standards (NIST) offers as the definition of an algorithm: .  In that definition, however, they make reference to a computable  set of steps.  To summarize, an algorithm is a set of operations that can be performed by a Turing machine in a finite number of steps.  The input is allowed to be random, but contrary to a prior poster's idea of nondeterministic algorithms, these too must terminate.  In fact, I will state it categorically and without any hesitation  
* THE DEFINITION OF AN ALGORITHM REQUIRES THAT IT CAN BE COMPLETED IN A FINITE NUMBER OF STEPS, REGARDLESS OF THE INPUT DATA.
It isn't usually necessary to prove this mathematically in applications, but it really, truly, honestly is the very definition of an algorithm.
:Afterthought:  all true wikipedists should go home and weep.  This article won an award despite incredible inaccuracies.  This is the very definition of a tragedy of the commons.  Silly rabbit 01:13, 19 November 2005 (UTC)
replies: text: Inacuracies aside, it's actualy badly written and confusing for whole paragraphs, tragedy indeed.--Cs01ab 12:12, 5 June 2006 (UTC)
thread_title: Tragedy of the commons

message: Well, I went and read through some of the early material.  There is a "Thus ..." that ends with "Turing-Complete system" that is off the mark in two regards.  1. There is nothing to make "Thus" follow, here.  Also, the reference to "Turing-Complete" is very tricky, appeals to knowledge that we don't want to presume, and might even be misleading for those of us who think we know what that means.
:Oh.  I see the problem.  In this paragraph, computer programs are equated with algorithms, rather than with procedures.  It is important to remember that not every procedure is an algorithm.  Furthermore, not every computer program is even a procedure in the sense required before the satisfaction of the additional conditions can be considered.  The particular conditions that a procedure must satisfy to be the procedure of an algorithm are stated well enough in the first paragraph of the article.  I don't think we should mess with that.  One might say that an algorithm consists of a certain form of procedure plus some other things.  In addition, not every computer program is a procedure of the certain form required by the definition of algorithm!  (I will leave that as a puzzle for the reader for now.  Hint: The procedure that a universal turing machine follows is not an algorithm.  Well, that's accurate but not such a great hint.  Consider ordinary computers and the impact of input-output operations and using new inputs as part of manipulation of the procedure itself.  That's a better hint.)  --Orcmid 01:30, 15 Mar 2004 (UTC)
thread_title: Formalized Algorithms

message: I think it would be a great idea if we came to some sort of standard on writing pseudocode. I've used a sort of hybrid procedural style for the algorithms in Linear search and Binary search but I'm wondering if there's a better standard out there. Can we borrow a style from a textbook like Intro to Algorithms? (is this copyrighted or is style a public domain thing like an idea?). Only a fairly small set of control structures is needed -- something to define functions, if-statements, loops, list access, mathematical operators and probably a few more. Comments? Mark Jeays
:I do think we should try to do standard pseudocode.  I have no idea what that pseudocode should be however.  CLR's style is usually clear, but sometimes I find it confusing (often because I do not parse the A <- B assignment syntax properly).  I don't think things like pseudocode style are copyrightable...  We should make a pseudocode article that defines whatever we use (in addition to explaning what pseudocode is in general), then link to that from every pseudocode example.  In addition, we could include examples in other languages (see bubble sort for example) by putting them in subpages like bubble sort/C++.  --BlckKnght
Robertson L.A, has released a book which attempts to standardise Pseudocode by specifying pseudocode words (READ, GET, DOWHILE etc) in a book "Simple Program Design - A step by Step approach" Nelson Thompson Publishing 2000.  The Pseudocode examples are close enough to most High Level Languages so as to easy to translate to any language.
We definitely need code samples for all the algorithms; I think there should be one language (pseudocode or otherwise) on the main page, and implementations in other languages on subpages, as BlckKnght suggested above.
I think some executable language would be far preferable to pseudocode, for the following reasons:
* it's possible to test executable implementations of algorithms to see if they're buggy
* executable languages tend to be more rigorous than pseudocode; people writing in pseudocode tend to gloss over relevant details (like whether the range n..m includes n, m, both, or neither --- this is a huge difficulty with, for example, binary search)
My current favorite languages for this are Scheme, C, and Python.  
Python is the most readable of the three; it reads like pseudocode itself.  It's also the least standardized of the three, the most rapidly changing, and the one with the most "hidden" stuff going on behind the scenes.  (arr.append(item) in Python may allocate new space for the array if the space it's in isn't big enough; that really screws with algorithmic complexity analysis.)
C is the most widely-used of the three, probably the one with the most complex and irregular syntax, the most standardized of the three, the least rapidly changing, and the one with the least "hidden" stuff going on behind the scenes.  It's also the most verbose and the least readable for people who aren't familiar with the language or one derived from it.  (Although, since it is so widely used, almost anyone who knows how to program is familiar with the language or one derived from it.)
Scheme is intermediate between C and Python, in my opinion, except that it is the least widely used.
For now, I'm going to add implementations in Python to the algorithm pages, and when I have time, I'll add implementations in C and Scheme on subpages.
-- Kragen
: Kragen, have a look at the pseudocode page, we thrashed out a "standard pseudocode" for Wikipedia a while ago (though feel free to make suggestions/improvements).  The trouble with providing actual implementations of algorithms in real languages is that the trees start to get in the way of the forest.  This is less of a problem in Python and Scheme, of course.  --Robert Merkel
Hmm, I don't see a standard pseudocode section anywhere.  I wonder where it went?  I thought it would be here. -- Kragen
:I advise you to not pursue any endeavor to create a standard pseudocode. I created one that I pushed vociferously and it was rejected by the community, who claimed that a standard was undesirable and unnecessary. I still think they're all wrong, but nothing I can do about it. See User:Dcoetzee/Wikicode. Deco 02:02, 30 July 2005 (UTC)
thread_title:  Standardized Pseudocode 

message: An algorithm is not a rough form of a computer program. This is an example (among many) of the distinct Computer-science bias of the Wikipedia. 
Not every computer program is an algorithm either, at least according to some of the definitions of algorithm.
I don't have a reference handy, but I have seen algorithm defined to mean, roughly, a finite set of rules that is supposed to produce an answer in a finite number of steps. Therefore, infinite loops (which can occur in computer programs) cannot occur in algorithms according to this definition.
This is, by the way, one of the motivations for the study of the halting problem. How do you prove that a certain method is in fact an algorithm?
:Well, it is done one computational procedure at a time.  I don't want to be facetious. I agree with the concern here, but we may be mixing too many things together.  Maybe the lapse is one of carelessness on the part of computer scientists, though I think it is more of an overgeneralization by practitioners and in the teaching of programming, not so much hard-core computer science.  Either way, I think there is a legitimate concern here.
:I am concerned with the substitution of computer codes for algorithmic definitions also, though there is nothing that says a computer code can't implement an algorithm.  (Be shown to terminate, clearly consist of well-defined operations and rules for their progressive carrying-out, etc.)
:But one must be careful about taking a computer code as the expression of an algorithm.  For example, there is more assumed in the Ruby illustration of binary search than meets the eye.
:So what is to be done here, in this section, and in the expression/illustration of algorithms in Wikipedia? I wouldn't recommend an overhaul, though maybe some tidiness can be introduced.  For example, the binary search section currently makes it clear that it is using Ruby as a means for illustrating an algorithm.  Considering that it makes the idea of binary search pretty accessible, I would not complain.  
:Here in the section on algorithm, I would be more concerned.  I also think that maybe procedure should be used in a lot of places, including binary search, and not over-use "algorithm" quite so much.
:I have given longer expression to my concern in discussions around the notion that programs are rarely algorithms.  I also have an in-progress article on the question "Do Programs Teach Algorithms" that, as it happens, uses Binary Search (and Python) as a basis for discussion.  --Orcmid 02:09, 12 Mar 2004 (UTC)
thread_title:  Computer-Science Bias 

message: I had a thought on the subject of good examples -- how about the Tower of Hanoi algorithm? -- Tarquin 11:52 Jan 24, 2003 (UTC)
:Has there been any more consideration of this?  I think the problem of demonstrating that the procedure terminates, and it always gets the right result might be a little tricky if you want to keep this informal.  The other nice aspect is that there are two different approaches, one that is easy to do with a computer, and the "practical" one that is iterative, rather than recursive, and more economical in a number of ways.  The number of moves of disks is the same, of course, unless you slip up, but the housekeeping for one is negligible and the other is a function of the number of disks in the stack (though I would not call it impractical for anything a person would be willing to carry out, or that I would be willing to watch carried out on my computer display).  But it is a practical, mostly math-free procedure. Of course, it is sort of fun to see why it works to say that to move the stack of n on post i to post j, you first move the top n-1 to post 6-i-j.  --Orcmid 02:33, 12 Mar 2004 (UTC)
thread_title:  Good Examples 

message: Ok, some of the problems with the opening paragraph:
*The definition of the algorithm was prefaced with generally, when broadly-defined was meant. The definition of the algorithm as presented may be restricted, but it is never excepted unless done so erroneously, so it makes sense to be more precise with the modifier.
*The term "list" has a more sequential denotation than does "set" as usually code is very non-linear. Take any assembly code for example and you get my point. I realize that an argument can be made the acutal storage of an implementation of code may be list, but this is not very strong as an argument on two points. First, most code today is non-linear in storage with the advent of shared libraries and subprocedures, and secondly the storage of instructions is really insignificant in comparison with the operation of the code, which is what algorithms are about. Set, therefore, is more precise. I realize for non-computing applications such as a recipe, list is generally the norm, but it seems to me that set is equally understandable to lay persons.
*I added the hyperlink iteration and the term decision with the links to Boolean logic and inequality because comparison and logic are the cornerstone of even the simplest cooking recipes. 
*I changed 'mnemonics' as an example of an algorithm, because strictly speaking, a mnemonic device is NOT an algorithm. It is the data structure associated with an alogrithm, as the process of encoding and decoding the original information IS the algorithm. The phrase ROY G BIV is no more an algorithm than an MP3 file. Both are the byproduct of a codec.
*I added the 'heuristics' link, because of the close relation.
*I thought that the bit on policy and mechanism was important for understanding how different algorthims get the same thing done.
*The rest of it I just cleaned up the syntax for conciseness and clarity.
jtvisona 01:51, 14 Aug 2003 (UTC)
thread_title: Reworked the First Paragraph

message: The algorithm to find the highest number in a list is flawed :
* It uses the first element of the list twice
* It fails when the list is empty
--Stephan Leclercq 08:34, 20 Jul 2004 (UTC)
replies: text: That has now finally been corrected. — 131.230.133.185 18:42, 12 July 2005 (UTC)

text: I deal with why I used that style of pseudocode below.  As for using "List.Max", that eliminates the example (an algorithm is a list of steps, not a command) entirely, which is pointless.  The current example shows the steps of the algorithm in a style that is close to the simple, nonprogrammer's English used to describe it. — 131.230.133.185 23:48, 19 July 2005 (UTC)
thread_title:  Example algorithm is flawed ... 

message: An automated Wikipedia link suggester has some possible wiki link suggestions for the Algorithm article, and they have been placed on this page for your convenience.Tip: Some people find it helpful if these suggestions are shown on this talk page, rather than on another page. To do this, just add  to this page. — LinkBot 10:24, 17 Dec 2004 (UTC)
thread_title:  [[User:LinkBot/suggestions/Algorithm|Link suggestions]] 

message: I agree that the "not Greek" insertion is better gone, tho 
: a) not popular belief and b) it's not from the word to gore, either, but we don't have to explicitly say that
are bad reasons for removal.  There is little popular knowledge that it came via Arabic, and irrational is it, normal human minds are far more confused by the anagram than by a coincidental syllable.   There's a stumbling block here, and a better-crafted corrective may well be worth while.
For that reason and others, how about some more etymology: what is the usual relationship between -ithm and -ism; it was certainly de-Arabified, and was it Grecified or Latinized?  Is there an early Arabic form other than just the personal and place names? Some of these answers may be worth including. 
--Jerzy(t) 21:17, 2005 Feb 8 (UTC)
Hi,
If everyone agrees that my edit was unecessary so be it, and remove it if you must. However, I agree with you that the resons given a) and b) where at least silly. I think it is popular belief, because of the ending -rithm which is a popular Greek word (logarithm, arithmetic etc etc) and I am also drawing from my experience as a student, where many people thought it had a Greek root. I think it makes more sense for someone who does not know, to assume its Greek rather than Arabic. As for b) and the fact that someone might associate it with "gore" rather than arithmetic, I think that tells a lot about that person. May I suggest a bit less TV and open a book. --Vasileios Zografos 21:29, 8 Feb 2005 (UTC)
thread_title:  Etymology 

message: I removed the reference to the USA as POV. The statement "Certain countries, such as the USA" seems to single out the USA for no reason apparent to the topic Algorithm. I'd be willing to compromise if a number of both pro-patent and anti-patent countries were listed, assuming a noteworthy software industry presence in the country.
I also removed the "provided a physical embodiment is possible" part, because it may give the idea that a physical embodiment isn't possible. If we're defining algorithms in terms of a Turing machine, then every algorithm has a possible physical embodiment. /* Pradeep Arya 18:20, 2 January 2006 (UTC)
replies: text: Why did [User:Mfc] remove "controversially"? It seems to me like it was neutrally reporting that controversy exists. -- Mikeblas 21:53, 2 January 2006 (UTC)
replies: text:  I agree. I think not mentioning the controversy is POV; slanted toward the pro-patent side in a lie by omission kind of way. However, since I made the last edit to that section, I won't change it myself. If somebody else agrees with me and Mikeblas, feel free to change it back. /* Pradeep Arya 23:18, 2 January 2006 (UTC)
thread_title:  Legal issues 

message: Regarding "Inherently serial problems", the text reads:
:One such example is depth-first search of a graph, which happens to be recursive, but can not be parallelized.
Firstly "inherently serial problems" occurs only 5 distinct times in a google search .
Secondly there seem to be several parallel implementations of depth-first search (and, if you think about it, it seems reasonable to parallelized - you just need a way of knowing which node would have been readed first, which you can do by encoding the node positions in the tree).   I'd suggest a better example would be Newton's method
MickWest 18:07, 8 January 2006 (UTC)
replies: text: I had the same thought about depth-first search when I read the article. It does not seem like a good example.  Perhaps another alternative for an example would be the Three-body problem which seem hard to parallelize beyond 3 processors. -R. S. Shaw 23:06, 10 January 2006 (UTC)
replies: text: Or perhaps repeated hashing, ala: result = MD5(MD5(MD5(MD5(plaintext)))); any good hash algorithm perturbs the result significantly in the presence of more information. It makes it very difficult to begin the next iteration of hashing without having completely finished the previous iterations. —Pradeep Arya 12:27, 11 January 2006 (UTC)
thread_title:  Inherently serial problem? 

message: Who the hell came up with the folowing translation?  "De numero Indorum" (Concerning the Art of Hindu Reckoning).  If the English translation is an accurate translation of the Arabic title, then the Latin is wrong.  If however the Latin is the correct title, then the English is worng. (De Numero Indorum means "Concerning the Indians'/Hindus' Number").  Jim62sch 15:05, 15 January 2006 (UTC)
replies: text: Yes, also see al-Khwarizmi more of his books suffer from this problem. Most references contradict each other (EB, TAoCP, MacTutor) and you'll find even more names on the Internet. I think part of the problem may lie in the fact that the English names comes from the original Arabic name, while the Latin translations (of the text, not only the title) have different titles. Most of the names of his books seem to be abbreviated as well. I'm currently doing some research on this. —Ruud 15:19, 15 January 2006 (UTC)
thread_title: Translation

message: The examples in the page must be rewritten in a langage with a more conventionnal syntax. Pascal? Splang 07:03, 15 May 2006 (UTC)
replies: text: The examples in this article have been written in a form of pseudocode. This has the advantage of being both accessible to lay-readers, language neutral, more expressive than any one language, and the form used by both mathematicians and computer scientists in describing the way an algorithm works rather than just how it is implemented. I suggest that you read through Wikipedia:Algorithms on Wikipedia, and more importantly Wikipedia talk:Algorithms on Wikipedia, to get a feel for the arguments that have already taken place about which languages to use in articles (or if any should be used). --Allan McInnes (talk) 15:43, 15 May 2006 (UTC)
replies: text: I'll continue the discussion of this page you have linked. Splang 14:08, 17 May 2006 (UTC)
thread_title: Proposal of rewrite

message: In 1963, Godel appended to his famous paper the following (quoted from From Frege to Godel):
:"Note added 28 August 1963: In consequence of later advances, in particular of the fact that due to A.M. Turing's work [footnote 69] a precise and unquestionably adequate definition of the general notion of formal system [70] can now be given, a completely general version of Theorems VI and XI is now possible. That is, it can be proved rigorously that in every consistent formal system that contains a certain amount of finitary number theory there exist undecidable arithmetic propositions and that, moreover, the consistency of any such system cannot be proved in the system" (p. 616)
::::[Footnote 69] references Turing's 1937 paper
::::[Footnote 70] "In my opinion the term "formal system" or "formalism" should never be used for anything but this notion...formal systems in the proper sense of the term, whose characteristic property is that reasoning in them, in principle, can be completely replaced by mechanical devices"(p. 616, boldface and itaclics added) wvbaileyWvbailey 23:09, 2 June 2006 (UTC)
thread_title: Kurt Gödel (1963) 

message: This article is too big (for me). I suggest to split it, specially by moving and rewriting the "classification" part.  Acaciz 13:14, 3 July 2006 (UTC)
thread_title: Too big