Add support for integral types as the underlying storage type #29

iliekturtles · 2017-05-17T13:20:23Z

Add support for integral types (i8, u8, i16, u16, i32, u32, i64, u64, usize? isize?, i128, u128) as the underlying storage type so that users can create new systems which do not use a floating point type. Use features to control code generation. Not all methods may be applicable. Types shouldn't be implemented for the ISQ.

iliekturtles · 2017-06-18T01:24:28Z

Use traits from the num crate instead of explicitly implementing each type?

radix · 2017-07-30T15:58:27Z

I use a bunch of integers in my code now, and that's why I'm not using uom yet. I think the num crate is a great idea for this. Note that it also has traits for floating point numbers which would allow you to generalize your float storage backends too (maybe?).

iliekturtles · 2017-07-31T11:59:56Z

I'm planning to start work on this issue after #3. I have a proof of concept for that issue but I've been pretty busy with summer activities. I haven't taken a look yet, but my understanding of num is that I should be able to completely generalize the underlying storage type. The only thing I'm not quite sure how to handle yet is the literal conversion factors.

If your code is open source I'd love to take a look when I start in on this issue to make sure a num trait-based solution works.

radix · 2017-07-31T23:05:49Z

Hi @iliekturtles ! Yep, my code is open source, but it's pretty embarrassing with respect to its handling units now. The project is P&T and I have, for example, types like a Distance type which just stores centimeters as a u32 and Point3 as a three-tuple of i16s (meters). Of course the fact that these representations and methods are embarrassing is why I want to switch to uom :)

You can consider it basically like a representation of a board-game or something like minecraft, with positions in discrete blocks. That's why I'm using integers. Most data can deal with integral meters, and occassionally I drop down to centimeters for certain things (especially dealing with lines drawn at an angle, but I still don't need anything more precise than a cm).

Part of #29.

usize, u8, u16, u32, u64, u128 (unstable), isize, i8, i16, i32, i64, i128 (unstable), bigint, biguint, rational, rational32, rational64, bigrational, f32, f64. All stable types are enabled by default but not yet implemented. Part of #29.

Part of #29.

All macros now organized in separate files. `storage_types!` allows for code that explicitly references an underlying storage type, `V`. Part of #29.

usize, u8, u16, u32, u64, u128 (unstable), isize, i8, i16, i32, i64, i128 (unstable), bigint, biguint, rational, rational32, rational64, bigrational, f32, f64. Only f32 and f64 are enabled by default for compile time reasons. All other types are not yet implemented. Part of #29.

Part of #29.

All macros now organized in separate files. `storage_types!` allows for code that explicitly references an underlying storage type, `V`. Part of #29.

Introduces a number of new traits to control how conversion factors are stored for each different underlying storage type. Part of #29.

Part of #29.

All macros now organized in separate files. `storage_types!` allows for code that explicitly references an underlying storage type, `V`. Part of #29.

stored for each different underlying storage type. Part of #29.

Part of #29.

radix · 2017-11-21T21:01:59Z

I just want to say that I've been following your development with interest and I'm very grateful that you're doing it :)

iliekturtles · 2017-11-21T21:16:13Z

Thanks for the positive feedback! I'm getting really close now. I just need to get all the tests passing. Once that is done I'm planning to put together a PR to replace Distance.

usize, u8, u16, u32, u64, u128 (unstable), isize, i8, i16, i32, i64, i128 (unstable), bigint, biguint, rational, rational32, rational64, bigrational, f32, f64. Only f32 and f64 are enabled by default for compile time reasons. All other types are not yet implemented. Part of #29.

Part of #29.

All macros now organized in separate files. `storage_types!` allows for code that explicitly references an underlying storage type, `V`. Part of #29.

stored for each different underlying storage type. Part of #29.

Part of #29.

Introduces a number of new traits to control how conversion factors are stored for each different underlying storage type. Part of #29.

Part of #29.

Generated test system macros no longer collide with generated macros from `uom::si`. Part of #29.

Part of #29.

All macros now organized in separate files. `storage_types!` allows for code that explicitly references an underlying storage type, `V`. Part of #29.

Introduces a number of new traits to control how conversion factors are stored for each different underlying storage type. Part of #29.

Explicit implementations allow for a literal left hand side. Part of #29.

Generated test system macros no longer collide with generated macros from `uom::si`. Part of #29.

Part of #29.

Handles equality and approximate equality for all underlying storage types. Tests don't need to be type specific or include approximation logic for floating point numbers. Part of #29.

All `quickcheck` tests accept `A<V>` as parameters and `deref` into the underling storage type. Allows for `quickcheck` tests for types that don't implement `Arbitrary` by default. Part of #29.