# Programming for Trading Research Build a reproducible analysis pipeline with explicit data contracts. Use this workbook alongside the course. Write your answers before opening the solutions. Practical work is self-reviewed; scored knowledge checks are in the Academy. ## 1. Programming foundations ### Types and units Represent prices, quantities, timestamps and identifiers with explicit types and units. A string that looks numeric should not be accepted silently in arithmetic. Financial calculations also need a deliberate decimal or integer-unit policy where rounding affects results. ### Functions and modules Functions should perform bounded transformations with named inputs and outputs. Separate data loading, feature calculation and reporting so each can be inspected independently. A function that both fetches changing data and calculates a result is harder to reproduce. ### Errors and missing values Errors and missing values should have explicit behavior. A failed data request is not an empty but valid market, and a missing multiplier is not zero. Return a clear unavailable state or raise an error before dependent calculations proceed. ### Deterministic transformations Deterministic transformations produce the same output from the same inputs and configuration. Remove hidden dependence on current time, random seeds or mutable global state unless it is explicitly part of the experiment and recorded. ### Worked example A function computes P&L from entry, exit, quantity and multiplier but reads direction from a global variable. Running it after another task changes the global direction and flips the result. Direction belongs in the explicit input contract. ### Independent exercise Write pseudocode for a pure linear-P&L function with validation. Include long/short direction and nonnegative quantity. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 2. Research tools ### Tabular operations Tabular operations should preserve row identity and expected counts. Joins can multiply rows when keys are not unique. Check cardinality before and after combining fills, specifications or economic observations. ### Time indexes Time indexes need timezone and availability semantics. Sorting by display text can differ from chronological order. Use parsed timestamps and distinguish event time from receipt or publication time. ### Vectorized calculations Vectorized calculations can improve clarity and efficiency, but alignment rules matter. Two series with different indexes may align by labels rather than row position. Verify the intended behavior instead of assuming a plausible-looking result is correct. ### Visualization with honest scales Plots should be generated from the same validated outputs used in tables. Label units, scales and transformations. A visual inspection complements numeric checks but cannot substitute for reconciliation of the underlying data. ### Worked example A specifications table contains two rows for the same symbol. Joining ten fills against it produces twenty rows and doubles aggregate P&L. The arithmetic on each row may be correct while the join is wrong. ### Independent exercise Specify an invariant that catches this error and a policy for conflicting specification versions. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 3. Engineering practices ### Version control Version control records changes to code and configuration. Commit identifiers help connect results with implementation, but untracked data or hidden environment settings can still prevent reproduction. ### Environment pinning Pin dependencies or record exact versions when behavior matters. A library update can alter defaults, numerical results or parsing. Reproduction instructions should identify the runtime and relevant package versions. ### Configuration separation Separate configuration from code and validate it at startup. Research parameters, data paths and execution settings should be explicit. Never infer a live endpoint from a convenient default in a teaching script. ### Secrets management Keep secrets out of source files, exported reports and logs. Use an appropriate credential store or environment mechanism and restrict access. A reproducible research package should describe required credentials without including their values. ### Worked example A report records a code commit but not the fee configuration. Another learner runs the same code with zero fees and gets a different conclusion. The commit alone was an incomplete experiment identifier. ### Independent exercise List the artifacts needed to reproduce that report without exposing credentials. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## 4. Verification ### Unit and invariant checks Unit checks test a bounded calculation; invariants test properties that should hold across many cases. For accounting, examples include quantity reconciliation and gross-minus-costs equalling net result under the stated convention. ### Golden datasets A golden dataset is a small, independently understood set of inputs and expected outputs. It should include losses, partial fills and invalid cases rather than mirror only the current implementation's happy path. ### Numerical tolerance Numerical tolerance should reflect units and the calculation, not merely be loosened until tests pass. Explain why a difference is acceptable and keep accounting rounding distinct from floating-point approximation. ### Independent result reconciliation Independent reconciliation compares the system with a separate calculation or authoritative record. Two outputs from the same flawed function are not independent confirmation. Investigate differences before publishing the result. ### Worked example A test calculates its expected P&L by calling the same function it is testing. It passes even when the function reverses short direction. The expected result must come from an independent calculation. ### Independent exercise Create three meaningful test cases for the P&L function: a winning short, a zero-size position and an invalid multiplier. My inputs and assumptions: My calculation or decision: Evidence that would change my conclusion: ## Course project Deliver a small tested pipeline from raw observations to a research report. ### Self-review rubric - Concepts and reasoning: 25% - Calculations, data and evidence: 30% - Process and risk controls: 25% - Limitations and communication: 20% Record one correction and one next practice task. This rubric is not automatically graded. ## Worked solutions ### Exercise 1 Validate finite numeric prices and multiplier, positive multiplier, nonnegative quantity and an allowed direction. Return direction-sign × (exit−entry) × quantity × multiplier. Keep fees as an explicit additional input or separate named calculation. ### Exercise 2 Require one applicable specification per fill at its event time, verify output cardinality and reject ambiguous matches. Version specifications by effective time rather than choosing an arbitrary duplicate. ### Exercise 3 Include code version, configuration, dependency versions, data identifiers or hashes, transformation instructions and expected outputs. Describe access requirements separately and exclude secret values. ### Exercise 4 Use known arithmetic for the short, expect zero gross P&L for zero quantity under the allowed contract, and require an explicit error for an invalid multiplier. These cases test behavior rather than restating the implementation. ## Further reading - https://docs.python.org/3/tutorial/ - https://scikit-learn.org/stable/common_pitfalls.html