3.05 Boolean Expressions HW
3.05 Boolean Expressions — Homework (SFI Backend Validator)
Lesson: https://pages.opencodingsociety.com/python/boolean/2027
Theme: SFI automotive safety-spec backend. A Boolean expression answers one backend question: does this record satisfy every rule required before it is accepted?
College Board connection: comparisons produce Booleans; and means all requirements must pass, or means either option is acceptable, and not rejects a duplicate. AP pseudocode uses = for comparison, while Python uses ==.
Popcorn Hack 1 — Check One SFI Part Record
An SFI record is complete when it has a product name, a racing category, a spec number, and an effective date. Auto Racing and Drag Racing are the accepted categories.
Prediction: the first run prints all True because every field is present and Auto Racing is accepted. Changing the category to Street Car flips only valid_category to False.
Code Runner Challenge
Popcorn Hack 1 — Check One SFI Part Record. Run the code, then change the category to Street Car and run again to see valid_category flip to False.
Output recorded: Has product name: True, Valid category (Auto Racing OR Drag Racing): True, Has spec number: True, Has effective date: True; changed run prints Street Car -> valid: False.
Explanation: all four checks are True for the starter record, so it is complete. valid_category uses in ["Auto Racing", "Drag Racing"], which is Python for (category = "Auto Racing") OR (category = "Drag Racing"). Any other category, such as Street Car, makes that check False.
Popcorn Hack 2 — Backend Create Rule
The backend receives the same style of SFI part record. A new record should be created only when every required field is valid and its spec number is not already stored.
Prediction: the starter record has spec 1.1, which already exists, so it prints REJECT even though its fields are valid. A new record with spec 1.2 prints CREATE.
Code Runner Challenge
Popcorn Hack 2 — Backend Create Rule. Run both cases: spec 1.1 should REJECT (duplicate) and spec 1.2 should CREATE.
Output recorded: Starter (spec 1.1) can_create: False -> REJECT record; New part (spec 1.2) can_create: True -> CREATE record in backend.
Explanation: the starter fails only on duplicate_spec = True, so ... and (not True) becomes False. The 1.2 record passes all five checks, so the entire and chain is True. Testing both branches proves the rule accepts valid data and rejects duplicates.
Popcorn Hack 3 — SFI Search Filter
An SFI backend search can match a record by product name or by exact spec number. Results should include only records from accepted racing categories.
Prediction: query "1.2" matches exactly one record by spec number. Query "Flywheel" matches by name and returns two records, both in accepted categories. Changing the query changes the result without changing the logic.
Code Runner Challenge
Popcorn Hack 3 — SFI Search Filter. Run the code, then change the query to "Flywheel" and run again to see the filter adapt.
Output recorded: Query "1.2" -> 1 match (Multiple Disc Clutch Assemblies | Drag Racing | spec 1.2); query "Flywheel" -> 2 matches (both in accepted categories).
Explanation: (name_match or spec_match) and valid_category is the entire filter. "1.2" hits only through spec_match; "Flywheel" hits through name_match. A record with a matching name but a category such as Street Car would still be excluded by the and valid_category gate.
In-class MCQ Check
Recorded result line copied from the in-class check:
MCQ 3.05: 4/4 | answers: A,C,A,B
Homework Hack (independent): SFI Backend Validator
Build a reusable validator for candidate SFI automotive records.
A valid record has:
- a non-empty product name,
- an accepted racing category (
Auto RacingorDrag Racing), - a non-empty spec number,
- a non-empty effective date,
- and a spec number that does not already exist in the backend.
The provided starter data includes three cases. The completed runner below validates every supplied record, prints ACCEPT or REJECT, and also tests edge cases: an empty product name, an invalid category, and a duplicate spec. The validator is self-contained so it can run on its own.
Code Runner Challenge
Homework Hack — SFI Backend Validator. Run the supplied records and edge cases to see each ACCEPT/REJECT decision.
Output recorded: the three supplied records produce ACCEPT RECORD for spec 1.2, REJECT RECORD for spec 3.1 (invalid Street Car category), and REJECT RECORD for spec 1.1 (duplicate). The edge cases also reject an empty product name, an invalid category, and a duplicate spec.
Explanation: the validator breaks the English rule into named Boolean checks before combining them. and enforces all required fields, in valid_categories implements the Auto Racing OR Drag Racing rule, and not duplicate_spec rejects specs already stored. Returning the checks dictionary makes each accept/reject decision traceable back to the exact condition that failed.
College Board pseudocode trace
The same rule in AP CSP pseudocode:
hasProductName <- (productName != "")
validCategory <- (category = "Auto Racing") OR (category = "Drag Racing")
hasSpecNumber <- (specNumber != "")
hasEffectiveDate <- (effectiveDate != "")
duplicateSpec <- (specNumber = "1.1") OR (specNumber = "2.1")
isValid <- hasProductName AND validCategory AND hasSpecNumber AND hasEffectiveDate AND NOT duplicateSpec
IF (isValid)
{
DISPLAY("ACCEPT RECORD")
}
ELSE
{
DISPLAY("REJECT RECORD")
}
Trace: 1.2 / Auto Racing / new -> T AND T AND T AND T AND NOT F = T -> ACCEPT. 3.1 / Street Car -> validCategory = F -> REJECT. 1.1 / Drag Racing / duplicate -> NOT T = F -> REJECT. The Python validator makes the same decisions.
| Notes for submission: Lesson: CSP 3.05 Boolean Expressions | MCQ 3.05: 4/4 | Popcorn Hacks 1–3 completed and copied to notebook: yes | Homework tested: 3 supplied records (1 ACCEPT, 2 REJECT) plus 3 edge cases (empty name, invalid category, duplicate spec), all rejected for the expected reason. |