Statistical randomness

[Jeroen Hoppenbrouwers]

For popup touch screen key pads, maybe this shouldn't be a PSX feature, but just done by the underlying operating system? There are plenty of popup key pads available and this gives people more choices, plus the option to do things with add-ons that otherwise would need their own key pads as well.



Jeroen

[marcom]

I think it would be useful to have more failures triggered at V1/Vr/V2 like hydraulic failures, burst tyres, bird strike if you haven't added these yet.
You could add these triggers to the standard combo box, wouldn't that make sense?

Some other possible triggers:
at DH / MDA
at flare altitude

[Hardy Heinlin]

The failures you mentioned are already added, or are planned to be added.

Re triggers: DH/MDA or flare altitude can be referenced by the altitude setting in the combo box.

Or ist it the "Any engine" trigger which you want to have for landing scenarios, not just for take-off?

This might be available in some form on the general Random page (not shown in the screenshot here).

For flare or DH (at least CAT II/III) an engine failure is less training relevant than in situations of high power setting, I think. During the flare the power is at idle anyway. It may be surprising if any reverser fails, though.


Cheers,

|-|ardy

[farrokh747]

toga switch failure? have seen this in sim sessions for go arounds....

[Phil Bunch]

A curiosity-based question - what probability distribution is used for generating the time until the next random failure?  

In other words, if one sets a mean failure rate of X per hour and a standard deviation of Y per hour (or perhaps some other relevant parameter), is a simple Gaussian (bell-shaped) probability distribution function used for generating the time between random events?  Since time starts at t=0 and does not extend symmetrically in the positive and negative directions, it would seem that some other distribution would be needed (Poisson?).   It's been too long since I worked on such things...sighs...

I hope this question isn't too obscure - some years ago I worked on simulating and modeling various types of random events (in space, not time), all related to medical x-ray imaging system R&D.

[Hardy Heinlin]

A curiosity-based question - what probability distribution is used for generating the time until the next random failure?  

In other words, if one sets a mean failure rate of X per hour and a standard deviation of Y per hour (or perhaps some other relevant parameter), is a simple Gaussian (bell-shaped) probability distribution function used for generating the time between random events?  Since time starts at t=0 and does not extend symmetrically in the positive and negative directions, it would seem that some other distribution would be needed (Poisson?).   It's been too long since I worked on such things...sighs...

I hope this question isn't too obscure - some years ago I worked on simulating and modeling various types of random events (in space, not time), all related to medical x-ray imaging system R&D.

It's the standard pseudo random value that the Intel chip provides whenever the function is invoked.

In PS it is invoked once per second.

The random value ranges from 0.0 to 0.999999.

R = Random
C = Condition

If R < C then trigger the malfunction

If C is set to 1.0, then the trigger occurs every second.

If C is set to 0.3333, then the trigger occurs every third second (statistically).

If C is set to 0.1, then the trigger occurs every tenth second (statistically).


Cheers,

|-|ardy

[Will]

I had to chuckle, Phil, with the Gaussian distribution!  You're assuming a central tendency, and that would look bizarre indeed for this type of event.  If the duration was 12 hours, a typical flight, then almost no failures would happen at takeoff or landing, and the great majority would occur during the dinner service.  

I had always assumed that Hardy was using a Poisson distribution, where the chance of one failure occurring was unrelated to whether there had been a failure in the moment previous, but of course that isn't realistic either... I'm sure the high-probablility times for failures are systems-dependent.  For example:

Engine failures: high probability when starting, or spooling up to high power/temperature; low probability in sustained cruise, very low probability during final approach (but higher probability on go-around).

Birdstrike: very high probability when below 1000', high probability between 1000' and 8000', very low probability above 8000.'

Airframe failures (cargo doors, etc.): very high probability on climbout (as pressure builds).

Airframe failures (top of the fuselage ripping off): highest probability when pressure is changing (and metal is deforming), whether on climbout or approach.

Electrical failures: highest probability with high loads (like when the movie starts?)

And so on... Very interesting to think about.  I do wonder what HArdy's put under the hood here.

[martin]

It's been too long since I worked on such things...sighs...

Same problem here*, but FWIW I, too, seem to remember that Poisson was the one for "raisins in dough", i.e. relatively few things in a continuum (or events in time).

So, Poisson Raison Raisins?

Cheers,
Martin
(just learning R...)

*) Then again who needs to remember anything nowadays when we have Wikipedia...

[Hardy Heinlin]

I've just written this little test. It simulates a test period of 10 seconds and this 10 sec test period is looped 10000 times so that I can detect any statistical tendencies in the printed results further below.

The test takes a millisecond, but in the sim this Math.random() method gets invoked only once per second. Everytime it is invoked the Intel chip delivers a value from 0.0 to 1.0 (1.0 not included). So, when the user has set "Malfunction within next 10 seconds" there'll be a countdown starting at 10:

