About the only time a "Manager" is acceptable is if the code for the thing it manages is outside your control. Otherwise, "Manager" is almost always an instant sign of a functional design that's pretending to be object-oriented and failing miserably.
Testability is critical, but it's pointless without actual tests. By tests, I do not mean a single test case verifying only the "normal" path where everything goes exactly as expected. I mean testing every boundary case, varying degrees of complexity where applicable, and failure modes, ensuring that it fails in the way that it is intended to fail and in every case where it is intended to fail.
Just as a follow-up, minasoko has pointed out in reply to another of my comments that ADS-B data shows the copilot specifically set the autopilot to fly to an altitude of 100 feet. As much as I want to give this guy the benefit of the doubt, for me, that pretty much rules out any possibility that this was not an intentional action by the copilot.
Simply falling on this switch wouldnt cause it to change positions - it requires a deliberate act to do so, the switch requires a certain force to pull up and then move to one position or another, its not like accidentally changing channels on your TV because you sat on the remote.
I can believe this. But what if, instead of falling against the switch, the copilot, recognizing that he was about to pass out (e.g. recognizing symptoms of an impending stroke), intentionally attempted to move the switch to the "unlocked" postion (to make it easier for the captain to get into the cockpit quickly)? Due to a combination of confusion, physical incapacitation, and infamiliarity with a probably rarely-used control, he could conceivably have turned the switch to the wrong position even while he was attempting to do what he thought would be the best possible action.
Also, there is no button or switch he could have fallen on which would have caused the gradual descent that we know the aircraft took. Changing the auto pilot altimeter requires you to use a dial and then confirm the change in two separate actions. Any interaction with the side stick would require the auto pilot to be off, which would mean we should have seen a lot of other, large movements in the aircrafts path, which are completely missing from the telemetry we have at the moment.
The few commands that we see in the telemetry (and by telemetry I mean the transponder tracks, which cover speed, height and directional changes) indicate that the aircraft was under either the control of the pilot or the autopilot for the entire duration of the descent.
As far as I can tell, this is nonsense. Under "normal law" in an Airbus autopilot system, sufficient pressure on the control stick will override the autopilot system. For downward pitch, the autopilot system will allow up to 15 degrees of downward pitch to be commanded without removing the autopilot system from "normal law"; other autopilot functions will continue to function normally. I'm not sure what the exact result of 15 degrees of downward pitch would be, but I'm pretty sure it would be a rapid but controlled descent—exactly what the telemetry shows.
The evidence does seem to be getting stronger, but I'm not quite ready to conclude that this was intentional. The fact that the co-pilot was breathing does not necessarily indicate that he was conscious. If he became unconscious, he could easily have fallen into a position where his body was pushing forward on the control stick. This would override the autopilot and cause the plane to descend under "manual" control. As far as I know, they still haven't found the FDR, so there's really no way to tell whether or not the "manual" control inputs were intentional (i.e. varying inputs with relatively light pressure would probably indicate intentional control; relatively continuous inputs at an extreme input position would probably indicate unintentional input). The locked cockpit door is harder, but not impossible, to explain: I'm not familiar with the design of the switch, but it's conceivable that he could have fallen against it and knocked into the locked position; perhaps more plausibly, he may have recognized that he was about to pass out (I have personally fainted due to low blood sugar a few times, and it generally doesn't happen without at least a few seconds of advanced warning) and, attempting to turn the switch to the "unlocked" position in order to simplify a hasty ingress of the captain, may have inadvertently turned the switch in the wrong direction. Before we vilify this guy posthumously, let's make sure we have precluded all other options.
Well, in a full motion simulator it's not impossible to surmount--anyone who has ridden on the Mission Space ride (especially the orange version) at Disney World will confirm that (it's an awesome ride, by the way). But unless you have a few million dollars to squander, yes, the feeling of acceleration would fall into that category of "non-visual sensory inputs" that you just can't get from a game. Great point.
LOL, I fail to see how the availability of expensive peripherals that provide improvements negate my comments, which were about "typical" setups. The average gamer has neither a high-tech, $300 wheel nor a $150 helmet (which still doesn't provide any form of peripheral vision).
Even using the most realistic settings, most video racing games fail to physically equate to real-life driving—for instance:
Typical racing wheels allow 1/2 to 3/4 turn of the wheel, lock-to-lock; a typical passenger car has well over 3 turns lock-to-lock, and even a high-performance sports car has over 2.
Peripheral vision, which is very important in real-life driving, is completely lost in video games; many racing games do not even allow you to look in a different direction than you are going (e.g. turn your head to look left while continuing to drive straight), and those that do allow it require some button-press that is not the same as just turning your head.
Most non-visual sensory inputs to driving (slight variations in vibrations, etc.) are lost in video games.
So there's no doubt that there's little, if any, physical correlation of video game driving skills to real-life driving skills, even in the most realistic games. However, more abstract skills learned in video gaming, such as situational awareness and reaction times, certainly do apply to real-life driving, especially in high-pressure accident-avoidance situations, where the split-second reaction times honed by racing games are clearly advantageous. Clearly, that was outside the scope of this "study", but the conclusion stated by the title of this post is entirely erroneous.
Did you even bother reading the whole comment? "Agencies often cite more than one exemption when withholding part or all of the material sought in an open-records request."
I took all of my notes throughout university (including engineering courses) using OpenOffice.org. The equation editor in OpenOffice is easy-to-learn, fast (as in, no mouse use required and the keystrokes are all sane), and the completed equations look great. (By default, there isn't a keyboard shortcut for inserting a new equation, so you'll need to manually assign one—I used Ctrl-Shift-F, if I remember correctly.
Your example would almost work as is; it would be entered as:
f_x (x) = int from -infinity to infinity f (x, y) dy
Or, if you prefer your parentheses to stretch (in case you have fractions inside, or what have you):
f_x left ( x right ) = int from -infinity to infinity f left ( x, y right ) dy
Either way, it comes out looking very nice. The one thing that takes some getting used to is that you need to make liberal use of whitespace (e.g. between f and the opening parenthesis of the function), otherwise things will occasionally come out looking a little strange. The best part is, when you don't know what you need to type for a particular symbol, you can select it from the menu and OO will insert the plaintext code, which makes it very easy to learn the code for new items.
From the linked article: "The books published by The Espresso Machine will have a recommended sales price of $8 per copy, although the final decision will be left to each retailer."
Possibly, but this at least eliminates the need for shipping the printed books (which weigh a LOT) all over the world. Plus, for me at least, I can only spend maybe five minutes at a time reading from a computer screenâ"and I'm even a Gen Y computer programmer. There's something about reading from a computer screen that is just a lot harder than reading from a paper.
Okay, you're right in one sense, because I wasn't completely accurate in my previous comment (I wrote it hurriedly during the last few minutes of my lunch break at work)--the probability does in fact increase somewhat with the sample size. However, your description doesn't describe the situation accurately at all; the correct analogy would be that, each of 100 stars has a 1 in 100 chance of having a planet spiraling into it; in this case, viewing all 100 stars does not yield a probability of 1 of seeing a planet spiraling into it.
Let me try another simplified description. First, consider a single, six-sided die. One of the six sides has a one on it; if you examine a single side of the die (roll it), you have a 1 in 6 chance of seeing the one; if you examine three of the six sides, you have a 1 in 2 chance of seeing the one; if you examine all six sides, you have a 1 in 1 chance (probability of 1) of seeing the one. This is analogous to your "1 out of 100 stars" situation above, but it is not analogous to real life.
Now consider six normal, six-sided dice. If you roll all six of them, what is the probability that at least one of them will come up with a one? You will probably immediately realize the probability is not 1, but calculating it is a bit of a math problem--it's been a while since my college statistics class, but if I remember correctly, the correct way of finding it is to calculate the probability that none of the dice will be a one, and then subtract that from 1, thus:
For each die, the probability of it not being a one is 5/6;
Thus, the probability of none of the six dice being a one is (5/6)^6, or about 0.335;
Thus, the probability of at least one of the six dice being a one is 1 - 0.335, or about 0.665, which is significantly less than 1.
Going back to your 1 in 100 probability, if there are 100 stars and each has a 1 in 100 chance of having a planet spiraling into it, then the probability of any of the 100 stars having a planet spiraling into it is 0.634. Examining only 50 of the 100 leaves a probability of 0.5 * 0.634 or only 0.317.
Now, we're making some huge assumptions about the probabilities of this event occurring; but just for the sake of discussion, let's just say that, for any given star, there is a 1 in 10^15 (one in a trillion) chance that, at the present time, it has a planet spiraling into it. (Given the relatively small number of stars we know of that have any planets at all, I suspect that number is a significant overestimate, but I'll use it.) Using your estimate of 100 billion stars in the universe, that makes the probability that any star exists, anywhere in the universe with a planet spiraling into it about 0.0000999, or 1 in 10,000, which is pretty small. Now I'll assume that we have examined 1 billion of those stars closely enough that we would be able to detect this occurrence (which I would guess is a gross overestimate); that makes the probability of any star that we have examined being in the midst of the occurrence about 0.000000999, or 1 in a million.
So, being what I would say is quite generous with all of the numbers, we have a 1 in a million chance of seeing this.
No: This is a common misunderstanding of probability. The probability of a particular event occurring does not increase with the number of non-occurrences (well, if the event is random, which in this case it is). Think of it on a smaller scale: Flipping a coin. Let's say I flip a coin and get heads five times in a row (not a likely occurrence, but very definitely possible). On the sixth flip of the coin, what is the chance of getting heads again? It's 1 in 2, or 50%. Regardless of the sample size, the probability of a given flipped coin being heads is 1 in 2.
So extend that concept to larger numbers: If the probability of a given occurrence is 1 in 1 billion, then the probability remains 1 in 1 billion regardless of whether there are 100 or 100 billion samples.
This is why statisticians have the concept of a mathematical impossibility: If the probability of an event is lower than a certain number (I think it's 1 in 10^50, if I remember right), it is considered mathematically impossible, regardless of the sample size! Now, I don't know what the probability of this is consideredâ"I doubt it's low enough to be considered a mathematical impossibility. But the point is, increasing the sample size does not make the event more likely to occur.
About the only time a "Manager" is acceptable is if the code for the thing it manages is outside your control. Otherwise, "Manager" is almost always an instant sign of a functional design that's pretending to be object-oriented and failing miserably.
Or, put another way: Classes called "Manager" almost always violate the single responsibility principle.
Testability is critical, but it's pointless without actual tests. By tests, I do not mean a single test case verifying only the "normal" path where everything goes exactly as expected. I mean testing every boundary case, varying degrees of complexity where applicable, and failure modes, ensuring that it fails in the way that it is intended to fail and in every case where it is intended to fail.
Just as a follow-up, minasoko has pointed out in reply to another of my comments that ADS-B data shows the copilot specifically set the autopilot to fly to an altitude of 100 feet. As much as I want to give this guy the benefit of the doubt, for me, that pretty much rules out any possibility that this was not an intentional action by the copilot.
Incidentally, the similarities to EgyptAir Flight 990 are stunning.
I wasn't aware of the ADS-B data. That definitely seems to be a pretty insurmountable piece of evidence against any kind of an "unintentional" theory.
Simply falling on this switch wouldnt cause it to change positions - it requires a deliberate act to do so, the switch requires a certain force to pull up and then move to one position or another, its not like accidentally changing channels on your TV because you sat on the remote.
I can believe this. But what if, instead of falling against the switch, the copilot, recognizing that he was about to pass out (e.g. recognizing symptoms of an impending stroke), intentionally attempted to move the switch to the "unlocked" postion (to make it easier for the captain to get into the cockpit quickly)? Due to a combination of confusion, physical incapacitation, and infamiliarity with a probably rarely-used control, he could conceivably have turned the switch to the wrong position even while he was attempting to do what he thought would be the best possible action.
Also, there is no button or switch he could have fallen on which would have caused the gradual descent that we know the aircraft took. Changing the auto pilot altimeter requires you to use a dial and then confirm the change in two separate actions. Any interaction with the side stick would require the auto pilot to be off, which would mean we should have seen a lot of other, large movements in the aircrafts path, which are completely missing from the telemetry we have at the moment.
The few commands that we see in the telemetry (and by telemetry I mean the transponder tracks, which cover speed, height and directional changes) indicate that the aircraft was under either the control of the pilot or the autopilot for the entire duration of the descent.
As far as I can tell, this is nonsense. Under "normal law" in an Airbus autopilot system, sufficient pressure on the control stick will override the autopilot system. For downward pitch, the autopilot system will allow up to 15 degrees of downward pitch to be commanded without removing the autopilot system from "normal law"; other autopilot functions will continue to function normally. I'm not sure what the exact result of 15 degrees of downward pitch would be, but I'm pretty sure it would be a rapid but controlled descent—exactly what the telemetry shows.
The evidence does seem to be getting stronger, but I'm not quite ready to conclude that this was intentional. The fact that the co-pilot was breathing does not necessarily indicate that he was conscious. If he became unconscious, he could easily have fallen into a position where his body was pushing forward on the control stick. This would override the autopilot and cause the plane to descend under "manual" control. As far as I know, they still haven't found the FDR, so there's really no way to tell whether or not the "manual" control inputs were intentional (i.e. varying inputs with relatively light pressure would probably indicate intentional control; relatively continuous inputs at an extreme input position would probably indicate unintentional input). The locked cockpit door is harder, but not impossible, to explain: I'm not familiar with the design of the switch, but it's conceivable that he could have fallen against it and knocked into the locked position; perhaps more plausibly, he may have recognized that he was about to pass out (I have personally fainted due to low blood sugar a few times, and it generally doesn't happen without at least a few seconds of advanced warning) and, attempting to turn the switch to the "unlocked" position in order to simplify a hasty ingress of the captain, may have inadvertently turned the switch in the wrong direction. Before we vilify this guy posthumously, let's make sure we have precluded all other options.
Well, in a full motion simulator it's not impossible to surmount--anyone who has ridden on the Mission Space ride (especially the orange version) at Disney World will confirm that (it's an awesome ride, by the way). But unless you have a few million dollars to squander, yes, the feeling of acceleration would fall into that category of "non-visual sensory inputs" that you just can't get from a game. Great point.
LOL, I fail to see how the availability of expensive peripherals that provide improvements negate my comments, which were about "typical" setups. The average gamer has neither a high-tech, $300 wheel nor a $150 helmet (which still doesn't provide any form of peripheral vision).
Have Slashdot stories always been this ridiculous and I just haven't noticed before?
So there's no doubt that there's little, if any, physical correlation of video game driving skills to real-life driving skills, even in the most realistic games. However, more abstract skills learned in video gaming, such as situational awareness and reaction times, certainly do apply to real-life driving, especially in high-pressure accident-avoidance situations, where the split-second reaction times honed by racing games are clearly advantageous. Clearly, that was outside the scope of this "study", but the conclusion stated by the title of this post is entirely erroneous.
Did you even bother reading the whole comment? "Agencies often cite more than one exemption when withholding part or all of the material sought in an open-records request."
HA! This has to be the best comment I've seen on Slashdot, ever! You hit the nail on the head!
I took all of my notes throughout university (including engineering courses) using OpenOffice.org. The equation editor in OpenOffice is easy-to-learn, fast (as in, no mouse use required and the keystrokes are all sane), and the completed equations look great. (By default, there isn't a keyboard shortcut for inserting a new equation, so you'll need to manually assign one—I used Ctrl-Shift-F, if I remember correctly.
Your example would almost work as is; it would be entered as:
f_x (x) = int from -infinity to infinity f (x, y) dy
Or, if you prefer your parentheses to stretch (in case you have fractions inside, or what have you):
f_x left ( x right ) = int from -infinity to infinity f left ( x, y right ) dy
Either way, it comes out looking very nice. The one thing that takes some getting used to is that you need to make liberal use of whitespace (e.g. between f and the opening parenthesis of the function), otherwise things will occasionally come out looking a little strange. The best part is, when you don't know what you need to type for a particular symbol, you can select it from the menu and OO will insert the plaintext code, which makes it very easy to learn the code for new items.
From the linked article: "The books published by The Espresso Machine will have a recommended sales price of $8 per copy, although the final decision will be left to each retailer."
Possibly, but this at least eliminates the need for shipping the printed books (which weigh a LOT) all over the world. Plus, for me at least, I can only spend maybe five minutes at a time reading from a computer screenâ"and I'm even a Gen Y computer programmer. There's something about reading from a computer screen that is just a lot harder than reading from a paper.
Going back to your 1 in 100 probability, if there are 100 stars and each has a 1 in 100 chance of having a planet spiraling into it, then the probability of any of the 100 stars having a planet spiraling into it is 0.634. Examining only 50 of the 100 leaves a probability of 0.5 * 0.634 or only 0.317. Now, we're making some huge assumptions about the probabilities of this event occurring; but just for the sake of discussion, let's just say that, for any given star, there is a 1 in 10^15 (one in a trillion) chance that, at the present time, it has a planet spiraling into it. (Given the relatively small number of stars we know of that have any planets at all, I suspect that number is a significant overestimate, but I'll use it.) Using your estimate of 100 billion stars in the universe, that makes the probability that any star exists, anywhere in the universe with a planet spiraling into it about 0.0000999, or 1 in 10,000, which is pretty small. Now I'll assume that we have examined 1 billion of those stars closely enough that we would be able to detect this occurrence (which I would guess is a gross overestimate); that makes the probability of any star that we have examined being in the midst of the occurrence about 0.000000999, or 1 in a million. So, being what I would say is quite generous with all of the numbers, we have a 1 in a million chance of seeing this.
No: This is a common misunderstanding of probability. The probability of a particular event occurring does not increase with the number of non-occurrences (well, if the event is random, which in this case it is). Think of it on a smaller scale: Flipping a coin. Let's say I flip a coin and get heads five times in a row (not a likely occurrence, but very definitely possible). On the sixth flip of the coin, what is the chance of getting heads again? It's 1 in 2, or 50%. Regardless of the sample size, the probability of a given flipped coin being heads is 1 in 2.
So extend that concept to larger numbers: If the probability of a given occurrence is 1 in 1 billion, then the probability remains 1 in 1 billion regardless of whether there are 100 or 100 billion samples.
This is why statisticians have the concept of a mathematical impossibility: If the probability of an event is lower than a certain number (I think it's 1 in 10^50, if I remember right), it is considered mathematically impossible, regardless of the sample size! Now, I don't know what the probability of this is consideredâ"I doubt it's low enough to be considered a mathematical impossibility. But the point is, increasing the sample size does not make the event more likely to occur.
That's my vote. :-)
Perhaps they should reconsider their evaluation of its age...