I just can't get over the irony of Mr Period, the Punctuation King, saying "I've been trying to get to the gym, more." Begone, superfluous comma!
Other than that, it seems to be a pretty common human reaction to try and forget past unpleasantries. Apparently a whole generation grew up in Japan knowing very little about their role in WW2, for instance.
It is beyond me why anybody would want to make something look like it did, instead of how it should look.
But this IS how it "should look". It was designed for that display. People want it to look like it originally did for the same reason that people like muscle cars, vinyl records (complete with the hiss and wow and flutter that they try so hard to eliminate), valve amplifiers. It's because sometimes the inaccuracies in equipment change the signal for the better, and people like that.
I haven't seen a flatpanel yet that in objective terms of quality comes anywhere near a CRT.
Try looking at a new one then. The colour isn't _quite_ where CRTs were but it's within spittin' distance. Ghosting hasn't been a problem for 5+ years.
Wrong. Mediocre(at best) programmers who think they are good will do that. GOOD programmers, especially the best ones, will look at what the app requires in the design stage, before even the first line of code is written.
GOOD programmers use butterflies. >.>
Maybe I didn't make this quite blatantly obvious enough, but I was talking about the general case where you have an array of whatsits and you want it to be sorted. Of course you'll take a squint at it and go "hmm, I'm sorting a list, I'll use bubblesort" (thanks adisakp for pointing out that obvious case) or "hmm, the data is often presented in reverse order (or whatever pathological case your particular quicksort implementation suffers from), maybe I should use something other than quicksort". If you just have 100 strings/ints/floats/whatever in an array and you want them rearranged to go from smallest to biggest, then you're wasting time puddling around with search algorithms instead of just using the library functions.
I bet you're the type that hand-codes everything in assembler "because it's faster".
No, I didn't. I was kind of hoping that people would see it as implied that we're talking about a stable, non-broken interface here. But still, good point - 10 years ago most 'publicly released' libraries were FUBAR and no-one thought to tell me (us?) that this wasn't to be expected.
And as N -> infinity, they are roughly equivalent. That's what big-O notation is about (not big O's, as you probably guessed...). It's about how the algorithm _scales_ as input sizes increase.
So when MSVC prints "Internal Compiler Error" and stops compiling my code, I'm wrong?:)
Yes. 100% your fault. The MSVC compiler cannot be wrong. All hail Big Bro~(erm)MSVC!!
And yah it's been a long time since I properly confused MSVC++. And even then it was mainly because the dependency system broke on our code and we ended up with mixed release and debug mode librarires.:/
See, even *I* know that one. It's because pre-increment stored the old value on the stack and post-increment didn't. At least in the compiler/assembler that I used... >.>
Hey,.jpg is OK. It combines actual mathematics with images of naked women and as such is a-o-kay in my book. I dunno about.pst and I'm glad of that.
Trying to get data out of a PSD file is like trying to find something in the attic of
your eccentric old uncle who died in a freak freshwater shark attack on his 58th
birthday.
This is possibly the best reason EVER for not being able to read a given file format. I am in awe, sir. Your description of this format is cross between geek humour and c'thulo-mythos-style horror.
But that's just it - according to him, you should be kicked out the industry. He stated:
Nono - I could code one alright. It'd just be shit compared with an optimized version. I understand the algorithm fine, I just haven't bothered to learn the intricacies of implementing it optimally in my current programming environment because it's _not necessary_. And that's why I (along with everyone who has a lot of experience in programming) extoll the virtues of reusing libraries for central, very-very-oft-repeated code. Which is because if a billion people have failed for a decade to improve the algorithm, it's probably as near as makes no beans to the optimal one.
I can code a list, a hash table, a bubble sort, a btree, and in fact have ad-hocked all of the above many times in my programming lifetime. But while I'd say all of the above are at or close to theoretical optimum just because I'm fucking awesome, I'll concede that more complicated algorithms (like quicksort) have subtleties that I haven't made a particular study of.
I'll agree with you for most of what you said, but I disagree that programmers should learn to implement sorting algorithms.
Eh? That was some other guy, I'm all in FAVOUR of all programmers learning basic sorting and searching, if for no other reason than that if you can't understand those then you probably shouldn't be programming.
I remember a case study I read when I was a young'un about a particular data set, where the person writing the article settled on bubblesort, because a fast machine-language implementation of bubblesort was quicker than the quickest implementation of quicksort that the author was able to come up with.
In the end, the fastest algorithm _in practice_ *is* the fastest algorithm, and should be used.
Try living in Australia. $50 USD for a game without having to fuck around with finding the right CD to insert before you can play? Yes please. I voted with my money, I bet plenty of Aussies did.
(Like with that stupid fucking "you wouldn't steal a car" anti-piracy video that's at the start of EVERY. FUCKING. DVD. That is what motivates me to download movies, is so I can just watch. the. fucking. movie without waiting for half a minute for an annoying fucking propaganda vid to finish. Sorry but my wife has made me watch a bunch of legit DVDs recently and it's REALLY been annoying me.)
(Note, as you may gather from my comments earlier about Steam, that I not only don't mind compensating artists for their work, but that I really would rather do so. But stupid middle men who want to charge me double and then steal my time for their adverts, just for tolerating the prophylactic of the information age, really get my goat. And a Dragon's goat is not to be got.)
Um, I'm pretty sure quicksort is still the go-to sort simply because it's the implementation that's built into almost every single programming environment. Then again honestly, I'd say that from the point of view of a pragmatic programmer... it doesn't matter. There's a built-in fuction (whether it's qsort() in the C standard library, or Arrays.Sort() in Java, or whatever) that will take your array and return it, sorted. If your app runs too slow and you profile it and it turns out the speed problem is in the sorting AND you can't find a better algorithm that doesn't depend so much on sorting... THEN you look at optimising it. Never forget the two cardinal rules of optimising:
But they're evil cash eating monsters who make cool games like Left 4 Dead. I gave them some money just so they could eat it and make more games, because, you know, I like games.:)
Working with a fairly large (several hundred source files, probably 20-30mb of C++ code all up plus a much larger amount of Python scripting) project, MSVC++ 2005 on a 2-year-old Core2 Duo system still has a sub-1-second pause at worst, and is usually pretty much instant. Once you get used to it, it really does make coding much quicker and easier, although if it distracts/bugs you enough to frequently knock you out of flow then it might be easier just to stick with what you're used to. Eclipse is still shite (in my experience).
Even mundane programmers would not dream of using a generic library that includes sorts they'll never refer to in, say, an e-mail client or a game. They'll write their own.
Erm, why the hell not? Good programmers, even the best programmers (in fact especially the best programmers), will just use qsort() (or the equivalent for the language they're using). Then, IF performance on their lowest-spec target hardware is unacceptable, they will profile their code and find out what's taking the time. And then, IF it's the sorting algorithm that's the bottleneck, only THEN will they implement a more specific version. Anything else is a waste of time and an additional risk of introducing unnecessary bugs.
Unless we're really pushing the boundaries (and those boundaries are so far away with modern computers that 99% of applications can't even SEE them from their cosy seat in the middle of userland) the stock sorting algorithm your language provides will be plenty fast enough. If you're using a high-level interpreted language, you'll never beat it in efficiency.
What you're saying may have been true 15, or even 10 years ago, but it's certainly not true now.
Bitsort / bucketsort algorithms run in O(n log(log(n))) time on data with a roughly uniform distribution, so O(n*log(n)) isn't a hard lower limit. However, I'm going to have to call BS on your claim of sub-linear time, since that would not even allow you to _touch_ every index in the array. Unless you're talking about a very VERY special case like "an array of arbitrary size that's sorted except for items X to Y, with X and Y supplied to the algorithm". Which is cheating, and if that's what you were doing I'm going to blow a raspberry at you.
Eew, that reminds me of when I first started DirectX programming. One tiny misstep in initialisation (or during runtime) and it was locked in full screen mode with no way to recover other than a hard reset. Fun times, fun times... imagine how ecstatic I was when I got a new computer and Windows XP, and could actually *gasp* run 3D apps in a window!!
My mother, who was programming before a fair few of us (including me) were born, once told me this: If you think you've found a bug in a compiler, or an operating system, or a programming language, or a well-known commonly used library... you're wrong.
Of course, this doesn't hold true 100% of the time, especially when you're pushing the limits of new versions of large 3rd party libraries, but when one is just starting to program (and hence using very well known, well tested libraries and code) it's true 99.99% of the time.
(Oh, btw, I love your sig. Makes me laugh every time.:)
Slashdot Mirror
Comic Book Guy's voice IS /sarcasm.
:(
And what's all this about "LoTR was not a trilogy"? I can hear a whooshing sound but I'm not sure what it is.
Someone pays you to implement realtime photon mapping? Are they hiring? O.o
For some reason, this comes to mind.
I just can't get over the irony of Mr Period, the Punctuation King, saying "I've been trying to get to the gym, more." Begone, superfluous comma!
Other than that, it seems to be a pretty common human reaction to try and forget past unpleasantries. Apparently a whole generation grew up in Japan knowing very little about their role in WW2, for instance.
Thin client? I use a CRT, you insensitive clod! :P
It is beyond me why anybody would want to make something look like it did, instead of how it should look.
But this IS how it "should look". It was designed for that display. People want it to look like it originally did for the same reason that people like muscle cars, vinyl records (complete with the hiss and wow and flutter that they try so hard to eliminate), valve amplifiers. It's because sometimes the inaccuracies in equipment change the signal for the better, and people like that.
I haven't seen a flatpanel yet that in objective terms of quality comes anywhere near a CRT.
Try looking at a new one then. The colour isn't _quite_ where CRTs were but it's within spittin' distance. Ghosting hasn't been a problem for 5+ years.
Wrong. Mediocre(at best) programmers who think they are good will do that. GOOD programmers, especially the best ones, will look at what the app requires in the design stage, before even the first line of code is written.
GOOD programmers use butterflies. >.>
Maybe I didn't make this quite blatantly obvious enough, but I was talking about the general case where you have an array of whatsits and you want it to be sorted. Of course you'll take a squint at it and go "hmm, I'm sorting a list, I'll use bubblesort" (thanks adisakp for pointing out that obvious case) or "hmm, the data is often presented in reverse order (or whatever pathological case your particular quicksort implementation suffers from), maybe I should use something other than quicksort". If you just have 100 strings/ints/floats/whatever in an array and you want them rearranged to go from smallest to biggest, then you're wasting time puddling around with search algorithms instead of just using the library functions.
I bet you're the type that hand-codes everything in assembler "because it's faster".
No, I didn't. I was kind of hoping that people would see it as implied that we're talking about a stable, non-broken interface here. But still, good point - 10 years ago most 'publicly released' libraries were FUBAR and no-one thought to tell me (us?) that this wasn't to be expected.
And as N -> infinity, they are roughly equivalent. That's what big-O notation is about (not big O's, as you probably guessed...). It's about how the algorithm _scales_ as input sizes increase.
So when MSVC prints "Internal Compiler Error" and stops compiling my code, I'm wrong? :)
Yes. 100% your fault. The MSVC compiler cannot be wrong. All hail Big Bro~(erm)MSVC!!
:/
And yah it's been a long time since I properly confused MSVC++. And even then it was mainly because the dependency system broke on our code and we ended up with mixed release and debug mode librarires.
Do-what-you-want-cuz-a-Pirate-is-freee :)
YOU ARE A PIRATE!
And wow, there can't be THAT many people around who actually genuinely struggled with the FDIV bug at work. O.o
See, even *I* know that one. It's because pre-increment stored the old value on the stack and post-increment didn't. At least in the compiler/assembler that I used... >.>
Trying to get data out of a PSD file is like trying to find something in the attic of your eccentric old uncle who died in a freak freshwater shark attack on his 58th birthday.
This is possibly the best reason EVER for not being able to read a given file format. I am in awe, sir. Your description of this format is cross between geek humour and c'thulo-mythos-style horror.
But that's just it - according to him, you should be kicked out the industry. He stated:
Nono - I could code one alright. It'd just be shit compared with an optimized version. I understand the algorithm fine, I just haven't bothered to learn the intricacies of implementing it optimally in my current programming environment because it's _not necessary_. And that's why I (along with everyone who has a lot of experience in programming) extoll the virtues of reusing libraries for central, very-very-oft-repeated code. Which is because if a billion people have failed for a decade to improve the algorithm, it's probably as near as makes no beans to the optimal one.
I can code a list, a hash table, a bubble sort, a btree, and in fact have ad-hocked all of the above many times in my programming lifetime. But while I'd say all of the above are at or close to theoretical optimum just because I'm fucking awesome, I'll concede that more complicated algorithms (like quicksort) have subtleties that I haven't made a particular study of.
I'll agree with you for most of what you said, but I disagree that programmers should learn to implement sorting algorithms.
Eh? That was some other guy, I'm all in FAVOUR of all programmers learning basic sorting and searching, if for no other reason than that if you can't understand those then you probably shouldn't be programming.
I remember a case study I read when I was a young'un about a particular data set, where the person writing the article settled on bubblesort, because a fast machine-language implementation of bubblesort was quicker than the quickest implementation of quicksort that the author was able to come up with.
In the end, the fastest algorithm _in practice_ *is* the fastest algorithm, and should be used.
Try living in Australia. $50 USD for a game without having to fuck around with finding the right CD to insert before you can play? Yes please. I voted with my money, I bet plenty of Aussies did.
(Like with that stupid fucking "you wouldn't steal a car" anti-piracy video that's at the start of EVERY. FUCKING. DVD. That is what motivates me to download movies, is so I can just watch. the. fucking. movie without waiting for half a minute for an annoying fucking propaganda vid to finish. Sorry but my wife has made me watch a bunch of legit DVDs recently and it's REALLY been annoying me.)
(Note, as you may gather from my comments earlier about Steam, that I not only don't mind compensating artists for their work, but that I really would rather do so. But stupid middle men who want to charge me double and then steal my time for their adverts, just for tolerating the prophylactic of the information age, really get my goat. And a Dragon's goat is not to be got.)
Um, I'm pretty sure quicksort is still the go-to sort simply because it's the implementation that's built into almost every single programming environment. Then again honestly, I'd say that from the point of view of a pragmatic programmer... it doesn't matter. There's a built-in fuction (whether it's qsort() in the C standard library, or Arrays.Sort() in Java, or whatever) that will take your array and return it, sorted. If your app runs too slow and you profile it and it turns out the speed problem is in the sorting AND you can't find a better algorithm that doesn't depend so much on sorting... THEN you look at optimising it. Never forget the two cardinal rules of optimising:
1) Don't optimise.
2) (Experts only:) Optimise later.
Or as I once read it eloquently expressed:
1) Make it work.
2) Make it work right.
3) Make it work fast.
But they're evil cash eating monsters who make cool games like Left 4 Dead. I gave them some money just so they could eat it and make more games, because, you know, I like games. :)
Working with a fairly large (several hundred source files, probably 20-30mb of C++ code all up plus a much larger amount of Python scripting) project, MSVC++ 2005 on a 2-year-old Core2 Duo system still has a sub-1-second pause at worst, and is usually pretty much instant. Once you get used to it, it really does make coding much quicker and easier, although if it distracts/bugs you enough to frequently knock you out of flow then it might be easier just to stick with what you're used to. Eclipse is still shite (in my experience).
Hollerith constants Equivalences Computed Gotos Arithmetic Ifs Common blocks
And my personal all time favourite - the ComeFrom Statement.
*delicate shudder*
Even mundane programmers would not dream of using a generic library that includes sorts they'll never refer to in, say, an e-mail client or a game. They'll write their own.
Erm, why the hell not? Good programmers, even the best programmers (in fact especially the best programmers), will just use qsort() (or the equivalent for the language they're using). Then, IF performance on their lowest-spec target hardware is unacceptable, they will profile their code and find out what's taking the time. And then, IF it's the sorting algorithm that's the bottleneck, only THEN will they implement a more specific version. Anything else is a waste of time and an additional risk of introducing unnecessary bugs.
Unless we're really pushing the boundaries (and those boundaries are so far away with modern computers that 99% of applications can't even SEE them from their cosy seat in the middle of userland) the stock sorting algorithm your language provides will be plenty fast enough. If you're using a high-level interpreted language, you'll never beat it in efficiency.
What you're saying may have been true 15, or even 10 years ago, but it's certainly not true now.
This thread requires a reference to The Story of Mel.
Bitsort / bucketsort algorithms run in O(n log(log(n))) time on data with a roughly uniform distribution, so O(n*log(n)) isn't a hard lower limit. However, I'm going to have to call BS on your claim of sub-linear time, since that would not even allow you to _touch_ every index in the array. Unless you're talking about a very VERY special case like "an array of arbitrary size that's sorted except for items X to Y, with X and Y supplied to the algorithm". Which is cheating, and if that's what you were doing I'm going to blow a raspberry at you.
Eew, that reminds me of when I first started DirectX programming. One tiny misstep in initialisation (or during runtime) and it was locked in full screen mode with no way to recover other than a hard reset. Fun times, fun times... imagine how ecstatic I was when I got a new computer and Windows XP, and could actually *gasp* run 3D apps in a window!!
My mother, who was programming before a fair few of us (including me) were born, once told me this: If you think you've found a bug in a compiler, or an operating system, or a programming language, or a well-known commonly used library... you're wrong.
:)
Of course, this doesn't hold true 100% of the time, especially when you're pushing the limits of new versions of large 3rd party libraries, but when one is just starting to program (and hence using very well known, well tested libraries and code) it's true 99.99% of the time.
(Oh, btw, I love your sig. Makes me laugh every time.