If the user overclocks their GPU and it ends up overheating and breaking down isn't the responsibility for that on the user's shoulders? Why does NVidia care so much?
Normally, yes. But if the driver has explicit support for it, not so much. Basically nVidia is washing their hands of legal responsibility for you breaking your laptop.
Right, the whole story came across as "I'm amazing, but for some reason interviewers keep turning me down after finding gaps in my knowledge, shouldn't they just overlook the gaps in my knowledge and see me for how amazing I really am?"
1) You missed out the "transmission" losses for the fuel (it takes roughly 1.2 gallons of fuel on average to transport 5 gallons of fuel to the petrol station) 2) You missed out the transmission losses for a mechanical car (around 30% of your energy is lost in the gearbox/diff/...) 3) EVs are actually about 90% efficient, not 40%. 4) Power plants are roughly 50-60% efficient even if you assume you use fossil fuels to generate the power.
What this adds up to: Fuel powered car = 80% (fuel tanker efficiency) * 26% (engine efficiency) * 70% (transmission efficiency) = roughly 15% efficient total system (ignoring the amount of energy it takes to dig up the fuel and carry it to shore) Electrically powered car = 60% (power plant efficiency) * 94% (power grid efficiency) * 85% (charging efficiency) * 90% (engine efficiency) = roughly 43% efficient total system.
Add to that that you hypothetically in the future can then replace the fossil fuel burning power plant with a {nuclear | wind | solar |... } one, and you get a rather huge win. You're literally using one third the power to drive your vehicle.
This is pretty much how it works in most of Europe, but America is deathly afraid of the government having databases, even of information that they themselves give to you.
"I'm sorry officer, I'd rather not let my phone out of my possession, could you go grab the spare battery from your car, or get another officer to come and join you please."
So... don't implement the system this way. Why are you guys all so unimaginative in its implementation?
Here's an alternative implementation.
"Hello, officer" "ID please." [holds up NFC scanner.] "here" [holds phone to NFC scanner, sees the drivers license and insurance card pop up on screen, puts finger on home button to authorise transfer of information] "thanks"
The cop now has a unique id for your drivers license and insurance card that he can look up in the DMV and insurer's databases, and you have your phone in hand, still locked.
What do you mean "there is no way for the policeman to scan the QR code while the phone is in your possession in you car."
This system hasn't been implemented yet, that means that the cops don't have the necessary hardware... yet. The necessary hardware is a hand held NFC terminal or QR code scanner. He walks up to your window, taps on it, says license and registration. You hold up your phone, he holds up the scanner, you put your thumb on your phone's fingerprint scanner, the information transfers.
If you had read the article at all, you would understand that "hand them my phone" is not a step in this process. Showing them a barcode, or holding your phone up to an NFC reader is.
Because often, this code is a lot more complex, involves loops, chunks of other simple statements in between etc. In general, the thing inside the "if (success)" can be substantially more complex, and end up needing nesting anyway.
What you're saying is "I'm afraid of the word goto, so you should write code with the exact same semantics as the goto based code, but with different words that imply different semantics".
I mean really, this code is just using goto, but renaming it do/while/break. It's not actually using the do/while abstraction for what it's for, it's simply abusing it to make goto.
In the mean time, others have already addressed why this is less convenient than the goto pattern for error handling, so I don't really buy this as a reason not to use goto in the structured "I'm simulating the error monad" case.
Which is exactly what this paper addresses. It turns out that the *actual* uses of goto in real world C code involve cases where it's immediately obvious where you're going to, like error handling code that just does a goto cleanup.
Okay then oh wise one. Explain to me why brackets, indentation and control flow is good in the above example? Why is the CHK control flow structure (one that effectively mirrors what the error monad does, but is a little lower level due to C) less a valid control flow structure than the nested ifs?
The reasoning behind not having multiple return statements is the exact same reasoning behind not using goto, so you're basically solving nothing here.
Also, the example given is a poor one, it has only one place where an error can be generated (which is not the case you should address with goto, instead, the case where you have lots of steps, each of which could fail is), plus, it doesn't have any real cleanup work to do (e.g. it's entirely reasonable to expect that you may need to deallocate buffers you were working with etc when you fail).
The problem is that the above is a remarkably simple case. The reality for a lot of cases where goto gets used for error handling is that with the above what you would end up writing is:
bool success = doSomethingThatMightFail(); if (success) {
success = doSomethingElseThatMightFail();
if (success) {
success = doMoreFailingStuff();
if (success) {
success = yepMoreFailingStuff();
if (success) {...
}
}
} } if (!success) {
cleanupWork }
Meanwhile with a reasonably constructed macro to wrap his pattern, you end up with: bool success = true; CHK(doSomethingThatMightFail()); CHK(doSomethingElseThatMightfail()); CHK(doMoreFailingStuff()); CHK(yepMoreFailingStuff());
end: if (!success) {
cleanupWork }
That's much easier to read, and just as safe.
Don't get me wrong, in a language where you can use exceptions for this, or better yet, the error monad, you should absolutely use those more abstracted concepts, but in plain C, this really is the best approach to handling errors in code where everything you do could go wrong.
I'm intrigued, what do you think the "correct way" to do error handling in code where you have a whole sequence of actions where each can fail is? You have no exceptions, and you have no error monad, or good way to implement it either. Do you propose that you simply copy/paste the error handling and cleanup code everywhere?
What's the "right way" to do this in C that everyone else is missing?
Because part of our success in the grand evolution game is that we're intelligent, and can learn from each other. By continuing to do that, you're not "stopping evolution", only reinforcing that we're good at surviving and breeding because we can educate each other.
Slashdot Mirror
If the user overclocks their GPU and it ends up overheating and breaking down isn't the responsibility for that on the user's shoulders? Why does NVidia care so much?
Normally, yes. But if the driver has explicit support for it, not so much. Basically nVidia is washing their hands of legal responsibility for you breaking your laptop.
Right, the whole story came across as "I'm amazing, but for some reason interviewers keep turning me down after finding gaps in my knowledge, shouldn't they just overlook the gaps in my knowledge and see me for how amazing I really am?"
1) You missed out the "transmission" losses for the fuel (it takes roughly 1.2 gallons of fuel on average to transport 5 gallons of fuel to the petrol station)
2) You missed out the transmission losses for a mechanical car (around 30% of your energy is lost in the gearbox/diff/...)
3) EVs are actually about 90% efficient, not 40%.
4) Power plants are roughly 50-60% efficient even if you assume you use fossil fuels to generate the power.
What this adds up to:
Fuel powered car = 80% (fuel tanker efficiency) * 26% (engine efficiency) * 70% (transmission efficiency) = roughly 15% efficient total system (ignoring the amount of energy it takes to dig up the fuel and carry it to shore)
Electrically powered car = 60% (power plant efficiency) * 94% (power grid efficiency) * 85% (charging efficiency) * 90% (engine efficiency) = roughly 43% efficient total system.
Add to that that you hypothetically in the future can then replace the fossil fuel burning power plant with a {nuclear | wind | solar | ... } one, and you get a rather huge win. You're literally using one third the power to drive your vehicle.
Right, because "zomg, we can't build cars fast enough" is such a horrible problem for him to have.
Oh god oh god, please don't do that. Not indenting the inner loop here is horrifically unreadable.
Right, because no one has ever stolen bitcoin by hacking into a computer and emptying accounts... oh wait...
This is pretty much how it works in most of Europe, but America is deathly afraid of the government having databases, even of information that they themselves give to you.
I'm going to file a police complaints report, and sue the cop for stealing my property without due cause.
"I'm sorry officer, I'd rather not let my phone out of my possession, could you go grab the spare battery from your car, or get another officer to come and join you please."
"I'm sorry officer, I'd rather not let it out of my possession, could you go grab a scanner that works instead please?"
So... don't implement the system this way. Why are you guys all so unimaginative in its implementation?
Here's an alternative implementation.
"Hello, officer"
"ID please." [holds up NFC scanner.]
"here" [holds phone to NFC scanner, sees the drivers license and insurance card pop up on screen, puts finger on home button to authorise transfer of information]
"thanks"
The cop now has a unique id for your drivers license and insurance card that he can look up in the DMV and insurer's databases, and you have your phone in hand, still locked.
What do you mean "there is no way for the policeman to scan the QR code while the phone is in your possession in you car."
This system hasn't been implemented yet, that means that the cops don't have the necessary hardware... yet. The necessary hardware is a hand held NFC terminal or QR code scanner. He walks up to your window, taps on it, says license and registration. You hold up your phone, he holds up the scanner, you put your thumb on your phone's fingerprint scanner, the information transfers.
If you had read the article at all, you would understand that "hand them my phone" is not a step in this process. Showing them a barcode, or holding your phone up to an NFC reader is.
Because often, this code is a lot more complex, involves loops, chunks of other simple statements in between etc. In general, the thing inside the "if (success)" can be substantially more complex, and end up needing nesting anyway.
What you're saying is "I'm afraid of the word goto, so you should write code with the exact same semantics as the goto based code, but with different words that imply different semantics".
I mean really, this code is just using goto, but renaming it do/while/break. It's not actually using the do/while abstraction for what it's for, it's simply abusing it to make goto.
In the mean time, others have already addressed why this is less convenient than the goto pattern for error handling, so I don't really buy this as a reason not to use goto in the structured "I'm simulating the error monad" case.
Which is exactly what this paper addresses. It turns out that the *actual* uses of goto in real world C code involve cases where it's immediately obvious where you're going to, like error handling code that just does a goto cleanup.
Okay then oh wise one. Explain to me why brackets, indentation and control flow is good in the above example? Why is the CHK control flow structure (one that effectively mirrors what the error monad does, but is a little lower level due to C) less a valid control flow structure than the nested ifs?
Because then when one thing fails, the following things still execute, but now in a bogus state.
The reasoning behind not having multiple return statements is the exact same reasoning behind not using goto, so you're basically solving nothing here.
Also, the example given is a poor one, it has only one place where an error can be generated (which is not the case you should address with goto, instead, the case where you have lots of steps, each of which could fail is), plus, it doesn't have any real cleanup work to do (e.g. it's entirely reasonable to expect that you may need to deallocate buffers you were working with etc when you fail).
The problem is that the above is a remarkably simple case. The reality for a lot of cases where goto gets used for error handling is that with the above what you would end up writing is:
bool success = doSomethingThatMightFail(); ...
if (success) {
success = doSomethingElseThatMightFail();
if (success) {
success = doMoreFailingStuff();
if (success) {
success = yepMoreFailingStuff();
if (success) {
}
}
}
}
if (!success) {
cleanupWork
}
Meanwhile with a reasonably constructed macro to wrap his pattern, you end up with:
bool success = true;
CHK(doSomethingThatMightFail());
CHK(doSomethingElseThatMightfail());
CHK(doMoreFailingStuff());
CHK(yepMoreFailingStuff());
end:
if (!success) {
cleanupWork
}
That's much easier to read, and just as safe.
Don't get me wrong, in a language where you can use exceptions for this, or better yet, the error monad, you should absolutely use those more abstracted concepts, but in plain C, this really is the best approach to handling errors in code where everything you do could go wrong.
I'm intrigued, what do you think the "correct way" to do error handling in code where you have a whole sequence of actions where each can fail is? You have no exceptions, and you have no error monad, or good way to implement it either. Do you propose that you simply copy/paste the error handling and cleanup code everywhere?
What's the "right way" to do this in C that everyone else is missing?
Because part of our success in the grand evolution game is that we're intelligent, and can learn from each other. By continuing to do that, you're not "stopping evolution", only reinforcing that we're good at surviving and breeding because we can educate each other.
No need for a different name, just you americans need to learn to pronounce pedofile - it's pee doh file. A ped oh file is someone who loves walking.
That's easy - dehydrate it, then burn it.
Milk has a huge amount of lactose in it - i.e. sugar, i.e. carbs.