At 10 sec: If random < 0.1 then trigger it (probability 1:10)
At 9 sec: If random < 0.1111 then trigger it (probability 1:9)
... etc. ...
At 5 sec: If random < 0.2 then trigger it (probability 1:5)
At 1 sec: If random < 1.0 then trigger it (probability 1:1)

It is important to make the factor exponential; otherwise, if it were linear, the probability of 50% would already be given at the fifth second.

Code Select Expand

int[] r = new int[ 10 ];
int k;
for ( int i = 0; i < 10000; i++ ) {
k = r.length;
while ( k > 0 ) {
     if ( Math.random() < ( 1.0 / k ) ) {
  r[ k - 1 ]++;
  k = 0; // stops the loop
     }
   k--;
}
}
for ( int v = r.length; v > 0; v-- )
System.out.println( r[ v - 1 ] );


This prints out a nice equally distributed noise:
1000
1013
980
1003
964
983
1015
1025
970
1047


Cheers,

|-|ardy



P.S.: Here's the linear version. The chance of getting a trigger increases in the first seconds.

At 10 sec: If random < 0.1 then trigger it (probability 1:10)
At 9 sec: If random < 0.2 then trigger it (probability 1:5)
... etc. ...
At 6 sec: If random < 0.5 then trigger it (probability 1:2)
At 1 sec: If random < 1.0 then trigger it (probability 1:1)

