[GSoC Proposal] Statically Checked Measurement Units

[Cristi Cobzarenco]

- I too was playing around with a units project before GSoC, that is why I
thought doing this project was a good idea. The way I was doing it without
numerical IDs was simply by having more complicated algorithms for equality,
multiplications etc. For example, equality would be implemented as:
template UnitTuple(P...) {
  alias P Units;
}

template contains( Unit, UT ) {
  /* do a linear search for Unit in UT.Units (since UT is a UnitTuple) -
O(n)*/
}

template includes( UT1, UT2 ) {
  /* check for each Unit in UT1 that it is also in UT2 (using contains) -
O(n^2) */
}

template equals( UT1, UT2 ) {
  immutable bool equals = includes!(UT1,UT2) && includes!(UT2, UT1);
}
Granted this means that each check takes O(n^2) where n is the number of
different units, but it might be worth it - or not. On the small tests I've
done it didn't seem to increase compile time significantly, but more
research needs to be done. I think that as long as there aren't values with
_a lot_ of units (like ten), the extra compile time shouldn't be noticeable.
The biggest problem I have with adding IDs is that one will have to manage
systems afterwards or have to deal with collisions. Neither one is very
nice.

- You're right, you don't need dimensions for implicit conversions, of
course. And you're also right about possibly making the decision later about
implicit conversions. The thing is F#, where units are very popular, only
has explicit conversions, and I was trying to steer more towards that model.

- I seem not to have been to clear about the way I would like to use
strings. The names of the units in the strings have to be the type names
that determine the units. Then one needs a function that would convert a
string like "Meter/Second" to Division!(Meter, Second), I'm not sure how you
would do that in C++. Maybe I'm wrong, but I can't see it.

- I hope it is by now clear that my proposal is not, in fact, string based
at all. The strings are just there to be able to write derived units in
infix notation, something boost solves by using dummy objects with
overloaded operators. The lack of ADL is a problem which I completely
missed; I have immersed myself in C++ completely lately and I've gotten used
to specializing templates in different scopes. These are the solutions I can
come up with, but I will have to think some more:
1. There is an intrusive way of solving this, by making the conversion
factors static members of the unit types, but this would not allow, for
example, having a Widget/Gadget counter the way I intended.
2. The way they get away with it in F# is to use global conversion factors,
that one manually uses. That actually is not bad at all. The only problem
was that I was hoping that conversion between derived units could
automatically be done using the conversion factors of the fundamental units:
(meter/second) -> (kilometer/hour) knowing meter->kilometer and
second->hour.

Again I will have to think some more about the latter point. And I'll do
some more tests on the performance of doing linear searches. Is there way to
get the name of a type (as a string) at compile time (not the mangled name
you get at runtime)? I wasn't able to find any way to do this. My original
idea was actually to use the fully qualified typenames to create the
ordering.

Thanks a lot for your feedback, it's been very helpful, especially in
pointing out the lack of ADL. Hope to hear from you again.

On 28 March 2011 20:57, David Nadlinger <see at klickverbot.at> wrote:

> On 3/28/11 5:43 PM, Cristi Cobzarenco wrote:
>
>> First, let me apologize for this very late entry, it's the end
>> of university and it's been a very busy period, I hope you will still
>> consider it.
>>
>
> This is by no means a late proposal – the application period has not even
> formally opened yet.
>
> I was somewhat surprised to see your post, because I had been playing
> around with a dimensional algebra/unit system implementation for a while
> before the whole GSoC thing started. I even have an unfinished project
> proposal for it lying around, but as I thought that I was rather alone with
> my fascination for unit systems, I decided to finish the Thrift one first.
> Well, seems like I was wrong… :)
>
> A few things that came to my mind while reading your proposal:
>  - The need for numerical ids is not inherent to a dimension-aware model
> like Boost.Units – it's just needed because there is no way to get a strict
> total order of types in C++. You will need to find a solution for this in D
> as well, because you want to make sure that »1.0 * second * metre« is of the
> same type as »1.0 * metre * second«.
>
>  - I think that whether disallowing implicit conversion of e.g. millimeters
> to meters is a good idea has to be decided once the rest of the API has been
> implemented and one can actually test how the API »feels« – although I'd
> probably disallow them in my design by default as well, I'm not too sure if
> this actually works out in practice, or if it just cumbersome to use. Also,
> I'd like to note that whether to allow this kind of implicit conversions
> doesn't necessarily depend on whether a system has the notion of dimensions.
>
>  - Not that I would be too fond of the Boost.Units design, but
> »convenience« functions for constructing units from strings like in your
> second example could be implemented for it just as well.
>
>  - You have probably already thought of this and omitted it for the sake of
> brevity, but I don't quite see how your current, entirely string-based
> proposal would work when units and/or conversion factors are defined in a
> module different from the one the implementations of Quantity/convert/… are
> in. Contrary to C++, D doesn't have ADL, so I am not sure how a custom base
> unit would be in scope for Quantity to find, or how a custom conversion
> template could be found from convert().
>
> Anyway, I am not sure whether I should submit my own units proposal as
> well, but if you should end up working on this project, I'd be happy to
> discuss any design or implementation issue you'd like to.
>
> David
>



-- 
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110328/12c1a014/attachment-0001.html>