Ch16 Discussion

Discussion Guide

Warm-up (think–pair–share, 5 min). "Name a library you have used — in any language — that you now suspect is Fortran (or calls Fortran) underneath." Surfaces the numpy/MATLAB/R → LAPACK realization and motivates §16.1.

Main discussion (15–20 min). 1. The overnight speedup. Present Case Study 1's puzzle: a colleague's Python got 2× faster after installing a different math library, with no code change. Have the class locate the change in the tower (Python → LAPACK → BLAS → tuned kernel). Use it to teach the threshold concept: you speed up numerical code by choosing the tuned library, not by rewriting loops. 2. Convention vs configuration. Put a hand-written Makefile beside an fpm.toml. Ask: what did fpm's conventions let us delete, and what did we give up? (We gave up fine control of layout; we deleted the error-prone module-order bookkeeping of Ch. 8.) Good place to discuss when conventions help and when a big HPC code needs CMake instead (Ch. 36). 3. Honest naming. "Is FFTW written in Fortran? Is NetCDF?" Use the (correct) answer — no, C cores with Fortran interfaces; only LAPACK/BLAS reference impls are Fortran — to model precision of claim and citation honesty, echoing the discipline from Ch. 1.

Group activity (10 min). In pairs, students write the fpm.toml and the app/–src/–test/ tree for the heat solver (Exercise 16.28), then swap with another pair and "review" it: is the dependency an inline table? Is it pinned? Does a program sit in app/, modules in src/? Peer review of a manifest is a transferable, real-world skill.

Exit ticket. "Decode dgesv, and name the one command that builds an fpm project." (Checks §16.1 name reading and §16.3; anything correct on precision·type·operation and fpm build is a pass.)