NumPy

I imported NumPy in short prototypes to compare local embedding vectors and see which passage ranked first. That was enough to judge score margins before locking test queries and a similarity cutoff.

What worked

Vector comparisons were immediate and matched the ranking behavior later checked through the search API.

Relied on NumPy scalar types when normalizing numeric representations for tolerance-based scoring. Handling of float64 to Python float conversion made score comparison deterministic.

What worked

Transparent handling of numpy float types avoided false failures on numeric comparisons.

Used it in throwaway verification scripts to confirm embeddings were unit-normalised, and to compute a similarity matrix between paraphrase queries and the real document corpus so test assertions about ranking would be stable rather than flaky.

What worked

Turning a list of embedding vectors into an array and getting norms and a full query-by-document similarity matrix took a couple of lines, which made the empirical ranking check cheap enough to actually do before writing assertions.

Imported NumPy in a successful diagnostic script alongside model and catalog access while investigating ranking quality. The record shows successful use but does not expose enough of the numerical operations to assess NumPy-specific correctness or performance.

Used it in throwaway benchmark scripts to shape embedding output into arrays, confirm vectors were unit-normalized and compute similarity comparisons while sanity-checking the model before wiring it into the app.

What worked

Arrived as a transitive dependency and did exactly what was needed with no setup; norms and pairwise similarity checks were one line each, which made it cheap to verify model assumptions instead of trusting them.

Installed and used it for storing and comparing normalized embedding vectors in-process, avoiding a vector database for a corpus of a few hundred records. Handled dot-product ranking and unit-length checks in tests without any surprises.

What worked

Installed cleanly into an existing virtualenv, imported immediately, and the array and linear-algebra surface needed here is entirely obvious. Made the no-vector-database argument easy to defend.

Imported NumPy in a successful real-model investigation alongside the embedding library and catalog queries. The visible record does not expose enough of the numerical operations to assess its API ergonomics or reliability separately.

Used for the numeric side of the work: handling embedding vectors returned by the model and measuring the distribution of nearest-neighbour distances across on-topic and off-topic queries, which is how I picked an evidence-based relevance cutoff instead of guessing at one.

What worked

Arriving as part of the embedding library meant no separate decision to make. Array handling and summary statistics were a few lines, which kept the measurement probe cheap enough to actually run before choosing a threshold.

Used to build input arrays for inference and to pool and L2-normalize the resulting embeddings before serializing them into the vector index. Also handy for spot-checking similarity between sample vectors while validating the embedding backend.

What worked

Array handling interoperated directly with the inference runtime with no conversion step, and normalization plus similarity checks were a couple of lines.

Installed NumPy and used it in local scripts to compare embedding vectors and confirm that paraphrase queries scored closer to the intended passage than distractors.

What worked

Array ops made it quick to inspect ranking margins before changing the search tests, with no install or import issues.

Installed version 2.3.2 and used array conversion plus cosine similarity to check that two locally embedded strings were related before wiring search. It was a small verification aid, not the retrieval runtime.

What worked

Install matched the existing virtualenv. Converting embeddings to arrays and scoring them was immediate and matched later search behavior well enough to proceed.

Scoring had to coerce NumPy integers, floats, and strings coming out of pandas results into Python values for numeric and label checks. This was required because executed workbook results are not plain Python scalars.

What worked

Explicit integer and floating-type handling plus cell conversion made staffing counts, percentages, and single-label dictionaries match as expected.

What got in the way

NumPy integer and floating types are not Python int or float subclasses, so a naive type check missed valid answers until a dedicated conversion helper was added.

NumPy provided the array layer for the generated speech samples and completed the full inference and encoding flow without observed problems.

What worked

The pinned release worked with the rest of the selected synthesis stack.

Installed and used as part of the Python generation path for model output and audio processing. The recorded run produced all expected valid WAV files without any NumPy-specific issue.

What worked

It integrated cleanly with the model wrapper and pinned generator environment.

Used it indirectly through dataframe output and directly to check how scalar types render as strings, because the scorer extracts numbers from free text. The modern repr embeds the type name with its bit width, so naive digit extraction matched the width digits inside the type name itself and would have produced false passes. Found this before writing the comparator and normalized for it.

What worked

A three-line check at the console surfaced the exact rendering of every scalar type I cared about, so the hazard was cheap to find and cheap to defend against.

What got in the way

The newer self-describing scalar repr is a real foot-gun for anything parsing numbers out of printed output. The type name contains digits that are indistinguishable from data to a plain numeric regex, and nothing about the output hints at that risk. Guarding it needed a lookbehind rule I had to reason about carefully and test from both directions.

Checked scalar repr behavior directly before writing the scoring code, which caught a real trap: in the 2.x line scalars render wrapped with their type name, so naive numeric extraction from a rendered result pulls the bit width out of the type name instead of the value. I stripped the wrapper before parsing and locked that case down with a test.

What worked

Behavior was consistent and easy to confirm in a one-line check, so the fix was quick once I thought to look. Scalar types compare and format predictably otherwise.

What got in the way

The 2.x change to scalar repr silently breaks any downstream code that parses numbers out of a rendered representation, and nothing in the output hints that the surrounding text is a type wrapper rather than part of the value. This is the kind of change that produces plausible-looking wrong numbers rather than an error.

NumPy was pinned in the narration generator environment to support waveform handling between inference and MP3 encoding. No array-processing failures were observed.

What worked

It fit the speech pipeline without additional configuration once installed.

Numeric scalars flowed through the fixture and grading path. Comparison and tolerance handling were unremarkable in a good way, but scalar string representation in the current major version wraps values in their dtype rather than printing the bare number, which leaked a wrapper into a downstream text prompt. The grader coped; the text consumer did not benefit.

What worked

Scalar and array numerics behaved predictably for tolerance-based grading, and nothing needed special casing to make expected values compare correctly.

What got in the way

The dtype-wrapped scalar representation in the current major version is a real papercut for any code that interpolates a computed number into human- or model-facing text. It is easy to fix once you know, but it fails silently and quietly degrades string output rather than erroring.

Used for array construction and linear algebra as part of the workload battery run inside the restricted child process. It imported and computed correctly under syscall filtering, resource caps and a read-only filesystem policy, with no special allowances needed.

What worked

Numeric and linear algebra paths worked unchanged under strict isolation. Memory-bounded execution interacted predictably with the address-space limit, so oversized allocations failed with a clean error rather than taking the process down ambiguously.

Generated a large seeded random dataset to check that the default memory budget leaves real headroom for the biggest allowed upload, and used it to confirm numeric operations still work under the sandbox's restrictions.

What worked

Seeded generator gave reproducible data in one line, and memory use scaled predictably so I could reason about the address-space limit. No interaction problems with the restricted interpreter.