telus-agcg / wise_units Goto Github PK
View Code? Open in Web Editor NEWA Rust library for working with UCUM units & measurements.
A Rust library for working with UCUM units & measurements.
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?
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).
I was reading through these and thought my terminology didn't quite match up:
I'm using terms given in the unitwise library; the terms in the summary would better match up with conventional terminology.
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.
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.
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.
Looks like https://github.com/dtolnay/ryu can improve outputting floats as strings...
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/
This is a valid UCUM unit that is not being recognized.
This issue was moved from JIRA; initially reported by @tindron.
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".
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:
Old internal issue: DEV-13560
Please support add support for Queen Anne's Wine Gallons (UK), not just Queen Anne's Wine Gallons (US).
Right now we can Measurement * Unit, but we should also be able to do Unit * Measurement. Do the same for division.
Just an idea, but could maybe help with either parsing or interpreting.
There are an existing number of problems that are currently more difficult than they should be to get through them:
This returns a ParsingFailed(UnknownUnitString("p"))
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.