telus-agcg/wise_units

A Rust library for working with UCUM units & measurements.

wise_units's Issues

"MiBy" (mebibytes) prefix unrecognized

Hi Folks
I tried running this program
https://github.com/danielrh/wise_units_example/blob/mebi/src/main.rs
and this snippet fails

    let over_one_mebibyte = Measurement::try_new(1.125, "MiBy").unwrap();
    let nine_mebi_bit = over_one_mebibyte.convert_to("bit").unwrap();
    assert_eq!(nine_mebi_bit, Measurement::try_new(9* 1024 * 1024, "bit").unwrap());
    eprintln!("M: {} {}", over_one_mebibyte, nine_mebi_bit);

with output

M: 1.125 MBy 9000000 bit
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParsingFailed(BadFragment { fragment: "MiBy", position: 0 })', src/main.rs:10:65

I'd like to be able to use the SI Mebibyte units in my application, but the prefix does not seem to be recognized

I see it in the parser, but I can't find any tests for this sort of unit-- is there something I can do to fix the issue?

Add AsMeasurement trait

The standard Measurement type is great, but also very permissive. It's nice to be able to make your own types that behave like a Measurement, but maybe have some restrictions on them (ex. a Duration that only allows duration-related units).

Rename Composition -> Dimension; Dimension -> BaseQuantity

I was reading through these and thought my terminology didn't quite match up:

• https://en.wikipedia.org/wiki/Dimensional_analysis
• https://en.wikipedia.org/wiki/International_System_of_Quantities#Base_quantities

I'm using terms given in the unitwise library; the terms in the summary would better match up with conventional terminology.

wise_units fails to parse UCUM non-unit example: "g.m/{H.B}"

Since it's listed in the UCUM guide (http://unitsofmeasure.org/ucum.html#section-Examples-for-some-Non-Units.) as an example non-unit; turns out wise_units fails to parse it.

Allow more chars in annotations

The current parsing uses the same rule for parsing both Unit symbols and annotations--this is wrong.
UCUM excluded a bunch of chars for allowed chars in
Units:

■2 Terminal unit symbols can consist of all ASCII characters in the range of 33–126
(0x21–0x7E) excluding double quotes (‘"’), parentheses (‘(’ and ‘)’), plus sign (‘+’'), minus sign
(‘-’'), period (‘.’'), solidus (‘/’'), equal sign (‘=’'), square brackets (‘[’ and ‘]’), and curly
braces (‘{’ and ‘}’), which have special meaning. ■3 A terminal unit symbol can not consist of
only digits (‘0’–‘9’) because those digit strings are interpreted as positive integer numbers.
However, a symbol “10*” is allowed because it ends with a non-digit allowed to be part of a symbol.

...but the rules for annotations should follow a different parsing rule; one that follows:

■1 The full range of characters 33–126 can be used within a pair of curly braces (‘{’ and ‘}’).
The material enclosed in curly braces is called annotation.

ASCII 123 and 125 are { and }, respectively, but parsing those inside of an annotation would
be a chunk of work (although it should technically be done); fixing annotations to allow ASCII
33-122, 124, and 126 is trivial. Let's do the latter and fix the former later, when we have more
time.

Rename Measurement::scalar to Measurement::base_scalar

Right now the call to scalar returns a float value of the measurement in terms of its base unit (ex. "1 km"'s scalar -> "1000.0"); this contradicts the behavior in js-quantities though, where scalar() returns the value of the measurement and baseScalar() returns the value in terms of the base unit.

After thinking about it a bit, it seems like scalar probably isn't used for much from the public API sense--it's primarily used when doing math on two compatible measurements or converting one measurement to another compatible unit type (we have to reduce down to that base units to do any of that). I think that just renaming scalar to base_scalar should clarify the API a bit.

Use ryu for printing f64s in Display

Looks like https://github.com/dtolnay/ryu can improve outputting floats as strings...

Add support for use of rational numbers over floats

While Rust's f64 type is capable of handling a majority of cases, it'd be great to be able to represent numbers that floating point numbers aren't able to represent.

More info: https://floating-point-gui.de/

ExpressionError for "[m/s2/Hz^(1/2)]"

This is a valid UCUM unit that is not being recognized.

---

This issue was moved from JIRA; initially reported by @tindron.

"dar" fails to parse to "deciare"

While the case in the summary probably isn't realistic, it's representative of other cases as well. In this case, wise_units (greedily) parses the prefix "da" (deka), leaving the "r" token, which doesn't parse, thus causing an error. In this case we'd actually like to non-greedily parse the "d" in "dar", leaving the parser to parse "d" and "ar".

Clean up the FFI

We have two FFIs in wise_units right now; one manually written, and one partially derived with ffi_derive. We should drop the manual one in favor of the ffi_derive version (with additional functions moved from wise_units-ffi to the custom_ffi module).

Couple of extra notes:

• We should make the measurement_init interface a bit easier to use. [Steve had some suggestions here|https://bitbucket.org/agrian/wise_units/pull-requests/64#Lapi/src/measurement.rsT234].

Old internal issue: DEV-13560

Queen Anne's Wine Gallons

Please support add support for Queen Anne's Wine Gallons (UK), not just Queen Anne's Wine Gallons (US).

Implement Div<Measurement>, Mul<Measurement> for Unit

Right now we can Measurement * Unit, but we should also be able to do Unit * Measurement. Do the same for division.

Memoize/cache unit definitions

Just an idea, but could maybe help with either parsing or interpreting.

Redo wise_units' internals

There are an existing number of problems that are currently more difficult than they should be to get through them:

• using rational numbers for relevant values for measurements and units
• custom units
• parsing strings into Unit objects. Parsing strings to objects is super common and strongly related to the difficulty in doing custom units well. The current parser is ok, but it's a) about 40x slower than unitwise (the old Ruby library we've used), b) a lot of extra code to interpret the parser tokens, c) requires dynamically building at compile time (which is difficult, and even moreso for newcomers to the project) because custom units are not defined in code (they're in a text file that we read in and turn into code).
• memoizing units (caching them after you've used them). ...or really just not duplicating data all over the place. Every time a Unit comes into existence, to do anything with it (ex. check compatibility with another unit) it has to traverse its internal list of units that it's built on (ex. an acre -> rods squared -> feet squared -> cm squared). This is super inefficient.

"ps" (picosecond) fails to parse

This returns a ParsingFailed(UnknownUnitString("p"))