A sphere can still have a flat spot, can't it? Slice a sphere with a plane just inside its radius, and the intersection will be perfectly flat. I don't know much about Kansas, but your logic certainly seems flawed.

I wasn't talking about Duff's device anymore, just the general normal usage of switch statements and the fact that they fall through by default, instead of the more logical opposite choice of breaking by default and continuing only by choice with an explicit instruction. Someone replied that falling through was useful if a whole list of values needed the same treatment, but I think it would have been better to have a standard where a list of values (and possibly ranges) could be provided rather than a silly list of "case x:case y:case z:".

Obviously, if you wanted to use Duff's device with such a modified switch syntax, every case label would need a "continue" to fall through explicitly.

OK, I'll amend my position slightly: they should break by default (and continue as an explicit option) but you should obviously be able to provide a list of values instead of the ridiculous 50 consecutive "case 5:case 6: case 7:...". Better still, they might add ranges while they're at it.

Oh well, I don't imagine them changing the standard for that any time soon, but one can dream...

Any decent compiler makes those changes automatically. Probably even with optimisations switched off, since these are such a no-brainer.

They really ought to have done it the other way around: break by default, and use "continue" to fall through. It can indeed be useful sometimes, but in the vast majority of cases you want it to break, and forgetting that statement causes all sorts of trouble.

They probably chose "ugly hack" because they couldn't figure out how to write a regexp that matched "hack" but didn't match "whack", "shack" etc.

Next up, a new study detailing how many puppies are killed by different programming languages, based on the comments in the code.

I remember something similar, called Duff's device. Not two overlapping switch statements (I don't think that's possible), but an intertwined loop and switch. I don't see any references to lines in bitmaps, but it's entirely possibe that the same kind of construction was used for that purpose too.

send(to, from, count)
register short *to, *from;
register count;
{
        register n = (count + 7) / 8;
        switch (count % 8) {
        case 0: do { *to = *from++;
        case 7: *to = *from++;
        case 6: *to = *from++;
        case 5: *to = *from++;
        case 4: *to = *from++;
        case 3: *to = *from++;
        case 2: *to = *from++;
        case 1: *to = *from++;
                        } while (--n > 0);
        }
}

And then your company upgrades its CPUs while you're long gone, and now they need to figure out who the hell wrote that crappy piece of code that keeps crashing on the new CPU, and some other programmer has to rewrite everything from scratch because they can't figure out how your code works and why it's not doing what it's supposed to be doing.

By the way, that other programmer may just be an older version of you who has completely forgotten what the younger version did there... (not that I have any experience with that, cough)

Tell that to people in the US who had their cash, car or even house seized because it might be connected to a crime. Traveling with $10000 cash? Surely that must be drug money, no matter how plausible your excuse is, we'll take it to buy game consoles, zambonis or margarita machines. You can always try to get it back by hiring a lawyer and going to court, good luck.

So you enter someone's name and date of birth on this website, and it gives you all the details? How exactly is this a hack? If I asked the president of the US for the nuclear launch codes, just for laughs, and to my great surprise he would simply give them to me, would I have "hacked" the US nuclear missile system? Would I be thrown in jail for hacking?

This is just plain irresponsible behaviour by PillPack, nothing to do with hacking.

I was just offering an alternative explanation as a possibility, not taking sides. When I use one part of the article to cast doubt on another part, that doesn't mean that I believe one part or the other. I just like to point out other possibilities when people jump to conclusions based on very scant information. Spectacular headlines often turn out to be less than accurate.

I must agree that you can't really say anything useful about this incident without knowing what was in the paper. The title makes it seem like an outrageous situation: "Scientists Have Paper On Gender Bias Rejected Because They Are Both Women". I imagine that what actually happened is probably a lot more nuanced.

It could very well be that the quality of the paper was rather poor. The article says the two female researchers just looked at the number of papers submitted by men and women, the number of jobs they applied to, and how long it took them to get accepted for a position. They then apparently concluded that, since women tended to be less successful, this obviously proves the existence of gender bias because the quality of the work cannot possibly be different, you know, men and women being equal and all.

I know that the article only gives a brief and possibly distorted summary of the paper, but if this was indeed the content, the reviewer has a perfectly valid point saying the results could also be explained by a lower quality of women's work. That doesn't mean that this is indeed likely to be the case, just that it would be an alternative explanation that must be ruled out before you can conclude anything about gender bias.

There have been other studies on academic gender bias, for example the one where identical papers were sent in with either men or women listed as the authors, and noting the discrepancy in their acceptance. And yes, a bias did indeed show up there, so I certainly don't rule it out, but you have to use proper methods instead of jumping to conclusions.

The remark about including a male co-author is obiously not a very smart one, but I kind of understand the reason for that suggestion too: a paper on the Palestinian conflict written by Jewish and Palestinian co-authors is more likely to be neutral than a paper written by only Jews or only Palestinians. So for this particular issue, having a male co-author is probably not a bad idea. Especially if they jumped to a conclusion about gender bias without ruling out alternative explanations, which would actually suggest gender bias in their work.

Once again, I haven't seen the paper so this is all just speculation on my part. The reviewer certainly could have phrased his comments a little better, though. Maybe he was just poking fun at them for writing an obviously flawed paper, but it clearly didn't get interpreted that way.

Except if it's one of these.

You could put on three spheres, so that any objects are always visible by at least two of them. Then you can do some processing (quite a lot of processing, actually) to synthesize the images that would have been seen by two cameras at a fixed distance from each other pointing in any particular direction. I'm not saying it's easy, but certainly feasible with today's processing power. And it would result in less lag than actually having to physically move the cameras. Also, multiple people could use the same feed like popo suggested.

There are obviously some disadvantages, one of them being the much higher bandwidth required to capture 360 degree vision from three cameras in sufficiently high resolution so that a relatively small view window still keeps enough pixels to look good.

But lag is an extremely important issue if you don't want people to get seasick within minutes of using the device.