## ← Fdiv - Software Testing

• 2 Followers
• 30 Lines

### Get Embed Code x Embed video Use the following code to embed this video. See our usage guide for more details on embedding. Paste this in your document somewhere (closest to the closing body tag is preferable): ```<script type="text/javascript" src='https://amara.org/embedder-iframe'></script> ``` Paste this inside your HTML body, where you want to include the widget: ```<div class="amara-embed" data-url="http://www.youtube.com/watch?v=NDUyvz5Lf_M" data-team="udacity"></div> ``` 1 Language

• English [en] original

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

1. All right. Let's try to work out the math.
2. So what we have is, by assumption, we can run 1 test every 10 microseconds.
3. Now, there are a million microseconds in a second, 60 seconds in a minute,
4. and 60 minutes in an hour, and 24 hours in a day.
5. So now we're going to do some unit cancellation.
6. We can kill microseconds, we can kill minutes, we can kill seconds,
7. and we can kill hours.
8. So if we do the multiplication, we can get tests per day.
9. And if we do that, we get 8,640,000,000 tests per day.
10. If we multiply this testing throughput by the failure rate
11. we're going to get 1 failure per 9 billion tests.
12. We can cancel tests, do the division, and arrive at 0.96 expected failures per day.
13. So under what I think are fairly modest assumptions here,
14. if we perform completely random testing of the input space for fdiv,
15. we should be able to find this bug in about a day.
16. And so now this kind of testing is going to need some sort of an oracle.
17. So we're going to need a way to tell if our particular output from fdiv is correct or not.
18. And the way this is going to work is IEEE floating point,
19. which is what fdiv is implementing, is specified very tightly.
20. That is to say, one implementation of IEEE floating point division
21. has to return the same bit pattern as another implementation.
22. That's one of the nice things about that particular specification is that it's fairly tight.
23. So we ask ourselves, what would have been the oracle for fdiv?
24. And probably it would have been Intel's existing 487 floating point unit,
25. which had been around for some years by the time they were developing the Pentium.
26. So what I think this shows, unless I've messed up sort of egregiously on the math somewhere,
27. is that random testing would have been a perfectly good way
28. to find the Intel Pentium fdiv flaw, presuming, of course,
29. that we could have found a way to rig up a Pentium in concert with a 487
30. in such a way that they could have cooperated to do the testing.