Re: Expressing physical units (Was: Reprise: 'in out' parameters for functions)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> But C++ does not allow double as a template parameter.
> 
> That's merely an implementation detail; you simply use a
> pair of integers to represent a fraction.

Ooch.

>> Why? It is no matter. Shifted units represent linear scales:
>> x = a * y + b
>> The dimension of a and b may have any powers.
> 
> No matter? What is the meaning of multiplying degrees Celsius
> by degrees Farenheit,

It is ambigous. But you can multiply Kelvin by Kelvin. For example, heat
flux has the dimension:

m**2 * kg / K**3

> or squaring degrees Celsius?

>> Because there can be a universal solution with zero-overhead in static
>> case.
> 
> Zero overhead in space as well? I assume this is another one of those
> cases which will require object tags to live in the classwide pointers
> instead of in the objetcs themselves?

Right. The idea is to have the powers as a discriminant and unit arithmetics
as pure routines. When the discriminant (unit) is statically known, it is
removed and we have a full equivalent of the template solution. When it is
unknown, we have run-time checks with space penalty. I belive it is a
doable approch, which has an additional advantage, that this mechanism
could be made available for all user types.

>> (:-))
> 
> Why is my unit output procedure funny?

It is still static and may no input counterpart.

>> Not that is the problem. One can add 1 [mm] and 1 [cm], it is legal. The
>> question is in which unit system the arguments are and the result will
>> be.
> 
> You need to guide the type of the result, since it could be either.
> So it's simpler to forbid the addition of differently scaled units,
> and require the user to convert one operand to the type of the other.

This does not solve the problem. These conversions either explicit or
implicit has to be done and thus checked. We have a geometrically exploding
number of cross conversions.
 
> Or, given that you're doing it in C++, it's easy to write traits
> templates that would represent rules for preferring one scale over
> another.

Too uncontrollable. The choice depends on the target value, so one cannot
say if lightyear is better than micrometer.

>> I do not see how you could add x in meters of SI with y in ft of
>> logarithmic scale using specialized templates. To represent scale you
>> will probably need some pointer to the scale descriptor in your template.
> 
> You represent scale and logness as template parameters. Then you just
> need to be able to convert one type to another (and if we're talking
> about addition of log-scaled quantities, we have to convert out anyway)
> for addition, and to write a specialized multiplication routine that
> takes two log-scaled units and adds their values, for example.

You have to do it for each of seven powers, representing each parameter by a
number of integers. I am afraid that the list of template arguments will be
longer than the source code. To have enough RAM to compile it, you would
need to made sand of all beaches into memory chips. And I am not sure if
the compiler will finish before the Entropic Death (:-))

> I doubt that anyone is going to build such a complicated system of
> units, but it could be done in principle.

Yes, it is Turing complete. (:-))

>> I do not see any way of making a GUI or DB interface based on templates.
>> Consider a distributed system with should have a communication protocol
>> to exchange physical measures. How would you do it using templates?
> 
> As I have already said, we are relying on knowing a fixed set of units
> within the program. Then the problem is no different than communicating
> any other fixed set of record types.

The problem is that you cannot have one piece of code dealing with all units
(though from a fixed set). You probably will be able to create a template
for this code, but the number of variants will be far greater than any
computer may hold. You need to instantiate all of them, because you do not
know which of them will be used at tun time.

And after all, who will be able to maintain this code? Finding an error in
C++ template instantiations is a work requiring a lot of experience, much
patience and great luck. And we want to give it engineers, who else needs
units so much? Even in Ada dealing with generics imposes much more
difficulties for a programmer than regular code. The price is to high.

>> Consider a large finite element library. If that has to be used for
>  > physical values, then the whole library has to be generic.
> 
> So?

Absolutely unrealistic.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de