When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

Python collections.Counter is a dict subclass for counting hashable objects, but it is richer than a positive-frequency table. A missing key reads as zero, explicit zero and negative counts can remain stored, update adds rather than replaces, subtract can cross below zero, elements ignores non-positive counts, and multiset operators deliberately discard non-positive results. Mastery means predicting both the numeric mapping and the stored-key order, choosing the right operation for replacement or accumulation, and normalising only when the domain actually requires a positive multiset. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

Counter(iterable) increments one count for each hashable item and preserves first encounter order as key insertion order. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is passing a mapping-shaped sequence and expecting its values to become counts. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Construction from an iterable counts occurrences, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Construction from an iterable counts occurrences chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on passing a mapping-shaped sequence and expecting its values to become counts. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

from collections import Counter
c=Counter(['red','blue','red'])
print(c)

Four purposeful transfer cases

Case 1: reading vocabulary. Predict the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: canteen survey. Contrast the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science samples. Stress-test the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: revision tracker. Explain the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers passing a mapping-shaped sequence and expecting its values to become counts.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Construction from an iterable counts occurrences, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Construction from an iterable counts occurrences?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing passing a mapping-shaped sequence and expecting its values to become counts be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA equipment with required and available quantities are compared as multisets. Include one ordinary case, one boundary and one deliberate failure caused by passing a mapping-shaped sequence and expecting its values to become counts. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Construction from an iterable counts occurrences, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter(mapping) copies keys with their supplied numeric counts, including zero and negative values. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming construction always counts how many mapping entries exist. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Construction from a mapping uses supplied counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Construction from a mapping uses supplied counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming construction always counts how many mapping entries exist. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter({'red':3,'blue':-1,'green':0})
print(c['red'],c['blue'],c['green'])

Four purposeful transfer cases

Case 1: science samples. Contrast the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: revision tracker. Stress-test the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: library returns. Explain the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA equipment. Transfer the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming construction always counts how many mapping entries exist.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Construction from a mapping uses supplied counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Construction from a mapping uses supplied counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming construction always counts how many mapping entries exist be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with missing, zero, negative, duplicate and tied values expose every boundary. Include one ordinary case, one boundary and one deliberate failure caused by assuming construction always counts how many mapping entries exist. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Construction from a mapping uses supplied counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Keyword arguments provide counts for identifier-shaped string keys, which is convenient but less general than a mapping. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is trying to express spaces, integers or arbitrary objects as keyword names. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Keyword construction names string keys, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Keyword construction names string keys chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to express spaces, integers or arbitrary objects as keyword names. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(red=2,blue=1)
print(c)

Four purposeful transfer cases

Case 1: library returns. Stress-test the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA equipment. Explain the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Transfer the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Predict the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers trying to express spaces, integers or arbitrary objects as keyword names.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Keyword construction names string keys, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Keyword construction names string keys?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to express spaces, integers or arbitrary objects as keyword names be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with Counter is compared with dict, defaultdict and a full records table. Include one ordinary case, one boundary and one deliberate failure caused by trying to express spaces, integers or arbitrary objects as keyword names. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Keyword construction names string keys, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter returns zero for a missing key instead of raising KeyError, and a read alone does not add that key to iteration. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is testing a missing key and assuming the key is now stored. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Missing keys read as zero without insertion, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Missing keys read as zero without insertion chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing a missing key and assuming the key is now stored. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=1)
print(c['missing'],'missing' in c,list(c))

Four purposeful transfer cases

Case 1: test laboratory. Explain the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Transfer the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading vocabulary. Predict the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: canteen survey. Contrast the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing a missing key and assuming the key is now stored.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Missing keys read as zero without insertion, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Missing keys read as zero without insertion?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing a missing key and assuming the key is now stored be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading vocabulary with repeated words become counts while punctuation policy stays explicit. Include one ordinary case, one boundary and one deliberate failure caused by testing a missing key and assuming the key is now stored. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Missing keys read as zero without insertion, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Setting c[key]=0 records the key with a zero value; del is required when the key should disappear. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating numeric zero and key absence as the same structural state. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Assigning zero keeps a stored key, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Assigning zero keeps a stored key chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating numeric zero and key absence as the same structural state. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=1); c['a']=0
print('a' in c,list(c.items())); del c['a']; print('a' in c)

