From: Matthias Schabel (boost_at_[hidden])
Date: 2003-12-18 16:00:20
> Another interest... Mr Scabel makes great use of MPL. His code was
> (as he pointed out), described as 'beautiful'...
> surely not a technical term... no objection was raised :-) (am I not
> right...? )
Few people would argue that the term 'beautiful' is either
absolutist, which are the objections Mr. Abrahams raised to Dr.
One can gracefully accept compliments without substantiation, but
particularly in a forum such as this where the goal is problem solving,
be couched in concrete terms with specific objections _and_ constructive
suggestions on how such objections could be addressed. Dr. Landry's
comments provided neither.
> An example of Mr Scabels 'debating style':
> I personally feel like this discussion is largely tangential (and am
> under the distinct
> impression that Mr. Landry couldn't be bothered to give the SI web
> site I referenced
> his time). Whether or not your personal religion admits degrees,
> radians, bunches of
> grapes, dozens, or any other random existing or future tag is largely
Please don't quote me out of context - that's poor form in any debate,
in the remainder of that paragraph I clarify _why_ I believe Dr.
Landry's opinion that
radians should not be included in the unit code is mistaken (not to
mention the SI's
clear stand on the issue) :
"There are people for whom it will be helpful in decreasing the error
potential of their code to
be able to use dimensional analysis, and those people are the users I'd
like to target
with this library. If you don't like the fact that radians appear in
the SI unit system, there
is no compulsion to use them nor any consequence to not doing so."
> Why not call a *ceasefire* :-) (joke) on the subject of angles....
> Lets talk
> about another
> MPL compile times.
> Are we going to have to wait for the next generation of compilers
> poor Mr Scabels code will be of any potential use?
As I've already stated clearly, I'm quite aware that the implementation
of some of
the core dimensional analysis algorithms is not as efficient as it
should be. I am also,
by my own admission, no expert in MPL programming, and admit to being
at a loss
as to where one would begin as far as profiling compile-time
performance to establish
bottlenecks. My hope is that, if the design of this library is deemed
and meets the functional requirements that potential users have,
someone with more
experience in the area might be willing to give the code a looking over
suggestions on improving performance. I am a little puzzled that Mr.
Little is suddenly
so fixated on compile-time performance when he recently stated :
"On the raw performance thing. It is surely only one factor in making a
successful type. I'd tend to put that later on the agenda, ...the
Naturally I'd like to see the compile time to be improved, but, as Mr.
Little points out quite
correctly, that is a premature optimization until the interface has
Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
mschabel at ucair med utah edu
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk