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";

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;

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

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)

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

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

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

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?

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.

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