Macks - adding unit constants?

Macks - adding unit constants?

[Jacob Sparre Andersen]

I have just started to use Macks to generate packages for handling 
physical units.  I like the tool, but I would appreciate some method for 
handling different proportional units like km, m and mm _in_ Macks.  I 
also find writing:

    Diameter := 3.0 * mm;
    Diameter := 0.003 * m;

more appealing than:

    Diameter := 0.003;
    Diameter := Meter (0.003);

I considered if changing the declaration of fundamental units from:

    Meter is fundamental;

to:

    Meter is fundamental Length;

naming the type "Length" and not "Meter", but declaring a constant 
"Meter" of type "Length".

Since "Unit * Integer" is reserved for declaring vectors, we need some 
other syntax for declaring derived units.  Could:

    mm := 0.001 * Meter;

be used?  Or should I just put the derived units in a separate package?

Jacob
-- 
"There is nothing worse than having only one drunk head."

Re: Macks - adding unit constants?

[Stephen Leake]

Jacob Sparre Andersen <sparre@crs4.it> writes:

> I have just started to use Macks to generate packages for handling
> physical units.  I like the tool, but I would appreciate some method
> for handling different proportional units like km, m and mm _in_
> Macks.  

Exception for user interfaces, you should only use one length unit in
your code; it might as well be meter (m). Anything else leads to
confusion.

In user interfaces, you must use whatever the user wants, but you
should not need full Macks support for that, since you don't need to
do math on the displayed value; you only need to convert to/from the
standard unit

-- 
-- Stephe

Re: Macks - adding unit constants?

[Jacob Sparre Andersen]

Stephen Leake wrote:

> Exception for user interfaces, you should only use one length unit in
> your code;

When it comes to my current problem I agree, but I am not sure I do it 
in general.

 > it might as well be meter (m).

It is very impractical to have to remember to write "0.000_86" and not 
"0.86", when you put constants in your code.  I prefer to have to write 
"0.000_86 * m" (or "0.86 * mm") so there is an explicit conversion from 
nondimensional to dimensional units.  Since this preference is rather 
strong, I have decided to use a hand-written units package for this project.

Later I will hopefully get time to make a modified version of Macks that 
suits my views of how to handle units in Ada.

 > Anything else leads to
> confusion.

It depends on how you do it.

Jacob (who views Ada code as a very important user interface)
-- 
"If you think Tuck has said something that is completely
  wrong, you are almost certainly missing something :-)"

Re: Macks - adding unit constants?

[christoph.grein]

Have also a look at:


http://home.t-online.de/home/Christ-Usch.Grein/Ada/Contents.html
http://home.t-online.de/home/Christ-Usch.Grein/Ada/Dimension.html
http://home.t-o
nline.de/home/Christ-Usch.Grein/Ada/SI.html

Re: Macks - adding unit constants?

[Preben Randhol]

On 2003-10-17, Jacob Sparre Andersen <sparre@crs4.it> wrote:
> It is very impractical to have to remember to write "0.000_86" and not 
> "0.86", when you put constants in your code.  I prefer to have to write 
> "0.000_86 * m" (or "0.86 * mm") so there is an explicit conversion from 
> nondimensional to dimensional units.  Since this preference is rather 
> strong, I have decided to use a hand-written units package for this project.

why not 8.6E-4 ?

Preben
-- 
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Macks - adding unit constants?

[Stephen Leake]

Jacob Sparre Andersen <sparre@crs4.it> writes:

> Stephen Leake wrote:
> 
> > Exception for user interfaces, you should only use one length unit in
> > your code;
> 
> When it comes to my current problem I agree, but I am not sure I do it
> in general.
> 
>  > it might as well be meter (m).
> 
> It is very impractical to have to remember to write "0.000_86" and not
> "0.86", when you put constants in your code.  

That's a user interface.

> I prefer to have to write "0.000_86 * m" (or "0.86 * mm") so there
> is an explicit conversion from nondimensional to dimensional units.
> Since this preference is rather strong, I have decided to use a
> hand-written units package for this project.

How often do you actually have hardcoded constants in real code? I'd
expect them to be in an input file somewhere.

-- 
-- Stephe

Re: Macks - adding unit constants?

[Jacob Sparre Andersen]

Stephen Leake wrote:
> Jacob Sparre Andersen <sparre@crs4.it> writes:
>>Stephen Leake wrote:

>>>Exception for user interfaces, you should only use one length unit in
>>>your code;
>>
>>When it comes to my current problem I agree, but I am not sure I do it
>>in general.
>>
>> > it might as well be meter (m).
>>
>>It is very impractical to have to remember to write "0.000_86" and not
>>"0.86", when you put constants in your code.  
> 
> That's a user interface.

Yes.  But code _is_ my user interface.  (or at least a part of it)

> How often do you actually have hardcoded constants in real code?

Much too often.

> I'd expect them to be in an input file somewhere.