Four purposeful transfer cases

Case 1: reading vocabulary. Transfer the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: canteen survey. Predict the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science samples. Contrast the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: revision tracker. Stress-test the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating numeric zero and key absence as the same structural state.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Assigning zero keeps a stored key, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Assigning zero keeps a stored key?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating numeric zero and key absence as the same structural state be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny canteen survey with meal choices are tallied and tied choices retain first-seen order. Include one ordinary case, one boundary and one deliberate failure caused by treating numeric zero and key absence as the same structural state. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Assigning zero keeps a stored key, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter.update adds counts from an iterable or mapping to existing counts. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is importing dict.update intuition and expecting replacement. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for update adds counts rather than replacing them, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the update adds counts rather than replacing them chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on importing dict.update intuition and expecting replacement. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=2); c.update({'a':3,'b':1}); print(c)

Four purposeful transfer cases

Case 1: science samples. Predict the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: revision tracker. Contrast the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: library returns. Stress-test the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA equipment. Explain the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers importing dict.update intuition and expecting replacement.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for update adds counts rather than replacing them, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from update adds counts rather than replacing them?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing importing dict.update intuition and expecting replacement be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science samples with observations can be added, corrected and compared. Include one ordinary case, one boundary and one deliberate failure caused by importing dict.update intuition and expecting replacement. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For update adds counts rather than replacing them, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter.subtract subtracts source counts in place and retains results at or below zero. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting subtraction to clip every value at zero. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for subtract can create zero and negative counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the subtract can create zero and negative counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting subtraction to clip every value at zero. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=3,b=1); c.subtract({'a':1,'b':4,'c':2}); print(c)

Four purposeful transfer cases

Case 1: library returns. Contrast the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA equipment. Stress-test the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Explain the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Transfer the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting subtraction to clip every value at zero.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for subtract can create zero and negative counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from subtract can create zero and negative counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting subtraction to clip every value at zero be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with attempts and recovered mistakes produce signed counts. Include one ordinary case, one boundary and one deliberate failure caused by expecting subtraction to clip every value at zero. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For subtract can create zero and negative counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

total returns the arithmetic sum of all counts, including zero and negative values. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is calling total the number of elements when signed corrections are present. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for total sums every stored count, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the total sums every stored count chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling total the number of elements when signed corrections are present. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=5,b=-2,c=0); print(c.total())

Four purposeful transfer cases

Case 1: test laboratory. Stress-test the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Explain the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading vocabulary. Transfer the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: canteen survey. Predict the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers calling total the number of elements when signed corrections are present.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for total sums every stored count, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from total sums every stored count?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling total the number of elements when signed corrections are present be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library returns with book codes are counted and zero balances are distinguished from deletion. Include one ordinary case, one boundary and one deliberate failure caused by calling total the number of elements when signed corrections are present. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For total sums every stored count, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

elements returns each key repeated its count times in encounter order and ignores counts below one. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting zero, negative or fractional counts to produce meaningful repetitions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for elements emits positive integer repetitions, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the elements emits positive integer repetitions chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting zero, negative or fractional counts to produce meaningful repetitions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=2,b=-1,c=1); print(list(c.elements()))

Four purposeful transfer cases

Case 1: reading vocabulary. Explain the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: canteen survey. Transfer the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science samples. Predict the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: revision tracker. Contrast the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting zero, negative or fractional counts to produce meaningful repetitions.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for elements emits positive integer repetitions, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from elements emits positive integer repetitions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting zero, negative or fractional counts to produce meaningful repetitions be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA equipment with required and available quantities are compared as multisets. Include one ordinary case, one boundary and one deliberate failure caused by expecting zero, negative or fractional counts to produce meaningful repetitions. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For elements emits positive integer repetitions, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

