<meta http-equiv="content-type" content="text/html; charset=utf-8">- 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:<div>
template UnitTuple(P...) {</div><div> alias P Units;</div><div>}</div><div><br></div><div>template contains( Unit, UT ) {</div><div> /* do a linear search for Unit in UT.Units (since UT is a UnitTuple) - O(n)*/</div><div>
}</div><div><br></div><div>template includes( UT1, UT2 ) {</div><div> /* check for each Unit in UT1 that it is also in UT2 (using contains) - O(n^2) */</div><div>}</div><div><br></div><div>template equals( UT1, UT2 ) {</div>
<div> immutable bool equals = includes!(UT1,UT2) && includes!(UT2, UT1);</div><div>}</div><div>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.</div>
<div><br></div><div>- 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.</div>
<div><br></div><div>- 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.<br>
<div><br></div><div>- 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:</div>
<div>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.</div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div></div><div>
<div><br><div class="gmail_quote">On 28 March 2011 20:57, David Nadlinger <span dir="ltr"><<a href="mailto:see@klickverbot.at" target="_blank">see@klickverbot.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 3/28/11 5:43 PM, Cristi Cobzarenco wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First, let me apologize for this very late entry, it's the end<br>
of university and it's been a very busy period, I hope you will still<br>
consider it.<br>
</blockquote>
<br></div>
This is by no means a late proposal – the application period has not even formally opened yet.<br>
<br>
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… :)<br>
<br>
A few things that came to my mind while reading your proposal:<br>
- 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«.<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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().<br>
<br>
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.<br><font color="#888888">
<br>
David<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>(Cristi Cobzarenco)<br>Pofile: <a href="http://www.google.com/profiles/cristi.cobzarenco" target="_blank">http://www.google.com/profiles/cristi.cobzarenco</a><br>
</div></div>