I suspect that the death penalty is different from incarceration however - in that I truly believe it doesn't have much deterrent effect at all.
In areas where you have gang violence and the like - why be scared of execution your chances of being killed is so high to begin with that if anything sitting on death row increases your life expectancy.
For the suburb case there are basically three common motives for murder.
Crimes of passion: by definition these cannot be deterred, a crime of passion is an emotional act done in the moment, it doesn't include any rational thought - if it had, it wouldn't be a crime of passion, so since there is no rational consideration, there is no deterrence for it.
Crimes of insanity: again, a crazy person isn't thinking rationally, since their acts are not rationally considered, no rational consideration can deter them.
Crimes of greed: the guy who murders out of greed did make a rational decision - but he also believes he will get away with it (nobody murders out of greed if he expects to get caught) - so the punishment isn't a deterrent as he strongly expects never to experience it.

It's unlikely the death penalty has any deterrent effect whatsoever. I'm still not sure incarceration does - though like I said in the original post, it obviously reduces your odds of committing the crime again if only by making it impossible for a while.
Comparing crime rates across countries is never a very useful comparison (just look at every gun control debate) as there are simply too many factors (socio-economic, environmental etc.) which influence crime rates but are not being factored in for, but a more useful comparison is to look at countries where the death penalty was banned - and see how crime rates before and after compared.
The answer in every country I know about is - immediately before and after they were the same, over the longer term crime rates declined, but only by the same rate they were declining before.
So the conclusion appears to be that banning the death penalty had no impact whatsoever on crime rates anywhere it's been done.

Interestingly - here in South Africa the death penalty was banned in 1994. At the time South Africa had the highest crime rate in the world (a murder every 17 seconds). It declined rapidly over the next few years, but this is likely because so much of that crime was political in nature and the politcal environment had changed. Since 2000 there has been a steady decline (while the crime rate is still unacceptably high we are nowhere near the top of the list anymore) - yet calls to reinstate the death penalty remain incredibly popular among the population, one of the few things South Africans of all races actually agree on.
Personally I'm opposed to it, but I find it interesting that it's such a popular concept despite the fact that it very obviously had no impact on crime rates at all - yet it's deterrent effect is the most commonly cited reason for bringing it back. Which proves, I suppose, that what we consider "common sense" will trump facts and evidence every time.

If that is the methodology then indeed it would be the lowest - since they have the longest sentences, and so the the biggest gap where you can't repeat the crime, also that long gap in it must reduce the risk of going back to it (if only because it breaks your networks).

I strongly suspect that if you count "number of times the crime was likely committed before you were caught the first time" that for rape it is near the top - the rate of rapes occurring versus the amount of actual rapists suggest this almost has to be the case.

Murder is interesting as it's usually a very high profile crime with a lot of media attention - so police tend to have a lot of motivation to get the guy, this may reduce the number of times you can get away with it before you are caught. But even then it varies by who the victim is.
The likelihood of getting away with killing a white girl is simply much lower than if you kill a black man - society just cares less in the latter case, and so the police does as well.

Well he said "or" not "xor" so that's okay.

Actually that conclusion doesn't follow even if you accept the premise. Most severe crimes are committed by repeat offenders who commit them many times - over and over.

So even if you accept the premise that prison has no deterent effect (a premise not entirely without merit I guess) it still doesn't follow that without a justice system crime rates would be unchanged - simply because it doesn't account for the crimes not committed while serving your sentence.

Yep, guys like him should really try lying under oath in a court and then claiming "Freedom of speech" as a defence against the resulting perjury charges...

But that still leaves the most important question unanswered.

Is it legal to shout "Theater" in a crowded firehouse ?

I mentioned the +/- zero thing in another comment elsewhere in this tree, actually! So we're all on board there.

It's not really that signless infinity is a contender for 'consensus' inasmuch as number systems which use signless infinity have utilities different from systems that have signed infinities, just like integer math continues to exist despite the 'improvements' of fractions and decimals.

