Talk:Algorithms

Guidelines and direction
Welcome to the project! Thanks all for your contributions. If you are new to writing for this book please read the following guidelines and style adopted:


 * 1) This is a techniques-oriented book: We aren't aiming to create an encyclopedia of every algorithm ever created, nor are we trying to present the absolutely best versions of particular algorithms (though we can of course mention the state of the art and where to find it). At this book's heart, we discuss the high-level "tricks" used by many algorithms in the hope of demystifying them.
 * 2) The book uses pseudocode to efficiently explain the algorithms, but the pseudocode should be clear and expository (and commented when there is a chance for confusion). Additionally, this book includes (will include) Python implementations of the algorithms in an appendix. Appendecies can be written for other languages as well.
 * 3) This is a teaching book: The materials should help the student and the autodidact alike in learning the material. If material requires information not specified in the prerequisites, that information should be covered too. The hope is that after covering this text, the reader can better consult Knuth and CLR (and other algorithms books we should recommend).
 * 4) Use primary sources as much as possible. This is good practice for two reasons: (1) because the book is technique-oriented, sometimes the first presentation of an algorithm is the clearest guide to its insight. For example, the original paper on quicksort simply relied upon "random" in order to get good performance. The layers of deterministic optimizations to quicksort over the past four decades have helped the algorithm, but only mystify a beautiful idea further. And, (2) because this is a free/open book, we must be very careful that we use proper citations and never plagarize other material. (Always ask for permission if you need to use a secondary source.)
 * 5) Use the wikipedia as another source for material, but edit the material to present only the main points and ideas: the encyclopedic detail of the wikipedia can become a distraction when trying to read a book that is not meant to be a reference book.
 * 6) Use the mathematical royal "we" for some phrases, but try to use the second-person "you" as much as possible: it makes sentences easier to construct that also sound more direct.
 * 7) Look for insights into understanding an algorithm or a part of the software engineering process in general.
 * 8) We cover backtracking before dynamic programming and greedy algorithms because both can be thought of as special cases of backtracking.
 * 9) Randomization is an important concept that's gaining more and more ground: it's discussed early instead of later because it shouldn't be thought of as an "advanced" or intimidating topic. It represents an attitude that shows where cutting edge research is heading, so we should be one of the books that best absorbs this paradigm.
 * 10) Please use "active voice", rather than "passive voice". ( Too many texts say stuff like "A null is put on the end of every string.". Huh ? Does that mean I need to make sure I manually add more code to add a newline to the end ? Does that mean the routine already puts a newline at the end of the code ? Does that mean the OS puts these newlines there ? Active voice avoids all this confusion: "The readline puts a null on the end of the string". )

Chapter headings and buckets
I just finished an advanced algorithms course, and this is what we covered. Right now, this is a terribly disorganized list because I'm dumping topics from my handwritten notes here. Later we should reorganize this. I suggest we follow the "big buckets first" approach and keep this as a one-page article until the length becomes unmanageable. Disprosia, when you replaced all my level-one headings, you didn't replace my level-two headings, so you flattened out my list. Some items were children of other items, but now, everything is one the same plane. Was this intentional? If so, it'd be nice if you posted a reason behind that.


 * My two-cents: I think that One-Level headings should be used for Chapter titles. This isn't the wikipedia, so the taboo against using one-level headings doesn't exist. These chapters might be best viewed as separate web-pages, and if that feature were to be implemented, discriminating based on one-level headings would be a good way to go. But I don't know the general wikibook rule of doing it, so I won't modify it back yet. Mshonle 21:35, 30 Jul 2004 (UTC)

This section looks outdated. Should it be removed? --jyasskin 22:19, 22 Jan 2005 (UTC)


 * Sure, is there a standard place to archive it? MShonle 23:49, 22 Jan 2005 (UTC)

Code versus Pseudo Code (was "Guidelines")
Here are my thoughts on where the book should go:

(Mshonle 21:02, 23 Jul 2004 (UTC))
 * 1) introduce backtracking before DP and greedy algorithms, as backtracking is easy to understand and helps in the understanding of DP and greedy.
 * 2) I intend on posting more notes from my own classes.
 * 3) we should use some pseudocode language that makes the algorithms themselves as clear as possible. We shouldn't do just one popular language or try to use multiple languages. pseduocode I've seen lately matches python, so maybe we'll want it to look more like a typed-Python
 * 4) we may want to consider genetic algorithms as well.

Thanks for all the work you've done! Here's my thoughts:
 * 1) I prefer well-commented real code (in any language) over pseudocode.  Pseudocode can be ambiguous.  I suggest we list as many code implementations of algorithms as possible.  I like python and C, but I don't want to get a language war started.  I just know I don't like pseudocode.
 * 2) Genetic algorithms (I think) are used in NP-complete problems, so we should introduce them after that point.

--Waxmop 18:24, 4 Aug 2004 (UTC)


 * For point 1: I think pseudocode is superior to explaining an algorithm than "real code". It's very, very hard to introduce algorithmic concepts if you have language implementation issues to contend with on top of that. Furthermore, I've seen a lot of algorithms books, and only the best books used pseudocode (we'll ignore for the moment that Knuth chose assembly). The syntax I've been using shouldn't be ambiguous at all: if you think something is ambiguous, you should mention it and we can work on it. Also, the pseudocode borrows heavily from Python anyway, only it's *less* ambiguous. For example, I include "end if" (as "fi") and "end for" (as "repeat") so that you can see where one if ends and another begins.


 * I've seen languages mark the bottom of a loop with "next" (BASIC), "loop" (ASM), or "continue" (C). Is there some real language that uses "repeat" ? (I think it's fine for pseudocode). -- DavidCary 03:15, 18 Nov 2004 (UTC)


 * Knuth presented the loop-while-repeat structure in one of his essays in the Literate Programming book. Because the pseudocode looks close enough to Python, but contains different features, it's important to make it look different enough so there's no confusion. The compromise was to include Python implementations of everything in an appendix, so no ambiguity would exist (provided the reader knew Python). MShonle 16:00, 18 Nov 2004 (UTC)


 * I also made this point for the data-structures book: there's no real advantage of including as many languages as possible: the current fad language (which is either Java or C#) and Python should be sufficient. If you want to create a "Python Implementation" appendix for all of the code in the book, feel free, but I most certainly do not want to clutter the text with three different implementations of the same thing (which makes the text look like it has a lack of focus and readers will get bored because perhaps they only care about C++ instead). I propose we use pseudocode for all of the book, and only attempt "real" implementations in an appendix (perhaps on a separate web-page). That should resolve your concernes.


 * For point 2: Genetic algorithms is its own technique, and this is a technique driven book, so if we were to cover them they should get their own chapter. (The "techniques" for NP-complete problems are proving their NP-completeness; i.e. the technique is run-time analysis of the polynomial time verifier and reductions. The backtracking section will include implementations for several NP-complete problems.) Either way, it would be a good idea to include an NP-complete approximation algorithm in the genetic algorithms chapter. I haven't made an outline for it yet as I don't have the materials to cover it. MShonle 19:13, 4 Aug 2004 (UTC)

Here's an example of comparing code. Here's the Python version:

def get_ugliest_puppy(puppies): ugliest = None for p in puppies: if ugliest = None: ugliest = p    elif p.ugliness > ugliest.ugliness: ugliest = p return ugliest

And now the pseudocode:

// find-max -- returns the maximum element, or -infinity if the array is empty function find-max(array vals): let result := $$-\infty$$ for-each v in vals: result := max(result, v) repeat return result end

