NialScorva

Probably depends upon the implementation of both the OS and the standard library you're compiling against. If you're using a fast random number generator, it may be more of an issue as well. Depending what you are doing with the numbers, it may or may not matter. You wouldn't want to use rand() for any crypto application, and doing Monte Carlo integration might be affected by throwing more points in a particular neighborhood of your bounding space. On the other hand, a game or other app isn't likely to matter much.

The biggest flaw is that taking 10x as many lines and including an unneeded loop for something that can be done with a multiplication and a division is a sin.

Clutch

Sheesh, is this pissing contest still going on?

Remember when there was a point to this, in the first thread? A statistical error about a point of evolutionary origins?

Principia said the error was clear, but that it did not amount to a vitiation of the conclusion that SIPF dipeptides are "too close of a fit to nature to be coincidental". DNAUnion did not seriously contest this point, eventually limiting the scope of his point to: Rode made a mistake and I found it.

So what? For the purposes of the original Evo thread, DNAUnion made no compelling point; for, yes indeed, many orders of magnitude sometimes make no relevant difference to an argument about all-things-considered probability. For example: Everything else between Principia and DNAUnion on the original thread and on this one is a waste of time.

Principia

Very well put, Clutch. I'll only qualify it to say that anything else pertaining to the "pissing match" is a waste of time. So I won't put any more effort into it (and give Jesse a well-deserved break).

I did enjoy though the site Lobstrosity put up about programming habits -- hilarious. And the commentary about RNGs is interesting.

sophie

After the program design is complete and the computational complexity taken, then the real science of programming becomes apparent.

Program clarity is most often achieved via descriptive variable names coupled with a few comments whenever the relationship between variables are not evident.

Most often the pre-conditions and post-conditions of any given program functionality dictates the ultimate complexity of the coding. These are two elements of good programming practice which cannot be avoided.


FInally the technique choosen to provide the functionality given in the specifications is what seperates the professional programmer from the hack.

Mageth

FInally the technique choosen to provide the functionality given in the specifications is what seperates the professional programmer from the hack.

Generally, the professional programmer is the better plagiarizer.

sophie

Mageth say that generally, the professional programmer is the better plagiarizer.

I would agree to the point where copying proven algorithms from some good source does indeed entail a form of plagarism. On the other hand advances in programming methodology cannot be achieved via plagarism.

On a final personal bit of advice, the computer geek who often encounters the top-down vs. the bottom-up approach should pay careful attention to both methods and incorporate both approaches in their design. This is sort of a big-picture approach.

NialScorva

The vast majority of programmers will go their entire career without creating a single new algorithm, and that's probably a good thing.

The true key to programm is not understanding algorithms, but understanding your data and data flow. The algorithms are pretty much a trivial excercise once you have that laid out since most programs are 95% data flow. The only place that I can think of that aren't data flow dominated is modelling and simulations, and even those are still 30-40% data flow in most cases that I've seen.

DNAunion

DNAunion: The following should satisfy any reasonable person.


DNAunion: See, you did as much as explicitly state that if itself suffers from “spaghettiness” (all ifs do the two things you claim…well, kind of). You even showed just how “spaghetti-ish” if statements are by adding the LOL, emphasizing your “point”.

Mageth

DNAunion, I'm pretty sure Principia has dropped this pointless discussion. Why don't you?

LeftCoast

You are grasping at straws. Ifs are not "spaghetti-ish". The whole concept of "Spaghetti Code" is predicated on the notion that human beings must understand the flow and logic structure of the program. If statements are not really contributors in this case because they cause the branching to happen in very obvious and easily traceable ways - you will either execute the block contained within the 'true' condition or the block contained in the 'false'/else condition. The fact that at the machine level this is implemented as a jump instruction is irrelevant. The machine does not in any way "understand" what it is doing, it simply executes the instructions in the order the program counter addresses them. If you look at the machine language (aka compiled) version of even the most elegantly constructed code, you will undoubtedly see many logic transfers that if written by a human would be labeled "spaghetti", however, since only the machine will ever encounter this code - and it does not get confused - calling it "spaghetti" is pointless.