Comments (7)
Thinking about this more, we're definitely going to want to include a lot of constants, for things like
const ft: Meter<f64> = Meter::new(0.305);
but maybe that would be better as a generic function?
from dimensioned.
It looks like you've hit on a reason for defining constants: it actually
enables you to abstract away the base units, in a sense, since there is no
difference between m and cm. But maybe the constants should go in a
separate optional module?
On Mon, Oct 24, 2016, 12:11 AM Paho Lurie-Gregg [email protected]
wrote:
Thinking about this more, we're definitely going to want to include a lot
of constants, for things likeconst ft: Meter = Meter::new(0.305);
but maybe that would be better as a generic function?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIZKUjmVes_8oAwL9dkKQLBh_jVm3IIks5q3Fo2gaJpZM4KeXK0
.
from dimensioned.
I think having the constants/conversions factors in the library is what will make it valuable. It also gives a single, reviewed, source for all constants, instead of every user having to enter any needed conversions on their own.
I've been doing some experiments (most current at https://github.com/iliekturtles/uom/tree/dev-8) and ended up with the base struct being Length
and not Meter
or Foot
. Conversion factors are used internally and also exposed as enum variants: length::Units::meter
, length::Units::foot
, ...
from dimensioned.
Constants are in for sure, so I've renamed this as there are some open questions.
Say, for example, that we have the module si
with the SI
system defined in it.
Structure
Do we also have consts
in that module? On the plus side, that makes them quite nice to use, as you can use dim::si;
then things like let v = 3.9 * si::m / si::s;
are both concise and clear. On the down side, if you wish to do a glob import from si
, that could get ugly. We could also make an si::prelude
module for glob imports of just the types, but that could be a pain to define without a build script.
Type
What primitive should consts be? I think f64
is a good default, but it'd be nice to have f32
ones also. This could be done either with a si::consts32
module, or with names like si::m32
. I don't know what's best.
Functions
In addition to consts, do we also define functions? We already have things like Meter::new(3.0)
, but something like 3.0.m();
could be nice. It has the benefit over consts that it could be generic, and the same function could work for f32
and f64
.
from dimensioned.
In my experiments (https://github.com/iliekturtles/uom/blob/dev-8/src/si/mod.rs#L32) I went with both f32 and f64 consts with the intention to add default features for both so that the undesired consts could be disabled.
from dimensioned.
That seems like a good idea. What I have now is, in each unit system, an f32consts
module and an f64consts
module, with a pub use f64consts::*
. So users have access to both, but f64
is a bit more convenient.
from dimensioned.
I think this is settled.
from dimensioned.
Related Issues (20)
- Add support for absolute values HOT 2
- Implement various functions on primitives.
- Use #[rustc_on_unimplemented] HOT 1
- travis fails to build HOT 2
- Re-add rustfmt and clippy to TravisCI build HOT 1
- Update `approx` dependency
- Validate and ideally repace uses of `mem::transmute`
- Typo in UCUM: MH20
- http://paholg.com/dimensioned/ is a 404 HOT 3
- Question: accepting generic dimension for calculation in specific units HOT 11
- Question: working with nalgebra HOT 7
- Feature request: Celsius HOT 5
- support std::iter::Sum. HOT 1
- Any good idea how to integrate with `ordered_float`? HOT 3
- Use conventional letter case HOT 1
- Support f256 via the qd github repo HOT 15
- fmt String as Joules instead of MKS HOT 2
- has_units() -> bool HOT 2
- Implement `max` and `min` functions for primitive types that have them HOT 1
- `serde_test` should be dev-dependency
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dimensioned.