Where the text will note that max between any object and negative infinitiy will always result in the object. You also note that code should be heavily commented: this is primarily a text, so the "comments" are the descriptions. But I do like the idea of having a sentence before each function, to hammer home "this is what this function should do". (It's good practice in real-life, as well.)

By allowing mathematics into the code, which is what all successful pseudocode based books do, you can speak on the higher-level of mathematics. The Aho book uses "sets" and only later do they mention different data-structures to use to make Dijkstra more efficient. (I think when the Dijkstra section gets written it will be worthy to discuss those trade offs.) There is a danger of being too mathematically clever, but part of the point of the book is to bring the reader into the world of mathematics.

Thinking of "well, I guess I need an if in there that needs to check each time if we're iterating for the first time or not" is not mathematical: it's just implementation details. In contrast, thinking of a for loop as a way to generalize the "max" function is loaded with detail. Once you arm the reader with that insight, they might see where that line of thinking can apply elsewhere.

Note, if we jumped into the functional programming zone, the function would be a one liner:

function find-max(array vals) := reduce(max, null, vals)

I do not think that's the way to go: Then the algorithm becomes too subtle and the solution only seems to be from the heavens: not from some general principle.

Eitherway, I think the strongest argument in favor of pseudocode (after the expository reasons) is that it's less likely to alienate readers than picking one specific language (picking multiple languages doesn't solve the problem because it turns the book into a comparitive programming language text instead of an algorithmic technique text; but a linked-to appendix of implemenations is a fine solution: such code should also have test cases and run results to show that it actually works). MShonle 22:30, 4 Aug 2004 (UTC)

Example pseudocode.
We can put links in the main text that point to implementations in each language. Maybe it would look something like this:

function return-1: return 1 end

The table code for it looks ugly, but it'll be out of the way from the reading yet also easy to access. (Naturally, little code snippits don't need the link, but each completed algorithm could have one.) MShonle 20:42, 5 Aug 2004 (UTC)

Some code we can use
Eric Lippert is allowing us to use this entry from his blog to cover the longest common subsequence. We just need to provide the above link in our references section. (Mshonle 21:02, 23 Jul 2004 (UTC))

Techniques versus Types of Data Philosophy
Because this is a text book, and not an encyclopedia, of algorithms, this book should focus on the underlying algorithmic techniques involved. Text books tend to discuss algorithms in two different ways: the "types of data"-oriented book breaks algorithms discussed into directed graph, undirected graph, string algorithms, and trees chapters; while the techniques-oriented book breaks algorithms discussed into the different techniques used: dynamic programming, greedy algorithms, and divide and conquer.

Naturally, there are books that merge the two philosophies. However, in order to carry a coherent message, and to aid learning, I believe this book should be technique-oriented. The insights to understanding greedy algorithms is aided when you see examples that include directed and undirected graphs. The insights to understanding dynamic programming (a particularly challenging topic to some) is aided when you see examples that include text, numerical, and graph problems. Some people get stuck in certain ways of thinking and seeing the methodolgy of one algorithmic solving technique in different contexts helps. Were we to be an exhaustive encyclopedia, we might consider the other presentation. However, this book must start out slim, and will likely be used to supplement other books already used in courses. Therefore, providing the high-level insights will be beneficial.

We do not want a book that merely brings down "from the heavens" solutions like Dijsktra's algorithm without giving the firm footing underneath to allow people to make their own algorithms. Mshonle 06:48, 30 Jul 2004 (UTC)