most_common returns descending counts, and equal counts retain the order first encountered. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming ties are alphabetically sorted. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for most_common orders by count then encounter order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the most_common orders by count then encounter order chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming ties are alphabetically sorted. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(['b','a','c','a','b']); print(c.most_common())

Four purposeful transfer cases

Case 1: science samples. Transfer the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: revision tracker. Predict the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: library returns. Contrast the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA equipment. Stress-test the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming ties are alphabetically sorted.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for most_common orders by count then encounter order, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from most_common orders by count then encounter order?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming ties are alphabetically sorted be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with missing, zero, negative, duplicate and tied values expose every boundary. Include one ordinary case, one boundary and one deliberate failure caused by assuming ties are alphabetically sorted. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For most_common orders by count then encounter order, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

most_common(n) returns at most n pairs, while omitting n returns all stored items including non-positive tails. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is slicing an assumed alphabetical list instead of using count order. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for most_common n limits the result, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the most_common n limits the result chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on slicing an assumed alphabetical list instead of using count order. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=4,b=2,c=1); print(c.most_common(2))

Four purposeful transfer cases

Case 1: library returns. Predict the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA equipment. Contrast the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Stress-test the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Explain the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers slicing an assumed alphabetical list instead of using count order.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for most_common n limits the result, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from most_common n limits the result?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing slicing an assumed alphabetical list instead of using count order be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with Counter is compared with dict, defaultdict and a full records table. Include one ordinary case, one boundary and one deliberate failure caused by slicing an assumed alphabetical list instead of using count order. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For most_common n limits the result, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

As a dict subclass, Counter remembers key insertion order; updates do not move an existing key merely because its count changes. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is predicting order from current count alone after an update. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Dictionary order still matters, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Dictionary order still matters chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on predicting order from current count alone after an update. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(); c.update(['x','y']); c.update(['y','x','z']); print(list(c))

Four purposeful transfer cases

Case 1: test laboratory. Contrast the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Stress-test the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading vocabulary. Explain the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: canteen survey. Transfer the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers predicting order from current count alone after an update.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Dictionary order still matters, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Dictionary order still matters?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing predicting order from current count alone after an update be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading vocabulary with repeated words become counts while punctuation policy stays explicit. Include one ordinary case, one boundary and one deliberate failure caused by predicting order from current count alone after an update. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Dictionary order still matters, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter equality treats absent items as having zero count, so explicit zero does not make two counters unequal. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is comparing the raw item lists and rejecting equal count functions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Equality treats missing counts as zero, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Equality treats missing counts as zero chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on comparing the raw item lists and rejecting equal count functions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

print(Counter(a=1)==Counter(a=1,b=0))

Four purposeful transfer cases

Case 1: reading vocabulary. Stress-test the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: canteen survey. Explain the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science samples. Transfer the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: revision tracker. Predict the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers comparing the raw item lists and rejecting equal count functions.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Equality treats missing counts as zero, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Equality treats missing counts as zero?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing comparing the raw item lists and rejecting equal count functions be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny canteen survey with meal choices are tallied and tied choices retain first-seen order. Include one ordinary case, one boundary and one deliberate failure caused by comparing the raw item lists and rejecting equal count functions. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Equality treats missing counts as zero, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Subset and superset comparisons test whether every effective count is no greater or no smaller, treating missing as zero. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is reading <= as insertion order or ordinary dictionary comparison. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Rich comparisons compare effective counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Rich comparisons compare effective counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading <= as insertion order or ordinary dictionary comparison. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

print(Counter(a=1)<=Counter(a=2,b=1)); print(Counter(a=3)<=Counter(a=2))

Four purposeful transfer cases