So much this.

It's such a small change but it totally screws up a flow we've had forever and which made perfect sense. Read title, read summary, read number of comments, click to read said comments. Now it's, read title, read summary, look to upper right to see number of comments, then move mouse back to title to read them (I'm sure I'm not the only one who moves the mouse along as I read).

And yeah, the weird floating videobytes thing.. that's gotta go.

Same reply: Python is not fully functional, and so list constructors like that cannot be counted upon to work elegantly in all situations. This is a completely normal thing common to basically every imperative language, and it's just something you have to accept—and write a special-purpose function for.

I think that just means you're a zealot of functional programming; your expectations are wrong. If the language isn't fully functional in nature, don't expect key patterns like map() to work elegantly. They're hacks at best and not really part of the core language design; this is excellent proof of that.

You're just validating your own arbitrary decision to use that integer set. IEEE 754 defines positive and negative infinity separately. (However, if you look at the other comments below this one, you'll see that I argued for exactly this, reassigning the largest negative value to NaN in a signed integer format—but only for select situations.)

A vector is... really not an applicable answer, as fun as vectors are! We're only working with one dimension here.

I wasn't thinking of the highest bit, just the highest value. As I'm guessing you already know, because of the nature of two's complement there's an asymmetry in positive and negative numbers (2^15 - 1 positive values, 2^15 negative values, and zero) resulting in one value that could easily be discarded; assigning this single value to an error would have an additional benefit of catching counter overflow. Certain older computers like UNIVACs actually used another system called one's complement, where the most significant bit was a negative sign, and numbers otherwise counted up from zero—this had the odd result of leaving a "negative zero" in the numbering system (which IEEE floating point numbers also have); this could also have been reassigned to NaN.

Yes, I agree that try/catch blocks are annoying from the perspective of people writing elaborate flat code—but they do force the programmer to actually handle errors instead of letting them propagate. In certain contexts this is vitally important. A programming language that permits NaNs is essentially making the decision that the division's failure is Not A Problem by default, which is a key point of contention: are we developing for a safety-critical application where a failure to test properly could have dire consequences? What if someone forgets to check for NaN values in the speed control system in an automobile? Is that better or worse than the program aborting entirely? (Almost certainly worse, as it's more likely there would be management code for catching and fixing that!)

So I would argue that, say, MATLAB or Lisp should support NaNs, but definitely not Ada, and I guess now I'm unsure about the C languages again.

Yes, exactly like how the number 1 is simultaneously true and false due to the ambiguous nature of your local pizzeria's ingredients, which may or may not include pepperoni.

It was a big story on Slashdot years ago. A similar cascade of discussions resulted. Let's think for a moment.

If you don't want to code to prevent a division by zero error in any situation where NaN isn't handled elegantly, you have an easy alternative, which is a try/catch structure. Adding NaN is basically just a magic error value, like -1 being returned on failure for C functions (example: failing to find a substring returns -1 as the index in many languages.) This practice is considered Generally Bad And Inadvisable by structured programming dogmatists, as it encodes control information inside of a content signal and potentially obfuscates the meaning of the program (and, in languages like Python, where negative indices have meaning, it can cause lots of subsequent problems.)

To keep things consistent, I would argue that NaN doesn't have a place in modern high-level languages that subscribe to structured programming paradigms; a division by zero is an error that occurs when data is improperly initialized or collected, and letting errors like this (a) propagate by ruining subsequent expressions and (b) potentially get displayed to the user is the vice of a PHP programmer who would rather just be told his or her code works rather than know if it was actually doing what was intended.

On the other side of things, I do actually agree with you and would propose that signed integer formats should reserve 0x8000000 (whatever the negative maximum value is, that one extra number you can't fit into the positive side anyway due to the asymmetry of two's complement) for NaN, because exception-handling invariably means unnecessary stack frame manipulation when used in C++, and programmers in low-level languages like the C family should have an alternative, just like they do with string search functions.