Re: quality control

Richard, thanks for your reply, however checking 1400 out of the 1500
items does not seem like a cost-effective approach. I may not have
phrased the question correctly and also did some additional research.

I'm thinking with the binary outcome of fail/not fail, then this is
more of just a sampling question and knowing there are 1500 items is
irrelevant. So, if I suspect that 1% of the items fail, and put a
confidence interval around this estimate with a width of plus/minus 10%
(that is, the interval would go from .09% to 1.1%), then I would need
to sample 38 with 95% confidence. That is, I can say that my sample of
38 will contain 1% of the proportion that fails 95% of the time.



Richard Ulrich wrote:
On 12 Nov 2006 17:00:04 -0800, "Frank" <deps_bear@xxxxxxxxx> wrote:

If I know a product fails .01% of the time and I have 1500 items I'm
running through a process. How many items do I need to check with,
say, 99% confidence that all the items are built correctly.

How many failures do you expect? Almost always, zero.
This is dealing with exact probabilities. For a higher failure
rate, you might want to look at the p of success, and raise
to a power, e.g., (.9999)^n . For the tiny p of 0.01%,
the figuring can be pretty much additive

You want to have only so many items *unchecked* that there
will be, on the average, only 1 bad item in 100 samplings --
so that 99 times out 100, there will be none.

You expect 1 failure in 10,000. One hundred samplings
that each fail to test 100 items will meet that condition.
So you need to check 1400 of each 1500.


--
Rich Ulrich, wpilib@xxxxxxxx
http://www.pitt.edu/~wpilib/index.html

.

Relevant Pages

  • Re: quality control
    ... Almost always, zero. ... will be, on the average, only 1 bad item in 100 samplings -- ... You expect 1 failure in 10,000. ... I'm thinking with the binary outcome of fail/not fail, ...
    (sci.stat.math)
  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... the correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.crypt)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.math)
Loading