Time to break up the single page...
I made a spelling edit to the text and I got a warning that the algorithms pages is 50kb, and some browsers might have trouble. I suggest we break up section into it own link based on the headings. Any other ideas?


 * I think breaking into pages by chapter seems like a good way to do it. The Chapter headings should still exist in the main page (so the table on contents will still be there), but only be links to the full page. That means a chapter might not be able to grow past 32k, though, without seeing the warnings again. I've seen other books try to put a separate page for *everything* and that's just death: No one can read the book as easily, potential future contributors included.


 * Do you know if there is a way to disable to top-level "edit" link? That way the largest text area editable at a time would be a chapter. That would probably be better than the breaking up solution.


 * I've also been discussing writing a tool that can turn the wiki into a pdf file (via latex), which would be a great way to give people something readable. But that shouldn't happen until the book is in better shape. I've been off the project to get work done, but next quarter I'm taking the PhD algorithms class, and I intend to get my notes in as I take it (sure, we've all heard that one before :-). Either way, I don't really like the format of the Data Structures book, which seems to be struggling quite a bit. I think partially the set up seems to encourage people to write wikipedia-like entries (or to copy wikipedia entries), but that's no way to write a textbook. A book needs more focus, and doesn't need to mention all of the history or sidebar level details that are appropriate for an encyclopedia entry. MShonle 03:48, 30 Aug 2004 (UTC)

OK, it's been broken up into chapters. The names of the subsections are the chapter numbers instead of the title of the chapter in hopes to keep the idea that this is all part of a single book, and not a collection of unrelated entries. MShonle 00:28, 29 Sep 2004 (UTC)

Some quick comments after I've read the first chapter:
 * It seems to focus too closely on low-level optimization ( See http://c2.com/cgi/wiki?ProfileBeforeOptimizing http://c2.com/cgi/wiki?OptimizeLater ).
 * It seems to tell people to re-invent the wheel every time (NIH syndrome) rather than use standard library functions.
 * Where's the big-O notation ?

I hope this is covered in later chapters

-- DavidCary


 * Hi David, Big-O notation is covered in the second chapter. Also, I'm not sure why you think that the chapter is focused on low-level optimization? I thought the "When is Efficiency Important?" subsection addressed that quite well. (Moreover, I don't think we even mention any low-level optimizations. We discuss different implementations for to-lower, but that's only to motivate the point for abstraction and the different levels of thinking.) If you are thinking of something else, please do explain.


 * As for the reinventing the wheel: The goal of the book is to introduce algorithmic techniques. We could invent problems (like homework assignments) that don't have solutions in libraries and present algorithms that solve them, but I think it's more natural to present well-known problems, because the motivation is better and the statement of the problem is easier. (The Python appendix has a note to implementers to demonstrate the use of standard libraries.) Either way, reinventing the wheel can be good, too: You want to avoid it as a common practice, but doing it once when taking a course in algorithms can be quite instructive. Every cute guideline has an exception. MShonle 16:13, 18 Nov 2004 (UTC)

Some links that can handy...
See if this community tool can give any help finding other sources...

http://del.icio.us/tag/algorithms


 * This would also be useful for the Computer Science:Advanced Data Structures and Algorithms book, which is much more eclectic in content and is still looking for new items. MShonle 04:49, 29 Dec 2004 (UTC)


 * I think it's cool for any other book but as I saw that you were active on this I just passed the information :) just add to the end next to the tag, I have included it on the C++ book that I'm contributing to...--Panic 05:31, 29 Dec 2004 (UTC)

All Chapters View
I created some templates that redirect to each chapter and then made an Uberpage that includes all of the templates.

You can find the link here: Computer_Science:Algorithms:Full_Text

I don't want to post it too many places yet, because it might cause for some heavy server load. Also, it includes the chapter nav templates at the beginning and end of each chapter: A Chapter_1_contents page (e.g.) would have to be created that would be the real content of the book, and then the single-chapter view of each would include the content plus the navigation, and the many-chapter view would only include all of the content pages. (Navigation might also be hurt in that style.) Perhaps for the Data Structures book we can try it that _content-based way to see how it works because there's still quite a bit of outlining left to do for that book.

Any other ideas welcome. -- MShonle 05:14, 29 Dec 2004 (UTC)


 * I like this concept very much! I started to try a little bit in my private sandbox how to improve this concept and make it more generally accessible. I thought of using templates to shield navigational elements in the PRINT version, so that one does not have to put all the content in templates (which has the disadvantage, that a user can not click "edit this page" on top to make changes). The shielding could work by using templates with parameters, but one has to be a little bit tricky. I've also been playing around with CSS2 page breaks (that currently work in Firefox) which might enhance the printing experience. All of this is in development, but I will let you know when it works, and when I have a handful of simple templates that anybody can use. (For now, if you have some time, help me to review some books and give development stages to some books on the IT bookshelf) (Another hint: templates don't actually have to be in the template: namespace. Each page can be included by preceding ":", like ). --Andreas Ipp 11:58, 15 Jan 2005 (UTC)


 * The Computer Science:Data Structures book handles it a little cleaner, but has the drawback that you are editing a _content page, the pointer of which you need to visit through a template. MShonle 08:11, 16 Jan 2005 (UTC)

Review
Hi MShonle. I just reviewed your book to update your development stages. It is a very clearly written book. I think the chapters are more complete than you suggest by having all the "ToDos" around each chapter. Even without them, the chapters look consistent to me, and I would give more chapters "100%" (and attract more possible readers) if you just deleted the ToDos, or put them collectively at the very end. But having empty subsection titles all over is not so reader-friendly, according to my opinion (and I am a reader! :-) ). See also my comment above on "All Chapters View" .--Andreas Ipp 11:58, 15 Jan 2005 (UTC)


 * Thanks. I think there's some more work that needs to be done before attracting more readers: it's still very much in the cathedral stages right now. Right now trying to get more writers is my primary objective. MShonle 08:14, 16 Jan 2005 (UTC)


 * Followup: Another reason to embed the TODOs right now is because the author of a section has an "ultimate plan" for that section, and the TODOs reflect the structure desired. How to present materials is highly subjective, so there isn't a "default" way for contributors to write, say, a divide and conquer chapter. MShonle 17:48, 17 Jan 2005 (UTC)


 * Hi MShonle, I guess I got your point. If you have a clear view of how things should be structured, then this is probably the best way. You're right, there's no point in presenting something as "ready" if it just is not yet. Actually, when browsing through your chapters, I thought about adding Newton's approximation by myself, but I was not quite sure how it would fit from the programming side (I'm more a physicist..). Keep the work, it is really getting a great book! --Andreas Ipp 21:39, 17 Jan 2005 (UTC)


 * Please do add, w.r.t. Newton's square root method (the general method should probably go in the calculus book isntead). For the programming I can put in the code. (Or, you can post an outline on the talk page before you write too much?) MShonle 23:20, 17 Jan 2005 (UTC)


 * I just added it to your chapter 8, Newton's Root Finding Method. Just after I added it, I found your comment that you just would like the square root formula. Well, I hope it is not too long now, and in principle, the Newton's method should be familiar from middle school (I guess, there is nothing wrong with presenting a little bit of calculus to programmers). --Andreas Ipp 00:16, 18 Jan 2005 (UTC)


 * Thanks! One style note is that we want to use wikipedia links as sparingly as possible: the idea is that the book should be self-contained and someone could print it out and use it, instead of clicking through many external pages. As for the calculus angle, perhaps the square root method itself could be derived from the more general material, and have the algorithm that uses the simpler method (i.e., averaging the guesses) be presented first. Thus, the calculus details can still be there, but be in a starred ("*") section to let the reader know it's not essential to know to understand later material. --MShonle 00:41, 18 Jan 2005 (UTC)


 * A star * section (or a note to skip at first reading) is fine with me. About the Wikipedia links: They won't show on printed material (look at your browser's Print Preview, if it supports CSS), and on screen they add interactivity: If I don't know a word, I just click on it, instead of having to type it into Google. It doesn't mean I have to follow all the links there are. I see it as a possibility to enhance the screen version of Wikibook (by its partner Wikipedia) to something more "live" than a "real" book. This said as a suggestion, the main stylistic decisions are of course determined by the main contributors (which is you..) --Andreas Ipp 02:19, 18 Jan 2005 (UTC)


 * Thanks for the comments: I have nothing against rich-links in principle, but they can create a confusing congitive experience for the reader. For example, they might think "do I need to understand this link?", "do I need to follow this?", and there's no clear answer as to how far the links should be followed. The rule of thumb is that if the link is required, it should be replaced with further exposition in the text instead. If a link isn't required, then perhaps a link at the bottom in a special "for further reading" section could be done. But too much information overload can turn a reader off: it can be exhausting either following links or determining not to follow links. (We may even privately decide that "all links are optional" but the challenge still remains that the reader might not know that, and second guess.)


 * Naturally, I think the wikipedia itself should have as many links as possible (within reason) because part of the value of the wikipedia is the richness of the links as a way for someone doing research to start from, say, Alan Greenspan, and follow links to the Federal Reserve, to the money supply, to inflation. But for wikibooks, I see the goal is primary to educate and have the reader gain special knowledge of a single topic. Too many distractions can hurt the focus. Most of the topics we cover are also wikipedia articles, so the tutorial nature is the value we are adding on top of that. --MShonle 02:47, 18 Jan 2005 (UTC)


 * Sidenote: For one example, links such as "root of a function" are probably best removed with a discussion of what a root of a function is (presumably copied from the wikipedia) and put in the Mathematical Background chapter of the text. Other links, such as "derivative" are probably too advanced: either the user will understand calculus and know already what a derivative is, or wouldn't be enlightened enough following the link: some concepts require a semester to really "get". (Though, I suppose you could make an arugment for including a link to the calculus book.) MShonle 02:57, 18 Jan 2005 (UTC)


 * Sidenote #2: I also forgot to mention the role of the Advanced book: it's much more eclectic in content and is meant to be more of a reference than a tutorial that is read cover-to-cover. Thus, in that context I could also see the high value of using wikipedia links. --MShonle 03:07, 18 Jan 2005 (UTC)

