I am in a slight dilemma, because although I would love to share my work
and ideas with you, right now this would automatically weaken my own
units proposal in comparison to yours. However, as this would be grossly
against the open source spirit, and the point of GSoC certainly can't be
to encourage that, I'll just do it anyway.
Regarding IDs: As I wrote in my previous post, the only point of the
unit IDs in Boost.Units is to provide a strict total order over the set
of units. If you can achieve it without that (see below), you won't need
any artificial numbers which you have to manage.
But why would you need to be able to sort the base units in the first
place? The answer is simple: To define a single type representation for
each possible unit, i.e. to implement type canonicalization. To
illustrate this point, consider the following (pseudocode) example:
auto force = 5.0 * newton;
auto distance = 3.0 * meter;
Quantity!(Newton, Meter) torque = force * distance;
torque = distance * force;
Both of the assignments to »torque« should obviously work, because the
types of »force * distance« and »distance * force« are semantically the
same. In a naïve implementation, however, the actual types would be
different because the pairs of base units and exponents would be
arranged in a different order, so at least one of the assignments would
lead to type mismatch – because a tuple of units is, well, a tuple and
not an (unordered) set.
And this is exactly where the strictly ordered IDs enter the scheme. By
using them to sort the base unit/exponent pairs, you can guarantee that
quantities semantically equivalent always end up with the same
»physical« type.
Luckily, there is no need to require the user to manually assign
sortable, unique IDs to each base type because we can access the mangled
names of types at compile time, which fulfill these requirements. There
are probably other feasible approaches as well, but using them worked
out well for me (you can't rely on .stringof to give unique strings).
When implementing the type sorting code, you might probably run into
some difficulties and/or CTFE bugs, feel free to contact me for related
questions (as I have already wasted enough time on this to get a working
solution…^^).
Regarding strings: I might not have expressed my doubts clearly, but I
didn't assume that your proposed system would use strings as internal
representation at all. What I meant is that I don't see a way how, given
»Quantity!("Widgets/Gadgets")«, to get the Widget and Gadget types in
scope inside Quantity. Incidentally, this is exactly the reason for
which you can't use arbitrary functions/types in the »string lambdas«
from std.algorithm.
David
On 3/28/11 9:43 PM, Cristi Cobzarenco wrote:
- 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.
