in reply to Problem Domains and Multiple Disciplines

Personally, I'd code that as:

```my \$sum = 5050;

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^2: Problem Domains and Multiple Disciplines
by itub (Priest) on Aug 30, 2004 at 18:22 UTC
I would do print 5050; ;-)

In response to the original post, you don't need to be a mathematician to know this. I heard about this formula in elementary school, with an anecdote supposedly involving Carl Friedrich Gauss and a nasty math teacher.

Regarding the "programmer/mathematician" comparison, be careful, because sometimes you see naive "mathematicians" that:

• suggest a wonderful but extremely complicated O(N) algorithm, without noticing that for a given aplication N is always between 0 and 2, and considering the overhead, the N^2 method is actually faster.
• don't care about the implementation issues of the language they are using, so they use a theoretically pretty but unnecessary recursive implementation that ends up being too slow or resource-intensive.

The point that thinking is sometimes better than brute force is well taken, but sometimes the opposite is good enough or better. From the Jargon File:

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.
Re^2: Problem Domains and Multiple Disciplines
by ambrus (Abbot) on Aug 30, 2004 at 16:11 UTC

That's a bad idea. You should code it as

```my sum = 100 * 101 / 2;
or something like that.

I know this from practice, as I once accidentally wrote 8092 instead of 32*256 in a program and had a hard time finding out why it wouldn't work. A computer can do arithmetic better than any of us.

I did it with a computer...in the shape of a calculator:)

I get your point, but unless the constants 100, 101 and 2 have some meaning in context, you've just advocated magic numbers.

A well named constant, that made sense in context, would be preferable.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon