The question is not whether or not an animal is able to navigate. All animals do navigation of some kind.
The question is how the animal navigates. The researchers are arguing that instead of using landmarks ("I've reached the big tree, I should turn left now"), they're relying on a mental map ("I started 20 paces forward and 5 paces left of my destination, and I've gone 20 paces forward, so I still need to go 5 paces left.")
If people here would actually take the time to read the actual research, they'd probably learn something. Instead, what I usually see is people make an assumption about what they think the research is (often aided by a poor blurb), fit it into something they already know, and dismiss it as irrelevant.
What Hoare is talking about is designing the language so that the entire concept of a null reference is impossible. That is, if you wrote a program that might result in a null reference, then your program would not compile.
It would help immensely if you just put in a link to a recent news article summarizing what's going on. It wasn't until I found an article in Harvard's newspaper that I knew the basics of the situation.
Very much so. I had to Google Charles Nesson to figure out the context. It would help if along with the new stuff, he linked to a news article summarizing the latest.
Why would it creep you out? People who are outstanding in their field stand out. Maintaining a professional page which serves as a way to say "This is who I am and what I do" is the least one can do in that regard.
Seeing as I barely noticed these things, I have to disagree that they are "central topics". It would be exceedingly easy to tell the important parts of the story while leaving most of that out, especially Rorschach's homophobia.
Story, yes. But like good literature, Watchmen is about its themes just as much as its story. I read Watchmen recently, and those two things were big deals to me. They made me uncomfortable, and consequently, I thought about them a lot.
I don't want to add to the silly geek speculation, but I think it is true that most Hollywood movies avoid making the viewer uncomfortable.
One can produce clean systems using Perl - but that's not what I said. I said Python itself is prettier and more coherent than Perl. Perl's object model is an afterthought. And I see sigils as noise in my code.
You've probably never done any coding in Python. Check out the book Dive Into Python (it's free and online): http://www.diveintopython.org/ Even browsing through it will give you a better idea of what Python is good for.
Personally, I think of Python as a prettier and more coherent version of Perl.
With the amount of time and effort it would require to organize such a thing, it would be faster and easier if you instead just asked for a $1 donation from those people.
Locking in software has implications that locking at the hardware level does not.
If a thread locks in software, any subsequent thread must block, waiting for the first thread to finish. If the thread is preempted, then the waiting threads wait needlessly. If the thread dies, then the waiting threads are hosed.
Lock-free techniques prevent this problem, at the expense of more complicated algorithms and data structures. The basic structure of most lock-free algorithms is read a value, do something to it, and then attempt to commit the changed value back to memory. The attempt fails if another thread has changed the value from underneath you, and you must try again. (This is detected through operations like compare-and-swap.) This allows greater concurrency and guarantees that the system as a whole will make progress, even if a thread is preempted or dies.
Lock-free algorithms and data structures is a well established area. What Click has done here is provide a Java implementation of some data structures that yield good performance on the manycore systems his company makes.
It is lock-free, but it is not wait-free. He explains the difference in his slides, and there's plenty of literature around for those who have access to Google.
Even if the read in Thread B occurs after the write in Thread A chronologically, Thread B may be looking at stale data. If Thread B has stale data, then it's commit (through a compare-and-swap or similar atomic operation) should fail, and the thread should try the operation again.
Take a look at the algorithms in the presentation. I've done a fair amount of lock-free programming, but all of it was in C. His algorithms look like standard lock-free practices, but since I'm not familiar with what correct lock-free Java code looks like, I can't say with confidence.
I will, however, say that I would be surprised if Cliff Click made such the obvious error you assume he is making. I saw him talk at ISMM 2006, and I trust him more than random people on slashdot.
If you read the report, you can find this information. Although, granted, it is tucked away in a footnote:
Guo Liang, deputy director of the Research Center for Social Development, Chinese Academy of Social Sciences, who directed the study and authored the report, describes the interview process as follows: âoeThe survey started with: âHello, I am conducting a survey sponsored by the Research Center for Social Development of the Chinese Academy of Social Sciences. This is a confidential random survey and your response will remain anonymous.â(TM) The respondents should know they were being questioned by pollsters working for an independent survey company.â He also notes that while CASS is not a government agency, it is funded by the government although this particular study was funded by the Markle Foundation, located in New York, and that more than 90% of CASS reports are not "official reports."
The comparison is misleading. The top frequency of a Power6 is 4.7Ghz, which is not significantly faster than the competition. He's also trying to revive the frequency race, which means less now that we must exploit parallelism (beyond ILP, that is) for performance.
Good question, and the answer me and the other people in my group came up with is that they probably just haven't implemented it. It would require effort on their part to get exceptions working properly (keep in the mind the SPE is not a typical processing core), and there isn't much function nesting on the SPE due to its limited size. Maintaining stacks more than half a dozen deep on the SPE can become problematic.
So, my guess is it's not unimplementable, it's just not a priority.
I think that "innate talent" is mostly prior experience mapping well to an analogous task.
I think there are clearly differences in terms of innate intelligence and physical ability, but I think we tend to over-estimate the role these differences actually make. I see the same attitude with athletic achievement: people tend to dismiss the enormous time and dedication exceptional athletes are required to have.
Oddly enough, I hold the opposite opinion as you, but for the same reason. I think people characterize genius as an innate ability in order to excuse themselves from working that hard. If they believe that no matter how hard they work, they could never attain the level of proficiency that geniuses attain, then they have an excuse not to try.
Slashdot Mirror
As pointed out below, what you're saying is the opposite of what the researchers are saying.
The question is not whether or not an animal is able to navigate. All animals do navigation of some kind.
The question is how the animal navigates. The researchers are arguing that instead of using landmarks ("I've reached the big tree, I should turn left now"), they're relying on a mental map ("I started 20 paces forward and 5 paces left of my destination, and I've gone 20 paces forward, so I still need to go 5 paces left.")
If people here would actually take the time to read the actual research, they'd probably learn something. Instead, what I usually see is people make an assumption about what they think the research is (often aided by a poor blurb), fit it into something they already know, and dismiss it as irrelevant.
What Hoare is talking about is designing the language so that the entire concept of a null reference is impossible. That is, if you wrote a program that might result in a null reference, then your program would not compile.
The point is that the example compiles, even though the behavior is undefined.
What Hoare is talking about is designing a language such that null references are impossible.
It would help immensely if you just put in a link to a recent news article summarizing what's going on. It wasn't until I found an article in Harvard's newspaper that I knew the basics of the situation.
Very much so. I had to Google Charles Nesson to figure out the context. It would help if along with the new stuff, he linked to a news article summarizing the latest.
Why would it creep you out? People who are outstanding in their field stand out. Maintaining a professional page which serves as a way to say "This is who I am and what I do" is the least one can do in that regard.
I don't want to add to the silly geek speculation, but I think it is true that most Hollywood movies avoid making the viewer uncomfortable.
One can produce clean systems using Perl - but that's not what I said. I said Python itself is prettier and more coherent than Perl. Perl's object model is an afterthought. And I see sigils as noise in my code.
The time and effort required to organize it would also come from within the community. Generally, I'd rather fork over $1 than my time.
You've probably never done any coding in Python. Check out the book Dive Into Python (it's free and online): http://www.diveintopython.org/ Even browsing through it will give you a better idea of what Python is good for.
Personally, I think of Python as a prettier and more coherent version of Perl.
http://www.apple.com/timecapsule/
?
With the amount of time and effort it would require to organize such a thing, it would be faster and easier if you instead just asked for a $1 donation from those people.
Locking in software has implications that locking at the hardware level does not.
If a thread locks in software, any subsequent thread must block, waiting for the first thread to finish. If the thread is preempted, then the waiting threads wait needlessly. If the thread dies, then the waiting threads are hosed.
Lock-free techniques prevent this problem, at the expense of more complicated algorithms and data structures. The basic structure of most lock-free algorithms is read a value, do something to it, and then attempt to commit the changed value back to memory. The attempt fails if another thread has changed the value from underneath you, and you must try again. (This is detected through operations like compare-and-swap.) This allows greater concurrency and guarantees that the system as a whole will make progress, even if a thread is preempted or dies.
Lock-free algorithms and data structures is a well established area. What Click has done here is provide a Java implementation of some data structures that yield good performance on the manycore systems his company makes.
It is lock-free, but it is not wait-free. He explains the difference in his slides, and there's plenty of literature around for those who have access to Google.
Take a look at the algorithms in the presentation. I've done a fair amount of lock-free programming, but all of it was in C. His algorithms look like standard lock-free practices, but since I'm not familiar with what correct lock-free Java code looks like, I can't say with confidence.
I will, however, say that I would be surprised if Cliff Click made such the obvious error you assume he is making. I saw him talk at ISMM 2006, and I trust him more than random people on slashdot.
Java has a well-defined memory model. C++ (and C) do not; behavior depends on the hardware it is run on.
Personally, I put no confidence in the data.
The comparison is misleading. The top frequency of a Power6 is 4.7Ghz, which is not significantly faster than the competition. He's also trying to revive the frequency race, which means less now that we must exploit parallelism (beyond ILP, that is) for performance.
We've also squeezed about as much as we can out of supercalar designs; see the Wikipedia entry on limitations and alternatives.
Good question, and the answer me and the other people in my group came up with is that they probably just haven't implemented it. It would require effort on their part to get exceptions working properly (keep in the mind the SPE is not a typical processing core), and there isn't much function nesting on the SPE due to its limited size. Maintaining stacks more than half a dozen deep on the SPE can become problematic.
So, my guess is it's not unimplementable, it's just not a priority.
I think that "innate talent" is mostly prior experience mapping well to an analogous task.
I think there are clearly differences in terms of innate intelligence and physical ability, but I think we tend to over-estimate the role these differences actually make. I see the same attitude with athletic achievement: people tend to dismiss the enormous time and dedication exceptional athletes are required to have.
Oddly enough, I hold the opposite opinion as you, but for the same reason. I think people characterize genius as an innate ability in order to excuse themselves from working that hard. If they believe that no matter how hard they work, they could never attain the level of proficiency that geniuses attain, then they have an excuse not to try.
Also, the view that genius (and innovation) are the result of hard work is supported by the research:
The Secret to Raising Smart Kids
How Not to Talk to Your Kids
How to Grow a Super Athlete