Case 1: science samples. Explain the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: revision tracker. Transfer the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: library returns. Predict the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA equipment. Contrast the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers reading <= as insertion order or ordinary dictionary comparison.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Rich comparisons compare effective counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Rich comparisons compare effective counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading <= as insertion order or ordinary dictionary comparison be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science samples with observations can be added, corrected and compared. Include one ordinary case, one boundary and one deliberate failure caused by reading <= as insertion order or ordinary dictionary comparison. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Rich comparisons compare effective counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter addition sums matching counts and returns a new Counter containing only results greater than zero. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting addition to preserve the signed bookkeeping map exactly. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Addition keeps only positive results, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Addition keeps only positive results chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting addition to preserve the signed bookkeeping map exactly. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

a=Counter(x=3,y=-2); b=Counter(x=-1,y=1,z=2); print(a+b)

Four purposeful transfer cases

Case 1: library returns. Transfer the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA equipment. Predict the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Contrast the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Stress-test the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting addition to preserve the signed bookkeeping map exactly.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Addition keeps only positive results, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Addition keeps only positive results?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting addition to preserve the signed bookkeeping map exactly be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with attempts and recovered mistakes produce signed counts. Include one ordinary case, one boundary and one deliberate failure caused by expecting addition to preserve the signed bookkeeping map exactly. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Addition keeps only positive results, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The binary minus operator returns positive differences only, unlike the subtract method that retains signed results. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating c-d and c.subtract(d) as interchangeable. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Subtraction as an operator clips non-positive results, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Subtraction as an operator clips non-positive results chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating c-d and c.subtract(d) as interchangeable. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

a=Counter(x=2,y=1); b=Counter(x=3,y=1); print(a-b); a.subtract(b); print(a)

Four purposeful transfer cases

Case 1: test laboratory. Predict the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Contrast the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading vocabulary. Stress-test the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: canteen survey. Explain the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating c-d and c.subtract(d) as interchangeable.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Subtraction as an operator clips non-positive results, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Subtraction as an operator clips non-positive results?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating c-d and c.subtract(d) as interchangeable be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library returns with book codes are counted and zero balances are distinguished from deletion. Include one ordinary case, one boundary and one deliberate failure caused by treating c-d and c.subtract(d) as interchangeable. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Subtraction as an operator clips non-positive results, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The ampersand operator chooses the minimum count per key and keeps only positive minima. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is confusing Counter intersection with shared key names regardless of quantity sign. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Intersection takes positive minimum counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Intersection takes positive minimum counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on confusing Counter intersection with shared key names regardless of quantity sign. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

a=Counter(x=3,y=1); b=Counter(x=2,y=-1,z=4); print(a & b)

Four purposeful transfer cases

Case 1: reading vocabulary. Contrast the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: canteen survey. Stress-test the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science samples. Explain the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: revision tracker. Transfer the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers confusing Counter intersection with shared key names regardless of quantity sign.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Intersection takes positive minimum counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Intersection takes positive minimum counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing confusing Counter intersection with shared key names regardless of quantity sign be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA equipment with required and available quantities are compared as multisets. Include one ordinary case, one boundary and one deliberate failure caused by confusing Counter intersection with shared key names regardless of quantity sign. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Intersection takes positive minimum counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The vertical-bar operator chooses the maximum count per key and keeps only positive maxima. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using union when the business rule requires adding inventories. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Union takes positive maximum counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Union takes positive maximum counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using union when the business rule requires adding inventories. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

a=Counter(x=3,y=-1); b=Counter(x=1,z=2); print(a | b)

Four purposeful transfer cases

