Re: [boost] [units] - learning to use

Subject: Re: [boost] [units] - learning to use
From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2011-11-28 10:39:55

Thanks a lot for your help,

> This is an object lesson in why using the value() method should be a last
> resort. I do think that we should try to get sensible behavior, without
> too many contortions, with the various built in types.

I might have got something wrong, and missed probably something in
the manual... So what is a better way of writing this line in the
code?

 a += (dd*exp(i*k*r)/r).value();

The result of dd*exp(i*k*r)/r is dimensionless, but direct assignment
(copy construction) isn't working here. And I would really admire if
the code could look in a sane way, like this:

 a += dd*exp(i*k*r)/r;

This would look, like I'm not really worrying about using
boost::units, just benefit from all the unit checking, and no extra
code to type. (and change k to use double, not complex ;)
Also I am suspicious that currently my code has a bug here, exactly
where the .value() is taken. Because `dd` and `r` are units of different
scale.

> > This is an idiosyncrasy of overload resolution.
> > std::complex::operator+= is a template, so an
> > implicit conversion doesn't work.  The template
> > argument can't be deduced.
> 
> Perhaps we should flesh out the toy complex implementation we wrote
> and incorporate it in the units library? It is a fairly common thing
> to use together with units and, as I understand it, the standard only
> defines complex for a subset of built in types...

that would be great. Because there is no physical reason why
wavenumber k would need to be complex.
It seems like allowing to perform a conversion from double to
complex is reasonable. Only opposite conversion has reasons to fail.
Just like converting double to int has reasons to fail. But
converting int to double should work flawlessly.

> >>  quantity<length> wavelength ( 632.8   *nano*meters);
> >>  quantity<length> wavelength = 632.8   *nano*meters;
> Although, in Janek's defense, this seems overly restrictive. Can we
> allow copy construction between scaled units and the corresponding
> unscaled unit without introducing undesirable side effects? 

I would really appreciate that :) It would simplify code. Also
because I cannot put 632.8*nano*meters directly as arguments to
function call.

btw, how usually do you define those scaled units to be a little more
convenient to use? I mean, just type: 632.8*nm
Is there some header to include, to benefit from all standard SI
system prefixes? It would be great, it's a standard after all :)
And those short names are carefully designed to not have any unit
name clashes.

Of course while writing C++ code we might end up with variables
names & units names clashing, like using single letter 'm' for
'meter', but this is why we have an si:: namespace after all. And if
my code grows a little bigger I will definitely switch to:
632.8*si::nm

If you will have some changes in library that will need testing
I will gladly try it.

If you tell me how to define si::km, si::m, si::kN, si::GJ I can
generate for you a header file with all possible units. Though
'micro' is not in latin alphabet. So micro meter is not possible, aww..

best regards
-- 
Janek Kozicki                               http://janek.kozicki.pl/  |