We test things on dozens of different kinds of animals.
A good biologist is supposed to know if the presence or absence of a reaction is due to the choice of species or not.
If they don't know, then they should be testing on several species before coming to any conclusions about the possible effects on other animals (i.e., us).
Re:Yes, of course they're constraining what we lea
on
Of Mice and Cancer
·
· Score: 1
. So a drug that works for mice might not in humans or perhaps even make it worse, while the wonder-drug that cures all human cancers might be missed completely because it had no effect when they tried it on mice.
I think that's true because they're mice. No need to invoke "inbreeding" as well.
"Moreover, sending information back in time itself violates the 2nd law of thermo."
Can you prove it? I'm trying to for a time, but it seems that it doesn't follow from the postulate of paradox-free time travel.
It's a silly statement. The laws of thermodynamics are based on observation. This observation was impossible at the time.
And given that the only means of generating a signal from neutrinos involves using a city-sized apparatus to fire a bajillion of them at a material and hoping to produce a photon or two from the collision, it seems likely that you're not going to actually violate the systemic version of the laws of thermo doing it.
And time-travel means moving something through time counter to its physical properties. Positrons are naturally equivalent to electrons that are moving backward in time, and vice-versa. At least, the math still works when you treat them that way. But having neutrinos that move faster than light doesn't mean you can take anything else along with it to make that thing move backward in time.
True. They have "eliminated one source of systematic error", but have not, clearly eliminated all of them.
Either they need a model that allows both this and the supernova data to coexist in this universe, or they need to figure out what they screwed up.
(And no, that explanation about GPS satellites moving and skewing the result is bollocks; GPS would not work at all if that sort of skew wasn't accounted for or neutralized. You can detect it by sending sync pulses between the clocks at either end. If they seem in sync with a pulse going one way, they'll be 2X out of sync for a pulse going the other way. Atomic-clock users everywhere would be screaming that GPS timing is bollocks if such a thing were true. Further, GPS satellites don't go in just one direction. They go in six directions. So there's no way to have an isotropic skew, so no way to create this timing error from that.)
Yes, of course they're constraining what we learn.
on
Of Mice and Cancer
·
· Score: 0
They're constraining what we learn to how the fuck are they immune to cancer!
Find out, then tell my doctor, and get me some of that.
The fact that they're even there means you know there's a vulnerability, and you know you don't have a viable way to deal with it, and that your users will, eventually, run into it, probably in a situation where it causes them way more grief than the rest of your code is worth.
Just using NDEBUG to turn them off is passing the buck to the rest of the code to crash cryptically instead of crashing identifiably, so it's even worse.
The "National Debt" might be the biggest number on there, but only in picas.
Harping on our government debt, which is a small fraction of our nation's wealth, ignores the fact that our corporations are sucking all the value out of small businesses and personal hands, even as the balance of payments is draining our total assets into foreign accounts.
And the "unfunded liabilities" number is completely made up. It's not current, and it's not amortized, and it's not even NPV. It's bullshit.
Really? Small caps at 48 V need bleeders? Pretty sure they'll bleed out once the phone goes off-hook and switches from 48 VDC to 6 VDC of the opposite polarity. And it's not like our application is going to be less safe because we omit them.
My code, which sometimes is the difference between life and death, considers all possibilities to be nominal cases, and deals with each equivalence class accordingly.
People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.
"There are no impossible conditions in input." "There are no impossible conditions in input." "There are no impossible conditions in input." "There are no impossible conditions in input."
. . .
Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.
At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.
Slashdot Mirror
Portable, luggable, wearable...ingestible?
Well, okay, but the non-luddites are going to be playing Angry Birds on every flat-panel TV in town without you.
It's actually a very silly complaint.
We test things on dozens of different kinds of animals.
A good biologist is supposed to know if the presence or absence of a reaction is due to the choice of species or not.
If they don't know, then they should be testing on several species before coming to any conclusions about the possible effects on other animals (i.e., us).
Or The New Yorker.
. So a drug that works for mice might not in humans or perhaps even make it worse, while the wonder-drug that cures all human cancers might be missed completely because it had no effect when they tried it on mice.
I think that's true because they're mice. No need to invoke "inbreeding" as well.
Can you prove it? I'm trying to for a time, but it seems that it doesn't follow from the postulate of paradox-free time travel.
It's a silly statement. The laws of thermodynamics are based on observation. This observation was impossible at the time.
And given that the only means of generating a signal from neutrinos involves using a city-sized apparatus to fire a bajillion of them at a material and hoping to produce a photon or two from the collision, it seems likely that you're not going to actually violate the systemic version of the laws of thermo doing it.
And time-travel means moving something through time counter to its physical properties. Positrons are naturally equivalent to electrons that are moving backward in time, and vice-versa. At least, the math still works when you treat them that way. But having neutrinos that move faster than light doesn't mean you can take anything else along with it to make that thing move backward in time.
True. They have "eliminated one source of systematic error", but have not, clearly eliminated all of them.
Either they need a model that allows both this and the supernova data to coexist in this universe, or they need to figure out what they screwed up.
(And no, that explanation about GPS satellites moving and skewing the result is bollocks; GPS would not work at all if that sort of skew wasn't accounted for or neutralized. You can detect it by sending sync pulses between the clocks at either end. If they seem in sync with a pulse going one way, they'll be 2X out of sync for a pulse going the other way. Atomic-clock users everywhere would be screaming that GPS timing is bollocks if such a thing were true. Further, GPS satellites don't go in just one direction. They go in six directions. So there's no way to have an isotropic skew, so no way to create this timing error from that.)
They're constraining what we learn to how the fuck are they immune to cancer!
Find out, then tell my doctor, and get me some of that.
Take a 5-gram balloon.
Blow it up to 6 liters.
Now it's 0.83 mg/cm^3.
How hard is that?
All they proved is that the simple statistical model is inadequate to describe why spooky-action-at-a-distance is not more commonplace.
The fact that they're even there means you know there's a vulnerability, and you know you don't have a viable way to deal with it, and that your users will, eventually, run into it, probably in a situation where it causes them way more grief than the rest of your code is worth.
Just using NDEBUG to turn them off is passing the buck to the rest of the code to crash cryptically instead of crashing identifiably, so it's even worse.
You might want to check the rest of our balance sheet.
http://www.usdebtclock.org/
The "National Debt" might be the biggest number on there, but only in picas.
Harping on our government debt, which is a small fraction of our nation's wealth, ignores the fact that our corporations are sucking all the value out of small businesses and personal hands, even as the balance of payments is draining our total assets into foreign accounts.
And the "unfunded liabilities" number is completely made up. It's not current, and it's not amortized, and it's not even NPV. It's bullshit.
Really? Small caps at 48 V need bleeders? Pretty sure they'll bleed out once the phone goes off-hook and switches from 48 VDC to 6 VDC of the opposite polarity. And it's not like our application is going to be less safe because we omit them.
I believe these people will become acquainted with the concept of a Title Search before they're done suing.
or U. S. Robotics doing...not so much...
Wire your big toes to either side of the phone line, and disconnect the phone's bell.
That sucker pumps 90 volts AC to ring your handset.
To stop the on-hook 48 VDC from giving you the crawlies, put a small capacitor in series with each lead.
Or typing them into PCs or pads...maybe...
Just how are the EU going to enforce that, when they don't have any money?
>exceptions you haven't prepared for
there's your problem right there.
when you go through your code and you see an assert, or something that does the same thing, you're not done coding.
My code, which sometimes is the difference between life and death, considers all possibilities to be nominal cases, and deals with each equivalence class accordingly.
People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.
So you're releasing your debug version of the code as a product? Nice.
Repeat after me:
"There are no impossible conditions in input."
"There are no impossible conditions in input."
"There are no impossible conditions in input."
"There are no impossible conditions in input."
. . .
In this case, it's a simple as not using an assert, particularly as an input validator...
Seriously, are they fucking kidding with that? Do they also hardcode backdoor passwords?
Grep all your code for assert, and, if they aren't wrapped in #ifdef DEBUG or something similar, replace them with something useful.
The assertion is a problem.
Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.
At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.
He had to leave those words out because he left so many useless ones in.
Seriously, this could have been a one-liner and a link.