I think it's the other way around: the chips are producing heat constantly and you want that heat to dissipate as quickly as possible, so it's not the right place to put a thermal insulator.
It's the same reason Greece was going bankrupt ... they couldn't print their own currency and run their own fiscal policy after they joined the Eurozone.
If you have a deep stack you can bluff, but your chances of winning aren't high if you don't have the nuts after all. You can only lose so many times before it becomes the martingale strategy.
This especially doesn't work against multiple opponents.
Actually Bash does have some issues with command line arguments if doing variable expansion. For example in Java apps it is actually fairly difficult to pass -DsomeParameter="something with a space in it" if doing variable expansion.
I'm trying to find the exact situation but basically if you have something like:
PROPS="-Dprop1=foo bar -Dprop2=bar foo"
java $PROPS SomeClass.class
You can try to escape with backslashes and what not but it becomes fairly hard if not impossible to expand multiple parameters correctly as a single variable. I believe one solution is to use arrays and another is just not use arguments and instead rely on other configuration mechanisms (env variables, files, etc).
You see this often rear its ugly head with daemon scripts.
(The quotes around `${PROPS[@]}` is important.) Do note, there is an unfortunate edge case here if PROPS is empty, you'll get a false `""` arg passed to java in that case. There's a less pleasant syntax that avoids that issue but I don't recall it off-hand.
(edit: Please read the replies to my post, I didn't think about the fact that this syntax is bash specific. Thanks to those who pointed it out)
Oh I am sure there are ways around it but the big issue is that almost all of the daemon scripts out there do not do it. That is you can't just set some configuration in /etc/default/some_daemon as the script will try to concatenate the command.
I tried to find a failsafe solution once while rewriting a daemon script and just gave up.
Sadly not: only quotes that appeared literally in the command-as-written affect word-splitting or are subject to quote removal, not those resulting from an expansion step (variable substitution, globbing, etc); so you'd end up with four elements in argv (or one if you double-quoted the variable reference), with literal single-quote characters in them. You'd have to do something unpleasant with "eval" to make that work.
It's a sensible rule, when you think about it - otherwise, for example, an expansion that introduced mismatched quotes would cause total chaos.
Yeah, that's the very behaviour I'm talking about - it just happens to be a problem in this particular case: the single-quotes in hk__2's PROPS variable would be passed to the executed command, not interpreted by the shell, but we wanted the latter here.
I think the parent misattributed where the fsckup was. Most probably it wasn't
bash or other shell as it is, it probably was broken /usr/bin/java script
(yes, it used to be a shell script) that looked for Java bytecode interpreter
in various places. As most scripts that come from a big company, its style was
terrible.
Yeah, the word bias seems to be overloaded with many meanings. I actually wonder if there is any philosophical difference between the word "knowledge" and the word "bias".
But about machine learning... a system can learn from a set of outcomes which are the result of a "biased" system, that is to say tainted with an incorrect Bayesian prior which is not properly corrected, such as let's say courts in a racist society or whatever. It would learn the same bias. Because its goal is to maximize compatibility with the outcomes that the humans did. So it perpetuates those weights.
The problem is that we don't know whether the human decisions matched the reality. "Did the person commit the crime" for example. We might have to wait until more unbiased estimators for such activity come along, and throw away old historical data.
It's sort of like when Black-Scholes became a self-fulfilling prophecy for valuing derivatives, but only after it became widespread. The market started using Black-Scholes to value derivatives, so it became the best model to predict the value of derivatives. But until then, other models might have fit the historical data better.
Yeah, the word bias seems to be overloaded with many meanings. I actually wonder if there is any philosophical difference between the word "knowledge" and the word "bias".
If you interpret the word "bias" statistically - rather than the way innumerate reporters trying to sound profound use it - then it's pretty straightforward to do so.
"Knowledge" represents a fixed snapshot of your information about the world.
"Bias" represents a tendency for your knowledge to systematically differ from reality even as more data is gathered.
In programming terms, knowledge is the data in your DB at a fixe dtime. Bias is a tendency for my inserts to fail while yours succeed.
But about machine learning... a system can learn from a set of outcomes which are the result of a "biased" system, that is to say tainted with an incorrect Bayesian prior which is not properly corrected, such as let's say courts in a racist society or whatever. It would learn the same bias. Because its goal is to maximize compatibility with the outcomes that the humans did. So it perpetuates those weights.
If the goal of a system is to predict human behaviors, then it will in fact do that. That's not "bias", that's just building a system with the goal of matching human behavior and getting what you asked for.
However, if the inputs to your algorithm are biased predictors of the output your outputs can still be unbiased. The tendency of machine learning systems is to detect hidden patterns in the data; biased inputs are just another pattern.
I do think it's important for people to be more clear about the goals they have for these systems. Do you want them to be accurate regardless of anything else, or do you want them to accomplish particular social goals by deliberately bending the results? There's nothing necessarily wrong with the latter, though you will inevitably find once you're being clear about the latter that even people who are generally ideologically aligned with each other will discover they have different and mutually conflicting goals...
Anyhow, either way, until you have a clear specification about goals you can't determine whether you're accomplishing them. A vague goal of being "nondiscriminatory" doesn't cut it for computers... "nondiscriminatory" is a set of possibilities, not a unique specification. (And if you disagree about my claim it's a set, just try to sit down with one of the aforementioned ideologically-aligned people and try to hammer it out to a coding level of detail.)
I.e. every algorithm will be "discriminatory" unless you predictor is perfect (i.e. gets 100% of decisions right). It's just a question of which kind of discriminatory they are. The same is true of any human decision process.
Unfortunately this means that we will be subjected to a slew of innumerate reporters posting "XXX is discriminatory" articles, regardless of how decisions are made.
Democracy isn't a failure, you just need a better voting system.
If people could rank their preferences then people like Bernie and Bloomberg would actually run without fear that they might "take away votes from Hillary" and therefore help Trump. In fact, the two-party syste would give way to something better. Only the party elites would NOT want this... but after this election, even they probably do.