(The threshold value is increased by 0.1 so that at 10 sec the if statement doesn't read < 0.0. That would be zero probability.)

Code Select Expand

int[] r = new int[ 10 ];
int k;
for ( int i = 0; i < 10000; i++ ) {
k = r.length;
while ( k > 0 ) {
     if ( Math.random() < 1.1 - k / 10.0 ) {
  r[ k - 1 ]++;
  k = 0; // stops the loop
     }
   k--;
}
}
for ( int v = r.length; v > 0; v-- )
System.out.println( r[ v - 1 ] );
Result:
971
1828
2195
1933
1534
876
451
160
46
6

[Shiv Mathur]

...the great majority would occur during the dinner service.  

I had always assumed that Hardy was using a Poisson distribution ...

And we'd hope that at least one of the pilots wouldn't have the fish.

[martin]

...nor any other Poison...
:mrgreen:
Sorry...

[Hardy Heinlin]

Note that I'm not responsible for the fish. I eat what the CPU spits out. The CPU may cook á la Poisson, but I don't know. Anyway, the distribution looks nicely flat. (Java also offers a Gaussian distribution. I don't use that.)


!-!

[torrence]

I see we have descended (ascended?) to French tongue-twisters:  Hardy will now use a Poisson distribution to determine if "le poison est dans les poissons"

Pardon my French as we say in the USA - I cheated and used Babel-fish (Babel-poissons?) to translate.

Cheers,
Torrence

[martin]

This prints out a nice equally distributed noise:

Just out of idle curiosity: To produce RBG* failures, why not do simply this:

Code Select Expand


int hitTime = 0 ;
while (hitTime == 0){
   hitTime = (int) Math.round(Math.random()*DUR + .5) ;
}
// DUR is the  interval in which failure should happen, e.g. 10 min
// and the loop just prevents that it never happens

and then count to (or down from) hitTime and fire the failure?

10,000 runs (for a 10 min interval) result e.g. in:
 1:  984
 2:  986
 3: 1015
 4: 1025
 5:  989
 6: 1029
 7: 1045
 8: 1014
 9:  974
10:  939

Cheers,
Martin

* RBG: Random But Guaranteed :mrgreen:

[Hardy Heinlin]

and the loop just prevents that it never happens

I don't understand it :-) Why not write the word true in the while condition then?

And what is checked when?

In my example, k represents one second in the countdown of seconds. The time the k-while-loop runs is a simulation of the countdown in the sim, e.g. when the user sets "malfunction within 10 sec." The sim will request a random value from the CPU every second. This random value may or may not trigger the malfunction. The probability rises when the countdown  approaches 0 sec. In the last sec the probabilty is 100%.

When the malfunction is triggered, say, at the 7th second, the countdown is over, the job done, and the remaining 3 seconds will not be performed.

Where's your r++ counter?


Cheers,

|-|ardy

[martin]

Probably I do not understand the context properly.

What my code does, is of course trivial, namely to draw an equally distributed random integer  between 1 and DUR (e.g. DUR = 10 min).
(The while loop only prevents that 0 is drawn and used, i.e. no failure happens at all.)

And this random_integer would then be used in a count-down for the failure (which I conveniently leave to the "surrounding code"  , see below ).

The problem may be that this, while simpler, does not fit into the surrounding structure. I was assuming that you have some sort of master timer loop and event schedule running somewhere else anyway, where you could "plug in" the failure countdown with the number as supplied above. (Put "failure" in the event schedule at time "now + random_int", so to speak).

In that case, there would be no need to handle the timing "locally", specifically for the failure, as in your code, and no need to fiddle with probabilities changing from one interval to the next  (I thought).

But my assumption may well be wrong, and you may have to take care of the whole failure timing here, as per your variable k etc..

Or in other words:

Your idea:
"The sim will request a random value from the CPU every second. This random value may or may not trigger the malfunction."
The dice "failure/no failure" is thrown once every minute; probabilities change so that the failure will always happen before DUR is over.

My idea (possibly misguided):
"The sim will request a random integer rand_int between 1 and DUR only once.
At time "now + rand_int" minutes, it will then trigger the failure (always)."
The dice "integer from 1 to DUR" (equal prob. for each value) is thrown only once. Failure will always happen before DUR is over (as we exclude rand_int = 0)

Cheers,
Martin

PS.
One could say that you use randomness, appropriately, as The Man From The Inside (Welcome To The Machine), sitting on the event, minute by minute.
While I'm The Man From The Outside Looking In ("there's a duration, let's drop in an event somewhere").
 

[Hardy Heinlin]

My idea (possibly misguided):
"The sim will request a random integer rand_int between 1 and DUR only once.
At time "now + rand_int" minutes, it will then trigger the failure (always)."
The dice "integer from 1 to DUR" (equal prob. for each value) is thrown only once. Failure will always happen before DUR is over (as we exclude rand_int = 0)

I see. I had a similiar idea; I considered a random UTC time stamp to be set once when the user has entered a value, e.g. 10 minutes: If the current UTC is 12:30, the random time will be anything between 12:30 and 12:40. Then the only thing the sim would have to do is check every second whether the UTC agrees with that preprogrammed time. Less work than doing a random call and a math division every second. Disadvantage:
-- When you change the global UTC, each trigger system must be resynchronized, otherwise you might wait for 23 hours instead of 1 hour.
-- The probability information is lost


At the moment, I think I'll keep the old "events/day" solution (non-RGB) for the single malfunction items, although I have a solution (as shown above). I find the RGB style is more useful on the general Random page.


Cheers,

|-|ardy

[Hardy Heinlin]

Two months later ...

On the Random page (no screenshots yet) I've considered adding a "guaranteed failure" mode to the regular "statistical" mode.

The statistical mode is an "event noise" distributed over an infinite time, that is: a failure may happen at the desired probability, but without guarantee. Classic PS1 style.

The guaranteed mode, on the other hand, will trigger a failure by all means.

On the Random page several categories could be implemented, e.g.:

[nn] Guaranteed failures during takeoff
[nn] Guaranteed failures during departure
[nn] Guaranteed failures during cruise
[nn] Guaranteed failures during approach
...

Now, after all that theory (see this thread), I'm starting to dislike that guaranteed mode more and more. Why?

It's too predictable.

Example: You want an engine failure during cruise. Your cruise takes 500 minutes.

Nothing happened for 490 minutes. Now your expectation is rising to the max. No surprise anymore.

Or, you just passed 10 minutes of cruise time and an engine has already failed. Now you know no more things will fail from now on. Surprise gone.

It's too predictable. So, a failure could be set right by the traditional time entries also.

...

It's sort of disappointing in any case. A design dilemma. On one hand, you want to be surprised, but the guarantee kills the surprise. On the other hand, the classic statistical mode is able to surprise you, but may also disappoint you if nothing fails on this flight.

After all, even if I won't include the guaranteed mode on the Random page, there are still some guaranteed random failures provided: For engine failures within specific V speed time frames. I think that's the most important area where this mode is necessary. For the other areas there's no significant advantage, just the disadvantage of additional programming work and time.


Cheers,

|-|ardy

[martin]

Moi,

A design dilemma.

Perhaps less so if seen from "didactic" point of view , i.e. the possible training goals:

Training goal Abnormal Procedures:
-- schedule failure at fixed time: don't waste time waiting for it; no surprises needed or indeed desired. (The point being to hit the right buttons, switches and levers etc. in the proper sequence, not to wait for a chance to do so).

Training goal Nerves / Reaction Time / Standing-Uppance in The Face of Adversity:
-- apply complete randomness: surprise is of the essence, and the test properly should include your frustration* that nothing untoward at all did happen; so, real randomness (non-guaranteed, including "zero-case") is appropriate indeed. (The point being, How long does it take you, under various circumstances, to go into the mode trained in the item above? And will you remain on your toes even if nothing happens for a long time?)

Conclusion: Having deterministic failures (at scheduled times) and completely random (non-guaranteed) ones (plus the semi-random ones for engine failures after Vx, etc.) should indeed cover all needs.

Cheers,
Martin

* rather unprofessional anyway, if you think about it -- any real pilot here (meaning commercial, perhaps not the fighter jock types) ever having been frustrated or disappointed that nothing bad happened (even in the simulator)?

[Hardy Heinlin]

Fully agreed :-)