Case 1: science samples. Stress-test the rule using observations can be added, corrected and compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: revision tracker. Explain the rule using attempts and recovered mistakes produce signed counts. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: library returns. Transfer the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA equipment. Predict the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using union when the business rule requires adding inventories.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Union takes positive maximum counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Union takes positive maximum counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using union when the business rule requires adding inventories be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with missing, zero, negative, duplicate and tied values expose every boundary. Include one ordinary case, one boundary and one deliberate failure caused by using union when the business rule requires adding inventories. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Union takes positive maximum counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Unary plus keeps positive counts; unary minus flips negative counts into positive magnitudes and drops the rest. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using unary minus as ordinary numeric negation that preserves every key. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Unary plus and minus normalise signed counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Unary plus and minus normalise signed counts chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using unary minus as ordinary numeric negation that preserves every key. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

c=Counter(a=3,b=-2,c=0); print(+c,-c)

Four purposeful transfer cases

Case 1: library returns. Explain the rule using book codes are counted and zero balances are distinguished from deletion. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA equipment. Transfer the rule using required and available quantities are compared as multisets. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Predict the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Contrast the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using unary minus as ordinary numeric negation that preserves every key.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Unary plus and minus normalise signed counts, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Unary plus and minus normalise signed counts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using unary minus as ordinary numeric negation that preserves every key be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with Counter is compared with dict, defaultdict and a full records table. Include one ordinary case, one boundary and one deliberate failure caused by using unary minus as ordinary numeric negation that preserves every key. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Unary plus and minus normalise signed counts, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Counter fits hashable-item tallies and multisets; ordinary dict fits arbitrary values, defaultdict fits other factories, and record tables fit events whose details must not be collapsed. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using counts when timestamp, source or sequence is essential evidence. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Choose Counter when the domain is a count mapping, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Choose Counter when the domain is a count mapping chapter on Python collections.Counter, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using counts when timestamp, source or sequence is essential evidence. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

tally=Counter(event.category for event in events)

Four purposeful transfer cases

Case 1: test laboratory. Transfer the rule using missing, zero, negative, duplicate and tied values expose every boundary. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Predict the rule using Counter is compared with dict, defaultdict and a full records table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading vocabulary. Contrast the rule using repeated words become counts while punctuation policy stays explicit. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: canteen survey. Stress-test the rule using meal choices are tallied and tied choices retain first-seen order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using counts when timestamp, source or sequence is essential evidence.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Choose Counter when the domain is a count mapping, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Python collections.Counter syntax. For this chapter, useful prompts are: “What did you expect from Choose Counter when the domain is a count mapping?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using counts when timestamp, source or sequence is essential evidence be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading vocabulary with repeated words become counts while punctuation policy stays explicit. Include one ordinary case, one boundary and one deliberate failure caused by using counts when timestamp, source or sequence is essential evidence. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Choose Counter when the domain is a count mapping, separate the documented Python collections.Counter mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. reading vocabulary: model, boundary and recovery

Create a small reading vocabulary using repeated words become counts while punctuation policy stays explicit. Combine “Construction from an iterable counts occurrences” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. canteen survey: model, boundary and recovery

Create a small canteen survey using meal choices are tallied and tied choices retain first-seen order. Combine “Missing keys read as zero without insertion” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. science samples: model, boundary and recovery

Create a small science samples using observations can be added, corrected and compared. Combine “subtract can create zero and negative counts” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. revision tracker: model, boundary and recovery

Create a small revision tracker using attempts and recovered mistakes produce signed counts. Combine “most_common orders by count then encounter order” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. library returns: model, boundary and recovery

Create a small library returns using book codes are counted and zero balances are distinguished from deletion. Combine “Equality treats missing counts as zero” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. CCA equipment: model, boundary and recovery

Create a small CCA equipment using required and available quantities are compared as multisets. Combine “Subtraction as an operator clips non-positive results” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. test laboratory: model, boundary and recovery

Create a small test laboratory using missing, zero, negative, duplicate and tied values expose every boundary. Combine “Unary plus and minus normalise signed counts” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. design decision: model, boundary and recovery

Create a small design decision using Counter is compared with dict, defaultdict and a full records table. Combine “Construction from a mapping uses supplied counts” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for Python collections.Counter
• eduKatePunggol: How Studying Works

Return to contents