Probability calculation of Python Counter object

Probability Calculation with Python Counter Objects Previously, we read the data and calculated the summary information in two separate passes. Sometimes, it is necessary to create the summary information when reading the initial data; this optimization can save processing time. We can write a more complex input reduction operation to calculate all totals, rotation totals, and defect type totals. These Counter objects are constructed one item at a time.

Previously, we focused on using Counter instances because they are flexible. Any changes to the data collection will still create Counter instances and will not change subsequent analysis.

The defect probabilities calculated by shift and defect type are as follows:

from fractions import Fraction
P_shift = {
shift: Fraction(shift_totals[shift], total)
for shift in sorted(shift_totals)
}
P_type = {
type: Fraction(type_totals[type], total)
for type in sorted(type_totals)
}

This creates two mappings: P_shift and P_type. The dictionary P_shift maps a shift to a Fraction object representing the contribution of that shift to the total number of defects. Similarly, the dictionary P_type maps a defect type to a Fraction object representing the contribution of that type to the total number of defects.

We chose the Fraction object to preserve the precision of all input values because, when dealing with counts like this, we want to get more intuitive probability values that are easier for humans to view the data.

The values of the data P_shift are as follows:

{'1': Fraction(94, 309), '2': Fraction(32, 103),
'3': Fraction(119, 309)}

The values of the data P_type are as follows:

{'A': Fraction(74, 309), 'B': Fraction(23, 103),
'C': Fraction(128, 309), 'D': Fraction(38, 309)}

For some people, values like 32/103 or 96/309 are more meaningful than 0.3106. Getting a float value from a Fraction object is easy, as we’ll show later.

In Python 3.6, dictionary keys retain the order of the keys in the source data. In previous Python versions, the order of the keys was unpredictable. In this example, the order doesn’t matter, but it helps when the order is predictable.

All rotations appear to have about the same level of defect generation. The defect types vary, which is typical. Defect C appears to be a relatively common problem, while defect B is less common, though the second defect may only appear in more complex situations.