Guidelines Questions

 * Should all math be placed in  tags? This conflicts with the advice at How to write a Wikipedia article on Mathematics, but of course, local guidelines win out. --jyasskin 22:19, 22 Jan 2005 (UTC)


 * My general bias is to use the math tags when possible. It's easier to type the single-quote versions, so there are places that still use them. Also, the pseudocode formatting is different: all variable names are slanted while only functions defined in the book, or as an exercise, are bold-- assumed library functions like max or abs aren't bolded. (This is as opposed to making keywords bold, which draws attention to the very thing that needs the least attention.) Function or variable names refered to in the text probably should not have the math tag, while actual formulas should.


 * The general idea is that a wiki to LaTeX tool will be written and the user can download a clean PDF: the conversion process will be easier if the tag is used consistently. (Also, for publishing, the other plan is that this book and the Data Structures book would be combined into a single Data Structures and Algorithms book.) MShonle 00:19, 23 Jan 2005 (UTC)


 * How deeply nested should headings be? In chapter 2, my first inclination is to make a separate subheading for each term that's defined. Is that reasonable, or are you trying to keep the heirarchy as flat as possible? --jyasskin 22:19, 22 Jan 2005 (UTC)
 * I think it's more of a question of emphasis. The Mathematical Definitions section is primarily there to provide a little more detailed explaination of elements used in later chapters.


 * For example, in the Longest Common Subsequence section I realized that I shouldn't assume everyone knew what a subsequence (or what a sequence) was, so that it needed to be defined along with some suitable examples. Instead of distracting from the discussion with the defintion and examples, I decided to put it in the front of the book. (Another goal is to avoid wikipedia links, so that the reader can enjoy the book on its own (possibly printed out) and not get frustrated trying to figure out what is just a footnote and what is manditory. Of course, much of the content in that section has been copied from the wikipedia, but edited for tutorial purposes.)


 * So, having headings would probably draw too much attention to what really is a glorified footnote and probably attract contributions trying to cover the topic in further depth, even though such depth might not be useful in understanding the rest of the book. MShonle 00:19, 23 Jan 2005 (UTC)

