A field visualization should answer a question, not just fill space with arrows. Density, length, color, and labels all change what a reader thinks is important.
Think like a programmer
A rendering is a lossy view of a data function. Treat arrow count, length cap, and color scale as explicit display configuration, then keep exact probe values outside the canvas.
Model checklist
Inputs
Field function, sampling grid, and visual scale.
State
Display settings and a probe position.
Rule
Sample the field and map values to arrows.
Output
A readable view plus exact text values.
Check
Changing density does not change a probe's mathematical value.
Loading the interactive visual. The lesson text and model remain available while it starts.
Try this experiment
Prediction: Grid density changes the picture, not the field at the selected probe.
Change grid half-width while holding the probe still. Verify that the text value stays the same, then describe one trade-off in a denser view.
Where this model breaks
Arrow direction and length can hide scale, uncertainty, or values between samples. Never use color or a canvas alone for a conclusion that needs an exact numerical reading.
Summary
Choose a field visual for the question at hand. Add a legend and text probe values so rendering choices do not become accidental scientific claims.
Glossary
Sampling density: number of field locations drawn.
Visual scale: rule that maps a data value to a displayed size or color.
Legend: explanation of visual encodings.
Self-check
Does denser sampling change a field function?
Why provide values outside the canvas?
What visual choice can hide large differences?
Sources
E. R. Tufte, The Visual Display of Quantitative Information.
Model contract
Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.
Quantities you set or measure, with units and useful bounds.
State
Values the program must retain to reproduce the next result.
Rule
The relationship or update that turns inputs and state into a result.
Check
A known limit, unit check, invariant, or measured result that can expose a bad model.
Implement the idea as a model
For Visualizing Vectors and Fields, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Vectors and Coordinate Systems, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.
Guided experiment
Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.
Where this model breaks
This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.
Summary
Treat Visualizing Vectors and Fields as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.
Glossary
Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.
Self-check
Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?
Model review: turn Visualizing Vectors and Fields into a test
Compare arrow sampling density and probe values to learn what a field visual communicates—and what it can hide.
Name the inputs and units that the vectors and coordinate systems model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.