4 ms·

But isn't the answer kind of the same? Undefined behavior will result.

by jsight 8y ago

mabbo 8y ago
And that's a fine answer. "Nobody has a plan for that because it's so unlikely, so the outcome is kind of unknown", then maybe some examples that come close.
aeternus 8y ago
I doubt it is even undefined in this case. Ejected vs. not-ejected is very likely not even an input variable to the autopilot. So the answer would be: Autopilot will attempt to do exactly what it was doing before the pilot ejected.
- derefr 8y ago
  Ejecting presumably shoves the plane downward in recoil from the pilot shooting upward. The autopilot would notice that. Also, the plane would be lighter after the ejection. And perhaps—I'm just guessing—the cockpit window or ceiling might now be gone? In which case there'd suddenly be a lot of drag from air swirling down into the cockpit. So no, I don't expect the autopilot would continue to do exactly what it was doing before. It'd have to do a bunch of corrections, and then it would return to what it was doing before :) (Or those corrections might be enough to make it decide "the pilot" should take over. What happens when there's no pilot and no autopilot? I'm guessing that's down to the way avionics hardware reads out when nobody's touching it.)
  - viraptor 8y ago
    The first two options are for acceleration and weight. The first one changes enough while the plane is flying to be measured in Gs. There's also air turbulence. You wouldn't want to rely on secondary things like that. The second one can change for a number of reasons in a military plane. If you can even measure it, considering the changing acceleration. The cockpit can be broken or sensors may be malfunctioning as well, so "cockpit missing" is not a great signal.
  - jsight 8y ago
    Yeah, that is what I was thinking as well. The autopilot itself won't care, but the disturbance may (or may not) be enough to cause it to turn off. Whether it does or not may even be situation dependent.
derefr 8y ago
Yeah, but we usually know what "undefined behaviour" actually means in practice. In programming languages, we can just go check what the particular compiler we're using spits out when you do something stupid. It might not generalize to any other compiler—and that's the reason you don't try to build anything predicated on any particular assumption about the behavior—but you can still know it for a particular context. And, in fact, often there are conventions in compiler-writing that mean that every compiler basically does the same thing in response to certain UB code. (Like optimizing away always-false branches, for example.) So, by analogy: there are a limited number of autopilot AI programs in existence. Of those concrete implementations, is there anything they would be predicted to do in response to this event they're not coded for? What would it look like to them—what branch would they take without an explicit branch for "ejected"—and how would they react to being in that branch?

But isn't the answer kind of the same? Undefined behavior will result.

by jsight 8y ago

But isn't the answer kind of the same? Undefined behavior will result.

And that's a fine answer. "Nobody has a plan for that because it's so unlikely, so the outcome is kind of unknown", then maybe some examples that come close.

aeternus 8y ago

I doubt it is even undefined in this case. Ejected vs. not-ejected is very likely not even an input variable to the autopilot. So the answer would be: Autopilot will attempt to do exactly what it was doing before the pilot ejected.

derefr 8y ago
Ejecting presumably shoves the plane downward in recoil from the pilot shooting upward. The autopilot would notice that. Also, the plane would be lighter after the ejection. And perhaps—I'm just guessing—the cockpit window or ceiling might now be gone? In which case there'd suddenly be a lot of drag from air swirling down into the cockpit. So no, I don't expect the autopilot would continue to do exactly what it was doing before. It'd have to do a bunch of corrections, and then it would return to what it was doing before :) (Or those corrections might be enough to make it decide "the pilot" should take over. What happens when there's no pilot and no autopilot? I'm guessing that's down to the way avionics hardware reads out when nobody's touching it.)
- viraptor 8y ago
  The first two options are for acceleration and weight. The first one changes enough while the plane is flying to be measured in Gs. There's also air turbulence. You wouldn't want to rely on secondary things like that. The second one can change for a number of reasons in a military plane. If you can even measure it, considering the changing acceleration. The cockpit can be broken or sensors may be malfunctioning as well, so "cockpit missing" is not a great signal.
- jsight 8y ago
  Yeah, that is what I was thinking as well. The autopilot itself won't care, but the disturbance may (or may not) be enough to cause it to turn off. Whether it does or not may even be situation dependent.

derefr 8y ago

Yeah, but we usually know what "undefined behaviour" actually means in practice. In programming languages, we can just go check what the particular compiler we're using spits out when you do something stupid. It might not generalize to any other compiler—and that's the reason you don't try to build anything predicated on any particular assumption about the behavior—but you can still know it for a particular context. And, in fact, often there are conventions in compiler-writing that mean that every compiler basically does the same thing in response to certain UB code. (Like optimizing away always-false branches, for example.) So, by analogy: there are a limited number of autopilot AI programs in existence. Of those concrete implementations, is there anything they would be predicted to do in response to this event they're not coded for? What would it look like to them—what branch would they take without an explicit branch for "ejected"—and how would they react to being in that branch?