Jump to content

Talk:Algorithmic efficiency

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 81.149.74.231 (talk) at 16:23, 21 June 2012 (Error (I think): new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputer science C‑class High‑importance
WikiProject iconThis article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
CThis article has been rated as C-class on Wikipedia's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.
Things you can help WikiProject Computer science with:

title

Better title needed. The word "efficient" is a common one used in many different contexts. --mav

What about 'efficient' and 'effective' The german wikipedia makes a distinction between both. If there is such a distinction in english (I do not know, I am no native speaker) then you should probably mention it.

efficiency/effectiveness

moved this from the article:

The term "efficient" is very much confused and misused with the term "effective", though a scientific impact takes place. Efficiency is a measureable, quantitative concept, given by the equation: Efficiency = Output/Input (which is same as the concept productivity); or alternatively Efficiency = Output/Predetermined expectation. Whereas Effectiveness is a vague, almost non-quantitative concept, mainly concerned with achieving objectives. --212.72.25.10 08:01, 17 November 2005 (UTC)"[reply]

perhaps created because of the redirect from effective? I'm changing the redirect to point to effectiveness which already exists. --naught101 06:47, 18 November 2005 (UTC)[reply]

Improvement Drive

Time management is currently a candidate on WP:IDRIVE. Support it with your vote if you want to see this article improved to featured status.--Fenice 07:51, 5 January 2006 (UTC)[reply]

Optimality assumption

A common assumption is that there is always a tradeoff between time and space in an algorithm, but that is only true if it is actually on the optimal curve of time vs space. It is quite possible (and common) for any given algorithm to be quite non-optimal, in which case both its time and space consumption can be reduced, bringing it closer to the optimal curve. MikeDunlavey 19:20, 29 May 2007 (UTC)[reply]

*Algorithmic* Efficiency

Looking through the history, this used to be a good page. But it's now bloated with dozens semi-related topcs (e.g., the compiler and hardware optimizations). Those topics all have their own pages; they don't belong here. 128.84.98.73 (talk) 20:20, 14 May 2010 (UTC)[reply]

Agree completely, anything related to optimisation shuold be elsewhere. Murray Langton (talk) 05:32, 15 May 2010 (UTC)[reply]
When discussing the efficiency of algorithms in general, it would be extremely dumb to only consider what can be done to improve a pre-existing algorithm. Are you suggesting that programs should be produced first, without any regard for how well they are likely to perform, and then - once they are "working" - go back and see how they can be improved by optimization? If you are, then consider this:-
Imagine a 10 man-year project with 10 programmers working on it, blindly coding away for 9 months, only to later discover - during testing - that it all ran much too slowly and had to be completely re-written to improve its efficiency. The oft-repeated phrase "premature optimization" has a lot to answer for, and has been used in isolation and completely out of cotext to justify not caring how efficient an algorithm is from the start. As for "semi-related topics", when it comes down to efficiency, all things have to be considered simultaneously. A racing car designer has to consider tyres, suspension, engine capacity, fuel, airflow, safety, gears, brakes as a complete package (not forgetting the driver and his interfaces). Similarly, a software engineer should consider all "semi-related" but contingent topics during the design phase or pay the price later. The good software engineer should, just like his mechanical counterpart, design and build optimally. There are rare exceptions, such as one-off programs - but even these have an inconvenient habit of being re-used again and again. —Preceding unsigned comment added by Kdakin (talkcontribs) 06:01, 8 June 2010 (UTC)[reply]

Algorithmic olympics

This article relates to the subject and is very interesting: wired magazine--Billymac00 (talk) 05:18, 8 January 2011 (UTC)[reply]

So why don't you (or somebody else) insert this as an external link with perhaps a note in the main text of the article about algorithm competitions (new section?). — Preceding unsigned comment added by 81.157.168.203 (talk) 16:37, 18 December 2011 (UTC)[reply]

Error (I think)

For example, a condition might test patients for (age > 18) before testing (blood type == 'AB-') because this type of blood occurs in only about 1 in 100 of the population. This would eliminate the second test at runtime in 99% of instances; something an optimizing compiler would almost certainly not be aware of - but which a programmer can research relatively easily even without specialist medical knowledge.

I think this is the wrong way around isn't it? The blood type check should be done first to avoid the age test (the second part of the statement seems to suggest it is meant this way around). But maybe I am just confused. --81.149.74.231 (talk) 16:23, 21 June 2012 (UTC)[reply]