|
Boost : |
From: Steven Watanabe (steven_at_[hidden])
Date: 2007-03-29 13:32:17
AMDG
Noah Roberts <roberts.noah <at> gmail.com> writes:
>
> What is your evaluation of the design?
>
> For a first iteration it's good. There is room for improvement but I
> think use needs to guide that.
>
> However, I feel that the library should use MPL standard operators
> instead of creating new ones. This has been discussed and deemed
> impossible but it is not.
Since that time I have made a few changes which make it
trivial to switch to mpl::plus etc. I agree that that
would be a good thing.
> What is your evaluation of the implementation?
>
> It seems to be slower to compile than competitors by quite a margin. On
> the other hand, this library is more generic and can handle arbitrary
> dimensions.
>
> What is your evaluation of the documentation?
>
> More instruction on what constitutes a unit and quantity so that a
> developer may override these concepts and use them with the library.
Well, quantities are not used by any other portion of
the library, so overriding it won't do you much good.
On the other hand, I think that we should try to support
usage such as
template<class Dimensions>
class runtime_unit {
//...
};
quantity<runtime_unit<length_type> > x = 3.28 * SI::meters;
This would mean that the quantity would store the
unit (perhaps as a base class to get EBCO) and do
the arithmetic on the unit and the value_type at the
same time. It would also mean not defining the quantity
operators to require unit<...>. All easy changes.
> What is your evaluation of the potential usefulness of the library?
>
> It would be more useful with runtime conversions. I don't believe
> static conversions will be that useful.
Sorry for being so dense but, I still don't
really understand the case for runtime
conversions. Do you think you can provide me with a
concrete case that I cannot solve easily using the
current library?
> Did you try to use the library?
>
> I played with it, I did not use it in any real project.
>
> With what compiler?
>
> MSVC 8 and g++
>
> Did you have any problems?
>
> With optimizations on full the library performed almost as well as a
> double. Next to 0 overhead but not quite. Without these optimizations
> it performed quite poorly, which could make debugging difficult. I
> could not find enough optimizations with the Microsoft compiler to make
> this library usable; 0 overhead was definitely not 0 overhead.
> Compilation overhead could be a bear for large projects.
I think that I can speed up compiliation a bit
(maybe 2x but probably not more than that), but
it would make the code very very ugly (much worse
than it is alreay) so I didn't think that it was
worth while.
> How much effort did you put into your evaluation?
>
> About 10 hours in which I tested various performance issues and tried to
> use it in various ways I need it to work. It performs moderately well
> but unless I can find the correct switches for the MS compiler it won't
> be useful to me. It also doesn't do everything I need and even after
> digging through the implementation I am not sure it will be useful or
> easy to even extend it.
>
> Are you knowledgeable about the problem domain?
>
> I do not work in a real time project where precision is of utmost
> importance; in fact we often round values. I work in fluid flow
> analysis, which is true scientific computing in the sense that it is a
> set of "close enough" guesses to predict the real world with a fairly
> high degree of certainty. This needs to be fast, so can't pay the
> expense of constant conversions, but doesn't have the same needs as some
> of the issues that have come up in discussion.
The library is powerful enough to make conversion to
a fixed system from some system that is known at
runtime easy, *provided that the set of possible systems
is known at compile time* (though not necessarily in
a single monolithic definition). If this is not what
you need, would you mind elaborating?
> Do you think the library should be accepted as a Boost library?
>
> I do not believe it meets the need of a wide enough audience, no.
>
Thanks for your comments.
In Christ,
Steven Watanabe
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk