Would you be interested in exploring an alternative representation for mixed_units?
I have implemented a prototype, IndexedUnits, that stores:
- A numeric vector
- An integer unit ID per element
- A dictionary of distinct units
Link to prototype and reproducible benchmarks
The aim is to reduce storage and processing overhead for long vectors containing relatively few different units. Arithmetic groups values by unit pairs and delegates operations to units. The prototype also provides vctrs integration for row binding and tidyr reshaping, including missing values. I benchmarked it against GitHub units 1.0-1.6, revision a823fef, including the recent conversion improvements. For 10,000 elements with eight balanced, shuffled unit types, the results were:
| Operation |
IndexedUnits |
mixed_units |
| Construction |
1.00 ms |
29.69 ms |
| Scalar multiplication |
1.55 ms |
618.91 ms |
| Addition with conversion |
2.19 ms |
695.69 ms |
| Multiplication across unit pairs |
17.54 ms |
717.37 ms |
| Row binding |
0.43 ms |
0.72 ms |
| Pivot round trip |
3.87 ms |
5.84 ms |
Retained object size was about 15× smaller. Benefits vary: concatenation was slower, and short vectors or greater unit diversity reduce the arithmetic advantage. In particular, multiplication involved 64 distinct unit pairs in this scenario.
Explicit unit conversion and full integration with the units API are not implemented yet. Some behavior also extends beyond mixed_units, including rep() and additional operators; these could be aligned separately.
Would this representation be worth pursuing for possible inclusion in units? I would particularly welcome feedback on compatibility requirements and whether the storage and grouped-arithmetic approach fits the package’s design.
Would you be interested in exploring an alternative representation for
mixed_units?I have implemented a prototype,
IndexedUnits, that stores:Link to prototype and reproducible benchmarks
The aim is to reduce storage and processing overhead for long vectors containing relatively few different units. Arithmetic groups values by unit pairs and delegates operations to
units. The prototype also provides vctrs integration for row binding and tidyr reshaping, including missing values. I benchmarked it against GitHubunits1.0-1.6, revisiona823fef, including the recent conversion improvements. For 10,000 elements with eight balanced, shuffled unit types, the results were:Retained object size was about 15× smaller. Benefits vary: concatenation was slower, and short vectors or greater unit diversity reduce the arithmetic advantage. In particular, multiplication involved 64 distinct unit pairs in this scenario.
Explicit unit conversion and full integration with the
unitsAPI are not implemented yet. Some behavior also extends beyondmixed_units, includingrep()and additional operators; these could be aligned separately.Would this representation be worth pursuing for possible inclusion in
units? I would particularly welcome feedback on compatibility requirements and whether the storage and grouped-arithmetic approach fits the package’s design.