Yes, but they could pick you up because you were in the area at the time, or because someone said you had a fight with the victim, or whatever.
If this is to be alarming, it means that using DNA evidence would have to increase the rate of false positives.
Something is seriously wrong if you can get more information about a crime and yet do less well at figuring out who did it. (Something may be seriously wrong, but one should at least make a compelling case, not just take it for granted, because OMG, they might get my DNA!)
I don't quite understand what the big deal is. You're acting as though the incoming class is being asked to sign its soul away.
I think universities should do this sort of thing much more often. If universities turned around and made the results of their research available to students on an accelerated schedule, it would be exciting, inspirational, and motivate learning a lot better than, "Well, read this textbook about stuff that happened 20 years ago while we do a lot of exciting new things that we won't tell you about and are licensing to for-profit companies who might sell it to you after you graduate."
Of course there are privacy issues, but universities have access to a fair bit of private information (e.g. financial, if the student has applied for aid; academic transcripts; possibly personal essays, and so on). As long as they're not completely careless with genetic information, it's hardly different from anything else (especially since they're doing a limited analysis).
Supposing you want to run a program that I write, and I'm going to write it in exactly one language because it's just me and not a corporation with thousands of employees, and I'm not so in love with the Mac that I will write it to run only there.
Then what do you recommend I do in the face of "de-emphasized" Java?
First: It was Sun that decided (up until recently) that they wouldn't open-source Java.
Completely irrelevant. Sun seemed happy to support various platforms and to work with large vendors including Apple. But Apple...
Second, Apple wanted to make sure that the crappy Swing interfaces in most Java apps at least looked somewhat native.
...didn't want to leave it to Sun, from everything I've read, and took it over themselves. And then decided to support it unenthusiastically and slowly instead of competently. I don't blame them for wanting interfaces to look nice--I blame them for saying they wanted control and then doing a slothful job. If you're not going to do things in a timely fashion, don't take them over!
And finally, when Apple takes away the ability to cross-compile most Linux/UNIX packages, usually with just a few modifications, then you can whine about cross-platform compatibility.
Why do I have to wait for that exact thing to happen in order to complain? I'm complaining because Apple's desire for control or purity or the perfect user experience or whatever it is has caused problems already.
I already can't easily write programs that run on all platforms with exactly zero changes (which I usually can with Java, at least during those periods when Apple's Java support is not too archaic), so the relative compatibility of Linux/UNIX packages isn't particularly relevant.
As someone who routinely writes in Java (or JVM-targeting languages) because it will run anywhere, it is hard to read Jobs' criticism that Adobe has been too slow with Flash support for OS X with a straight face.
Apple's track record with Java--from having 1.6 appear years late, to dropping 32 bit support, to insisting on packaging it themselves--seems to strongly indicate that they have to be dragged kicking and screaming to cross-platform compatibility.
Notice that Apple's only making a fuss now that Adobe is stepping up its support. That'll teach anyone to try to make their cross-platform tools work better with Apple's products, won't it!
Maybe you haven't seen as much abysmally slow code as I have that was created because the coder wasn't thinking about divide-and-conquer strategies. From what I've seen, I wouldn't be too dismissive of a "explain quicksort"-style question. It's a very simple algorithm conceptually (though getting the implementation details exactly right and avoiding worst cases and such is less easy). I wouldn't ask that for *every* programming job, just the ones that involve processing of data of non-negligible size in a fashion that is not entirely handled by high-level calls to some library.
I would, however, accept "it's in reference X" (as long as they were correct that it was there) unless X==Wikipedia (it _is_ in Wikipedia, but this provides no assurance of past experience, whereas picking out a section of a book on algorithms suggests that they've had exposure to a decent number of algorithms and would have some idea of when to go looking for details).
The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb.
Actually, that's the coder, not the compiler. The worst cases there were for code that was apparently not written with performance in mind at all. From what I saw, there was only one "gotcha" that arguably was the compiler or JVM's fault having to do with lack of optimization in certain types of static initializer code, and even then it only came up because the coder tried to save a dozen or so characters in the code.
Ruby can be made a lot more terse than Scala can but at that point it's quite difficult to read. I've tried to match the terseness of a number of very compact Ruby programs in Scala and I'm lucky to get within 50%.
At the same level of terseness (maximum Scala terseness, comfortable Ruby terseness), Ruby is easier to read unless you're much more familiar with Scala than Ruby. (Stuff like _._2 < _ in Scala takes a while to figure out, and even when you've got it it takes a bit of thinking.)
At a comfortable level in both languages, I find Scala easier to read but less terse--the key being mostly Scala's descriptive inline operators.
Those supposedly cute features are there for a reason--they make abnormally clean and maintainable code possible.
The best Scala code I've seen is clearer (to an outside observer) than the best Java code could possibly be, since the language features allow you to focus more on what is going on rather than necessary theatrics.
The worst Scala code is, admittedly, worse than the worst Java code could possibly be.
So, if I had programmers who wrote nice clean code, I'd encourage them to use Scala. If I had programmers who wrote ugly tangled code, I'd force them to use Java.
Scala is better and different from Groovy and JRuby and Jython in that it is statically typed (but does a fantastic job at hiding all the type nonsense as long as you are doing something sensible). Those of us who make type errors as one of their most common errors really benefit from this. It is also better and different in that it is quite a lot faster than the interpreted languages. (It is worse and different in that a few fancy tricks are impossible, such as method-missing stuff, or generic operations using anything for which the operator is defined, etc..)
I've found NetBeans + Java + Scala to not detract at all from NetBeans + Java. So to me, it's a win to add Scala to the mix. It would also be a win to add Groovy or Clojure or Jython or whatever; I just find adding Scala to be the biggest win because the interoperability with Java is easiest (at least in the Java->Scala direction) and because performance is by far the best.
I'm not sure what to link to; there isn't a whole lot written about modeling the human brain at that scale and level of detail. Questions of the type "In field X is it possible to do Y?" generally require a large amount of knowledge about field X.
That said, one can--if one is at a university with appropriate access--browse journals like Neural Computation to see the gap between what people do now (even in those few papers that are most on-target) and what the goal is.
Heck, we can't even agree on what the classes of neurons are on in the cortex. (Try googling "inhibitory neuron class cortex" and note that instead of finding handy tables of the interneuron classes, you find things that sound like, "Golly, we just found three more!")
I'm not talking about something that *seems* self-conscious; I'm talking about something that *is* self-conscious in that it is modeling the world, including itself and its own state. The more complicated the system, the richer and more abstract the representation can be. Humans are very, very complicated with very, very rich and abstract representations (including multiple representations for the same thing: red can be known declaratively, intuitively (it "looks red"--unique internal identifier for that sensory input), emotionally, etc..).
Human rights are an almost completely separate issue, I think, from consciousness. All sorts of animals have varying levels of consciousness (and suffering), and we don't apply human rights to them. If you tell me what human rights are for, I might be able to tell you whether they should be applied to computers. If the answer is, "We feel instinctive revulsion to unpleasant things happening to others, so we establish rights to stop that from happening," then the answer is, "If we feel similar revulsion to unpleasant things happening to a computer, then it is consistent to apply parallel rights (if not identical) to appropriate computers." If the answer is, "Because we think humans have a nonphysical soul," then the answer is, "No, computers are physical, so no rights for them." Etc..
If you have a "paying attention" module (implemented physically) that represents states of the world, and you pay attention to paying attention, you get something that acts a lot like self-consciousness. Why is this complicated?
I wouldn't say Markram's opinion is in the majority. I know the field well, and I think that either he's sitting on a lot of super-ultra-exciting results that he has mysteriously not presented at the last conferences his team went to, or, more likely, is being hopelessly optimistic (or is confusing "years" and "centuries", or something).
It is theoretically possible, but the ~1000 cubic centimeter mass of the brain requires approximately 8*10^21 voxels of (5 nm)^3 imaging data just to get the structure--and that misses all of the proteins that are essential to get it to work, and we don't know how to turn those 80000 exabytes into anything useful for computation without going through by hand.
For the time being, it is "theoretically possible, practically impossible" to do it that way. And it will remain so for longer than ten years.
You're not doing a very convincing job of constructing an argument. So far you have
- ad hominem: You only think Ray's good cause he's popular on Slashdot
- argument from authority: lawyers, judges, and juries must be right
- another ad hominem: for Ray to claim those guys are wrong, wow, what arrogance!
Ray's blog, on the other hand, contains actual substantive arguments pertaining to proper procedures (who should be allowed to testify and with what caveats or warnings) and prior case history (what is the relationship between award of damages and monetary harm). He might be wrong, but then so might be the jury.
In fact, if the jury thinks the way you've presented your arguments, they'll just think, "Wow, all these really masterful lawyers on one side, they can't be wrong--I'll just trust whatever they say and not think about it!" The judge, if he or she shares the approach you took in this post, is liable to be similarly swayed.
Morphine works because it mimics natural opioids. It's extremely unlikely that a morphine blocker wouldn't block any natural opioids at all. That's the whole point--morphine and natural opioids are too close to each other in structure.
So the expectation should be that the morphine blocker *would* cause an effect because it blocks the natural opioids.
The best solution seems to be for planes to not hit birds. Planes move way too fast for birds to dodge at short range, and at long range they don't know what to expect--nor should we expect them to unless we install bird telepathy projectors on the planes.
On the other hand, planes move really fast, and a small change in angle early on will take the plane far away from, say, a flock of incoming geese. The question is, then, _where are the geese_?
Now, geese might be hard to see from a plane when they're lost in a bunch of buildings and what not. But they're not hard to see from the ground if you have a clear line of sight to the sky and a good IR illumination system. So you sweep your flight path from the ground until an altitude where bird strikes aren't likely to be a problem with a strobed IR laser and look for returning flashes. Ground control tells the plane where the geese are and which way they're going (and how fast), and the plane takes evasive action.
I am surprised that the benchmarks perform so much worse *without* being significantly more compact. If you're going to write compact functional code, you have to accept a bit (or a lot) of overhead. But there's no reason a Scala program should be both longer and slower than a Java one except through inattention.
Slashdot Mirror
Yes, but they could pick you up because you were in the area at the time, or because someone said you had a fight with the victim, or whatever.
If this is to be alarming, it means that using DNA evidence would have to increase the rate of false positives.
Something is seriously wrong if you can get more information about a crime and yet do less well at figuring out who did it. (Something may be seriously wrong, but one should at least make a compelling case, not just take it for granted, because OMG, they might get my DNA!)
I don't quite understand what the big deal is. You're acting as though the incoming class is being asked to sign its soul away.
I think universities should do this sort of thing much more often. If universities turned around and made the results of their research available to students on an accelerated schedule, it would be exciting, inspirational, and motivate learning a lot better than, "Well, read this textbook about stuff that happened 20 years ago while we do a lot of exciting new things that we won't tell you about and are licensing to for-profit companies who might sell it to you after you graduate."
Of course there are privacy issues, but universities have access to a fair bit of private information (e.g. financial, if the student has applied for aid; academic transcripts; possibly personal essays, and so on). As long as they're not completely careless with genetic information, it's hardly different from anything else (especially since they're doing a limited analysis).
You think it's more likely for law enforcement to make a mistake when they get DNA than when they don't? How exactly does that work?
Supposing you want to run a program that I write, and I'm going to write it in exactly one language because it's just me and not a corporation with thousands of employees, and I'm not so in love with the Mac that I will write it to run only there.
Then what do you recommend I do in the face of "de-emphasized" Java?
First: It was Sun that decided (up until recently) that they wouldn't open-source Java.
Completely irrelevant. Sun seemed happy to support various platforms and to work with large vendors including Apple. But Apple...
Second, Apple wanted to make sure that the crappy Swing interfaces in most Java apps at least looked somewhat native.
...didn't want to leave it to Sun, from everything I've read, and took it over themselves. And then decided to support it unenthusiastically and slowly instead of competently. I don't blame them for wanting interfaces to look nice--I blame them for saying they wanted control and then doing a slothful job. If you're not going to do things in a timely fashion, don't take them over!
And finally, when Apple takes away the ability to cross-compile most Linux/UNIX packages, usually with just a few modifications, then you can whine about cross-platform compatibility.
Why do I have to wait for that exact thing to happen in order to complain? I'm complaining because Apple's desire for control or purity or the perfect user experience or whatever it is has caused problems already.
I already can't easily write programs that run on all platforms with exactly zero changes (which I usually can with Java, at least during those periods when Apple's Java support is not too archaic), so the relative compatibility of Linux/UNIX packages isn't particularly relevant.
As someone who routinely writes in Java (or JVM-targeting languages) because it will run anywhere, it is hard to read Jobs' criticism that Adobe has been too slow with Flash support for OS X with a straight face.
Apple's track record with Java--from having 1.6 appear years late, to dropping 32 bit support, to insisting on packaging it themselves--seems to strongly indicate that they have to be dragged kicking and screaming to cross-platform compatibility.
Notice that Apple's only making a fuss now that Adobe is stepping up its support. That'll teach anyone to try to make their cross-platform tools work better with Apple's products, won't it!
Maybe you haven't seen as much abysmally slow code as I have that was created because the coder wasn't thinking about divide-and-conquer strategies. From what I've seen, I wouldn't be too dismissive of a "explain quicksort"-style question. It's a very simple algorithm conceptually (though getting the implementation details exactly right and avoiding worst cases and such is less easy). I wouldn't ask that for *every* programming job, just the ones that involve processing of data of non-negligible size in a fashion that is not entirely handled by high-level calls to some library.
I would, however, accept "it's in reference X" (as long as they were correct that it was there) unless X==Wikipedia (it _is_ in Wikipedia, but this provides no assurance of past experience, whereas picking out a section of a book on algorithms suggests that they've had exposure to a decent number of algorithms and would have some idea of when to go looking for details).
The JVM scales nicely, but you can load stuff on top of it that makes it not scale nicely.
That the Scala folks were careful to let the JVM scale nicely is a credit to them.
(Plus, the scalability also refers to the types of modularity that are available--Scala allows good practice in that area also.)
The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb.
Actually, that's the coder, not the compiler. The worst cases there were for code that was apparently not written with performance in mind at all. From what I saw, there was only one "gotcha" that arguably was the compiler or JVM's fault having to do with lack of optimization in certain types of static initializer code, and even then it only came up because the coder tried to save a dozen or so characters in the code.
Ruby can be made a lot more terse than Scala can but at that point it's quite difficult to read. I've tried to match the terseness of a number of very compact Ruby programs in Scala and I'm lucky to get within 50%.
At the same level of terseness (maximum Scala terseness, comfortable Ruby terseness), Ruby is easier to read unless you're much more familiar with Scala than Ruby. (Stuff like _._2 < _ in Scala takes a while to figure out, and even when you've got it it takes a bit of thinking.)
At a comfortable level in both languages, I find Scala easier to read but less terse--the key being mostly Scala's descriptive inline operators.
Those supposedly cute features are there for a reason--they make abnormally clean and maintainable code possible.
The best Scala code I've seen is clearer (to an outside observer) than the best Java code could possibly be, since the language features allow you to focus more on what is going on rather than necessary theatrics.
The worst Scala code is, admittedly, worse than the worst Java code could possibly be.
So, if I had programmers who wrote nice clean code, I'd encourage them to use Scala. If I had programmers who wrote ugly tangled code, I'd force them to use Java.
Scala is better and different from Groovy and JRuby and Jython in that it is statically typed (but does a fantastic job at hiding all the type nonsense as long as you are doing something sensible). Those of us who make type errors as one of their most common errors really benefit from this. It is also better and different in that it is quite a lot faster than the interpreted languages. (It is worse and different in that a few fancy tricks are impossible, such as method-missing stuff, or generic operations using anything for which the operator is defined, etc..)
I've found NetBeans + Java + Scala to not detract at all from NetBeans + Java. So to me, it's a win to add Scala to the mix. It would also be a win to add Groovy or Clojure or Jython or whatever; I just find adding Scala to be the biggest win because the interoperability with Java is easiest (at least in the Java->Scala direction) and because performance is by far the best.
A very high volume of triviality is non-trivial.
I'm not sure what to link to; there isn't a whole lot written about modeling the human brain at that scale and level of detail. Questions of the type "In field X is it possible to do Y?" generally require a large amount of knowledge about field X.
That said, one can--if one is at a university with appropriate access--browse journals like Neural Computation to see the gap between what people do now (even in those few papers that are most on-target) and what the goal is.
Heck, we can't even agree on what the classes of neurons are on in the cortex. (Try googling "inhibitory neuron class cortex" and note that instead of finding handy tables of the interneuron classes, you find things that sound like, "Golly, we just found three more!")
I'm not talking about something that *seems* self-conscious; I'm talking about something that *is* self-conscious in that it is modeling the world, including itself and its own state. The more complicated the system, the richer and more abstract the representation can be. Humans are very, very complicated with very, very rich and abstract representations (including multiple representations for the same thing: red can be known declaratively, intuitively (it "looks red"--unique internal identifier for that sensory input), emotionally, etc..).
Human rights are an almost completely separate issue, I think, from consciousness. All sorts of animals have varying levels of consciousness (and suffering), and we don't apply human rights to them. If you tell me what human rights are for, I might be able to tell you whether they should be applied to computers. If the answer is, "We feel instinctive revulsion to unpleasant things happening to others, so we establish rights to stop that from happening," then the answer is, "If we feel similar revulsion to unpleasant things happening to a computer, then it is consistent to apply parallel rights (if not identical) to appropriate computers." If the answer is, "Because we think humans have a nonphysical soul," then the answer is, "No, computers are physical, so no rights for them." Etc..
If you have a "paying attention" module (implemented physically) that represents states of the world, and you pay attention to paying attention, you get something that acts a lot like self-consciousness. Why is this complicated?
I wouldn't say Markram's opinion is in the majority. I know the field well, and I think that either he's sitting on a lot of super-ultra-exciting results that he has mysteriously not presented at the last conferences his team went to, or, more likely, is being hopelessly optimistic (or is confusing "years" and "centuries", or something).
It is theoretically possible, but the ~1000 cubic centimeter mass of the brain requires approximately 8*10^21 voxels of (5 nm)^3 imaging data just to get the structure--and that misses all of the proteins that are essential to get it to work, and we don't know how to turn those 80000 exabytes into anything useful for computation without going through by hand.
For the time being, it is "theoretically possible, practically impossible" to do it that way. And it will remain so for longer than ten years.
You're not doing a very convincing job of constructing an argument. So far you have
- ad hominem: You only think Ray's good cause he's popular on Slashdot
- argument from authority: lawyers, judges, and juries must be right
- another ad hominem: for Ray to claim those guys are wrong, wow, what arrogance!
Ray's blog, on the other hand, contains actual substantive arguments pertaining to proper procedures (who should be allowed to testify and with what caveats or warnings) and prior case history (what is the relationship between award of damages and monetary harm). He might be wrong, but then so might be the jury.
In fact, if the jury thinks the way you've presented your arguments, they'll just think, "Wow, all these really masterful lawyers on one side, they can't be wrong--I'll just trust whatever they say and not think about it!" The judge, if he or she shares the approach you took in this post, is liable to be similarly swayed.
Morphine works because it mimics natural opioids. It's extremely unlikely that a morphine blocker wouldn't block any natural opioids at all. That's the whole point--morphine and natural opioids are too close to each other in structure.
So the expectation should be that the morphine blocker *would* cause an effect because it blocks the natural opioids.
The best solution seems to be for planes to not hit birds. Planes move way too fast for birds to dodge at short range, and at long range they don't know what to expect--nor should we expect them to unless we install bird telepathy projectors on the planes.
On the other hand, planes move really fast, and a small change in angle early on will take the plane far away from, say, a flock of incoming geese. The question is, then, _where are the geese_?
Now, geese might be hard to see from a plane when they're lost in a bunch of buildings and what not. But they're not hard to see from the ground if you have a clear line of sight to the sky and a good IR illumination system. So you sweep your flight path from the ground until an altitude where bird strikes aren't likely to be a problem with a strobed IR laser and look for returning flashes. Ground control tells the plane where the geese are and which way they're going (and how fast), and the plane takes evasive action.
I am surprised that the benchmarks perform so much worse *without* being significantly more compact. If you're going to write compact functional code, you have to accept a bit (or a lot) of overhead. But there's no reason a Scala program should be both longer and slower than a Java one except through inattention.
By "funny unit" I meant one that mixes SI and Imperial. Mass squared is not that novel of a unit on its own. (E.g. it would have use in gravitation.)
If you do--at least if you're at work--you're committing a felony!
Oops, too late.