Check sort - precursor to the Rapid sort - used to eliminate duplicates
I have "invented" several algorithms which after having been reduced t minimum form are so simple it is obvious that any other computer programmer could have invented them independently. The Check sort is a good example. The Check sort not only sorts numerical data (and potentially also alphanumeric data converted to its ASCII code) it main value and purpose is in eliminating duplicates. Even though simple enough to have been invented independently and at a prior time I have not been able to find another algorithm which duplicates its function although others have claimed that its successor the Rapid sort is nothing more than a version of the Bucket sort in one instance or the Counting sort in another. I feel that both sort routines are useful and unique enough, however, as to merit their distinction and publication somewhere even though they have not been published elsewhere except on my homepage in 1996 and briefly in the past month in the Wikipedia (now restricted to talk pages) The Rapid sort is now published on line in the Urban Dictionary. Furthermore because I modified the Harvard Chart Method of Logical Equation Reduction to handle multiple states so that I might explore a computer's capability of reducing multiple state logical equations to minimum form and thus be able to "think" at the level of a human being and comment on such issues as to whether God exists or not (which actually as a result led me to the logical definition of God that God is the only entity by definition who can reduce an infinite number of equations having an infinite number of variables with and infinite number of states to minimum form instantaneously) it can not be published under the WP:NOR policy. The same restriction applies to an article entitled "Optimal classification" I wrote about Dr. Rypka's method of microbiological classification after using my own research to answer several questions, clarify several misconceptions and eliminate other points of confusion. I would therefore like to inquire about publication of these methods here. Typetive 09:49, 5 June 2006 (UTC)


 * This book is a catalog of algorithmic techniques, not a catalog of every algorithm ever invented by somebody. I just don't think it really fits the aim of this book. --MShonle 00:57, 3 July 2006 (UTC)
 * Most such algorithms will not find themselves in this book anyway since they were originally published by the ACM or IEEE or other Journals who copyright their publications and require paid membership and or subscriptions or purchase of the articles in which the algorithms appear. In this case the author has presented an algorithm without requiring its purchase, a rare but welcome event. Typative (talk) 17:31, 6 October 2007 (UTC)

Merge with other book: Nay
I see no meritt in merging the Algorithm implementation book with this one. The two books have different aims. To have the best learning experience books must be focused and not aim to be everything to everyone.

My recommended course of action is that the two projects be aware of each other's aims. Given that the table of contents for this book is fixed and stable all that's required is that the new book's plan complements this book's plan. It's probably misleading that both books have the word "Algorithm" in the title. In one, it's the mathematical definition, while the other is the more general programming definition (as a synonym for "subroutine"). --MShonle 01:04, 3 July 2006 (UTC)


 * Fair point. I comment on Talk:Algorithm implementation --Krischik T 06:19, 3 July 2006 (UTC)

```` I am very very new to WIKI, but very very old in the computer game, I published my first computer paper, the design of a random access system for manufacturing control in 1958. I have since retired from BTL/WE/etc and playing at computer. I looked with interest in your development of a book, inh public ..., that is very good. Now the final very very good step would be for you to PROVE conclusively thatthe algorithms that you may illustrate really work, and if the need for final code rather than pseudo code then you MUST prove their equivalency, and then having done that your printing system for the final imprint MUST develop the result of the algorithm in real time using the correct softsware as part of the type setting system, so that you need not actually provide the answer to be typset. That is the most likely point of error. This has been done long ago in the Manual for the sam76 language, and the only time there was a erroneous answer was traced back to a fault in the algorithm manjuscript. An example of what I mean is in Algorithms in Sam76 rectly posted in Wikki. Good Luck Algorithms in Sam76

Standardized pseudocode
Is there a page that specifies the pseudocode that is to be used in this wikibook?

If more than a couple of people are going to contribute, it really needs to be defined and included as an appendix in the book as well as in a style guide. I've spent about 1/2 hr trying to find some kind of specification, and haven't been able to. 69.181.2.10 23:58, 30 August 2006 (UTC) Joe_n_bloe


 * There was a definition called Wikicode but it is now depreciated and was not never used in Algorithms. Personaly I think rightfully - a pseudocode should use little special characters as possible (better begin/end then '{'/'}' - you can look up the meaning of begin in an english dictonary but not the meaning of '{') . Krischik T 08:17, 31 August 2006 (UTC)

Come on!Let's work harder!
It is a pity that this book is far from being complete.I hope this book can be interesting and easy to understand. More examples and pictures and animations are needed. Visame (talk) 19:40, 3 May 2008 (UTC)

print version license
you need to update the license notice in the print version, I would do it but I am not sure how it should read.

Prime numbers
Hello, there is a book in the Mathematics subject, A More Efficient Prime Number Generating Algorithm, that I wonder if it might fit in this book? I have not taken a course on algorithms so I do not know and I wonder what those who have worked on this book think? This book has some original research, it is short (more like a section than a book), and is mostly on an algorithm to make a list of primes. So, I thought maybe it could fit here somewhere. And, since it has no references and seems to have original research, I thought perhaps one of you might know of a reference on the subject to use as well instead of just copying directly from this other "book". Any thoughts? NumberTheorist (talk) 20:10, 14 February 2010 (UTC)
 * Oh, I see above that there is another book, Algorithm Implementation, and perhaps this would fit there instead if it doesn't seem like a good fit here? NumberTheorist (talk) 20:12, 14 February 2010 (UTC)
 * Yes good have in day net .welcome on so side note.what be i done so it by look it after to. 2401:4900:4478:86D4:0:1:DD31:E601 (discuss) 08:35, 29 March 2023 (UTC)