Actually, there is a such thing as a 16-bit color mode that uses 5 bits for red, 6 for green, and 5 for blue (presumably because our eyes are slightly more sensitive to different shades of green), which does lead to 65,536 colors. As far as I know, some video cards use 15-bit mode for high colors, and others use 16-bit mode. I don't know of any that use both. Not to say there weren't inaccuracies in the article - see my comment below.
As the article hints at, it would make no sense for Apple to release an Intel version of the MacOS, because all of the existing Mac software has been compiled for a PowerPC (or a Motorola 68K series). The Star Trek project mentioned in the article is source-compatible, not binary-compatible, so every software manufacturer would have to recompile all of their code for the x86, and some would have problems, and many just wouldn't bother. The biggest issue would not be with the major applications like Photoshop and Excel (I have no doubt Apple could talk Adobe and Microsoft into supporting any new type of MacOS they come out with) but the thousands of free, shareware, or small commercial applications that people wouldn't bother to recompile.
When Apple switched from the 68K to the PowerPC a few years ago, not only was the PowerPC many times faster and able to emulate the 68K in real time, but it was the only significant change to the hardware, so many programs which accessed low-level MacOS hardware on the 68K still worked on the PowerPC. Also, Intel/PC hardware is too varied. Remember how long it's taken Linux to get support for all of the different PC hardware out there?
What happened in Washington is very sad. I used to live in Seattle, but I'm never planning to go back because the traffic is so horrible. Part of the reason the transportation bill passed was that almost all public transportation is in the Seattle area, so everyone near Seattle voted against the tax decrease, but everyone else in the state voted for it.
The thing that disgusts me is that ordinary citizens pay 20-30% of their income in taxes, but the richest of the rich, and especially big businesses, often pay next to nothing. Micro$oft, for example, 'gives away' what they claim is millions of dollars worth of software every year, because they write off $350 for every copy of Office they give away, even though it costs them about $5.
One of the libraries listed there is aalib - isn't that the one that renders stuff in ASCII Art? Can you actually render an MPEG movie in ASCII Art in real time?
It's true that X is way out of date and needs to be improved. However, why should we settle for a few small additions (like cubic splines and transparency) to barely catch us up to today's technology? We discussed Aqua/Quartz, the new graphics technology developed by Apple (if you haven't read about it already, it's radically different than any existing system) and maybe we should all be moving towards something more like that.
Someone posted a concern that a new system would break existing X programs - but I doubt that would be a problem - if we switch to something new (and more powerful) we would just need wrappers that support the X11 API. I'm all for it.
Heh. You're thinking of the longest path problem, which is NP-complete. Finding the shortest path between a pair of nodes is easy - use a simple breadth-first search for an unweighted graph, or Dijkstra's algortihm for a weighted one.
To find the shortest path between all pairs of nodes, you can use the Floyd-Warsha ll algorithm, which runs in O(n^3) time. It can be done faster, but in this particular case we were guaranteed n is no more than 100, so this was quite reasonable.
The teams recently received letters from the contest directors, who say that they have finally decided to "personally re-examine all submissions of Problem F from the archives" and that "the results of the re-examination will be posted in the standings by April 24th."
So I'm not expecting to see any changes until April 24th, which is next Monday.
If they make any changes, teams will be bumped up to a higher position, but no team will have its position lowered. Best of all, they have changed their official policy so that in the future, teams will have access to their programs after the contest is over, and also there will be a standard procedure for regrading after the contest is over, in case this happens again.
I'm particularly happy since there's a reasonable chance that my team's score will improve, but I think everyone should be glad that they're making an effort to keep this a fair contest. I highly recommend this contest to all interested college students. If you haven't already, check out the problem set from this year.
Most important is number of problems solved correctly out of 8.
During the 5-hour contest, whenever you submit a correct solution, the number of minutes that have elapsed since the beginning of the contest get added to your penalty. Each wrong submission adds 20 more points. For each number of problems solved, the lowest penalty ranks the highest.
I was on the CMU team. If you look at the statistics, you see that we solved 3 problems and were ranked 15th (in a tie). This is not what actually happened. We actually solved problem F correctly and did not get credit for it. At least a dozen other teams were also denied credit for a correct solution to this problem.
The controversy is that the judges and ACM contest staff still claim that there was no error in the grading of the problem, and that their datasets were consistent with the problem statement. Here's why I don't believe them.
Take a look at problem F. (Here are the contest problems in PDF if you're interested.) In a nutshell, you're given a complete directed graph, and you need to return the average length of all shortest paths between all pairs of nodes. The problem explicitly stated that you will only be given graphs in which there exists a path from every node to every other.
This is not a hard problem to work out, but anyone who has had a formal course in computer science ought to recognize that the Floyd-Warshall all-pairs shortest path algorithm is designed to solve exactly this problem. Then all you have to do is add up all of the elements of the matrix and divide by n * (n-1).
Except that the judges made a mistake, and tested our input using a graph that was not connected - in other words, there were nodes that could not reach other nodes via a directed path. This would not be a big deal, except that the problem explicitly stated that this would not occur. (Input validation is never a part of this contest.) Furthermore, without further explanation it is unclear how these nonexistent paths should affect the average. It turns out that the judges' solution was not counting these paths, and averaging only the paths that existed. Some teams did this by accident, and others (including Waterloo) figured it out only after submitting multiple runs and incurring large penalties. My team was one of the many that did not figure out the judges' mistake, so we did not get credit for the problem, even though our solution was certainly correct as the problem was worded. If we had received credit we would have had four problems correct, possibly putting us in the top ten. Of course, if we had received credit right away, we might not have wasted so much time figuring out what was wrong with our solution and we could have solved another problem in that time. Of course, many other teams were in a similar situation, so I have no idea what the final ranking would have been, but clearly it would have been different.
Now for some disclaimers.
First of all, I do not know firsthand that the judges had an incorrect data set, because their policy is not to release the data sets they use to test our programs. However, literally dozens of the 60 teams there encountered this error and many of them gained serious evidence that this was in fact the exact error. For example, one person showed me code he had written that would cause the program to seg fault if and only if the graph was not connected. He turned it in, and he got "runtime error" from the judges, indicating his program crashed. When he removed that line, he got "wrong answer". Even the team from Waterloo agreed that the data set was faulty.
Also, I am not trying to imply that the teams that did win did not deserve it. All of the top teams did an excellent job and deserve to be congratulated. I'm mostly upset that the ACM contest staff will not either admit there was an error, or release the datasets to prove there wasn't one.
I'm not going to speak for the other top U.S. schools, but I was on the CMU team, and I can give you two reasons why we didn't finish in the top three.
* It's not the school that wins the contest, it's three individual students. One excellent programmer from an average school is worth much more than a good programmer from a top school.
* CMU does not practice for the contest. Some teams spend 10 hours a week preparing for the contest starting at the beginning of the year. CMU comes every year, cold, and almost always finishes in the top 25%, sometimes higher.
There were other reasons we didn't do as well as we wanted to - see my post on the controversy, below.
Yes, the same binaries will run. There are now three classes of Mac applications:
1. The new apps written specifically for Mac OS X. Since Mac OS X is Posix-compliant, a lot of unix utilities could be very easily ported.
2. Old apps recompiled with "carbon" - these binaries will be cross-compatible and will run identically on OS 9 and OS X, but on OS X will take advantage of modern OS features.
3. Old apps that are not recompiled must be run inside of a separate window which emulates Mac OS 9. It won't be fun to run apps this way, but at least it will be possible.
Note that this page has the old navigation bar at the bottom instead of the new Aqua one at the top. So this page has probably been around for a while and certainly hasn't been updated since Apple redesigned their site.
I completely agree that humans can always write better assembly than compilers can generate, but it's getting harder.
Not all that long ago, compilers weren't all that smart, and processors were a lot simpler. Today processors use tricks like out-of-order execution and branch prediction, making it extremely difficult for an assembly-language programmer to determine exactly what is going on. It still remains the case, though, that the programmer may know something about the code that the processor doesn't (that a register will never contain a certain value, or that some execution paths are much more likely or more critical than others) which will give the programmer the edge.
None of the just-in-time compilers that I am aware of recompile code as they go. If the Crusoe actually attempts to optimize sections of the code based on runtime profiling information, this could be the main reason it performs so well. There have been academic papers written on this idea before but this would be the first implementation I've heard of.
A similar site, RealAroma, appeared three and a half years ago (I remember, because I interned at RealNetworks that summer) and I thought their site was bad enough then. Especially their 3-"vile" system to reproduce smells and their "Smell-U, Smell-Me" software for all-too-live aromaconferencing. Digiscents seems to have very nice site design, but I still don't believe it's for real.
I could be wrong, but I got the impression that they cache the instructions once they're translated, thus allowing short loops that are executed many times to operate just as fast as if they were native. This is the same trick used by Java Just-In-Time compilers.
There is also no reason to believe that they couldn't add support later for MMX or other such instructions natively, but keep in mind that very few normal programs take advantage of these anyway.
Linux has made it this far without anything as extravagent as Codewarrior.
People typeset amazingly beautiful documents before LaTeX came around, and people got from point A to point B before automobiles. This is no argument that we shouldn't embrace new technology.
There's still large factions that say that the CLI is superior to the GUI.
If you're doing kernel hacking or scientific programming, sure, why even boot into X when virtual terminals are so fast? For the rest of us, we need to develop applications that have user interfaces, and visual tools speed up this process immensely.
There are hundreds of free alternative to Code Warrior.
There are hundreds of web browsers, too, but most of them suck. CodeWarrior is robust, fast, and mature, and it has a large user base already.
It seems understandable for a company to doubt how much impact their product will have on a hugely saturated market.
Here I agree with you. Most current Linux users will not switch. However, I think that having CodeWarrior available for Linux would help entice developers coming from the Windows/Mac world.
I know a lot of you think that gmake is sexy and that real programmers debug using printf, but once you've used a real IDE like CodeWarrior, everything else seems so primitive. It would be a shame to see the Linux version dropped.
I routinely use MS DevStudio on Windows and CodeWarrior on the Mac, and there is just no comparison. DevStudio is quirky and frustrating, and their debugger is both unintuitive and limited. CodeWarrior is slick, clean, and fast, and the debugger is a joy to use. It's the little things, like dragging and dropping files into the project and having it do the right thing, or being able to click on a void * in the debugger and being able to instantly view it as an array of 100 doubles (or whatever else), that make it so much nicer. I've never found an environment with all of these features in the Unix world. Let's hope they change their minds and continue the CodeWarrior/Linux project.
Scale of 1-10 not good indicator
on
The Sparrow
·
· Score: 1
I'm not at all surprised that all of the books reviewed here get scores of 8-10. I can imagine a Slashdot article about a really bad book, but only if it wasn't obvious that it was bad, or it was really popular in spite of its being bad. "The Bible Code" comes to mind (not flamebait - just my opinion). Just as with movies and music, I tend to tell all of my friends about the really good books (and sometimes the really bad) but I often forget about the mediocre - the 3's and 7's.
That said, one way I like to rate books is something like "that was the best book I've read in the last month" or "the last year" or "possibly ever".
"The Sparrow" was the best book I've read in about two years, and I like to read a lot. Though it didn't have a lot of sci-fi, the sci-fi that was in it was mostly good (plausible). I really loved the treatment of the alien languages, and the human characters were believable and even lovable. Parts of it were very heavy and hard to read, which is why I haven't yet picked up "Children of God".
Slashdot Mirror
Actually, there is a such thing as a 16-bit color mode that uses 5 bits for red, 6 for green, and 5 for blue (presumably because our eyes are slightly more sensitive to different shades of green), which does lead to 65,536 colors. As far as I know, some video cards use 15-bit mode for high colors, and others use 16-bit mode. I don't know of any that use both. Not to say there weren't inaccuracies in the article - see my comment below.
As the article hints at, it would make no sense for Apple to release an Intel version of the MacOS, because all of the existing Mac software has been compiled for a PowerPC (or a Motorola 68K series). The Star Trek project mentioned in the article is source-compatible, not binary-compatible, so every software manufacturer would have to recompile all of their code for the x86, and some would have problems, and many just wouldn't bother. The biggest issue would not be with the major applications like Photoshop and Excel (I have no doubt Apple could talk Adobe and Microsoft into supporting any new type of MacOS they come out with) but the thousands of free, shareware, or small commercial applications that people wouldn't bother to recompile.
When Apple switched from the 68K to the PowerPC a few years ago, not only was the PowerPC many times faster and able to emulate the 68K in real time, but it was the only significant change to the hardware, so many programs which accessed low-level MacOS hardware on the 68K still worked on the PowerPC. Also, Intel/PC hardware is too varied. Remember how long it's taken Linux to get support for all of the different PC hardware out there?
Why not go to mp3.com and download music by indie artists there?
What happened in Washington is very sad. I used to live in Seattle, but I'm never planning to go back because the traffic is so horrible. Part of the reason the transportation bill passed was that almost all public transportation is in the Seattle area, so everyone near Seattle voted against the tax decrease, but everyone else in the state voted for it.
The thing that disgusts me is that ordinary citizens pay 20-30% of their income in taxes, but the richest of the rich, and especially big businesses, often pay next to nothing. Micro$oft, for example, 'gives away' what they claim is millions of dollars worth of software every year, because they write off $350 for every copy of Office they give away, even though it costs them about $5.
One of the libraries listed there is aalib - isn't that the one that renders stuff in ASCII Art? Can you actually render an MPEG movie in ASCII Art in real time?
It's true that X is way out of date and needs to be improved. However, why should we settle for a few small additions (like cubic splines and transparency) to barely catch us up to today's technology? We discussed Aqua/Quartz, the new graphics technology developed by Apple (if you haven't read about it already, it's radically different than any existing system) and maybe we should all be moving towards something more like that.
Someone posted a concern that a new system would break existing X programs - but I doubt that would be a problem - if we switch to something new (and more powerful) we would just need wrappers that support the X11 API. I'm all for it.
Heh. You're thinking of the longest path problem, which is NP-complete. Finding the shortest path between a pair of nodes is easy - use a simple breadth-first search for an unweighted graph, or Dijkstra's algortihm for a weighted one.
To find the shortest path between all pairs of nodes, you can use the Floyd-Warsha ll algorithm, which runs in O(n^3) time. It can be done faster, but in this particular case we were guaranteed n is no more than 100, so this was quite reasonable.
The teams recently received letters from the contest directors, who say that they have finally decided to "personally re-examine all submissions of Problem F from the archives" and that "the results of the re-examination will be posted in the standings by April 24th."
So I'm not expecting to see any changes until April 24th, which is next Monday.
If they make any changes, teams will be bumped up to a higher position, but no team will have its position lowered. Best of all, they have changed their official policy so that in the future, teams will have access to their programs after the contest is over, and also there will be a standard procedure for regrading after the contest is over, in case this happens again.
I'm particularly happy since there's a reasonable chance that my team's score will improve, but I think everyone should be glad that they're making an effort to keep this a fair contest. I highly recommend this contest to all interested college students. If you haven't already, check out the problem set from this year.
Most important is number of problems solved correctly out of 8.
During the 5-hour contest, whenever you submit a correct solution, the number of minutes that have elapsed since the beginning of the contest get added to your penalty. Each wrong submission adds 20 more points. For each number of problems solved, the lowest penalty ranks the highest.
I was on the CMU team. If you look at the statistics, you see that we solved 3 problems and were ranked 15th (in a tie). This is not what actually happened. We actually solved problem F correctly and did not get credit for it. At least a dozen other teams were also denied credit for a correct solution to this problem.
The controversy is that the judges and ACM contest staff still claim that there was no error in the grading of the problem, and that their datasets were consistent with the problem statement. Here's why I don't believe them.
Take a look at problem F. (Here are the contest problems in PDF if you're interested.) In a nutshell, you're given a complete directed graph, and you need to return the average length of all shortest paths between all pairs of nodes. The problem explicitly stated that you will only be given graphs in which there exists a path from every node to every other.
This is not a hard problem to work out, but anyone who has had a formal course in computer science ought to recognize that the Floyd-Warshall all-pairs shortest path algorithm is designed to solve exactly this problem. Then all you have to do is add up all of the elements of the matrix and divide by n * (n-1).
Except that the judges made a mistake, and tested our input using a graph that was not connected - in other words, there were nodes that could not reach other nodes via a directed path. This would not be a big deal, except that the problem explicitly stated that this would not occur. (Input validation is never a part of this contest.) Furthermore, without further explanation it is unclear how these nonexistent paths should affect the average. It turns out that the judges' solution was not counting these paths, and averaging only the paths that existed. Some teams did this by accident, and others (including Waterloo) figured it out only after submitting multiple runs and incurring large penalties. My team was one of the many that did not figure out the judges' mistake, so we did not get credit for the problem, even though our solution was certainly correct as the problem was worded. If we had received credit we would have had four problems correct, possibly putting us in the top ten. Of course, if we had received credit right away, we might not have wasted so much time figuring out what was wrong with our solution and we could have solved another problem in that time. Of course, many other teams were in a similar situation, so I have no idea what the final ranking would have been, but clearly it would have been different.
Now for some disclaimers.
First of all, I do not know firsthand that the judges had an incorrect data set, because their policy is not to release the data sets they use to test our programs. However, literally dozens of the 60 teams there encountered this error and many of them gained serious evidence that this was in fact the exact error. For example, one person showed me code he had written that would cause the program to seg fault if and only if the graph was not connected. He turned it in, and he got "runtime error" from the judges, indicating his program crashed. When he removed that line, he got "wrong answer". Even the team from Waterloo agreed that the data set was faulty.
Also, I am not trying to imply that the teams that did win did not deserve it. All of the top teams did an excellent job and deserve to be congratulated. I'm mostly upset that the ACM contest staff will not either admit there was an error, or release the datasets to prove there wasn't one.
Dominic
I'm not going to speak for the other top U.S. schools, but I was on the CMU team, and I can give you two reasons why we didn't finish in the top three.
* It's not the school that wins the contest, it's three individual students. One excellent programmer from an average school is worth much more than a good programmer from a top school.
* CMU does not practice for the contest. Some teams spend 10 hours a week preparing for the contest starting at the beginning of the year. CMU comes every year, cold, and almost always finishes in the top 25%, sometimes higher.
There were other reasons we didn't do as well as we wanted to - see my post on the controversy, below.
Dominic
Yes, the same binaries will run. There are now three classes of Mac applications:
1. The new apps written specifically for Mac OS X.
Since Mac OS X is Posix-compliant, a lot of unix utilities could be very easily ported.
2. Old apps recompiled with "carbon" - these binaries will be cross-compatible and will run identically on OS 9 and OS X, but on OS X will take advantage of modern OS features.
3. Old apps that are not recompiled must be run inside of a separate window which emulates Mac OS 9. It won't be fun to run apps this way, but at least it will be possible.
Note that this page has the old navigation bar at the bottom instead of the new Aqua one at the top. So this page has probably been around for a while and certainly hasn't been updated since Apple redesigned their site.
I completely agree that humans can always write better assembly than compilers can generate, but it's getting harder.
Not all that long ago, compilers weren't all that smart, and processors were a lot simpler. Today processors use tricks like out-of-order execution and branch prediction, making it extremely difficult for an assembly-language programmer to determine exactly what is going on. It still remains the case, though, that the programmer may know something about the code that the processor doesn't (that a register will never contain a certain value, or that some execution paths are much more likely or more critical than others) which will give the programmer the edge.
None of the just-in-time compilers that I am aware of recompile code as they go. If the Crusoe actually attempts to optimize sections of the code based on runtime profiling information, this could be the main reason it performs so well. There have been academic papers written on this idea before but this would be the first implementation I've heard of.
A similar site, RealAroma, appeared three and a half years ago (I remember, because I interned at RealNetworks that summer) and I thought their site was bad enough then. Especially their 3-"vile" system to reproduce smells and their "Smell-U, Smell-Me" software for all-too-live aromaconferencing. Digiscents seems to have very nice site design, but I still don't believe it's for real.
According to their FAQ, they are planning to release the source, but they are not getting into the distribution business.
I could be wrong, but I got the impression that they cache the instructions once they're translated, thus allowing short loops that are executed many times to operate just as fast as if they were native. This is the same trick used by Java Just-In-Time compilers.
There is also no reason to believe that they couldn't add support later for MMX or other such instructions natively, but keep in mind that very few normal programs take advantage of these anyway.
Linux has made it this far without anything as extravagent as Codewarrior.
People typeset amazingly beautiful documents before LaTeX came around, and people got from point A to point B before automobiles. This is no argument that we shouldn't embrace new technology.
There's still large factions that say that the CLI is superior to the GUI.
If you're doing kernel hacking or scientific programming, sure, why even boot into X when virtual terminals are so fast? For the rest of us, we need to develop applications that have user interfaces, and visual tools speed up this process immensely.
There are hundreds of free alternative to Code Warrior.
There are hundreds of web browsers, too, but most of them suck. CodeWarrior is robust, fast, and mature, and it has a large user base already.
It seems understandable for a company to doubt how much impact their product will have on a hugely saturated market.
Here I agree with you. Most current Linux users will not switch. However, I think that having CodeWarrior available for Linux would help entice developers coming from the Windows/Mac world.
I know a lot of you think that gmake is sexy and that real programmers debug using printf, but once you've used a real IDE like CodeWarrior, everything else seems so primitive. It would be a shame to see the Linux version dropped.
I routinely use MS DevStudio on Windows and CodeWarrior on the Mac, and there is just no comparison. DevStudio is quirky and frustrating, and their debugger is both unintuitive and limited. CodeWarrior is slick, clean, and fast, and the debugger is a joy to use. It's the little things, like dragging and dropping files into the project and having it do the right thing, or being able to click on a void * in the debugger and being able to instantly view it as an array of 100 doubles (or whatever else), that make it so much nicer. I've never found an environment with all of these features in the Unix world. Let's hope they change their minds and continue the CodeWarrior/Linux project.
I'm not at all surprised that all of the books reviewed here get scores of 8-10. I can imagine a Slashdot article about a really bad book, but only if it wasn't obvious that it was bad, or it was really popular in spite of its being bad. "The Bible Code" comes to mind (not flamebait - just my opinion). Just as with movies and music, I tend to tell all of my friends about the really good books (and sometimes the really bad) but I often forget about the mediocre - the 3's and 7's.
That said, one way I like to rate books is something like "that was the best book I've read in the last month" or "the last year" or "possibly ever".
"The Sparrow" was the best book I've read in about two years, and I like to read a lot. Though it didn't have a lot of sci-fi, the sci-fi that was in it was mostly good (plausible). I really loved the treatment of the alien languages, and the human characters were believable and even lovable. Parts of it were very heavy and hard to read, which is why I haven't yet picked up "Children of God".