Showing Revision 3 created 05/25/2016 by Udacity Robot.

1. Title:
   Fdiv - Software Testing
2. Description:

3. 0 0:00 - 0:02
   All right. Let's try to work out the math.
4. 2000 0:02 - 0:07
   So what we have is, by assumption, we can run 1 test every 10 microseconds.
5. 7000 0:07 - 0:11
   Now, there are a million microseconds in a second, 60 seconds in a minute,
6. 11000 0:11 - 0:15
   and 60 minutes in an hour, and 24 hours in a day.
7. 15000 0:15 - 0:17
   So now we're going to do some unit cancellation.
8. 17000 0:17 - 0:22
   We can kill microseconds, we can kill minutes, we can kill seconds,
9. 22000 0:22 - 0:24
   and we can kill hours.
10. 24000 0:24 - 0:27
    So if we do the multiplication, we can get tests per day.
11. 27000 0:27 - 0:33
    And if we do that, we get 8,640,000,000 tests per day.
12. 33000 0:33 - 0:36
    If we multiply this testing throughput by the failure rate
13. 36000 0:36 - 0:41
    we're going to get 1 failure per 9 billion tests.
14. 41000 0:41 - 0:48
    We can cancel tests, do the division, and arrive at 0.96 expected failures per day.
15. 48000 0:48 - 0:50
    So under what I think are fairly modest assumptions here,
16. 50000 0:50 - 0:53
    if we perform completely random testing of the input space for fdiv,
17. 53000 0:53 - 0:55
    we should be able to find this bug in about a day.
18. 55000 0:55 - 0:58
    And so now this kind of testing is going to need some sort of an oracle.
19. 58000 0:58 - 1:03
    So we're going to need a way to tell if our particular output from fdiv is correct or not.
20. 63000 1:03 - 1:06
    And the way this is going to work is IEEE floating point,
21. 66000 1:06 - 1:09
    which is what fdiv is implementing, is specified very tightly.
22. 69000 1:09 - 1:12
    That is to say, one implementation of IEEE floating point division
23. 72000 1:12 - 1:15
    has to return the same bit pattern as another implementation.
24. 75000 1:15 - 1:18
    That's one of the nice things about that particular specification is that it's fairly tight.
25. 78000 1:18 - 1:20
    So we ask ourselves, what would have been the oracle for fdiv?
26. 80000 1:20 - 1:26
    And probably it would have been Intel's existing 487 floating point unit,
27. 86000 1:26 - 1:29
    which had been around for some years by the time they were developing the Pentium.
28. 89000 1:29 - 1:32
    So what I think this shows, unless I've messed up sort of egregiously on the math somewhere,
29. 92000 1:32 - 1:35
    is that random testing would have been a perfectly good way
30. 95000 1:35 - 1:38
    to find the Intel Pentium fdiv flaw, presuming, of course,
31. 98000 1:38 - 1:41
    that we could have found a way to rig up a Pentium in concert with a 487
32. 101000 1:41 - 1:44
    in such a way that they could have cooperated to do the testing.