Phobos Integration

[burner]

quantities is awesome, you should push for phobos inclusion!

[biozic]

Thank you. I will consider the suggestion, but I don't have enough time right now to submit something up to standard.

[burner]

from what I can see, it is pretty good already. a lot of people will complain anyway, just because they don't want new stuff in phobos or because they are jealous that their code was not merged.

It was discussed at dconf, with the powers that are, that phobos needs to be powerful and that we need something similar to boost::unit.

just move it to std.experimental, create the PR and push for it.

[nordlow]

@biozic, I agree with @burner. This is the best D unit library yet!

I can help you out too if you want to.

If this gets into Phobos other languages will be major jealous!

Two things:

1. I believe versioning on SIReal, SIDouble or SIFloat is too unflexible for the developer. A better way is to make Numeric a template parameter for the definitions in si.d.
2. I'm missing one detail though, namely shorthands in toString logic, namely

enum second = unit!(Numeric, "T");
enum hertz = 1 / second;
writeln(hertz);

currently prints

1 [T^-1]

I believe the developer would prefer to have it be printed in a similar compact way as

1 hertz

provided such a mapping exists. I'm not sure how to solve this though. We sooner or later need to put the foot down and specify that a hertz or Hertz is equivalent to 1 [T^-1] so this can be reflected back to the developer both at compile-time and run-time.

What do you think?

[biozic]

@nordlow Thanks for your feedback !

I've updated the README file to make clear some design principles and their consequences. They result in unusual features (or lack thereof). Especially, one could say that it is a 'dimensions' library, not a 'unit' library (and that could be controversial). This makes me feel that, though it's quite usable, the library may not be fit for Phobos yet.

Concerning the two points you make:

1. Yes, versioning the SI definitions is a bad temporary workaround that has to be dealt with! I haven't yet found an acceptable solution that ensures that all SI quantities have the same underlying numeric type.
2. The mapping from dimensions to units is totally dependent on the context of the problem. Reciprocal seconds are not always hertz. Moreover, when you use quantities in a formula, the right unit for the result cannot usually be decuded from the formula. From my expericience of other units library (Python mainly), automatic unit formatting fails most of the time, excepted in the simplest cases! Compare it to the automatic printing of floating point values (without a format specification). But usually, the right unit is actually known beforhand. So I personnaly use the format helpers you can find in si.d, and I gave up on automatic formatting. Nevertheless, I agree that the present solution of printing "1 [T^-1]" is surprising.

I work on it from time to time, but don't expect fast evolution :( I would happily accept help improving the design and/or the implementation!

[nordlow]

@biozic: Could you please elaborate on what you mean by;

I haven't yet found an acceptable solution that ensures that all SI quantities have the same underlying numeric type.

?

I'm working on templatzing the definitions in si.d right now to see where that leaves us: #4

[saurabhdas]

This library is fantastic. It is so useful. Great work!

I would really love to see it included in Phobos as std.dimensions or std.quantities.

PS: Apologies if this is not the correct place to leave a comment :-/

[burner]

any news?

[nordlow]

Or std.unit.

No news yet. I'm willing to start working on PR for Phobos. We need comments from the github D team in order to know in which direction to go.

[biozic]

Sorry for the blackout. I have no time to work on anything important concerning this project. If somebody wants to take it over to bring it to Phobos, I'm OK with it. I would be of little help unfortunately.

[burner]

@nordlow so you are creating a PR against phobos?

[nordlow]

Yeah, I can put my work on this onto a Phobos module.

What should we call it?: std.experimental.unit?

[burner]

awesome.

or maybe call it std.experimental.quantities to keep the name close to the original

[nordlow]

According to http://chemistry.about.com/od/unitsconversions/fl/What-Is-the-Difference-Between-Quantity-and-Unit.htm

I believe unit is the correct term.

I don't think the original naming should matter at all.

Ok?

[burner]

Ok!

[burner]

It is awesome you took the time to figure this out. Put this effort into the PR and it will pass with flying colors.

[nordlow]

@burner ... I believe there will be a looong and very interesting discussion about the details ;)

[burner]

@nordlow I fear you are right. I can only advise you to point to the link if you think they make a solid point, and then stop feeding the troll.

[biozic]

@nordlow That's great if you can work on this to bring it to Phobos! I also anticipate a long discussion about the implementation, but also about the notions. Be careful of misconceptions: for example, the link that you posted earlier is plain wrong about quantities and units; see the SI brochure: "The value of a quantity is generally expressed as the product of a number and a unit. The unit is simply a particular example of the quantity concerned which is used as a reference, and the number is the ratio of the value of the quantity to the unit.". Nonetheless, units is probably a better name, more efficient.

[wilzbach]

@nordlow That's great if you can work on this to bring it to Phobos!

Guys what happened? I lost a bit track, but I remember this discussion partially. So what is your plan @nordlow? Any way to help you out?

[nordlow]

AFAICT, David's Nadlingers solution is better because it offers a more flexible conversion architecture. Typically it allows representing units separated from values. See forum discussion at

http://forum.dlang.org/thread/[email protected]?page=1

I've cleaned up David Nadlingers implementation a bit and put it

https://github.com/nordlow/units-d

for anyone review or improve.

I've added a TODO list. I'm currently struggling with understanding GetConversion which is the contains the heart of the logic.

I wanted to add support for representing scaled units with arbitrary precision (both integer and floating Point) but the current logic contains a bug prohibits this.

Typically we want to be able to to represent angles in degrees in integer precision and do logic on integers before they are, on demand, converted to floating point, before feed builtins such sin, cos, tan, etc. It has to do with GetConversion. For details about the problem see:

https://github.com/nordlow/units-d/blob/master/src/experimental/units/si.d#L143

Further, David Nadlinger wants to refactor GetConversion to do a breadth-first match instead of current depth-first.

I'm hoping David or someone more skilled in CT-logic would take on the task of fixing this. It's above my skill and time resources.

PRs are very welcome. It's also ok with me if somebody forks this repo and takes over the responsibility of adding this to Phobos.