The basic thing is that is not a specific number like or e -- it is really a class of numbers with a particular property -- that of being a random string of binary digits with no internal structure. The procedure the researcher outlined will produce only one such number, not the entire infinite set of such numbers.
I'm reminded of the cantor dusts when reading Chaitins work, and the ubiquity of infinitie classes of numbers in the Continium. But it is not all that surprizing, I think. It answers a deep question -- why does math work the way it does? Because we see what we find useful....
We are approaching the end game of software development in almost all arenas except AI and games.
I couldn't disagree more. We may find that we run out of steam with hardware, but as I look around at the software in use I notice that the interfaces are hard to grasp, that work flow is not well supported, that programs don't always interact nicely. Programs still crash far too often. They consume far more memory and processor than they should. Software projects are over budget and late far too often, and by wide margins. Programs fail when presented with unfortunate but all too common badly formed input, or an uncooperative environment.
Then there is this business of demonstrating that programs are robust, and do what the spec says they will -- we still don't do that well at all.
I think we still have lots to learn about software construction. I'll accept that we have reached the endgame when building a program carries the same kinds of risks as getting out of bed in the morning;-)
OK, I'm from old school. I've been at it for 15 years or so, most of that time doing seriously complex programs of the engineering automation sort. McConnell is a nutcase. I have his book on my shelf, and it sucks. He recommends coding styles that only make sense in Redmond.
Remember -- code should follow design. Good code follows a Good Design. Good design handles boundary cases in a normal fashon. Good design is semantically clear. Debugging is a last resort when your code is not working right. Good code behaves in obviously correct ways. Good Designs are self-testing to a large degree.
To sum -- it is *you* who need to learn to design and program, my friend.
A debugger is good for figuring out what your program is doing when it is not doing what you needed it to do. You can't figure out that your code is correct meerly by stepping through it line by line. It is far better, IMHO, to write code that is simple enough to be obviously correct to the extent possible, self testing where reasonable, and with clear intent everywhere else.
If you think that the only way to determine what a program is doing, then you have only the weakest grasp of whatever language you are working with. Ofcourse, there is an exception to that general statement -- I find that exposure to Win32 makes people paranoid about whether code works like they think it should.
However, the types of large-scale programs I write (traffic planning systems, mostly) demand that the code be self testing to a large extent because the data structures are large and complex enough that we have been unable to find effective output/display mechanisms, but we *can* write algorithmic tests that we can trust because they are simple to state, even for complex data.
I say -- debug to dig out info about a misbehaving program, but that is no substitue for clearly written code, and a well thought out design. Do that, and you too will need your debugger less.
IIRC, COBOL was designed by Admiral Grace Murray Hopper. The committe happened later. COBOL did what it was supposed to do -- make computing accessible to business. It just didn't have the grace to die gracefully when the time came.
Difficult is a relative thing. Maybe you mean time consuming, but once you are over that hump....
My father has had to rebuild machine tools several times. He could have paid large sums of money for the parts that needed to be replaced, but the machines in question are 70 years old or so, and the parts are not stocked -- thus special order. Therefore, he made them using the broken tools (!). Actually, he made a series of each part, installed it into the machine under repair, them made a better part, reducing the tolerances and slop each time. At the end of the process the rebuilt machine performed better than the original design.
Clearly the machines were not totally broken, and that helped a lot. But for your example of machine threads, I can imagine making wood threads by hand, and using those to mill out (large ) iron or steel threads, gears, etc. and using those to mill still better parts, ad infinitem. Just like we did to start the process in the industrial revolution. The main difference is that we know what works and where we are going. We could probably skip some steps along the way too.
I imagine that the process with computers would be similar, but we might ditch some of the sillier instruction sets, but who knows?
Pardon me, AC, but I believe you have just demonstrated that you have never worked on a real project of significant size that tried to use CASE tools for any real length of time.
First, CASE is nothing like automatic routing, since the key element of programming is semantics, while the key element of routing is, well, routing.
I have. 100,000 lines of automatically generated crap which bore little resemblance to my actual intent as stated in the CASE model has been a hindrance, not to mention now being saddled with a number of silly idioms which I will be months removing.
You might like an IDE. I don't. I understand my tools. Most of the people I know who like IDE's like them because they don't understand the tools, or even some of the more important aspects of program construction.
It's friday, so -- I'll flame. Advocating CASE and IDE's is a demonstration of your unmitigated ignorance.
If you mean by that that EMACS doesn't have an assembler, au contraire (did I spell that right?;-). EMACS has the only assembler you'll ever need, once you have Emacs installed. It translates elisp into bytecodes.
Now for those of you thinking -- wait, isn't that a compiler? -- remember that the bytecode compiler has a lower level section that you can use as an assembler, which again points out that with LISP you can do anything, and make it look the way you like, as long as you like lists:-).
The site left me a little stunned. Taking some simple phrase and translating it to a hundred lines of dreck and then being able reverse translate is amazing, and just might accomplish the desired goal of forcing the watcher to scan nearly everything, making the needles in the hay stack that much harder to find.
On the other hand: Looks like spam; smells like spam; gets tossed out like spam.... Did you get the message? Not yet -- just 300 spams -- trashed em all. *urk*;-)
I remember seeing another nebula photo with similar characteristics, but which was slightly tilted toward the viewer. It has the same hour-class pinch in the middle, but the main structure was more hour-glass like -- as if it were still a pressure wave, while this one looks more like a burst baloon at the instant just after the puncture.
Baloney. Depending on the complexity of an application, and the cost associated with failure, and the possible causes of that failure, you will require wildly different architectures. Those silly web aps are on one end of the scale, with Air Traffic Control on the other in terms of complexity and potential damage. Not only that, but a web app usually only has to not crash itself, take care of user input (if any) and any web connections it might require. Air Traffic Control has to be concerned with distributed hardware, user interface design, wide area communication, possibly out of date information, possibly wrong information, hardware or communication failures that might or might not be detectable, etc. etc. etc., and if the system responds in the wrong way, people die. You might notice that in the above list, most of the failures were outside the control of the system, but the system is still expected to react gracefully and safely, because the cost of getting it wrong is so high.
Forget pacemakers -- that's easy. Think Air Traffic Control systems -- billions and counting, and it the new one still does not work.
I'll bet there is enough blame to go around, some for the FAA, some for the contractors, some for the managers, some for the programmers.
Indeed, I've been burned so many times by using commercial-off-the-shelf (COTS) stuff professionally, that my first thought these days is to build it myself unless I can get the source, or it is really well known and stable. If I am *forced* use COTS, I write insulation layers so I can replace that junk later on. Even with that level of paranoia, I still get the shaft from time to time with a no-work-around situation.
I think there may be a correlation between how committed a person is and whether their faith is based mostly on their upbringing or mostly on their personal quest for spirituality.
There certainly is such a correlation, and it is well known among those who study intergenerational faith development (or to put it another way -- those who try to figure out "Who grows up to raise children who are christian who grow up to raise children who are christian......?")
The key concept is that at some point (usually during the late-teen/young-adult years), the faith of your parent(s) becomes your faith, or it is simply something you do (your childred will reject it), or it is rejected by you.
I suspect that principle [accepting (with reason) or rejecting (with reason) or just continuing to follow (without any thought) the ideas/beliefs/philosophy of our parents applies to every area of belief, and further that the majority of people (99%?) simply accept what they were taught -- after all -- that is the major lesson of the school system, isn't it?
Those of us who question, have always been feared/abhored, regardless of the conclusions we might draw.
(I too am a conservative Christian, by rearing, then by my own search for truth. It was my fathers faith (to my great fortune) -- now it is *mine* -- tempered, tested, and I'll share it with any who are interested)
As to why compilers abandoned generating C, I can answer that readily. Two things come immediately to mind.
(1) The ability to do source level debugging is nearly completely lost in translation from C++ to C.
(2) It is much easier to optimize code when you are going from a symbolic representation to RTL or some other near-machine-level representation than it is when going from symbolic code to some other symbolic code with uncertain semantics. While the translation is *possible* the results are not elegant, efficient, or readable.
IIRC, fossel fuel power plants are about 40% efficient at turning heat into mechanical energy. There are some fairly hard limits on energy recovery in a thermodynamic cycle of the type used by every internal or external combustion engine. You can see this by examing a carnot cycle diagram for the particular plant, but I don't have one handy.
Fuel cells tend to win big on efficiency measurements because they do not used a thermodynamic cycle, but an electrochemical path instead -- less entropy is introduced that way.
hth
Many jobs available away from the coasts
on
Too Old To Code?
·
· Score: 1
Folks, when you get tired of the pressure in Silicon Valley, come to Pittsburgh, where we can't find enough tallented programmers of any age. The companies here are falling over each other trying to recruit, and the city is a wonderful place to live.
The steel city has completely changed since the mills closed 30 years ago. It is clean and beautiful, and cheap to live in, especially compared to the isane prices in the valley. There has always been a number of quietly successful high-tech start up companies here, and now there are more than ever.
Night life, a world class symphony, parks everywhere... Come on out and find work!
This commercial for Pittsburgh brought to you by a recent new resident;-)
I'm not sure I agree with this. I've been working with cooperative systems lately, and I have been surprized by the speed with which these systems solve problems. It seems that the fact that small adjustments to a proposed solution made by entities with only local information can rapidly improve the solution, provided that many (maybe only 20 or 30) entities suggest different changes, and the effect of the changes can be measured.
The really big surprize is that the quality of the changes does not have to be all that good. The system has much better behaviour than the individual entities would be able to manage alone.
Even if most of the actions (up to 80%) turn out to be useless or even damaging, the over all system state continues to improve. You may not call this intelligence, but the result is still really useful.
Reading the article a little more closely than the poster, It seems that the 15 month interval is when some small devices might be constructed. That's not really a hybrid-nano computer yet.
Still, the possibilities for nano-computing devices are really stunning, and it seems to be just a matter of engineering now. Oh yeah -- there is still some science to work out also;-)
The press release mentioned the term "heat pipe" in passing.
A heat pipe is a really interesting device for transfering heat from one point to another. The way they work is by containing some fluid and vapor at near the vaporization pressure for that fluid. The pipe is sealed permanently -- no chance for a leak unless the device is breached. Usually the pipe is arranged more or less vertically, so that fluid flows to the bottom (where the heat source is), boils (sucking heat out of the heat source in the process), vapor flows up the pipe to the top, where it condenses (releasing heat to the cooler part of the system), and the resulting fluid runs down to collect at the bottom once more, completing the circuit. No moving parts at all. And they are amazingly fast at managing this heat transfer.
\begin(wild speculation)
One wonders if the cooling unit mentioned is really a heat pipe. The problem with this is that a heat pipe needs to have a gravity assist to work correctly. The hot part has to be at the bottom of the pipe. If you could manage this, however, you could cool the CPU for nearly nothing, in terms of additional energy input for fans and the like. and you could easily transfer the heat from the concentrated point on the CPU, to a more dispersed area around the case.
Did I mention the gravity requirement? If the machine were tipped the wrong way, you'd immediately loose your cooling system altogether.
\end(wild speculation)
I have *no* idea if this is correct or not. One cannot trust a press release to get details like this right.
There is considerable difference between shooting a deer and dropping bombs. Bombs destroy everthing in sight, leaving little that is useful later. I hunt -- I like deer meet. I provide food for my family that way. I garden also -- more food. If you must insist on equating animals and humans, then I am a predator. Are wolves to be considered sociopathic for following their nature?
As to the certainty of a kill -- you have clearly never hunted deer or rabbit. Finding the critters and getting a clear shot is not easy. Taking a bad shot is dangerous and a waste of ammunition. If you only wound the animal, you run the risk of being attacked by it, or having it run off to die someplace where you are unable to retrieve the meat from the carcase. I don't know what you would consider a fair fight -- but I'm not interested in a fair fight. I want to feed my family.
I can say nothing about fox hunting or badger baiting -- they don't make good food, AFAIK. I've never hunted whale -- I don't live by the sea. So I will say nothing about those as activities.
Perhaps you would do well to live in the wilderness for a year or so before condemning those of us who live that life. Being faced with a choice between feeding your family, and killing a deer, the choice is easy, if you are human.
I think you need to look much deeper for the roots of what you apparently consider sadistic behaviour. I doubt that any simple measure will reveal those who enjoy hurting other people, which is (IMHO) the root problem anyway.
As I see things, this is precisely the problem with WAVE -- they use these simple indicators.
As to me being an improbable individual -- well I am. I hunt. I garden. I live in the country. I make furniture. I hack computers. Don't make generalizations and expect them to hold everwhere.
Slashdot Mirror
The basic thing is that is not a specific number like or e -- it is really a class of numbers with a particular property -- that of being a random string of binary digits with no internal structure. The procedure the researcher outlined will produce only one such number, not the entire infinite set of such numbers.
I'm reminded of the cantor dusts when reading Chaitins work, and the ubiquity of infinitie classes of numbers in the Continium. But it is not all that surprizing, I think. It answers a deep question -- why does math work the way it does? Because we see what we find useful....
We are approaching the end game of software development in almost all arenas except AI and games.
;-)
I couldn't disagree more. We may find that we run out of steam with hardware, but as I look around at the software in use I notice that the interfaces are hard to grasp, that work flow is not well supported, that programs don't always interact nicely. Programs still crash far too often. They consume far more memory and processor than they should. Software projects are over budget and late far too often, and by wide margins. Programs fail when presented with unfortunate but all too common badly formed input, or an uncooperative environment.
Then there is this business of demonstrating that programs are robust, and do what the spec says they will -- we still don't do that well at all.
I think we still have lots to learn about software construction. I'll accept that we have reached the endgame when building a program carries the same kinds of risks as getting out of bed in the morning
OK, I'm from old school. I've been at it for 15 years or so, most of that time doing seriously complex programs of the engineering automation sort. McConnell is a nutcase. I have his book on my shelf, and it sucks. He recommends coding styles that only make sense in Redmond.
Remember -- code should follow design. Good code follows a Good Design. Good design handles boundary cases in a normal fashon. Good design is semantically clear. Debugging is a last resort when your code is not working right. Good code behaves in obviously correct ways. Good Designs are self-testing to a large degree.
To sum -- it is *you* who need to learn to design and program, my friend.
A debugger is good for figuring out what your program is doing when it is not doing what you needed it to do. You can't figure out that your code is correct meerly by stepping through it line by line. It is far better, IMHO, to write code that is simple enough to be obviously correct to the extent possible, self testing where reasonable, and with clear intent everywhere else.
If you think that the only way to determine what a program is doing, then you have only the weakest grasp of whatever language you are working with. Ofcourse, there is an exception to that general statement -- I find that exposure to Win32 makes people paranoid about whether code works like they think it should.
However, the types of large-scale programs I write (traffic planning systems, mostly) demand that the code be self testing to a large extent because the data structures are large and complex enough that we have been unable to find effective output/display mechanisms, but we *can* write algorithmic tests that we can trust because they are simple to state, even for complex data.
I say -- debug to dig out info about a misbehaving program, but that is no substitue for clearly written code, and a well thought out design. Do that, and you too will need your debugger less.
IIRC, COBOL was designed by Admiral Grace Murray Hopper. The committe happened later. COBOL did what it was supposed to do -- make computing accessible to business. It just didn't have the grace to die gracefully when the time came.
Actually, you can manage some clever control with strictly analog components -- they are just not very flexible, and tuning is a little tedious.
Difficult is a relative thing. Maybe you mean time consuming, but once you are over that hump....
My father has had to rebuild machine tools several times. He could have paid large sums of money for the parts that needed to be replaced, but the machines in question are 70 years old or so, and the parts are not stocked -- thus special order. Therefore, he made them using the broken tools (!). Actually, he made a series of each part, installed it into the machine under repair, them made a better part, reducing the tolerances and slop each time. At the end of the process the rebuilt machine performed better than the original design.
Clearly the machines were not totally broken, and that helped a lot. But for your example of machine threads, I can imagine making wood threads by hand, and using those to mill out (large ) iron or steel threads, gears, etc. and using those to mill still better parts, ad infinitem. Just like we did to start the process in the industrial revolution. The main difference is that we know what works and where we are going. We could probably skip some steps along the way too.
I imagine that the process with computers would be similar, but we might ditch some of the sillier instruction sets, but who knows?
Just different news sources. Must be a slow news day?
The other article is here
Pardon me, AC, but I believe you have just demonstrated that you have never worked on a real project of significant size that tried to use CASE tools for any real length of time.
First, CASE is nothing like automatic routing, since the key element of programming is semantics, while the key element of routing is, well, routing.
I have. 100,000 lines of automatically generated crap which bore little resemblance to my actual intent as stated in the CASE model has been a hindrance, not to mention now being saddled with a number of silly idioms which I will be months removing.
You might like an IDE. I don't. I understand my tools. Most of the people I know who like IDE's like them because they don't understand the tools, or even some of the more important aspects of program construction.
It's friday, so -- I'll flame. Advocating CASE and IDE's is a demonstration of your unmitigated ignorance.
If you mean by that that EMACS doesn't have an assembler, au contraire (did I spell that right? ;-). EMACS has the only assembler you'll ever need, once you have Emacs installed. It translates elisp into bytecodes.
:-).
Now for those of you thinking -- wait, isn't that a compiler? -- remember that the bytecode compiler has a lower level section that you can use as an assembler, which again points out that with LISP you can do anything, and make it look the way you like, as long as you like lists
I *love* EMACS... I love LISP even more.
The site left me a little stunned. Taking some simple phrase and translating it to a hundred lines of dreck and then being able reverse translate is amazing, and just might accomplish the desired goal of forcing the watcher to scan nearly everything, making the needles in the hay stack that much harder to find.
;-)
On the other hand: Looks like spam; smells like spam; gets tossed out like spam.... Did you get the message? Not yet -- just 300 spams -- trashed em all. *urk*
It is a young star called Eta Carinae.
Interesting that a dying star and an apparently new star show a similar shockwave pattern....
{searching the web}
There is a better writeup at STSci. They also mention Eta C.
I remember seeing another nebula photo with similar characteristics, but which was slightly tilted toward the viewer. It has the same hour-class pinch in the middle, but the main structure was more hour-glass like -- as if it were still a pressure wave, while this one looks more like a burst baloon at the instant just after the puncture.
Baloney. Depending on the complexity of an application, and the cost associated with failure, and the possible causes of that failure, you will require wildly different architectures. Those silly web aps are on one end of the scale, with Air Traffic Control on the other in terms of complexity and potential damage. Not only that, but a web app usually only has to not crash itself, take care of user input (if any) and any web connections it might require. Air Traffic Control has to be concerned with distributed hardware, user interface design, wide area communication, possibly out of date information, possibly wrong information, hardware or communication failures that might or might not be detectable, etc. etc. etc., and if the system responds in the wrong way, people die. You might notice that in the above list, most of the failures were outside the control of the system, but the system is still expected to react gracefully and safely, because the cost of getting it wrong is so high.
Forget pacemakers -- that's easy. Think Air Traffic Control systems -- billions and counting, and it the new one still does not work.
I'll bet there is enough blame to go around, some for the FAA, some for the contractors, some for the managers, some for the programmers.
Indeed, I've been burned so many times by using commercial-off-the-shelf (COTS) stuff professionally, that my first thought these days is to build it myself unless I can get the source, or it is really well known and stable. If I am *forced* use COTS, I write insulation layers so I can replace that junk later on. Even with that level of paranoia, I still get the shaft from time to time with a no-work-around situation.
I think there may be a correlation between how committed a person is and whether their faith is based mostly on their upbringing or mostly on their personal quest for spirituality.
There certainly is such a correlation, and it is well known among those who study intergenerational faith development (or to put it another way -- those who try to figure out "Who grows up to raise children who are christian who grow up to raise children who are christian......?")
The key concept is that at some point (usually during the late-teen/young-adult years), the faith of your parent(s) becomes your faith, or it is simply something you do (your childred will reject it), or it is rejected by you.
I suspect that principle [accepting (with reason) or rejecting (with reason) or just continuing to follow (without any thought) the ideas/beliefs/philosophy of our parents applies to every area of belief, and further that the majority of people (99%?) simply accept what they were taught -- after all -- that is the major lesson of the school system, isn't it?
Those of us who question, have always been feared/abhored, regardless of the conclusions we might draw.
(I too am a conservative Christian, by rearing, then by my own search for truth. It was my fathers faith (to my great fortune) -- now it is *mine* -- tempered, tested, and I'll share it with any who are interested)
... and that might represent a net icrease in intelligence (!)
As to why compilers abandoned generating C, I can answer that readily. Two things come immediately to mind.
(1) The ability to do source level debugging is nearly completely lost in translation from C++ to C.
(2) It is much easier to optimize code when you are going from a symbolic representation to RTL or some other near-machine-level representation than it is when going from symbolic code to some other symbolic code with uncertain semantics. While the translation is *possible* the results are not elegant, efficient, or readable.
na -- it should be pronounced see-hash, since it makes a hash of lots of good design ideas... ;-)
IIRC, fossel fuel power plants are about 40% efficient at turning heat into mechanical energy. There are some fairly hard limits on energy recovery in a thermodynamic cycle of the type used by every internal or external combustion engine. You can see this by examing a carnot cycle diagram for the particular plant, but I don't have one handy.
Fuel cells tend to win big on efficiency measurements because they do not used a thermodynamic cycle, but an electrochemical path instead -- less entropy is introduced that way.
hth
Folks, when you get tired of the pressure in Silicon Valley, come to Pittsburgh, where we can't find enough tallented programmers of any age. The companies here are falling over each other trying to recruit, and the city is a wonderful place to live.
;-)
The steel city has completely changed since the mills closed 30 years ago. It is clean and beautiful, and cheap to live in, especially compared to the isane prices in the valley. There has always been a number of quietly successful high-tech start up companies here, and now there are more than ever.
Night life, a world class symphony, parks everywhere... Come on out and find work!
This commercial for Pittsburgh brought to you by a recent new resident
I'm not sure I agree with this. I've been working with cooperative systems lately, and I have been surprized by the speed with which these systems solve problems. It seems that the fact that small adjustments to a proposed solution made by entities with only local information can rapidly improve the solution, provided that many (maybe only 20 or 30) entities suggest different changes, and the effect of the changes can be measured.
The really big surprize is that the quality of the changes does not have to be all that good. The system has much better behaviour than the individual entities would be able to manage alone.
Even if most of the actions (up to 80%) turn out to be useless or even damaging, the over all system state continues to improve. You may not call this intelligence, but the result is still really useful.
Reading the article a little more closely than the poster, It seems that the 15 month interval is when some small devices might be constructed. That's not really a hybrid-nano computer yet.
;-)
Still, the possibilities for nano-computing devices are really stunning, and it seems to be just a matter of engineering now. Oh yeah -- there is still some science to work out also
The press release mentioned the term "heat pipe" in passing.
A heat pipe is a really interesting device for transfering heat from one point to another. The way they work is by containing some fluid and vapor at near the vaporization pressure for that fluid. The pipe is sealed permanently -- no chance for a leak unless the device is breached. Usually the pipe is arranged more or less vertically, so that fluid flows to the bottom (where the heat source is), boils (sucking heat out of the heat source in the process), vapor flows up the pipe to the top, where it condenses (releasing heat to the cooler part of the system), and the resulting fluid runs down to collect at the bottom once more, completing the circuit. No moving parts at all. And they are amazingly fast at managing this heat transfer.
\begin(wild speculation)
One wonders if the cooling unit mentioned is really a heat pipe. The problem with this is that a heat pipe needs to have a gravity assist to work correctly. The hot part has to be at the bottom of the pipe. If you could manage this, however, you could cool the CPU for nearly nothing, in terms of additional energy input for fans and the like. and you could easily transfer the heat from the concentrated point on the CPU, to a more dispersed area around the case.
Did I mention the gravity requirement? If the machine were tipped the wrong way, you'd immediately loose your cooling system altogether.
\end(wild speculation)
I have *no* idea if this is correct or not. One cannot trust a press release to get details like this right.
There is considerable difference between shooting a deer and dropping bombs. Bombs destroy everthing in sight, leaving little that is useful later. I hunt -- I like deer meet. I provide food for my family that way. I garden also -- more food. If you must insist on equating animals and humans, then I am a predator. Are wolves to be considered sociopathic for following their nature?
As to the certainty of a kill -- you have clearly never hunted deer or rabbit. Finding the critters and getting a clear shot is not easy. Taking a bad shot is dangerous and a waste of ammunition. If you only wound the animal, you run the risk of being attacked by it, or having it run off to die someplace where you are unable to retrieve the meat from the carcase. I don't know what you would consider a fair fight -- but I'm not interested in a fair fight. I want to feed my family.
I can say nothing about fox hunting or badger baiting -- they don't make good food, AFAIK. I've never hunted whale -- I don't live by the sea. So I will say nothing about those as activities.
Perhaps you would do well to live in the wilderness for a year or so before condemning those of us who live that life. Being faced with a choice between feeding your family, and killing a deer, the choice is easy, if you are human.
I think you need to look much deeper for the roots of what you apparently consider sadistic behaviour. I doubt that any simple measure will reveal those who enjoy hurting other people, which is (IMHO) the root problem anyway.
As I see things, this is precisely the problem with WAVE -- they use these simple indicators.
As to me being an improbable individual -- well I am. I hunt. I garden. I live in the country. I make furniture. I hack computers. Don't make generalizations and expect them to hold everwhere.