They should be.  But 1) you still need default values and 2) it is in
some cases (including the one I am working on right now) an unneeded
complication to add configuration files to the system.

Jacob
-- 
"This page inadvertently left blank."

Re: Macks - adding unit constants?

[Jacob Sparre Andersen]

Preben Randhol wrote:
> On 2003-10-17, Jacob Sparre Andersen <sparre@crs4.it> wrote:

>>It is very impractical to have to remember to write "0.000_86" and not 
>>"0.86", when you put constants in your code.  I prefer to have to write 
>>"0.000_86 * m" (or "0.86 * mm") so there is an explicit conversion from 
>>nondimensional to dimensional units.  Since this preference is rather 
>>strong, I have decided to use a hand-written units package for this project.
> 
> why not 8.6E-4 ?

As opposed to what?  It still doesn't tell which units we are working
in.  Dimensionless numbers should not be able to suddenly become
dimensioned numbers without som kind of explicit conversion.

And I have made too many mistakes which could have been caught by proper
handling of dimensioned numbers to make me want to take chances.

Jacob
-- 
A password should be like a toothbrush. Use it every day;
change it regularly; and DON'T share it with friends.

Re: Macks - adding unit constants?

[christoph.grein]

> As opposed to what?  It still doesn't tell which units we are working
> in.  Dimensionless numbers should not be able to suddenly become
> dimensioned numbers without som kind of explicit conversion.

Why not:

   Dist: constant Meter := +0.000_86;

Or use Dmitry Kazakov's or my method:

  Dist: constant SI := 0.000_86 * Meter;
or
  Dist: constant SI := 0.86 * Milli * Meter;

See http://home.T-Online.de/home/Christ-Usch.Grein/Ada/

You'll find references to four methods to use dimensioned items (one of them of 
course Macks).

Re: Macks - adding unit constants?

[Preben Randhol]

On 2003-11-03, Jacob Sparre Andersen <sparre@crs4.it> wrote:
> Preben Randhol wrote:
>> On 2003-10-17, Jacob Sparre Andersen <sparre@crs4.it> wrote:
>
>>>It is very impractical to have to remember to write "0.000_86" and not 
>>>"0.86", when you put constants in your code.  I prefer to have to write 
>>>"0.000_86 * m" (or "0.86 * mm") so there is an explicit conversion from 
>>>nondimensional to dimensional units.  Since this preference is rather 
>>>strong, I have decided to use a hand-written units package for this project.
>> 
>> why not 8.6E-4 ?

As 0.000_86 etc.. where you can get the 0's wrong. :-)
>
> As opposed to what?  It still doesn't tell which units we are working
> in.  Dimensionless numbers should not be able to suddenly become
> dimensioned numbers without som kind of explicit conversion.

well you can write 

   8.6E-4 * m

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Macks - adding unit constants?

[Jacob Sparre Andersen]

Christoph Grein wrote:

> Why not:
> 
>    Dist: constant Meter := +0.000_86;

Because that converts a dimensionless number to a dimensioned number, 
and you can't do that (in physics).

> Or use Dmitry Kazakov's or my method:
> 
>   Dist: constant SI := 0.000_86 * Meter;
> or
>   Dist: constant SI := 0.86 * Milli * Meter;

This is in some ways more to my taste.  Here there are no conversions of 
dimensionless numbers to dimensioned numbers.  But I prefer the 
compile-time checking I get with Macks to the run-time checking implied 
in the above examples.

Jacob
-- 
"[...] *transfer* a bit of salary from the person who writes
  a bug to the person that finds a bug..." -- Keith Ray

Re: Macks - adding unit constants?

[christoph.grein]

> >   Dist: constant SI := 0.000_86 * Meter;
> > or
> >   Dist: constant SI := 0.86 * Milli * Meter;
> 
> This is in some ways more to my taste.  Here there are no conversions of 
> dimensionless numbers to dimensioned numbers.  But I prefer the 
> compile-time checking I get with Macks to the run-time checking implied 
> in the above examples.

Compile time checking will only work for simple cases satisfactorily.

How are you going to handle fractional powers? (See my paper).
How power series?
Every now and then you will run into problems because a certain overloading of 
multiplication operators is not available and you have to reorder your 
expression in order to make it compile.
With Macks, you still have the wrong overloadings (e.g. T*T giving T for any 
type T) still present, albeit abstract, and those _can_ screw up overloading 
resolution under certain conditions.

ARG has abandoned a proposal for Ada05 that would have added unit checking at 
compile time because of the many problems that come with it. (One of the authors 
was Tucker Taft.)

If you really want dimension checking in full generality (my personal feeling 
is, it's not worth it, real software problems are buried somewhere else, see Ada 
Europe Conference 2003, Springer Verlag *), you need a run-time method where 
dimensions can easily be switched off when the code has been subject to 100% 
coverage unit testing (because then you have _proved_ that all equations are 
dimensionally correct).

(*) I can send you the PDF file if you're interested.

Christoph Grein