On 03 Dec 2001 11:11:15PM +0800, Dax ([EMAIL PROTECTED]) said:
> Kung me deadline kelangan ma meet. Kasi baka malugi kompanya.
> Kung me oras pa siguro pwedeng ma modify para malinis yung code.
> Minsan yung mga boss walang pakialam kung paano mo ginawa basta magawa mo
Actually, I was browsing through the Jargon File and the entry on
{brute force} is rather insightful.
brute force: /adj./ Describes a primitive programming style,
one in which the programmer relies on the computer's processing
power instead of using his or her own intelligence to simplify the
problem, often ignoring problems of scale and applying naive
methods suited to small problems directly to large ones.
The term can also be used in reference to programming style:
brute-force programs are written in a heavyhanded, tedious way,
full of repetition and devoid of any elegance or useful
abstraction (see also {brute force and ignorance}).
The {canonical} example of a brute-force algorithm is associated
with the `traveling salesman problem' (TSP), a classical
{NP-}hard problem: Suppose a person is in, say, Boston, and
wishes to drive to N other cities. In what order should the
cities be visited in order to minimize the distance travelled?
The brute-force method is to simply generate all possible
routes and compare the distances; while guaranteed to work and
simple to implement, this algorithm is clearly very stupid in that
it considers even obviously absurd routes (like going from Boston to
Houston via San Francisco and New York, in that order). For very
small N it works well, but it rapidly becomes absurdly inefficient
when N increases (for N = 15, there are already 1,307,674,368,000
possible routes to consider, and for N = 1000 -- well, see {bignum}). Sometimes,
unfortunately, there is no better general solution than brute
force. See also {NP-}.
A more simple-minded example of brute-force programming is finding
the smallest number in a large list by first using an existing
program to sort the list in ascending order, and then picking the
first number off the front.
Whether brute-force programming should actually be considered
stupid or not depends on the context; if the problem is not
terribly big, the extra CPU time spent on a brute-force solution
may cost less than the programmer time it would take to develop a
more `intelligent' algorithm. Additionally, a more intelligent
algorithm may imply more long-term complexity cost and bug-chasing
than are justified by the speed improvement.
Ken Thompson, co-inventor of Unix, is reported to have uttered the
epigram "When in doubt, use brute force". He probably intended
this as a {ha ha only serious}, but the original Unix kernel's
preference for simple, robust, and portable algorithms over {brittle}
`smart' ones does seem to have been a significant factor in the success
of that OS. Like so many other tradeoffs in software design, the choice
between brute force and complex, finely-tuned cleverness is often a
difficult one that requires both engineering savvy and delicate esthetic
judgment.
------
That aside, brute force is hard for big projects. So we need to be good
at both. =)
Sacha 8)
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
