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.

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?

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?

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);
}
==============================

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

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

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.

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

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

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.