Are they using some kind of giant land-snails as intra-office couriers?
Seriously, the delay must be due to the time the folders spend sitting untouched in a filing cabinet or on someone's desk, not in transit. They could just as easily store digital information, unprocessed, on a server or desktop computer for the same amount of time.
Most likely they will blame all problems on lack of computerization, then spend $100 million on a new computer system (which will be obsolete by the time it is complete) and 10 years later the real problems still won't be fixed.
I'm too lazy to do the math so I ran a simulation instead.
With groups of size 8000, if the vaccine is ineffective, and if the probability of a subject becoming infected is (51+74)/2/8000=0.0078125, then the probability of getting >=23 FEWER infections in the vaccine group is around 2%. I suspect this is low enough for a drug trial to be generally considered a success, but yes it could certainly happen by chance. It's not a proof, it's a trial.
MTRand rng(1);
unsigned count = 0;
double prob = 0.0078125;
for(unsigned itr=0; itr<100000; itr++){ int c1 = 0; int c2 = 0;
I see the motivation (prevent buffer overflow exploit when programmer lazily uses a fixed-size buffer and doesn't check if the data is too big). But it will probably actually CAUSE bugs. More parameters = more confusion, more risk of mixing the parameters up and getting them wrong. The new parameter (destination size) does not add any functionality, yet if you get it wrong it will break your code. I guess the hope is that those bugs will be caught by QA, whereas buffer overflows might not (because overflow won't occur during normal use).
Documentation for memcpy_s is rather confusing (naming of parameters is weird) increasing risk that a novice programmer will mess things up.
Slashdot Mirror
Are they using some kind of giant land-snails as intra-office couriers?
Seriously, the delay must be due to the time the folders spend sitting untouched in a filing cabinet or on someone's desk, not in transit. They could just as easily store digital information, unprocessed, on a server or desktop computer for the same amount of time.
Most likely they will blame all problems on lack of computerization, then spend $100 million on a new computer system (which will be obsolete by the time it is complete) and 10 years later the real problems still won't be fixed.
iGuessIJustLikeMakingLists:
iSmudge
iCanHas?
(EvaCan)iStabLiveEvilBatsInACave?
iWentToDubaiAndAllIGotMyWivesWereTheseLousyNetTablets
iMightBuyOneIfItWereSlightlyCheaperAndHadTheWordsDONTPANIC InscribedInLargeFriendlyLettersOnItsCover
iSomehowThoughtTheFutureWouldBeCoolerThanThis
iScry
iPon
iBigger
iViddy
iDiddy
iWantOne
iCantBelieveItsNotActuallyUsefulForAnything
iDroppedItLikeTwoDaysAfterIBoughtIt
iThinkItLooksGreatOnMyCoffeeTable
iBoughtANewCoffeeTableJustForIt
Close enough?
Yes, this is very much standard practice in the industry. That's why big tech companies file so many patents -- ammunition in case they need it.
Unfortunately it doesn't work against patent trolls because they have no product to sell.
I'm too lazy to do the math so I ran a simulation instead.
With groups of size 8000, if the vaccine is ineffective, and if the probability of a subject becoming infected is (51+74)/2/8000=0.0078125, then the probability of getting >=23 FEWER infections in the vaccine group is around 2%. I suspect this is low enough for a drug trial to be generally considered a success, but yes it could certainly happen by chance. It's not a proof, it's a trial.
MTRand rng(1);
unsigned count = 0;
double prob = 0.0078125;
for(unsigned itr=0; itr<100000; itr++){
int c1 = 0;
int c2 = 0;
for(unsigned i=0; i<8000; i++){
if(rng.rand()<prob){
c1++;
}
if(rng.rand()<prob){
c2++;
}
}
if(c1-c2>=23){
count++;
}
}
printf("count: %u = %.6f\n", count, (double)count/100000);
That was my first thought...but maybe they are looking for signs that the space between us and the pulsar has been distorted.
I meant the Wikipedia article that I linked to :)
http://en.wikipedia.org/wiki/Bucket-wheel_excavator
I think they're moving it from one mine to another, as described in the above article.
I see the motivation (prevent buffer overflow exploit when programmer lazily uses a fixed-size buffer and doesn't check if the data is too big). But it will probably actually CAUSE bugs. More parameters = more confusion, more risk of mixing the parameters up and getting them wrong. The new parameter (destination size) does not add any functionality, yet if you get it wrong it will break your code. I guess the hope is that those bugs will be caught by QA, whereas buffer overflows might not (because overflow won't occur during normal use).
Documentation for memcpy_s is rather confusing (naming of parameters is weird) increasing risk that a novice programmer will mess things up.
So look there first.
No hope for test subjects who over-identify with Weighted Companion Cube.