Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 29 March 2016 at 12:46:44 UTC, Seb wrote: So @nordlow how about pushing this code to a separate repository and dub? Here you are: https://github.com/nordlow/units-d
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 22 March 2016 at 09:55:28 UTC, Zardoz wrote: Impressive! I like the idea, in special when you can handled derived units and doing conversions like this : convert!(kilo(newton))(200 * gram * meter / pow!2(second))); Wow that's pretty sweet! So @nordlow how about pushing this code to a separate repository and dub? It seems that now there is enough interest in pushing this :) I would like to move forward with std.experimental.unit(s). +1 for pushing this to Phobos!
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote: Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here. When this topic came up previously, it has been proposed to include units support with Phobos, and thus I have merged my work into my Phobos fork. Please note, however, that even if we should come to the conclusion that we really want something like this in Phobos, this is not a formal review request yet. There are still a couple of items left on my to-do list, but I'd like to get some feedback first. Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html. David Impressive! I like the idea, in special when you can handled derived units and doing conversions like this : convert!(kilo(newton))(200 * gram * meter / pow!2(second)));
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 13:39:48 UTC, Nordlöw wrote: On Wednesday, 16 March 2016 at 11:28:05 UTC, Nordlöw wrote: I'm working on these issues right now. Regularly updated here: https://github.com/nordlow/justd/blob/master/units.d https://github.com/nordlow/justd/blob/master/si.d BTW, is there overlap between a unit system library and Andrei's BigO system? Maybe it would be useful if the later can be expressed with the former.
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 17:12:42 UTC, ZombineDev wrote: Sometimes a more gradual approach may be useful: […] How would this be any more than an informational annotation? If anything, you could build a custom lint tool to propagate and verify the unit annotations, but I don't quite see how the type system/compiler would make use of it. — David
Re: RFC: Units of measurement for D (Phobos?)
On Thursday, 17 March 2016 at 12:51:28 UTC, Nordlöw wrote: I believe `isConvertableTo` is a more Phobos-compliant naming, right? Correction: Should be named `isConvertibleTo`. BTW: We already have https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible Why don't we already have isConvertibleTo or/and isExplicitlyConvertibleTo
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 11:28:05 UTC, Nordlöw wrote: I'm working on these issues right now. Regularly updated here: https://github.com/nordlow/justd/blob/master/units.d https://github.com/nordlow/justd/blob/master/si.d
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 02:03:09 UTC, David Nadlinger
wrote:
The code was written in a dark age where CTFE bugs were very
common (e.g. trying to use std.algorithm.sort would give weird
results), there was a number of issues with template
parameters, and many relevant features simply did not exist yet:
- UFCS (!)
Done
- UDAs
Could you elaborate on possible usage in this case?
- Extracting template symbol/arguments from template instances
Could you elaborate on possible usage in this case?
- Natural alias syntax ("=")
Done
- alias/enum/… templates
Done
- Eponymous templates with extra members
Could you elaborate on possible usage in this case?
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 22:16:20 UTC, Nordlöw wrote: How should then sin, cos, tan, expi be redesigned to support `ScaledUnit` aswell as `Quantity`? What you can do is to take an arbitrary quantity with an (angle.canConvert!radian) template constraint. Inside the function, you then simply use cos(angle.convert!radian / radian) or whatever. — David
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 22:34:04 UTC, David Nadlinger wrote: What you can do is to take an arbitrary quantity with an (angle.canConvert!radian) template constraint. Inside the I believe `isConvertableTo` is a more Phobos-compliant naming, right? Is there are reason why `convert` wasn't named the shorter and Phobos-compliant `to` instead? Was this prior to `std.conv.to`? function, you then simply use cos(angle.convert!radian / radian) or whatever. Why not simply add a Quantity member auto ref toValue() const used as cos(angle.to!radian.toValue) Shorter and puts less stress on the compiler.
Re: RFC: Units of measurement for D (Phobos?)
On 3/16/16 7:19 AM, Nordlöw wrote: On Wednesday, 16 March 2016 at 13:57:51 UTC, ZombineDev wrote: BTW, is there overlap between a unit system library and Andrei's BigO system? Maybe it would be useful if the later can be expressed with the former. Interesting. Could you elaborate? What units should be involved? Andralex? I don't see overlap, but I may be wrong. -- Andrei
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 02:03:09 UTC, David Nadlinger wrote: Please make a really, really thorough pass through the source before proposing it for Phobos. Thanks! I'm working on these issues right now.
Re: RFC: Units of measurement for D (Phobos?)
Hi Per, Many thanks for working on the code! Could you put it up as a separate Dub package to make it easier for people to try out? `justd` is an 68 MiB-heavy clone, which makes it somewhat cumbersome to play around with and contribute to it. You'd probably also want to add your name to the Authors list. On Wednesday, 16 March 2016 at 14:27:16 UTC, Nordlöw wrote: - UFCS (!) Done There might be additional design possibilities now that didn't previously exist. The way of constructing a quantity is one such example, although I still like the approach using `*`. - UDAs Could you elaborate on possible usage in this case? For example, to replace SuperSecretAliasToMarkThisAsUnit. It could conceivably also be used for the extra metadata like the base linear unit for affine units, etc. - Extracting template symbol/arguments from template instances Could you elaborate on possible usage in this case? IIRC there are various `isXyz` templates where I went with a duck typing approach out of necessity (which might or might not be a better design choice than just checking for a certain template instance). - Eponymous templates with extra members Could you elaborate on possible usage in this case? The code in and around GetConversion can probably be simplified. It currently explicitly uses `.Result` members and so on. Another thing I forgot to mention in the previous post are documented unit tests. Pretty much all of the example blocks should probably be converted to it. The CTFE-related code could also use a closer look, for example makeIndexCtfe() is probably not needed any longer. Best, David
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 14:19:56 UTC, Nordlöw wrote:
On Wednesday, 16 March 2016 at 13:57:51 UTC, ZombineDev wrote:
BTW, is there overlap between a unit system library and
Andrei's BigO system? Maybe it would be useful if the later
can be expressed with the former.
Interesting. Could you elaborate? What units should be involved?
Andralex?
I think it started here:
http://forum.dlang.org/post/n3sdm1$1fba$1...@digitalmars.com
See also:
http://forum.dlang.org/post/n3t8f8$2ii6$1...@digitalmars.com
http://forum.dlang.org/post/n4s66a$i9u$1...@digitalmars.com
https://issues.dlang.org/show_bug.cgi?id=15464
The two dimensions are time and space (memory). They are not
expressed in absolute units of measurement, but show approximate
rate of growth as the size of the input grows. Andrei's proposal
defines an algebra over them. A system of units is also an
algebra, so I wondering if we can somehow generalize the essence
of both ideas.
BTW, after rereading the links above, I came up with a related
idea:
When you have a large existing codebase it may be too much work
to change all types to be strongly typed like this:
==
// before:
struct Car
{
double relativeSpeed(Car other); // measured in km/h
double relativeDistance(Car other); // measured in km
}
// after:
alias KMpH = kilo!Metre / Second(3600);
struct Car
{
KMpH!double relativeSpeed(Car other);
kilo!(Metre!(double)) relativeDistance(Car other);
}
==
Sometimes a more gradual approach may be useful:
==
// before:
struct Car
{
double relativeSpeed(Car other); // km/h
double relativeDistance(Car other); // km
}
// after:
alias KMpH = kilo!Metre / Second(3600);
struct Car
{
double relativeSpeed(Car other) @Unit!KMpH;
double relativeDistance(Car other) @Unit!(kilo!Metre);
}
==
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 17:46:39 UTC, David Nadlinger wrote: Hi Per, Many thanks for working on the code! Could you put it up as a separate Dub package to make it easier for people to try out? Ok, I'll do that in a couple of days. In the mean while could you take a look at the overloads of sin, cos and tan in si.d. I just want to start at something, IMHO, having type-safe handling of angles in trigonometric functions would some projects more correct. This is cheap solution (used by many unit-libraries) uses a floating-point-scaling of the radian unit. Which of course may result in loss accuracy. A better approach to represent degrees would of course be to use `ScaledUnit`. How should then sin, cos, tan, expi be redesigned to support `ScaledUnit` aswell as `Quantity`? Could you, please, highlight the basic idea here or perhaps give a code. Thanks in advance, David.
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 16 March 2016 at 13:57:51 UTC, ZombineDev wrote: BTW, is there overlap between a unit system library and Andrei's BigO system? Maybe it would be useful if the later can be expressed with the former. Interesting. Could you elaborate? What units should be involved? Andralex?
Re: RFC: Units of measurement for D (Phobos?)
On Thursday, 17 March 2016 at 12:51:28 UTC, Nordlöw wrote:
I believe `isConvertableTo` is a more Phobos-compliant naming,
right?
I went for canConvert since it is a bit shorter than
isConvertible and there is precedent for it in Phobos as well
(e.g. find/canFind). It's a matter of taste, though. If I were to
work on the library again today, I might just as well go for
isConvertible.
Is there are reason why `convert` wasn't named the shorter and
Phobos-compliant `to` instead?
One thing to consider is that convert!U differs from to!T in that
the latter returns something of type T, whereas the former
returns a Quantity!(U, …). This seems enough of a difference that
choosing the same name as the widely used std.conv.to might be
somewhat misleading (even though I usually advocate for using the
module system for disambiguating names).
function, you then simply use cos(angle.convert!radian /
radian) or whatever.
Why not simply add a Quantity member […] toValue()
This is again a design decision that can go either way. The
choice I made was deliberate, although of course not above debate:
Since I chose to have dimensionless quantities implicitly convert
to "plain" value types, it seemed superfluous to add another
primitive (`a / a.unit` is simple enough to write). Furthermore,
it underlines the point that `*` and `/` between quantities and
units do not actually change the numeric value, but merely modify
its units. Making use of that for the "core functionality" seemed
like a cute way to drive the point home to users. Explicitly
specifying the unit also helps avoiding mistakes in generic code.
If you want to go the other route, I would suggest carefully
deliberating the naming scheme, since discarding unit information
is a lossy and potentially "unsafe" (as in code correctness). In
an attempt to make this obvious in the current implementation
(where it is only enabled for dimensionless quantities), I named
the function rawValue(). For example, renaming (fromValue,
rawValue) to {from, to}Raw() might be clearer than {from,
to}Value().
By the way, I highly doubt that "puts less stress on the
compiler" is a valid argument for that decision. In that regard,
the big elephant in the room is GetConversion, which you might
want to re-do using a breadth-first search anyway (see TODO
comments; I couldn't be bothered to implement it back then due to
the numerous DMD bugs I had to fight).
— David
Re: RFC: Units of measurement for D (Phobos?)
On Thursday, 17 March 2016 at 12:55:39 Ping, David Nadlinger!
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote: Could somebody point out if something is missing in David's solution. And, if so, which parts of biozic's which could be reused. that could/should be reused for filling in these gaps. Last time I evaluated these modules, I recall issues with exponents. I have to dig to find excact limitations, but IIRC you couldn't express rational exponents or evaluate expressions with them, like the square root of a meter or squaring the square root of a meter. Or was it only the operator "^^" that wasn't supported?
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 09:07:05 UTC, Nordlöw wrote:
On Monday, 14 March 2016 at 18:51:45 UTC, Chris Wright wrote:
Ohm my, that's awesome. Watt needs to happen to get this into
Phobos?
I'm cleaning up David's work right and will put up a PR today.
Please make a really, really thorough pass through the source
before proposing it for Phobos.
The code was written in a dark age where CTFE bugs were very
common (e.g. trying to use std.algorithm.sort would give weird
results), there was a number of issues with template parameters,
and many relevant features simply did not exist yet:
- UFCS (!)
- UDAs
- Extracting template symbol/arguments from template instances
- Natural alias syntax ("=")
- alias/enum/… templates
- Eponymous templates with extra members
- …
Back then, getting this to work with a half-reasonable API in
spite of all the compiler bugs and limitations was quite the tour
de force (IIRC some of the issues are marked using @@BUG@@ in the
code, but that was by far not all of them). With the current
compilers, it should be much more a question of design than of
implementation.
The basic design should still be sound, though. The main
decisions to make concern not so much the implementation (or
whether unit string parsing is implemented, etc.) but the level
of flexibility in the unit and conversion structure. One such
decision would be whether to store
a) the numerical value verbatim in the units specified by the
user, or
b) in some distinguished base unit for the given dimension.
Another such question is whether to use
1) a pre-defined, closed system of dimensions (e.g. the SI
units),
2) an explicit, but extensible structure of dimensions (to
which units can be assigned), or
3) units can arbitrarily be created and the concept of
dimensions emerges implicitly from conversions between them.
The less flexible solutions often have the advantage of allowing
a simpler implementation, being easier to understand for the
novice user (less types/templates) and possibly being quicker to
compile.
For my original library, the general motif was the to follow the
most expressive and flexible solution (3) and a) in the above).
For instance, on top of the obvious consequences regarding
precision, going with a) allows you to seamlessly interface with
non-unit-aware code and to define runtime conversions that are
only applied when actually requested by the user. Similar
considerations apply to other aspects of the design.
— David
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 14:46:30 UTC, D.Enguiyen wrote: Is it able to manage quantities with a non-linear transformations, for example when dealing with octet and byte ? (1024)!"byte" == 1!"kbyte"; There are no non-linear transformations going on here, following usual math terminology. If your question is whether unit conversions are possible with non-power-of-ten factors, the answer is an empathic "yes" – the scale factors could even be determined at run-time! The most basic solution would be to define a scaled unit like this: enum kibyte = scale!(byte, 1024, "kibibyte", "kiB"); You would probably want to define a power-of-two PrefixSystem though. (http://klickverbot.at/code/units/std_units.html#PrefixSystem) — David
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 19:08:18 UTC, Robert burner Schadek wrote: have a look at this! https://github.com/biozic/quantities This has been brought up (and subsequently discussed) on the first page of this thread, more than two years ago. — David
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 09:08:11 UTC, Nordlöw wrote: On Monday, 14 March 2016 at 19:08:18 UTC, Robert burner Schadek wrote: have a look at this! https://github.com/biozic/quantities Could you briefly outline why you prefer this over David's work? - has been in code.dlang.org since 2014 - maintained - good CT string parsing abilities - ... have a look at the github page! its inclusion has been discussed before (did go nowhere because author was busy, issue is still assigned to his github project)
Re: RFC: Units of measurement for D (Phobos?)
On 3/15/16 3:31 AM, Marc Schütz wrote: For some other modules, Andrei has insisted that package.d must publicly import all subpackages Not too strongly, I think std.allocator doesn't do that. But the judgment must be thoroughly sound and explained. For the putative package, importing packagename should generally be the same as import packagename.everything. -- Andrei
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 14:46:30 UTC, D.Enguiyen wrote: Is it able to manage quantities with a non-linear transformations, for example when dealing with octet and byte ? (1024)!"byte" == 1!"kbyte"; 1!"byte" * 1024 == 1!"kbyte";
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 14:50:42 UTC, D.Enguiyen wrote: On Tuesday, 15 March 2016 at 14:46:30 UTC, D.Enguiyen wrote: Is it able to manage quantities with a non-linear transformations, for example when dealing with octet and byte ? (1024)!"byte" == 1!"kbyte"; 1!"byte" * 1024 == 1!"kbyte"; I meant byte!1 * 1024 == kbyte!1;
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 09:13:10 UTC, Nordlöw wrote: On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote: http://klickverbot.at/code/units/std_units.html http://klickverbot.at/code/units/std_units.html#PrefixSystem No module name in Phobos is currently in plural form. I suggest we stick to that standard a name these std.experimental.unit std.experimental.unit.si One thing. How should these modules be represented on the file system? Destroy! Is it able to manage quantities with a non-linear transformations, for example when dealing with octet and byte ? (1024)!"byte" == 1!"kbyte";
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 15 March 2016 at 09:13:10 UTC, Nordlöw wrote: On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote: http://klickverbot.at/code/units/std_units.html http://klickverbot.at/code/units/std_units.html#PrefixSystem No module name in Phobos is currently in plural form. std.traits std.signals std.typecons ;-) I suggest we stick to that standard a name these std.experimental.unit std.experimental.unit.si One thing. How should these modules be represented on the file system? std/experimental/unit/package.d std/experimental/unit/si.d For some other modules, Andrei has insisted that package.d must publicly import all subpackages, but I see no reason for this. std.experimental.unit can contain the basic general functionality, and std.experimental.unit.si the SI specific ones.
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote: http://klickverbot.at/code/units/std_units.html http://klickverbot.at/code/units/std_units.html#PrefixSystem No module name in Phobos is currently in plural form. I suggest we stick to that standard a name these std.experimental.unit std.experimental.unit.si One thing. How should these modules be represented on the file system? Destroy!
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 19:08:18 UTC, Robert burner Schadek wrote: have a look at this! https://github.com/biozic/quantities Could you briefly outline why you prefer this over David's work?
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 18:51:45 UTC, Chris Wright wrote: Ohm my, that's awesome. Watt needs to happen to get this into Phobos? I'm cleaning up David's work right and will put up a PR today.
Re: RFC: Units of measurement for D (Phobos?)
have a look at this! https://github.com/biozic/quantities
Re: RFC: Units of measurement for D (Phobos?)
On Mon, 14 Mar 2016 09:04:28 +, Nordlöw wrote: > I've gained time and energy to take up this task again. It seems like > David Nadlinger's solution is very complete: > > https://github.com/klickverbot/phobos/tree/undefined > > http://klickverbot.at/code/units/std_si.html Ohm my, that's awesome. Watt needs to happen to get this into Phobos?
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 09:37:10 UTC, Nordlöw wrote: One more thing: Angular units: I suggest non-SI-derived units for `Radian` and `Steradian` instead. Then, degrees and other derived angular units shall be expressed as scaled versions of these. Oops, already defined here: http://klickverbot.at/code/units/std_si.html#radian Thanks, David.
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 09:10:21 UTC, Nordlöw wrote: http://klickverbot.at/code/units/std_si.html One more thing: Angular units: I suggest non-SI-derived units for `Radian` and `Steradian` instead. Then, degrees and other derived angular units shall be expressed as scaled versions of these. I don't see the point in defining these as meter/meter and meter^^2/meter^^2 in the type system. Destroy!
Re: RFC: Units of measurement for D (Phobos?)
On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote: http://klickverbot.at/code/units/std_units.html#PrefixSystem Should be: http://klickverbot.at/code/units/std_si.html
Re: RFC: Units of measurement for D (Phobos?)
On Thursday, 10 September 2015 at 07:01:19 UTC, David Nadlinger wrote: You must be confusing the library with something else (or me with another David). I'm pretty sure that my original proof-of-concept is the most flexible of all of them, coming with support for composing arbitrary runtime conversion functions, affine quantities and so on. SI unit definitions are merely predefined in a second module because they are commonly used. That being said, my implementation is ages old and could probably be done much better today. - David I've gained time and energy to take up this task again. It seems like David Nadlinger's solution is very complete: https://github.com/klickverbot/phobos/tree/undefined http://klickverbot.at/code/units/std_units.html http://klickverbot.at/code/units/std_units.html#PrefixSystem but not a complete superset of https://github.com/nordlow/quantities/tree/master/source/undefined One key issue here is whether we should provide an instantiator based API auto q = 1.0.meter; or operator plus constants/CT-constants (via David's std.si) import std.si : meter; const q = 1.0*meter; or a combined (my proposal) auto q = 1.0.meters; // plural naming auto q = 1.0*meter; // singular naming for expressing quantities. David's SI-unit solution is, IMO, better than biozic's as it doesn't force the unit to be associated with a specific numerical scalar type upon construction. Another key-question is whether we should support biozic's compile-time parsing of unit expressions such as - 1.0.si!"km/h" - 1.0.si!"m/s" etc. Could somebody point out if something is missing in David's solution. And, if so, which parts of biozic's which could be reused. that could/should be reused for filling in these gaps. Another key-issue is if the template `Rational` in std.units should be extracted and put into a separate module. I vote for moving forward with David's solution.
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 9 September 2015 at 15:21:22 UTC, HaraldZealot wrote: One big problem is, that in SI base unit for mass is kilogram not gram. This is definitely not a "big problem". There is nothing that sets apart the "base" units in my old library from any other units, except for the fact that they happen to be defined using baseUnit!(), not by adding a prefix. Kilogram just happens to be defined as kilo!gram so that you don't get things like millikilogram. — David
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 9 September 2015 at 07:04:05 UTC, Per Nordlöw wrote: - David's library and quantities use different interal representation. Davids 7-dimensional vector of rational integers (a la Boost) is hardcoded to represent SI units. You must be confusing the library with something else (or me with another David). I'm pretty sure that my original proof-of-concept is the most flexible of all of them, coming with support for composing arbitrary runtime conversion functions, affine quantities and so on. SI unit definitions are merely predefined in a second module because they are commonly used. That being said, my implementation is ages old and could probably be done much better today. - David
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote: Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here. I would like to move forward with std.experimental.unit(s). A question that needs to be decided on Before starting this is: - David's library and quantities use different interal representation. Davids 7-dimensional vector of rational integers (a la Boost) is hardcoded to represent SI units. biozic's is not and uses a tuple of strings and is therefore more flexible. Which direction should we choose?
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote: Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here. ... Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html. ... David One big problem is, that in SI base unit for mass is kilogram not gram.
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 9 September 2015 at 07:04:05 UTC, Per Nordlöw wrote: Which direction should we choose? quantities
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 26 February 2014 at 22:49:57 UTC, Nordlöw wrote: On Wednesday, 26 February 2014 at 21:41:57 UTC, Kelet wrote: Tangentially related: https://github.com/biozic/quantities Impressive! This seems similar to David Nadlingers std.units and std.si. When will all these efforts on implementing Units/SI be synchronized and reviewed? One question: I know what angles are but I have never seen them defined like this before! enum radian = meter / meter; // ditto enum steradian = square(meter) / square(meter); /// ditto What on earth does this mean? /Per Thanks! I think David Nadlingers' is more elaborate (scaled and affine units) and less prone to rounding errors. I haven't used it yet. Mine is more basic but has a parsing system that I use to define units quickly at compile-time and parse data files at runtime. -- Nicolas
Re: RFC: Units of measurement for D (Phobos?)
Thanks! I think David Nadlingers' is more elaborate (scaled and affine units) and less prone to rounding errors. I haven't used it yet. Mine is more basic but has a parsing system that I use to So you cannot defined things lika kPa from Pa in compile-time? define units quickly at compile-time Can't David's package also quickly define in compile-time? Have you thought about merging your effort vid Davids and propose it to Phobos? This issue has stale for quite some time know. I would like to have support add support for geometric units like angles, coordinate systems, etc. Have you thought about integrating these with your module?
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 4 March 2014 at 13:20:02 UTC, Nordlöw wrote: Thanks! I think David Nadlingers' is more elaborate (scaled and affine units) and less prone to rounding errors. I haven't used it yet. Mine is more basic but has a parsing system that I use to So you cannot defined things lika kPa from Pa in compile-time? enum kPa = kilo(pascal); which is equivalent to enum kPa = 1000 * pascal; Note that my module defines no real unit type, just quantities: a unit is only a special quantity with a value of 1 and a set of dimensions (a base unit in the sense of the SI). I think it better fits what physical units really are. kPa would then be a quantity that stores 1000 and a set of dimensions corresponding to a pressure. If you declare: auto p = 101.3 * kPa; p stores a value that is 101.3 * 1000 internally, not 101.3. With David's library, I think you can declare kilopascal as a scaled unit derived from pascal, and then a quantity in kilopascal would actually store 101.3. The result is globally the same, but in fact the representations of the numeric values would be a bit different, and so would the rounding errors, when using floating point types. define units quickly at compile-time Can't David's package also quickly define in compile-time? I think it can. Have you thought about merging your effort vid Davids and propose it to Phobos? This issue has stale for quite some time know. I just think that David's package could have been proposed for Phobos a long time ago. I don't know what has stopped it then. I developed mine afterwards, not being aware of David's one. I would like to have support add support for geometric units like angles, coordinate systems, etc. Have you thought about integrating these with your module? My package is extendable. The SI module is just a predefined set of common quantities and prefixes. You can use your own. Some angle units are defined in quantites.si. I am not sure of what you call a coordinate systems in this respect. -- Nicolas
Re: RFC: Units of measurement for D (Phobos?)
Is somebody waiting for this to be reviewed? /Per
Re: RFC: Units of measurement for D (Phobos?)
Tangentially related: https://github.com/biozic/quantities
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 26 February 2014 at 21:41:57 UTC, Kelet wrote: Tangentially related: https://github.com/biozic/quantities Impressive! This seems similar to David Nadlingers std.units and std.si. When will all these efforts on implementing Units/SI be synchronized and reviewed? One question: I know what angles are but I have never seen them defined like this before! enum radian = meter / meter; // ditto enum steradian = square(meter) / square(meter); /// ditto What on earth does this mean? /Per
Re: RFC: Units of measurement for D (Phobos?)
enum radian = meter / meter; // ditto enum steradian = square(meter) / square(meter); /// ditto What on earth does this mean? It has to do with the definition of radian itself. If you draw a circle (of any radius) around an angle. The measure of the angle is radian is the ratio between the arc length of the circle and the radius. This is the reason why one full rotation is 2*pi radians: A circle's circumference is always 2*pi times its radius. Steradian is similar, but in three dimensions.
Re: RFC: Units of measurement for D (Phobos?)
On 4/12/11 6:40 PM, David Nadlinger wrote: - The helper functions for creating instances of new unit types (scale, affine, ...) are currently template functions taking an instance of the unit they manipulate as actual argument. This is only for »historical« reasons really, would it be cleaner to use just templates? I just went ahead and changed them to pure templates, having the unit helpers as functions only to infer the type of the passed unit instance really made no sense in the current design (which uses template alias parameters to pass unit instances heavily anyway). Another missing thing I didn't mention in the original post is support for named derived units – currently, there is no way you could enable (kilogram * metre / pow!2(second) to be printed as »Newton«. It wouldn't be hard to implement, but I didn't really feel the need for it so far… David
RFC: Units of measurement for D (Phobos?)
Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here. When this topic came up previously, it has been proposed to include units support with Phobos, and thus I have merged my work into my Phobos fork. Please note, however, that even if we should come to the conclusion that we really want something like this in Phobos, this is not a formal review request yet. There are still a couple of items left on my to-do list, but I'd like to get some feedback first. Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html. A couple of notes: - DDoc emits the documentation for some template functions twice, once for the template, and once for the eponymous function itself (bug 4107). Is there a workaround for this issue? This also affects, amongst others, the docs for std.container. - The documentation could use quite a bit of work in general, I'd be happy about any suggestions. - In a previous discussion, Andrei brought up the topic of categorical types implemented as quantities without any operators defined. An extra template parameter to disable arithmetic could easily be added to Quantity, if deemed useful. However, I think that using an units system to define them is pretty much overkill, as neither conversions nor arithmetic operations would be used. - Currently, »auto« returns are used quite liberally for things that should »just work«, e.g. just mirror underlying value type operations. This has the advantage of keeping code and function signatures readable, but obviously also hides the real type from the user. Any other thoughts on this? - I have followed the general Phobos guidelines to use template constraints where they would logically belong (and where they are actually implementable without hacks due to DMD bugs), instead of, say, static asserts or just letting instantiation fail. However, this way, you lose the ability to specify helpful error messages (which is somewhat important as the underlying types can be quite complex), and the DDoc documentation is cluttered up somewhat. - The helper functions for creating instances of new unit types (scale, affine, ...) are currently template functions taking an instance of the unit they manipulate as actual argument. This is only for »historical« reasons really, would it be cleaner to use just templates? - If this library should really be included into Phobos eventually, I am not quite sure about the right organization of the code. While I think that std.units would be a good fit for the core module, I am not sure how modules containing definitions of actual physical units and other related code (e.g. CODATA values for the natural constants) should be organized. Putting them directly into std.* is certainly a bad idea, as it would add even more clutter to the already crowded (overcrowded, in my opinion) package. What about a new std.physical (or similar) package? David
