The versions were npm’s @sewingselami/sewlore-sewing-math 0.1.0, Packagist’s sewlore/measurement-calculators 1.0.0 and crates.io’s sewlore-sewing-math 0.1.0. The companion harness retains unchanged published source snapshots and SHA-256 values in source-lock.json; python run.py reproduces its ten-case comparison. No hosted pipeline is claimed.

There is an important language distinction. The Drupal module uses PHP to render its calculator block and configure an optional reference link, but its arithmetic runs in JavaScript. Our comparison executed that JavaScript, the npm functions and the Rust command-line program. It did not invent or test a separate PHP implementation. Minimal unchanged source snapshots were tied to the published versions and file hashes before execution.

Unit support and input validation

The straightforward case behaved as expected: converting one inch produced 2.54 centimetres in all three interfaces. Millimetres revealed the first difference. The npm conversion function accepts only centimetres and inches, while the Drupal arithmetic and Rust accept millimetres too. For 25.4mm to inches, the latter two returned one. We marked the npm case unsupported instead of inserting an adapter conversion and implying that the package provided it.

Negative input exposed another contract choice. Converting −1cm to inches returned approximately −0.3937007874 in npm. Drupal and Rust rejected the negative length. Neither outcome proves that one package is generally better. A signed coordinate or mathematical difference can be useful, while a physical length often needs a nonnegative constraint. An integration should choose and document the meaning of its input before calling the function.

One deliberately extreme case tested numerical range rather than sewing practice. Converting the positive binary floating-point value represented by 5e-324 centimetres to inches returned zero in both JavaScript converters. Rust rejected the conversion because it would turn a positive length into zero through underflow. This input is a synthetic software stress case, not a plausible fabric measurement. It illustrates why accepting a finite input does not automatically guarantee a useful converted result.

Stretch recovery and undefined results

The ordinary stretch example agreed across the implementations. Original 10cm, stretched 14cm and released 10.5cm produced 40% stretch, 5% residual change and 87.5% recovered extension. The first two percentages use original length as their denominator. Recovered extension uses the applied extension, which is 4cm here. When all three readings were 10cm, that last denominator was zero. All three interfaces preserved an undefined recovery value, represented as null in their JSON output.

A released reading below the original stayed visible. For 10cm, 15cm and 9.5cm, the results included −5% residual change and approximately 110% recovered extension, with an unusual-reading flag. The values were not clamped into a more comfortable range. Mixed units required more care: Rust normalized 10cm, 140mm and 10.5cm and returned the ordinary 40%, 5% and 87.5% result. The JavaScript stretch APIs require a common unit, so the comparison refused that mixed-unit input rather than treating 10 and 140 as directly comparable lengths.

Check each print axis and their difference

The print-scale case separated two questions. Against a 100mm target, widths and heights of 99.6mm and 100.4mm are each within a 0.5% threshold. Their difference is 0.8 percentage points, however, so npm and Rust also flagged the X/Y gap as excessive. The Drupal math export has no print-scale operation. A passing per-axis check therefore does not imply that the two directions behave uniformly, and no result here prescribes a printer correction.

Reproduce the comparison

The run generated 30 outcome records from 26 actual numerical calls; four entries were explicitly unsupported. All expected outcomes matched. The inputs were synthetic, and no physical fabric specimens, printer readings or empirical accuracy study were collected. The Sewlore measurement methods guide gives the recording assumptions behind these calculations. AI assisted this comparison and explanatory draft; its evidence is execution of the published code with stated limitations.

This tutorial uses the published sewlore-fabric-care 0.1.0 package, an MIT Python API and local CLI. Every numerical example is hypothetical software input, not measured fabric data. AI assistance was used to prepare this article; its API contracts were checked against the published source and documentation.

Choose the validation boundary deliberately

The package exposes two CSV entry points. The lower-level validate_csv function accepts text, generic identifiers and free-text notes, with a one-million-character limit. It is useful inside a controlled application, but it does not implement the bounded anonymous-record policy.

The CLI uses validate_submission instead. That function accepts bytes, requires UTF-8 CSV, and applies a 128 KiB limit and a maximum of 250 nonempty records. Its ten-column header is fixed. Sample identifiers follow sample- plus one to six digits; care methods come from an explicit list, and notes must be empty. These restrictions reduce accidental free-text collection. They do not verify how a physical sample was measured.

An anonymous-policy failure in sample_id, care_method or notes rejects the whole file before calculation. Once that policy gate passes, core validation separates units or numeric errors row by row, allowing valid rows to continue.

from sewlore_fabric_care import BLANK_CSV, validate_submission

accepted, corrections = validate_submission(BLANK_CSV.encode("utf-8"))
assert accepted == [] and corrections == []

A header-only template is a valid empty collection. Treating it as a fabricated sample would change the meaning of the data. The package documentation describes the API boundary, export columns and strict policy separately.

Keep units and shape assumptions in the record

The columns are sample_id, before_unit, after_unit, before_length, before_width, after_length, after_width, care_method, rectangle_assumption and notes. Four before/after readings must be positive and finite. Within a row, before and after units must match and must be cm, mm or in. Different rows can use different supported units.

Consider these two hypothetical rows. The first is eligible for calculation. The second intentionally changes its after unit to mm; the strict policy returns a unit correction instead of silently deciding that the numbers were converted correctly.

from sewlore_fabric_care import BLANK_CSV, validate_submission

hypothetical = (
    BLANK_CSV
    + "sample-001,cm,cm,20,20,19,19.5,wash-and-dry,yes,\n"
    + "sample-002,cm,mm,20,20,190,195,wash,no,\n"
)
accepted, corrections = validate_submission(hypothetical.encode("utf-8"))

The rectangle flag is also a data contract. yes enables the area calculation; no or an empty flag omits it. Recording two spans does not establish that a sample remained rectangular. The software cannot inspect skew, irregular edges, marking technique or measurement uncertainty.

Preserve the sign and multiply the remaining factors

For each axis, signed contraction is 100 times one minus after divided by before. Positive means contraction; negative means expansion. An after length of 21 compared with a before length of 20 therefore gives -5%, rather than a clipped zero or an unsigned five.

from sewlore_fabric_care import calculate_changes, convert_length

# Hypothetical paired rectangular spans, expressed in millimetres.
changes = calculate_changes(200, 200, 190, 195, rectangle_assumption=True)
# Approximately +5%, +2.5% and +7.375% rectangular-area contraction.

length_mm = convert_length(0.625, "in", "mm")  # 15.875

The remaining length fraction is 0.95 and the remaining width fraction is 0.975. Multiplying them gives 0.92625 remaining area, so the reduction is 7.375%. Adding the two axis percentages would give 7.5% and double-count their overlap. This calculation assumes paired flat rectangles, rather than estimating an arbitrary shape.

Finite input alone is not a complete numeric guarantee. Very large or very small values can still produce an unrepresentable conversion or ratio. The Python calculation core raises ValueError for invalid ranges and unrepresentable results. Its positive-length conversion contract also differs from the separate JavaScript sewing-math helper, which permits signed offsets and zero.

Separate accepted records from correction entries

Export both streams explicitly. A correction is a reason to inspect a record, not an alternative measurement. In the local CLI, the count summary goes to stderr, while a selected CSV can go to stdout. This keeps a pipeline from receiving human-readable summaries mixed into its CSV data.

python -m pip install sewlore-fabric-care==0.1.0
sewlore-fabric-care template --output blank.csv
sewlore-fabric-care validate readings.csv \
  --accepted accepted.csv --corrections corrections.csv

Exit code 0 means completed validation with no corrections, including an empty template; 1 means completed validation with corrections; 2 means a usage or file/destination error. Existing outputs are protected unless --overwrite is explicitly selected. Input/output aliases, including existing hard links, are rejected. Writes are not transactional, so an I/O failure can leave partial exports.

CSV quoting and formula-prefix handling in the export layer serve a different purpose from row validation. They preserve cell boundaries and reduce common spreadsheet interpretation problems. They are not a universal guarantee about every spreadsheet application, and they cannot repair a wrong unit or an unsupported physical assumption.

Make the method reproducible without inventing data

Keep the actual marking, direction, care process and waiting time in a separate method record. The measurement methods guide explains what those context fields mean. Leave the machine template empty until real readings exist; keep personal information and free-text observations out of this strict input.

The public package source makes the policy and CLI behavior inspectable. A useful integration preserves its accepted/correction distinction and tests hypothetical edge cases before using real records. Passing validation establishes a supported numeric record, not fabric quality, garment fit or laboratory compliance.