Back in high school, I thought I was the most badass programmer on this planet. Could hand assemble code and hyper-optimize my programs counting clock cycles everywhere. I got into college. There was a book on algorithms in the small library the computer room had. I learned about asymptotic behavior. So I realized that my cleverly optimized O(n^2) sorting assembly program was going to eventually lose badly to a straightforward interpreted implementation of quicksort. Clearly I had to become good at this. I started reading all books I could find on the topic and very quickly I noticed that they all included a sentence meaning "If you want to understand the subtle underpinnings of this, see TAOCP." So I got a copy of volumes 1 & 3. It was expensive (I was not in USA and books were VERY expensive because of currency exchange issues). Mom & Dad chipped in and I still thank them for that. I borrowed volume 2 from a friend.
I decided to go though the book solving all exercises up to level 30. Saturday was my TAOCP day. I cannot say I read ALL of the text nor that I solved ALL problems of difficulty below 30, but I solved all that I tried and they were way more than a few. I even solve some in the 35 level, whenever I considered them interesting.
FF to the beginning my PhD studies at a good school in the USA: When taking the grad level Algorithms class, I was doing VERY well. The professor, a scary smart guy (now full professor at Stanford) asked me how may courses on algorithms and information theory I had taken. The answer was none. My undergrad degree was in Systems Engineering, from a crappy school in South America. I was never formally taught what a big-Oh was. That professor become my thesis advisor. He used to joke saying I was a walking encyclopedia of algorithms.
Will it work for everybody? Probably not. If you want to do theoretical CS, as I did, you will have to handle that math and some more anyways. CLR is more up to date and time efficient for learning. If you want to be a software engineer, chances are you are not going to be doing the heavy math, you will be using off the shelf algorithms.
Still TAOCP is a hell of a reference. Funny thing is, after finishing my PhD, I browsed through it. It looked simple, not very formal at all. I guess PhD does mean "permanently head damaged":-)
Though, his reliance on ACME for equipment, should be reconsidered.
I always thought that Wiley Coyote depicts very well the agony of working as an engineer. The laws of nature seem to work against you. Murphy's laws are against you. The tools/equipment do not behave according to the specs, and tend to fail at the worst possible time. Good ideas fail because of implementation details or even bad luck. Yet, you cannot let the problem go, you have to fix it! One last try, ok, maybe another one!
NP is short for Natalie Portman, and the car analogy follows:
Adleman's chief scientist, Nickolas Chelyapov, offered this illustration: Imagine that a fussy customer walks onto a million-car auto square and gives the dealer a complicated list of criteria for the car he wants.
"First," he says, "I want it to be either a Cadillac or a convertible or red." Second, "if it is a Cadillac, then it has to have four seats or a locking gas cap." Third, "If it is a convertible, it should not be a Cadillac or it should have two seats."
The customer rattles off a list of 24 such conditions, and the salesman has to find the one car in stock that meets all the requirements. (Adleman and his team chose a problem they knew had exactly one solution.) The salesman will have to run through the customer's entire list for each of the million cars in turn -- a hopeless task unless he can move and think at superhuman speed.
This serial method is the way a digital electronic computer solves such a problem.
What if you are depending on a library written by someone not as fscking brilliant as yourself? If that library has a bug and throws an exception you will have to deal with it. You may even have to propagate the exception up to be handled by someone else. That may require some cleanup.
Besides, bugs are not the only conditions to trigger exceptions. Unusual but possible events can do it as well. Out of disk or memory conditions are such examples. Some idiot/rogue user may delete a needed file from the command line and so forth.
If you installation produced 45 KWH of ENERGY during a 5 hour period (being conservative here), it's average output POWER was 9KW. Let's say 10KW to simplify the math. Now, you will need 11000 times as many panels to reach 110MW. The total number of panels per mile you need is 48*11000/116=4551. That is one panel every 14 inches (if i got the units right, not used to imperial).
Feasible? I would say it still is, but not as much as your calculations suggested
110 MW per train sounds like too much. The typical power output for a locomotive seems to be roughly 5000 HP (http://www.ecoworld.com/blog/2008/05/23/ges-4500-hp-locomotive/). Even if we double that number, since it a high speed train, 10 000 HP = 7 456 998 watts. It is only 7.5 MW. You could power more than 10 of these suckers with 110MW
The same happened to me when I upgraded from kernel 2.6.24-19 to 2.6.24-21. I kept the old one, and I boot using the grub menu. The changelog does not show changes in the network driver I use (my card is a Ralink RT2500), so I don't know what the real cause is.
There are some other sources of pressure. When professor's/instructor's performance is evaluated by the university's experts in teaching, how much they change the syllabus from one year to the next one is a big deal. You don't change it, you are not trying hard enough to keep your class up to date. It sucks because you cannot keep using the same classic textbooks as they are "old" and "modern" is better. If you are teaching a mature subject (people mentioned algebra/calculus there are others) especially at undergrad level, you may be forced to be shuffling the bibliography to include the latest craptacular rework of something that was done better before.
It happened 12 years ago or so. A co-worker asked me if he could use my computer to format a floppy disk because he was having problems with his. I said "yeah, sure." He sat down, inserted the disk and typed "format c:". The rest is history.
It also has a well-designed, usable multiple inheritance mechanism. It allows removing name clashes by letting the programmer to rename features. It is such a simple a neat idea that I cannot understand why it is not present in more languages.
As other posters pointed out, you are thinking about the 68K family. Motorola produced a 6800 processor, though. It had an 8 bit data bus and a 16 bit addr bus. It was sort of an advanced 6502 (used in Apple II's). I'm not aware of any computer based on the 6800. Radio Shack sold the famous Color Computer based on the 6809 and the Micro Color Computer based on the 6803, IIRC. The 6800 was sold mostly in kits used by hobbists and in universities, to build small projects.
I think it's kind of a marketing issue. When a new language is proposed and does not look like C but more like Ada/Pascal/Modula etc many programmers will just say "It is so verbose, there is no ++ operator, and it shoud use braces, they save LOTS of typing!". Who cares if the programs are more readable. I happen to be interested in programming language design, and I have asked some programmers "What would an ideal language be like". They all answer "Oh, it should be like X, but with feature Y", where X is their favorite language and Y is their favorite (usually superficial) missing feature of X. Stangely, nobody answers "It should use garbage collection, it should have easy to remember operator precedeces, it should disallow jumping into data, it should have optional array bound checking" and so on. People just look at superficial properties of the language, mostly the lexical part. They don't even get to the context free part, and forget about semantics. If it looks like C/C+/Java (which they know) it must be like C/C++/Java (and they feel confortable)
You are right when you point out that Kolmogorov complexity (KC) is not a computable function. However, there is more to say about computational information theory.
1- Kolmogorov complexity is a poor measure of "meaning" of strings. Imagine a long string S of zeros. It's KC is very low, about log(length(S)), and clearly a strings of zeros means very little. Now consider a string S' made out of ones and zeros and generated by flipping a fair coin, which of course, does not mean much either. It's KC is as high as it can be, about length(S'). So, the KC being low or high does not tell us much.
2- There are other mathematical measures the can be thought of as the amount of "meaning" of a string. One such measure is Lempel-Ziv complexity (On the Complexity of Finite-Sequences, 1976), another is pithiness (L. Adleman, "Time, space and randomness," MIT/LCS/TM-131, 1979). I understand both are computable, I am not sure about tractability.
> Why not just fly the other drection and stay in the sunlight? > >1- You cannot fly fast enough. (as many other posters said) > >2- If you are thinking about enjoying a longer day, consider that you will also suffer a longer night:)
Ah, when I submitted the previous message it stroke me: The idea is to make the night shorter. If the beast flies at only 160Kph, which is reasonable considering its size, the length of the night (going east)is about 20% shorter than duration of the night when you go west. This means you can get rid of 20% of your weight in batteries.
Slashdot Mirror
Back in high school, I thought I was the most badass programmer on this planet. Could hand assemble code and hyper-optimize my programs counting clock cycles everywhere. I got into college. There was a book on algorithms in the small library the computer room had. I learned about asymptotic behavior. So I realized that my cleverly optimized O(n^2) sorting assembly program was going to eventually lose badly to a straightforward interpreted implementation of quicksort. Clearly I had to become good at this. I started reading all books I could find on the topic and very quickly I noticed that they all included a sentence meaning "If you want to understand the subtle underpinnings of this, see TAOCP." So I got a copy of volumes 1 & 3. It was expensive (I was not in USA and books were VERY expensive because of currency exchange issues). Mom & Dad chipped in and I still thank them for that. I borrowed volume 2 from a friend.
I decided to go though the book solving all exercises up to level 30. Saturday was my TAOCP day. I cannot say I read ALL of the text nor that I solved ALL problems of difficulty below 30, but I solved all that I tried and they were way more than a few. I even solve some in the 35 level, whenever I considered them interesting.
FF to the beginning my PhD studies at a good school in the USA: When taking the grad level Algorithms class, I was doing VERY well. The professor, a scary smart guy (now full professor at Stanford) asked me how may courses on algorithms and information theory I had taken. The answer was none. My undergrad degree was in Systems Engineering, from a crappy school in South America. I was never formally taught what a big-Oh was. That professor become my thesis advisor. He used to joke saying I was a walking encyclopedia of algorithms.
Will it work for everybody? Probably not. If you want to do theoretical CS, as I did, you will have to handle that math and some more anyways. CLR is more up to date and time efficient for learning. If you want to be a software engineer, chances are you are not going to be doing the heavy math, you will be using off the shelf algorithms.
Still TAOCP is a hell of a reference. Funny thing is, after finishing my PhD, I browsed through it. It looked simple, not very formal at all. I guess PhD does mean "permanently head damaged" :-)
BTW, are any of the Coco clubs and what-not still around?
Here you have one.
http://www.glensideccc.com/coc...
Nitpick: O(2n)=O(1.7n)
Wiley Coyote... Super Genius.
Though, his reliance on ACME for equipment, should be reconsidered.
I always thought that Wiley Coyote depicts very well the agony of working as an engineer. The laws of nature seem to work against you. Murphy's laws are against you. The tools/equipment do not behave according to the specs, and tend to fail at the worst possible time. Good ideas fail because of implementation details or even bad luck. Yet, you cannot let the problem go, you have to fix it! One last try, ok, maybe another one!
NP is short for Natalie Portman, and the car analogy follows:
Adleman's chief scientist, Nickolas Chelyapov, offered this illustration: Imagine that a fussy customer walks onto a million-car auto square and gives the dealer a complicated list of criteria for the car he wants.
"First," he says, "I want it to be either a Cadillac or a convertible or red." Second, "if it is a Cadillac, then it has to have four seats or a locking gas cap." Third, "If it is a convertible, it should not be a Cadillac or it should have two seats."
The customer rattles off a list of 24 such conditions, and the salesman has to find the one car in stock that meets all the requirements. (Adleman and his team chose a problem they knew had exactly one solution.) The salesman will have to run through the customer's entire list for each of the million cars in turn -- a hopeless task unless he can move and think at superhuman speed.
This serial method is the way a digital electronic computer solves such a problem.
What if you are depending on a library written by someone not as fscking brilliant as yourself? If that library has a bug and throws an exception you will have to deal with it. You may even have to propagate the exception up to be handled by someone else. That may require some cleanup.
Besides, bugs are not the only conditions to trigger exceptions. Unusual but possible events can do it as well. Out of disk or memory conditions are such examples. Some idiot/rogue user may delete a needed file from the command line and so forth.
I'm going to review your physics.
If you installation produced 45 KWH of ENERGY during a 5 hour period (being conservative here), it's average output POWER was 9KW. Let's say 10KW to simplify the math.
Now, you will need 11000 times as many panels to reach 110MW. The total number of panels per mile you need is 48*11000/116=4551. That is one panel every 14 inches (if i got the units right, not used to imperial).
Feasible? I would say it still is, but not as much as your calculations suggested
110 MW per train sounds like too much. The typical power output for a locomotive seems to be roughly 5000 HP (http://www.ecoworld.com/blog/2008/05/23/ges-4500-hp-locomotive/). Even if we double that number, since it a high speed train, 10 000 HP = 7 456 998 watts. It is only 7.5 MW. You could power more than 10 of these suckers with 110MW
man aspell
The same happened to me when I upgraded from kernel 2.6.24-19 to 2.6.24-21. I kept the old one, and I boot using the grub menu. The changelog does not show changes in the network driver I use (my card is a Ralink RT2500), so I don't know what the real cause is.
There are some other sources of pressure. When professor's/instructor's performance is evaluated by the university's experts in teaching, how much they change the syllabus from one year to the next one is a big deal. You don't change it, you are not trying hard enough to keep your class up to date. It sucks because you cannot keep using the same classic textbooks as they are "old" and "modern" is better. If you are teaching a mature subject (people mentioned algebra/calculus there are others) especially at undergrad level, you may be forced to be shuffling the bibliography to include the latest craptacular rework of something that was done better before.
Maybe you are a denormal :-P
3.5mm audio jacks have cylindrical symmetry.
It happened 12 years ago or so. A co-worker asked me if he could use my computer to format a floppy disk because he was having problems with his. I said "yeah, sure."
He sat down, inserted the disk and typed "format c:". The rest is history.
Fascinating!
It also has a well-designed, usable multiple inheritance mechanism. It allows removing name clashes by letting the programmer to rename features. It is such a simple a neat idea that I cannot understand why it is not present in more languages.
Famous last words: "I'll install SP2!"
Primality testing is in NP. Every problem in P is in NP. What you meant was primality testing is not NP-hard.
As other posters pointed out, you are thinking about the 68K family. Motorola produced a 6800 processor, though. It had an 8 bit data bus and a 16 bit addr bus. It was sort of an advanced 6502 (used in Apple II's). I'm not aware of any computer based on the 6800. Radio Shack sold the famous Color Computer based on the 6809 and the Micro Color Computer based on the 6803, IIRC. The 6800 was sold mostly in kits used by hobbists and in universities, to build small projects.
After all, last night I downloaded and compiled 2.6.6. Darn.
He probably had a Tandy 2000, AFAIK the only PC using an 80186. I have seen it described at "TRS 80 model 2000" in some places.
Yes, they are used.
http://www.monito.com/wankel/aircraft.html
Even for R/C planes
http://www.osengines.com/engines/osmg1400.html
I think it's kind of a marketing issue. When a new language is proposed and does not look like C but more like Ada/Pascal/Modula etc many programmers will just say "It is so verbose, there is no ++ operator, and it shoud use braces, they save LOTS of typing!". Who cares if the programs are more readable. I happen to be interested in programming language design, and I have asked some programmers "What would an ideal language be like". They all answer "Oh, it should be like X, but with feature Y", where X is their favorite language and Y is their favorite (usually superficial) missing feature of X. Stangely, nobody answers "It should use garbage collection, it should have easy to remember operator precedeces, it should disallow jumping into data, it should have optional array bound checking" and so on. People just look at superficial properties of the language, mostly the lexical part. They don't even get to the context free part, and forget about semantics. If it looks like C/C+/Java (which they know) it must be like C/C++/Java (and they feel confortable)
You are right when you point out that Kolmogorov complexity (KC) is not a computable function. However, there is more to say about computational information theory.
1- Kolmogorov complexity is a poor measure of "meaning" of strings. Imagine a long string S of zeros. It's KC is very low, about log(length(S)), and clearly a strings of zeros means very little. Now consider a string S' made out of ones and zeros and generated by flipping a fair coin, which of course, does not mean much either. It's KC is as high as it can be, about length(S'). So, the KC being low or high does not tell us much.
2- There are other mathematical measures the can be thought of as the amount of "meaning" of a string. One such measure is Lempel-Ziv complexity (On the Complexity of Finite-Sequences, 1976), another is pithiness (L. Adleman, "Time, space and randomness," MIT/LCS/TM-131, 1979). I understand both are computable, I am not sure about tractability.
> Why not just fly the other drection and stay in the sunlight? :)
>
>1- You cannot fly fast enough. (as many other posters said)
>
>2- If you are thinking about enjoying a longer day, consider that you will also suffer a longer night
Ah, when I submitted the previous message it stroke me:
The idea is to make the night shorter. If the beast flies at only 160Kph, which is reasonable considering its size, the length of the night (going east)is about 20% shorter than duration of the night when you go west. This means you can get rid of 20% of your weight in batteries.