From what I've heard (and a quick DDG search confirms this) the switch was actually to get away from the fact that killing oneself has actually been a crime (that one "committed") in the past.
I guarantee you that most of those actually affected by suicide care far more about the passivization of their loved one's final act than a tortured etymological concern.
That's ~900 Gal/Day which sounds pretty high for 1 or 2 households but I suppose if they are large and have large lawns or something it could be reasonable. I would naively think it is closer to 5 to 10 households.
The programs for spending the money are slated to last as little as a single year, while the taxes to balance the spending are expected to do so over 10 years. It absolutely is inflationary, particularly if any of these shorter than 10 year programs get extended without new taxes to pay for them.
> The programs for spending the money are slated to last as little as a single year
What does this mean? Are you saying that there exists a program in this package that will take less than a year, or are you saying that all of the programs in this package could be wrapped up within a single year? If the latter, fine. If the former, you're using careful phrasing to be intentionally deceptive, which is not a way to argue with people you're trying to convince.
If there are 10 programs that will all be paid for by 10 years of tax increases and one program’s spending happens all in a year and the others across a range of times, none longer than 10 years, that line of argument is convincing to me that there is short-term spending in excess of taxation married to pay for it, even if no programs overrun their budget or get extended without new taxes to cover the extension.
Yes, the former. For instance, the Expanded Child Tax Credit, is extended for 1 year at a estimated cost of $190M if this were expanded to the 10 years the bill is supposed to be payed for, it would be larger than the entire bill is supposed to be.
I disagree with your case, this is clearly an error because it should never get to dividing by 0.
You MUST validate user input and user input validation failures are a class of errors not exceptions.
For example look at java (which uses the opposite terminology but exact same concept). Checked exceptions are expected state that should be handled gracefully, unchecked exceptions and errors are unexpected and the handling of them is generally let someone know what happened and exit quickly.
> I disagree with your case, this is clearly an error because it should never get to dividing by 0. You MUST validate user input and user input validation failures are a class of errors not exceptions.
This is bizarre: it sounds like you're disagreeing with me, by agreeing with me (that this is an error, not an exception)! For the confused (myself included), please realize that lost953's argument is considered "begging the question" (a logical fallacy [1]): You're using your a-priori assumption that 'divide by zero' is an exception, to argue that what we really should be doing here is add an if-guard before the "actual divide" occurs, so we can return an error, instead of an exception!
Otherwise, thank you for conceding that exceptions are just a category of error :)
No you misread my refutation, I make no claims of the errorness or exceptionness of dividing by 0, merely that your proposed example doesn't support your claim that it depends on the nature of the application. I claim that unchecked user input falls into the category of 'error' and that clearly is what has occurred in your proposed example.
I understand them to be saying that if execution is supposed to be halted before the division occurs, then whether the division is an exception or an error is a moot point.
I think the point the GP is making is that your calculator might have a function like like
calc_div(num: Number, den: Number) -> (Error | Number):
if den == 0:
return Error("division by zero")
else
return num / den
Now this function pre-validates the data. But it might be used as part of a much larger system. Should that system be programmed to know that `den` should always be non-zero and pre-pre-validate accordingly? Or else should it leave "calc_div" to be the expert on the rules for division?
If you take the latter approach, then the caller has to have a way of accepting the error gracefully, as a normal thing that might happen. And thus we have a div0 that is an error rather than an exception.
Ah, but floating-point math is such fun! Here is how it might work...
den is a tiny non-zero value in an 80-bit register. It gets spilled to a 64-bit slot on the stack, rounding it to zero, while another copy of it remains in an 80-bit register. The 80-bit version is compared against zero, and is non-zero. The 64-bit version, which is zero, gets used for the division.
It is fully standards-compliant for a C compiler to do this. Some languages may specify otherwise, but often the behavior is unspecified or is implicitly the same as C.
For many use cases, it a bad idea for a calculator program to use floating point, rather some more exact representation.
However if you do use floating point, then the kind of dangers you point out make my point even stronger. You could conceivably embed the `calc_div` function in a larger system that knew about pre-validating for div0. But if you want to deal with all possible sources of FP weirdness when doing division, then you really need to concentrate it in the "division expert": i.e. have calc_div pre validate all that stuff, and have its caller accept that errors are a normal result.
“Divide by zero” is an exception in the math library. But a GUI calculator shouldn’t pass all input to the math library without parsing it first, and figuring out what the user wants and if the user has entered a valid statement.
One guideline I follow for choosing between error codes and exceptions is “can the immediate caller do anything about this issue?” Even if the calculator does feed user input directly into the math library, the calculator can’t do anything sensible with an invalid statement. The calculator will have to “go up a level” and ask the user for help.
Disagree with validating that sort of input in code you (the non-framework/BCL author) write; let the operators, functions, etc., do their own work of deciding if their operands are acceptable. Otherwise, where does it end--do you pre-test two integers to verify their product won't overflow the type declared for their product? I think you gotta let the exception happen.
Silk Road has been gone for a long time. At this point I would guess that 75% of the volume of BTC movement is from speculators. That's probably conservative.
As far as I can tell this is mostly the EFF being sore losers over the DRM issue. They only joined W3C so they could oppose it, now they are leaving since they failed. While I'm neither here nor there on the DRM issue, the EFF leaving isn't exactly the big deal they are making it out to be.
The only issue with that is there are a few groups that have consistently beat the market over time, so perhaps its more pseudorandom than we think. One example might be the Renaissance Medallion Fund.
I think people who actually can beat the market fall into the general category of "knows something others don't". Renaissance probably is one of the very few firms that could qualify as that on purely technocratic means (instead of the usual, which is shades of grey in what's really insider trading). The other category would be simply HFT, but I'm not sure how profitable that is at this point, though.
Most of the people who seem to beat the market, though, are generally just happy benefactors of survival bias (eg. the 10000 monkeys on typewrites effect)
The bar in civil cases is preponderance of the evidence, of which Google has plenty and Uber / Levandowski have shown very little. It seems beyond sufficient at this point anyway.
