www.scifun.org is a good website oriented toward experiments that can be performed with household items. There's also a TV show that corresponds to the website that has been playing nightly on PBS (in the Seattle area, anyway).
"Yes, it is, because it is something that does not need to be implemented, because heapsort works perfectly well for practical purposes."
Beautiful. You made my original point, proving the classic FORTRAN programmer mentality: "I can't implement something because my language is missing a feature necessary to do so. But, rather than admit that this is the case, I'll avoid the issue by pretending that another approach is better anyway." This doesn't make my argument a red herring, it makes your argument a straw man.
"arguing that FORTRAN is bad because it doesn't work for a number of problems that aren't in its major workload is silly. It would be like, oh, saying that Perl is evil because it can't do matrix transformations as fast as C.
Are you reading what I write? FORTRAN is good at what it does well -- loop iteration algorithms. However, when all you have is FORTRAN, everything starts to look like a loop iteration problem! This is the core of my argument; you're getting too caught up in the details to notice.
"Either you compare Fortran 77 on its own merits with C++ circa 1977 (i.e. nothing) or else you should consider the most modern incarnation of Fortran (Fortran 95) with C++."
Who are you to decide what can and can't be compared? A language is a language, and I can compare and contrast the features of languages as I please. Note that I talked about FORTRAN 77 in my post, not F90 or F95. It was a fair comparison - F77 is deficient when compared to a modern language such as C++.
As for F9x, look around for my other post on the topic. Yeah, the language adds some desperately needed features, but all in all, it's as messy as C++, has fewer features than C++, and has a smaller user community! I personally wouldn't even consider F90, unless I had a big chunk of F77 code that I didn't want to port, and a good reason not to link it into a C or C++ application.
"You may hate the simplemindedness, but in the real world people have to read, understand, and maintain other people's code. All those cute syntactic tricks one feels obliged to play in C or C++ just add to the time it takes for someone to read over your code and figure out what the heck it is supposed to be doing."
These issues have been so well debated that I'm not even going to go into them here. You're wrong. Time and experience have shown this to be true. The "cute" features that bother you are important to writing large, maintainable projects. Can they be misused? Yes. Sure. But to programmers skilled with the language, they provide valuable tools that FORTRAN just doesn't offer.
"As for your slam of heapsort in Numerical Recipes, in my recollection Press et al. identified many specific technical reasons for suggesting heapsort for many numerical applications over quicksort: it is an "in-place" sort, it has the same computational complexity as quicksort, the worst case scenario is only about 20-30% slower than the best case scenario, and, yes, its implementation in some languages is more transparent."
Gee, it'd be interesting to see the date of the paper you cite, given that the introsort variant of quicksort guarantees O(n log n) performance, and has a lower constant than heapsort for most inputs (and, BTW, this is the std::sort in the C++ standard library). To be fair, introsort wasn't around when the original version of NR was published, but the authors haven't bothered to include or even mention it in any subsequent volume. Wonder why that is....(my own personal opinion is that the other versions of NR are simple-minded translations of the original FORTRAN code...)
"To be fair, I should comment that "object oriented" F95 doesn't support runtime polymorphism, but I've yet to encounter a numerical analysis task that would benefit in any significant way from this language feature."
I work in molecular simulation, and it's easy for me to come up with numeric tasks that benefit from polymorphism. Consider this: geometrically "building" a molecule is essentially nothing more than linear algebra, but polymorphism allows you to write the build code once, and re-use it on whatever particular molecule type you desire. Incredibly convenient....
"In summary, the quicksort-vs-heapsort argument is a red herring."
No, it isn't. It is an example of something that cannot be implemented properly in FORTRAN. I love that this thread is littered with the responses of "well, you don't need recursion because you can always implement your own stack!" Classic FORTRAN programmer-ese: "My language isn't deficient, you're just lazy!"
The fact is, introsort (the variant of quicksort used in the C++ standard library) does guarantee O(n log n) performance, it has a lower constant than heapsort on many input sizes, and a constant on par with heapsort for many more. And you can't implement it in FORTRAN either -- it's a recursive algorithm. Sure, you could write your own stack, but A) you have to write your own frigging stack and B) try to do that in FORTRAN without imposing some artificial limit on stack size, input size, or something else. The authors of NR couldn't...their code breaks with inputs larger than a certain size....
It may be a relatively minor example, but it was an easy one to come up with. Pick another -- let's talk about space-efficent random list insertion or deletion, or implementation of a balanced tree, or any of a number of other areas where data structures are critical to algorithm performance. FORTRAN is not made for these things. Unfortunately, not every scientific problem is so cleanly decomposed into the tight little loopy segments that FORTRAN is good at computing.
It is absurd. What's the advantage gained by the hand-coded stack approach? Smaller stack frame, you say? Why does that affect execution speed in this context? You do some hand-waving by mentioning "cache and TLB misses," but this is almost pure crap, given that the context in a recursive function is going to be local anyway, and thus, the issue of cache misses will rarely, if ever, arise during function body excecution.
Granted, you might run into this problem at the unwinding phase of the stack at the end of the recursion, but at this point, the performance impact is negligible anyway.
Pile on top of this the fact that the NR stack makes it harder for a C/C++ compiler to properly optimize call dispaches in a sensible way, and the fact that, most likely, the compiler is going to do a better job of optimizing the stack code of a particular architecture than the authors of NR, and you end up with a smelly implementation of a good algorithm. And it isn't the only one. The code in NR is positively awful.
FWIW, both heapsort and quicksort have average complexity O(n log n), but heapsort has the same worst case complexity, whereas quicksort has O(n^2).
True, however, quicksort's constant is lower than heapsort, which means that in most implementations, it is faster than heapsort, on average.
It is also true that quicksort has a worst case of O(n^2), but introsort (the variant of quicksort acutally used in the C++ library), has both average and worst case of O(n log n).
(FWIW, the constant difference is one of the reasons that NR doesn't implement quicksort. well, that and their irrational fear of the cost of recursion - they go so far as to implement their own stack, which is absurd.)
Consider two identical algorythms written in F77 and C++...
Ok. It depends on the algorithm, actually. C++ can actually be faster. But that wasn't the original point. The point is, that algorithms are often more important than sheer loop-iterating speed, and for this, FORTRAN comes up short.
NR writes for both FORTRAN and C. The shortcomming isn't the language.
Sorry, but no. Look at the code in the versions of NR. The C version is basically a rehashed version of the FORTRAN version (almost, but not quite, an f2c of the original book). The algorithms are the same, with minor exceptions. And frankly, it is a language isssue. FORTRAN doesn't have recursion. You can't properly implement quicksort in a non-recursive language. And quicksort outperforms heapsort in most cases.
While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).
However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...
Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
Don't use Fortran 90. It's as messy a language as C++, with the significant disadvantage that it has a much smaller user base.
Honestly, your objection to C++ is unclear to me...you say you spend more time fixing bugs than approaching the task at hand? Is this because you don't know the language that well? Perhaps because you're not taking advantage of the many excellent libraries available to you? Keep in mind that C++ library design requires a great deal of skill, but using a well-designed library is actually easier than coding in other languages.
C++ is my own personal choice for anything by the most demanding of high-performance computing applications. Is there an overhead to the language? Debatably, yes. Does it matter, in 99.9% of applications? No. And with only a little bit of forethought, even the "inherent" performance hits can be avoided in the places where it matters. It's just that you have to rely on a profiler to tell you where those places are...
There is a significant community of researchers and developers working on scientific and high-performance computing in C++. Check out some of these:
POOMA - a high-performance mathematics C++ framework
Blitz++ - a C++ mathematics library which uses template metaprogramming to achieve FORTRAN-caliber performance.
MTL - another example of template metaprogramming.
oonumerics.org - a good site for information on high-performance object-oriented code.
These are just a few good starting points. Do a google search for 'high performance c++' to find many more. Just, please, for the love of Deity, don't code in FORTRAN. ick....
"Daisey...long ago fled Starbucks-land for Brooklyn...where he has prospered, adapting his book into a successful off-Broadway play."
Bzzt. Sorry, Jon. Please Play Again. And next time? Try to at least get some of the facts right.
21 Dog Years was a play long before it was a book...Daisey put it on in Seattle in a few different theaters, including the back room of the speakeasy.net cafe! I saw it there about 2 years ago (before the cafe burned down).
As for Brooklyn, Daisey didn't leave for New York until this year. He'd been putting the show on in Seattle for several years by that time...
"Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using."
Uhm, last I checked, that's because Micro$oft doesn't implement the STL standard properly, and their MSDN docs reflect their implementation, not the standard one.
Maybe this has changed, but I doubt it. For a much better (and correct!) STL reference, go see dinkumware, which sells an online reference, as well as a complete library implementation, should you need it. Dinkumware, conveniently, also provides the online docs over the web for free, as long as you promise not to download them to your machine.
"In all seriousness, if/. wants people to pay for it, there needs to be some serious checking of stories before posting. The Internet may have partially obsoleted deadtree papers, but it hasn't obsoleted the concept of journalistic integrity - and integrity is what separates a legitmate newspaper from a tabloid."
I'm going to get nailed for this, but I think it has to be said. I'm not trolling.
No one ever told you that you were paying for slashdot to have "journalistic integrity." Or that you have to pay. Or that you should pay for slashdot at all. In fact, you've been given every ability not to pay, and still obtain the same content. It's just that now you'll have to look at a few annoying ads if you choose not to pay. So will you pay? That depends on how much you can tolerate ads, doesn't it?
You know, whether you like it or not, slashdot has been doing the same damn thing for as long as I've been here. Maybe you'll argue that I missed the "grand old days," but I think I've been reading for long enough that I'd have noticed if slashdot's content changed appreciably at some point. I haven't noticed. So I guess I'm confused--why is this lack of "journalistic integrity" such a surprise to you? More specifically, why is it such a surprise that you have to spend time writing snarky little comments about the site, ON the site that you so despise? Don't you have anything better to do with your time?
In my recollection, no one here has ever suggested that slashdot should be your only source for "news." In fact, other than the occasional noteworthy editorial, book review, or famous comment, I don't recall slashdot ever generating any "news" of it's own. It's nearly always about linking to something interesting that somebody else wrote, and making some editorial comment about the link. You'd have to be living in a dreamworld to think that this was ever objective "news." For me, it's always been about two things: 1) rapid exposure to things and ideas that interest me and 2) reading the collected opinions of a bunch of like-minded people on subjects that I enjoy thinking about. Except that recently, that second aspect has been increasingly buried by pissy little comments like your own. And that really chaps my ass.
So you don't like slashdot. You think it's subjective and lacking integrity. Fine. That's your right. Go read something with integrity and leave the rest of us alone. We'll get along fine without you.
I don't want to sound like a troll, but really, if you don't know the answer to this question already, you aren't ready to be a tech manager.
I'm serious. You say that you're "not a great coder," but you provide no other information about your technical skill level. So, one can only assume that you're an inexperienced coder/hacker, and that you've never worked on a real project team before, let alone led one.
My answer to your question is this: I've always wanted a boss who understood what I was doing as well as I did, and probably better. At the very least, I wanted a boss who had been through the grinder, and could understand why I was making certain choices, without second-guessing them. And honestly, if you don't have at least a few years of professional-level coding experience under your belt before you enter the world of tech management, you won't meet that requirement. In short: if you want to be a good tech manager, be a tech worker long enough to count.
"Most engineers keep up reasonably well with the changes in ForTran. It has come a long way since f77, which is often used as an excuse NOT to change to a C based platform, along with lack of adequately optimized compilers."
Horse-hoohah. Maybe, by "adequately optimized compilers" you're referring to C++ platforms, but even that's not true anymore, unless you're discussing older implementations. Fact is, the current generation of C (and yes, even C++) compilers are as well optimized as any Fortran compiler for the common cases, and very few people make use of the esoteric, vector/matrix parallelization enhancements that most Fortran programmers love to brag about (many of which have been implemented in C++ libraries, btw). Frankly, the "optimizations" that keep people tied to Fortran are pretty much irrelevant today anyway--computers are getting faster and cheaper, but programmer time is becoming more expensive. It makes no sense to stick with a programmer-intensive language like Fortran in this world.
"I am guessing right now - no - scratch that. I am almost positive right now you've never worked for a senior engineer. They are tweakers, coders, hackers, etc.
A "my experience is more valid than your experience" argument. Oh goody. For your information, I've worked for a wide variety of "senior engineer" types, and, yeah, your experience is typical for the breed. The "senior engineers" duck into their office and do something irrelevant for a week once or twice a year, while the rest of the team produces new, useful code over the course of the entire year. And that pile of "optimized" code the senior guy produced? Well, at least he can read it, I guess...usually no one else can.
My point remains: even if the "senior engineers" get in a coding snit every now and again, their output typically barely matches that of the younger members of the team. And that's the way it should be--you want to see your senior engineers/coders/scientists acting as mentors and supervisors, not grunt coders. And, given that the Fortran langage does not lend itself to software maintenance and readability, it makes no sense to force new members of the team to learn it when they probably already know C/C++ anyway (esp. if they're out of school in the last 10 years).
Now, before you flame, keep in mind that I'm refferring to new projects. I'm not an advocate of rewriting old code for the sake of rewriting old code. I just think it's technically foolhardy to use an archaic language like F77 for a new project. Maybe you would want to use F90, but even then, you have to ask yourself why you're choosing that language over something that new graduates are going to know right out of school...
"Let's just say you'll have a hard time finding a senior engineer who knows C++, and an equally hard time finding one who doesn't know ForTran. And, often, the senior engineers are among your better resources."
Well-phrased. Yes, older engineers (and scientists) are better versed in FORTRAN. Of course, by "FORTRAN" we really mean that these folks know FORTRAN 77, and you have to ask yourself--do you really want to begin any new coding project in a language as primitive as F77?
It's a bit like saying: "we're going to code in BASIC, because that's what the staff knows." Sure, you gain in developer training, but you lose many times more in code management, reuse and maintenance. And what about newer FORTRANs, like F90? Well, if you're going to retrain on that rats-nest of a language, you might as well just stick with the industry-standard rats-nest, and use C++. For an F77 programmer, the learning curve will be the same.
Another funny thing is, most truly senior engineers and scientists aren't the ones writing code anymore. So it becomes even more absurd to suggest that new code should be developed in a language they understand. Indeed, develop in a language the new engineers know, because they're the ones who will be maintaining it well after Dr. Cranky is eating tapioca in the nursing home, babbling on about COMMON blocks, hollerith strings, and how "back in the good old days, all we had was GOTO, and dammit, we LIKED it!"
"The Office of Technology Licensing happens to hold the licensing rights for the DNA polymerase chain reaction (PCR) which is the basis for most biotech."
No they don't. Hoffman-LaRoche and Applied Biosystems, Inc., hold the patents for all of the commercially/experimentally important parts of PCR. And PCR was invented at Cetus, a private research house.
"And so it was very predictable that once we had gotten the PC going, and going and gotten hundreds of millions of machines out there, that it had always been sort of free software and the universities would flourish and there would be more of that."
Bill's right. We should be nicer to Microsoft. The universities are flourishing, fer chrissakes!!
"And so it was very predictable that once we had gotten the PC going, and going and gotten hundreds of millions of machines out there, that it had always been sort of free software and the universities would flourish and there would be more of that."
I, for one, am glad that Microsoft came along. After all, what would we do without the universities?
Well, I'm probably going to be modded down to the dirt for this, but...part of your problem is that you seem to be taking an MIS curriculum at your school.
Not to get too down on those MIS folks out there, but in my experience, MIS programs are all very good at skimming lots of topics superficially, and very rarely delving deeply into any one area. In a way, it's understandable: they've tried to create programs that will teach "business" and "computers" in the same time frame as a regular CS or Business degree. You have to expect that there's going to be some topics in both areas that don't get covered well...
Now, since I can hear the flamethrowers revving up already, let me say this: I'm sure there are good MIS programs out there. In particular, I'm sure that your MIS program is the best one out there, and that you're getting a better education than everyone else. That said, I've sat through non-introductory CS classes with MIS students, and in my experience, the MIS students were far less prepared for the curriculum than the CS students.
To me, it sounds like you're dissatisfied with the content of your program, more than a "liberal arts" education. So, before you blame it on the school, why don't you try out a different major and see how things go. In particular, try out a CS major + Business minor (or even a CS/Business double, if you can), and see how you like that. I think you'll find that a lot of your complaints will go away...
"This is why the Arabs have NEVER attacked any Israeli religious targets. It is not the religion that bothers them. It is the lack of religion. It is the secular Israel that offends, not the Jewish one."
Exactly right. I have been more than a little bothered by the rhetoric from our leaders that would suggest this attack was "an attack on democracy," or "an attack on our way of life."
This attack was an attack on American political and ideological hegemony, plain and simple. Fundamentalists may or may not be "fanatical" (I don't like to paint with such a broad brush), but it seems pretty clear that the people who did this were not attacking our way of life, specifically. They were attacking our tendency to impose our way of life on nations and cultures around the planet.
I will never suggest that this justifies the taking of thousands of innocent lives, because it doesn't. But, we can only expect these types of disasters to continue as long as our leaders fail to recognize the underlying causes and continue with their own chest-beating, flag-waving version of patroitic fundamentalism.
Our cells will not exchange DNA between themselves, or with cells of other types. Not naturally, anyway.
The concern is that mouse cell lines may be contaminated with viruses that could infect human cell lines. Just like several new strains of flu seem to come out of China every year due to pig/people interactions, this type of contamination could have serious public health implications.
Slashdot Mirror
www.scifun.org is a good website oriented toward experiments that can be performed with household items. There's also a TV show that corresponds to the website that has been playing nightly on PBS (in the Seattle area, anyway).
"Yes, it is, because it is something that does not need to be implemented, because heapsort works perfectly well for practical purposes."
Beautiful. You made my original point, proving the classic FORTRAN programmer mentality: "I can't implement something because my language is missing a feature necessary to do so. But, rather than admit that this is the case, I'll avoid the issue by pretending that another approach is better anyway." This doesn't make my argument a red herring, it makes your argument a straw man.
"arguing that FORTRAN is bad because it doesn't work for a number of problems that aren't in its major workload is silly. It would be like, oh, saying that Perl is evil because it can't do matrix transformations as fast as C.
Are you reading what I write? FORTRAN is good at what it does well -- loop iteration algorithms. However, when all you have is FORTRAN, everything starts to look like a loop iteration problem! This is the core of my argument; you're getting too caught up in the details to notice.
"Either you compare Fortran 77 on its own merits with C++ circa 1977 (i.e. nothing) or else you should consider the most modern incarnation of Fortran (Fortran 95) with C++."
Who are you to decide what can and can't be compared? A language is a language, and I can compare and contrast the features of languages as I please. Note that I talked about FORTRAN 77 in my post, not F90 or F95. It was a fair comparison - F77 is deficient when compared to a modern language such as C++.
As for F9x, look around for my other post on the topic. Yeah, the language adds some desperately needed features, but all in all, it's as messy as C++, has fewer features than C++, and has a smaller user community! I personally wouldn't even consider F90, unless I had a big chunk of F77 code that I didn't want to port, and a good reason not to link it into a C or C++ application.
"You may hate the simplemindedness, but in the real world people have to read, understand, and maintain other people's code. All those cute syntactic tricks one feels obliged to play in C or C++ just add to the time it takes for someone to read over your code and figure out what the heck it is supposed to be doing."
These issues have been so well debated that I'm not even going to go into them here. You're wrong. Time and experience have shown this to be true. The "cute" features that bother you are important to writing large, maintainable projects. Can they be misused? Yes. Sure. But to programmers skilled with the language, they provide valuable tools that FORTRAN just doesn't offer.
"As for your slam of heapsort in Numerical Recipes, in my recollection Press et al. identified many specific technical reasons for suggesting heapsort for many numerical applications over quicksort: it is an "in-place" sort, it has the same computational complexity as quicksort, the worst case scenario is only about 20-30% slower than the best case scenario, and, yes, its implementation in some languages is more transparent."
Gee, it'd be interesting to see the date of the paper you cite, given that the introsort variant of quicksort guarantees O(n log n) performance, and has a lower constant than heapsort for most inputs (and, BTW, this is the std::sort in the C++ standard library). To be fair, introsort wasn't around when the original version of NR was published, but the authors haven't bothered to include or even mention it in any subsequent volume. Wonder why that is....(my own personal opinion is that the other versions of NR are simple-minded translations of the original FORTRAN code...)
"To be fair, I should comment that "object oriented" F95 doesn't support runtime polymorphism, but I've yet to encounter a numerical analysis task that would benefit in any significant way from this language feature."
I work in molecular simulation, and it's easy for me to come up with numeric tasks that benefit from polymorphism. Consider this: geometrically "building" a molecule is essentially nothing more than linear algebra, but polymorphism allows you to write the build code once, and re-use it on whatever particular molecule type you desire. Incredibly convenient....
"In summary, the quicksort-vs-heapsort argument is a red herring."
No, it isn't. It is an example of something that cannot be implemented properly in FORTRAN. I love that this thread is littered with the responses of "well, you don't need recursion because you can always implement your own stack!" Classic FORTRAN programmer-ese: "My language isn't deficient, you're just lazy!"
The fact is, introsort (the variant of quicksort used in the C++ standard library) does guarantee O(n log n) performance, it has a lower constant than heapsort on many input sizes, and a constant on par with heapsort for many more. And you can't implement it in FORTRAN either -- it's a recursive algorithm. Sure, you could write your own stack, but A) you have to write your own frigging stack and B) try to do that in FORTRAN without imposing some artificial limit on stack size, input size, or something else. The authors of NR couldn't...their code breaks with inputs larger than a certain size....
It may be a relatively minor example, but it was an easy one to come up with. Pick another -- let's talk about space-efficent random list insertion or deletion, or implementation of a balanced tree, or any of a number of other areas where data structures are critical to algorithm performance. FORTRAN is not made for these things. Unfortunately, not every scientific problem is so cleanly decomposed into the tight little loopy segments that FORTRAN is good at computing.
My biggest gripe about sorting algos in practice - the C library sort has a very slow constant factor because comparing is done by a callback.
A good reason to use C++. The C++ sort faces no such limitation (thanks to functors).
It is absurd. What's the advantage gained by the hand-coded stack approach? Smaller stack frame, you say? Why does that affect execution speed in this context? You do some hand-waving by mentioning "cache and TLB misses," but this is almost pure crap, given that the context in a recursive function is going to be local anyway, and thus, the issue of cache misses will rarely, if ever, arise during function body excecution.
Granted, you might run into this problem at the unwinding phase of the stack at the end of the recursion, but at this point, the performance impact is negligible anyway.
Pile on top of this the fact that the NR stack makes it harder for a C/C++ compiler to properly optimize call dispaches in a sensible way, and the fact that, most likely, the compiler is going to do a better job of optimizing the stack code of a particular architecture than the authors of NR, and you end up with a smelly implementation of a good algorithm. And it isn't the only one. The code in NR is positively awful.
FWIW, both heapsort and quicksort have average complexity O(n log n), but heapsort has the same worst case complexity, whereas quicksort has O(n^2).
True, however, quicksort's constant is lower than heapsort, which means that in most implementations, it is faster than heapsort, on average.
It is also true that quicksort has a worst case of O(n^2), but introsort (the variant of quicksort acutally used in the C++ library), has both average and worst case of O(n log n).
(FWIW, the constant difference is one of the reasons that NR doesn't implement quicksort. well, that and their irrational fear of the cost of recursion - they go so far as to implement their own stack, which is absurd.)
Consider two identical algorythms written in F77 and C++...
Ok. It depends on the algorithm, actually. C++ can actually be faster. But that wasn't the original point. The point is, that algorithms are often more important than sheer loop-iterating speed, and for this, FORTRAN comes up short.
NR writes for both FORTRAN and C. The shortcomming isn't the language.
Sorry, but no. Look at the code in the versions of NR. The C version is basically a rehashed version of the FORTRAN version (almost, but not quite, an f2c of the original book). The algorithms are the same, with minor exceptions. And frankly, it is a language isssue. FORTRAN doesn't have recursion. You can't properly implement quicksort in a non-recursive language. And quicksort outperforms heapsort in most cases.
While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).
However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...
Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
Honestly, your objection to C++ is unclear to me...you say you spend more time fixing bugs than approaching the task at hand? Is this because you don't know the language that well? Perhaps because you're not taking advantage of the many excellent libraries available to you? Keep in mind that C++ library design requires a great deal of skill, but using a well-designed library is actually easier than coding in other languages.
C++ is my own personal choice for anything by the most demanding of high-performance computing applications. Is there an overhead to the language? Debatably, yes. Does it matter, in 99.9% of applications? No. And with only a little bit of forethought, even the "inherent" performance hits can be avoided in the places where it matters. It's just that you have to rely on a profiler to tell you where those places are...
There is a significant community of researchers and developers working on scientific and high-performance computing in C++. Check out some of these:
These are just a few good starting points. Do a google search for 'high performance c++' to find many more. Just, please, for the love of Deity, don't code in FORTRAN. ick....
"Daisey...long ago fled Starbucks-land for Brooklyn...where he has prospered, adapting his book into a successful off-Broadway play."
Bzzt. Sorry, Jon. Please Play Again. And next time? Try to at least get some of the facts right.
21 Dog Years was a play long before it was a book...Daisey put it on in Seattle in a few different theaters, including the back room of the speakeasy.net cafe! I saw it there about 2 years ago (before the cafe burned down).
As for Brooklyn, Daisey didn't leave for New York until this year. He'd been putting the show on in Seattle for several years by that time...
Uhh...use [us] and you'll get a bunch of fscks, which may actually be legit.
I counted 26 legitimate guns n' roses references in the linux-2.4.2 source.
"Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using."
Uhm, last I checked, that's because Micro$oft doesn't implement the STL standard properly, and their MSDN docs reflect their implementation, not the standard one.
Maybe this has changed, but I doubt it. For a much better (and correct!) STL reference, go see dinkumware, which sells an online reference, as well as a complete library implementation, should you need it. Dinkumware, conveniently, also provides the online docs over the web for free, as long as you promise not to download them to your machine.
"I bastun bor vi allihopa = we all live in the sauna (it's swedish)"
Damn. You mean it's not "I'm cuckoo for cocoa puffs"?
All my hopes for this release are dashed.
"In all seriousness, if /. wants people to pay for it, there needs to be some serious checking of stories before posting. The Internet may have partially obsoleted deadtree papers, but it hasn't obsoleted the concept of journalistic integrity - and integrity is what separates a legitmate newspaper from a tabloid."
I'm going to get nailed for this, but I think it has to be said. I'm not trolling.
No one ever told you that you were paying for slashdot to have "journalistic integrity." Or that you have to pay. Or that you should pay for slashdot at all. In fact, you've been given every ability not to pay, and still obtain the same content. It's just that now you'll have to look at a few annoying ads if you choose not to pay. So will you pay? That depends on how much you can tolerate ads, doesn't it?
You know, whether you like it or not, slashdot has been doing the same damn thing for as long as I've been here. Maybe you'll argue that I missed the "grand old days," but I think I've been reading for long enough that I'd have noticed if slashdot's content changed appreciably at some point. I haven't noticed. So I guess I'm confused--why is this lack of "journalistic integrity" such a surprise to you? More specifically, why is it such a surprise that you have to spend time writing snarky little comments about the site, ON the site that you so despise? Don't you have anything better to do with your time?
In my recollection, no one here has ever suggested that slashdot should be your only source for "news." In fact, other than the occasional noteworthy editorial, book review, or famous comment, I don't recall slashdot ever generating any "news" of it's own. It's nearly always about linking to something interesting that somebody else wrote, and making some editorial comment about the link. You'd have to be living in a dreamworld to think that this was ever objective "news." For me, it's always been about two things: 1) rapid exposure to things and ideas that interest me and 2) reading the collected opinions of a bunch of like-minded people on subjects that I enjoy thinking about. Except that recently, that second aspect has been increasingly buried by pissy little comments like your own. And that really chaps my ass.
So you don't like slashdot. You think it's subjective and lacking integrity. Fine. That's your right. Go read something with integrity and leave the rest of us alone. We'll get along fine without you.
I don't want to sound like a troll, but really, if you don't know the answer to this question already, you aren't ready to be a tech manager.
I'm serious. You say that you're "not a great coder," but you provide no other information about your technical skill level. So, one can only assume that you're an inexperienced coder/hacker, and that you've never worked on a real project team before, let alone led one.
My answer to your question is this: I've always wanted a boss who understood what I was doing as well as I did, and probably better. At the very least, I wanted a boss who had been through the grinder, and could understand why I was making certain choices, without second-guessing them. And honestly, if you don't have at least a few years of professional-level coding experience under your belt before you enter the world of tech management, you won't meet that requirement. In short: if you want to be a good tech manager, be a tech worker long enough to count.
"For instance, would you rather have an experienced admin run NT or a bunch of clowns running Linux? I know which I'd pick."
Hrm. I'd pick an experienced admin running Linux. Preferably one who knew what a false dichotomy was.
"Most engineers keep up reasonably well with the changes in ForTran. It has come a long way since f77, which is often used as an excuse NOT to change to a C based platform, along with lack of adequately optimized compilers."
Horse-hoohah. Maybe, by "adequately optimized compilers" you're referring to C++ platforms, but even that's not true anymore, unless you're discussing older implementations. Fact is, the current generation of C (and yes, even C++) compilers are as well optimized as any Fortran compiler for the common cases, and very few people make use of the esoteric, vector/matrix parallelization enhancements that most Fortran programmers love to brag about (many of which have been implemented in C++ libraries, btw). Frankly, the "optimizations" that keep people tied to Fortran are pretty much irrelevant today anyway--computers are getting faster and cheaper, but programmer time is becoming more expensive. It makes no sense to stick with a programmer-intensive language like Fortran in this world.
"I am guessing right now - no - scratch that. I am almost positive right now you've never worked for a senior engineer. They are tweakers, coders, hackers, etc.
A "my experience is more valid than your experience" argument. Oh goody. For your information, I've worked for a wide variety of "senior engineer" types, and, yeah, your experience is typical for the breed. The "senior engineers" duck into their office and do something irrelevant for a week once or twice a year, while the rest of the team produces new, useful code over the course of the entire year. And that pile of "optimized" code the senior guy produced? Well, at least he can read it, I guess...usually no one else can.
My point remains: even if the "senior engineers" get in a coding snit every now and again, their output typically barely matches that of the younger members of the team. And that's the way it should be--you want to see your senior engineers/coders/scientists acting as mentors and supervisors, not grunt coders. And, given that the Fortran langage does not lend itself to software maintenance and readability, it makes no sense to force new members of the team to learn it when they probably already know C/C++ anyway (esp. if they're out of school in the last 10 years).
Now, before you flame, keep in mind that I'm refferring to new projects. I'm not an advocate of rewriting old code for the sake of rewriting old code. I just think it's technically foolhardy to use an archaic language like F77 for a new project. Maybe you would want to use F90, but even then, you have to ask yourself why you're choosing that language over something that new graduates are going to know right out of school...
"Let's just say you'll have a hard time finding a senior engineer who knows C++, and an equally hard time finding one who doesn't know ForTran. And, often, the senior engineers are among your better resources."
Well-phrased. Yes, older engineers (and scientists) are better versed in FORTRAN. Of course, by "FORTRAN" we really mean that these folks know FORTRAN 77, and you have to ask yourself--do you really want to begin any new coding project in a language as primitive as F77? It's a bit like saying: "we're going to code in BASIC, because that's what the staff knows." Sure, you gain in developer training, but you lose many times more in code management, reuse and maintenance. And what about newer FORTRANs, like F90? Well, if you're going to retrain on that rats-nest of a language, you might as well just stick with the industry-standard rats-nest, and use C++. For an F77 programmer, the learning curve will be the same.
Another funny thing is, most truly senior engineers and scientists aren't the ones writing code anymore. So it becomes even more absurd to suggest that new code should be developed in a language they understand. Indeed, develop in a language the new engineers know, because they're the ones who will be maintaining it well after Dr. Cranky is eating tapioca in the nursing home, babbling on about COMMON blocks, hollerith strings, and how "back in the good old days, all we had was GOTO, and dammit, we LIKED it!"
"The Office of Technology Licensing happens to hold the licensing rights for the DNA polymerase chain reaction (PCR) which is the basis for most biotech."
No they don't. Hoffman-LaRoche and Applied Biosystems, Inc., hold the patents for all of the commercially/experimentally important parts of PCR. And PCR was invented at Cetus, a private research house.
"And so it was very predictable that once we had gotten the PC going, and going and gotten hundreds of millions of machines out there, that it had always been sort of free software and the universities would flourish and there would be more of that."
Bill's right. We should be nicer to Microsoft. The universities are flourishing, fer chrissakes!!
"And so it was very predictable that once we had gotten the PC going, and going and gotten hundreds of millions of machines out there, that it had always been sort of free software and the universities would flourish and there would be more of that."
I, for one, am glad that Microsoft came along. After all, what would we do without the universities?
Well, I'm probably going to be modded down to the dirt for this, but...part of your problem is that you seem to be taking an MIS curriculum at your school.
Not to get too down on those MIS folks out there, but in my experience, MIS programs are all very good at skimming lots of topics superficially, and very rarely delving deeply into any one area. In a way, it's understandable: they've tried to create programs that will teach "business" and "computers" in the same time frame as a regular CS or Business degree. You have to expect that there's going to be some topics in both areas that don't get covered well...
Now, since I can hear the flamethrowers revving up already, let me say this: I'm sure there are good MIS programs out there. In particular, I'm sure that your MIS program is the best one out there, and that you're getting a better education than everyone else. That said, I've sat through non-introductory CS classes with MIS students, and in my experience, the MIS students were far less prepared for the curriculum than the CS students.
To me, it sounds like you're dissatisfied with the content of your program, more than a "liberal arts" education. So, before you blame it on the school, why don't you try out a different major and see how things go. In particular, try out a CS major + Business minor (or even a CS/Business double, if you can), and see how you like that. I think you'll find that a lot of your complaints will go away...
"This is why the Arabs have NEVER attacked any Israeli religious targets. It is not the religion that bothers them. It is the lack of religion. It is the secular Israel that offends, not the Jewish one."
Exactly right. I have been more than a little bothered by the rhetoric from our leaders that would suggest this attack was "an attack on democracy," or "an attack on our way of life."
This attack was an attack on American political and ideological hegemony, plain and simple. Fundamentalists may or may not be "fanatical" (I don't like to paint with such a broad brush), but it seems pretty clear that the people who did this were not attacking our way of life, specifically. They were attacking our tendency to impose our way of life on nations and cultures around the planet.
I will never suggest that this justifies the taking of thousands of innocent lives, because it doesn't. But, we can only expect these types of disasters to continue as long as our leaders fail to recognize the underlying causes and continue with their own chest-beating, flag-waving version of patroitic fundamentalism.
Our cells will not exchange DNA between themselves, or with cells of other types. Not naturally, anyway.
The concern is that mouse cell lines may be contaminated with viruses that could infect human cell lines. Just like several new strains of flu seem to come out of China every year due to pig/people interactions, this type of contamination could have serious public health implications.