Consider her way -- Re: Dimensionality Checking

Consider her way -- Re: Dimensionality Checking

[Alexandre E. Kopilovitch]

Recent discussion about the dimensions/unit analysis seems to me... well, not
directed by the spirit of the Ada language. As far as I understand, all
participants of the discussion presume that if the dimensional/unit analysis
should be done for an Ada program then it must be performed entirely with the
facilities of Ada language itself. I think that that assumption is plain wrong.

  Let us consider what the dimensional/unit analysis is, in general terms.
For every dimension/unit U we have the mapping Deg_U, which assigns the
rational numbers to the subtypes (that is, the domain of the Deg_U is the set
of all subtypes in our Ada program, and the range of the Deg_U is the set of
rational numbers). We extend this mapping to the variables and user-defined
functions, using the subtype of a variable and the subtype that a function
returns. The mapping Deg_U is "logarithmic", that is, for any variables (or 
user-defined functions) X, Y, Z:
  Z is compatible with X * Y implies Deg_U(Z) = Deg_U(X) + Deg_U(Y), and
  Z is compatible with X / Y implies Deg_U(Z) = Deg_U(X) - Deg_U(Y),
Then we require for all assignments (including an argument passing), additions
and subtractions in our program, that the values of the mapping Deg_U for the
right operand (side) must be equal to the corresponding value for the left
operand. This requirement permits us to define Deg_U over the rational
expressions. Taking into account that the "logarithmic" rule effectively
determines the values of the mapping for the square root, we conclude that 
the mapping Deg_U is defined over the algebraic expressions. The final step
is to assign zero value to all standard (predefined) transcendent functions
(such as Sin etc.). So, the mapping Deg_U is defined for all expressions,
and the condition to be verified is already formulated: for each assignment,
addition and subtraction the value of the mapping Deg_U on the right operand
must be equal to the corresponding value on the left operand.
  This is a definition of the basic "linear" dimensional analysis. One may
construct other, more sophisticated forms of the dimensional analysis for the
specific purposes.

  Now let's recall the fact that the Ada is not a problem-oriented language,
but rather a "superassembler". It intentionally and carefully avoids all
paradigms that aren't closely related to the real computer architectures or
to the general software engineering, even if those paradigms are heavily used
in some significant application area. (Note that I'm speaking here about the
paradigms; the data representation issues are another matter, that is a natural
job for an assembler.)
  Obviously, the dimensionality paradigm is one of the kind that Ada avoids:
it belongs neither to a computer architecture nor to the general software
engineering, but to the particular application area, no matter how significant
it is in the real world. Therefore Ada most probably will not take any move
to support it directly.

  The proper way to do the dimensional/unit analysis for the Ada programs is
to use the ASIS and some suitable language processor, I guess that the SML
might be the best for this purpose (because it is well-suited for the
manipulations with the algebraic type systems). So the configuration of the
whole tool chain may look like that:

       dimension/unit values for the subtypes
                       |
                       |
                      \|/
                       |
  |------|         |---------|	      |-------------|
  | ASIS | ------> | SML     | ------ | SML         |
  | tool |         | program |        | interpreter |
  |------|         |---------|        |-------------|
     |                 |
    /|\                |
     |                \|/
     |                 |
  |----------|    diagnostic output
  | Ada      |      
  | compiler |
  |----------|
     |
    /|\
     |
     |
 program to be verified
   

  Finally, I'll try to explain why the subtypes, and not the types, are the
natural carriers for the dimensionality info. Briefly, with the physical
magnitudes, all the dimensionalities are imaginary, and only the repetition
count within some underlying measurement process is real. That count is obviously
dimensionless. In fact, a dimension of physical magnitude is the abstraction
for the class of the instruments with which we can measure the magnitude.
  If you do not like such vague metaphysical arguments then consider the
following question: if X and X*X belong to the different types, how will you
treat (interpret) the usual approximations by the Taylor series?
  And as for the units, I hope everyone will agree that there is no fundamental
difference (in physics) between miles and kilometers.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Consider her way -- Re: Dimensionality Checking

[Mark Lundquist]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org...
>
>[snip...]
>   Now let's recall the fact that the Ada is not a problem-oriented
language,
> but rather a "superassembler". It intentionally and carefully avoids all
> paradigms that aren't closely related to the real computer architectures
or
> to the general software engineering, even if those paradigms are heavily
used
> in some significant application area. (Note that I'm speaking here about
the
> paradigms; the data representation issues are another matter, that is a
natural
> job for an assembler.)
>   Obviously, the dimensionality paradigm is one of the kind that Ada
avoids:
> it belongs neither to a computer architecture nor to the general software
> engineering, but to the particular application area, no matter how
significant
> it is in the real world. Therefore Ada most probably will not take any
move
> to support it directly.

Well OK, but then how do you explain Ada's type system?  If the language did
not
abstract types away from its own "machine model", then wouldn't we have
C-style type-equivalence instead?  Instead, in Ada we have the idea that
"number of lines in a file" and "number of cows" can be different types.
Isn't that pretty abstract for a "superassembler"?

>
>   The proper way to do the dimensional/unit analysis for the Ada programs
is
> to use the ASIS and some suitable language processor [snip...]

For one thing, you would still have to code all of of your own unit
conversions.  See other posts in this thread, keywords "combinatoric" and
"explosion" :-)
(Hmmm, "explosion" might pick up that other post about pajamas being
inflammable, or inflatable, or whatever that was... :-)

>
>   Finally, I'll try to explain why the subtypes, and not the types, are
the
> natural carriers for the dimensionality info. Briefly, with the physical
> magnitudes, all the dimensionalities are imaginary, and only the
repetition
> count within some underlying measurement process is real. That count is
obviously
> dimensionless. In fact, a dimension of physical magnitude is the
abstraction
> for the class of the instruments with which we can measure the magnitude.

Are you just trying to say that we have base units which are arbitrary, and
derived units based on those?

>   If you do not like such vague metaphysical arguments then consider the
> following question: if X and X*X belong to the different types, how will
you
> treat (interpret) the usual approximations by the Taylor series?

Well, I think you're almost right here... you don't have to think about
Taylor series to see the problem.  The fundamental glitch is that
unit-safety takes you from a numeric system that is closed under
multiplication to one that is not.  Every expression in Ada has a value; if
X is of a "dimensioned type" as we have been considering, then what is the
type of the expression 'X * X'?  So you're right that in the "dimensioned
type" approach there has to be some relationship between the types, but it
would be absolutely wrong to co-opt subtyping for this.  For one, we want to
save subtypes for what they are already used for (constraint checks); but
more fundamentally, it just does not make sense.  Given a subtype and a
value, you can tell whether the value is in the subtype!  The subtype is not
some abstract property of the object, which is what dimensions/units would
be.

Best Regards,
Mark

Re: Consider her way -- Re: Dimensionality Checking

[Nick Roberts]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org...

> Recent discussion about the dimensions/unit analysis seems to me... well,
not
> directed by the spirit of the Ada language. As far as I understand, all
> participants of the discussion presume that if the dimensional/unit
analysis
> should be done for an Ada program then it must be performed entirely with
the
> facilities of Ada language itself. I think that that assumption is plain
wrong.
> ...

The reason for proposing a unit (or dimension) checking scheme as an
extension to the Ada language, is so that the portability and other benefits
of standardisation will then apply.

My reasons for associating a unit with a type rather than a subtype is to do
with explicit conversion between values of the same dimensionality but
different units.

In Ada, values of the same subtype can be used interchangeably in
expressions; the only place where the subtype matters is where a variable is
updated, in which case the new value is checked to ensure it is compatible
with the variable's subtype. This is a basic priciple in Ada, and I did't
want to change it.

With scalar values of different types, the only way to use a value, X1 say,
of one type, T1 say, in a place where another type, T2 say, is expected, is
with an explict conversion T2(X1). The converse conversion T1(X2) is always
possible, and a view conversion implies two conversions, one in each
direction. This fits perfectly with the conversion between two values of
different units (of the same dimensionality), which is assumed to be
achievable by multiplication by a certain factor: the conversion is always
bidirectional (the converse conversion is achieved by multiplication by the
inverse of the factor).

Hence, it works neatly to associate a unit with a type.

--
Best wishes,
Nick Roberts

Re: Superassemblers: was Dimensionality Checking

[Richard Riehle]

"Alexandre E. Kopilovitch" wrote:

>   Now let's recall the fact that the Ada is not a problem-oriented language,
> but rather a "superassembler". It intentionally and carefully avoids all
> paradigms that aren't closely related to the real computer architectures or
> to the general software engineering, even if those paradigms are heavily used
> in some significant application area.

How do you characterize problem-oriented from superassembler?  Also,
is this bifurcated view just a little too large-grained to be truly useful.

Do  superassemblers include Java, C++, C#, COBOL, Fortran, and PL/I, and
Eiffel?  Can we say that those that are not superassemblers inlcude Haskell,
Lisp, APL,  Prolog, and OCAML?   And which ones are truly problem-oriented?

Richard Riehle

Re: Superassemblers: was Dimensionality Checking

[Alexandre E. Kopilovitch]

Richard Riehle <richard@adaworks.com> wrote:

>"Alexandre E. Kopilovitch" wrote:
>
>>   Now let's recall the fact that the Ada is not a problem-oriented language,
>> but rather a "superassembler". It intentionally and carefully avoids all
>> paradigms that aren't closely related to the real computer architectures or
>> to the general software engineering, even if those paradigms are heavily used
>> in some significant application area.
>
>How do you characterize problem-oriented from superassembler?
I don't think that there exists a characterization, which is good enough for
general audience, and at the same time short. Tell me the background and the
experience of the questioner, and I'll be able to give an answer.
  I hope that the following definition is sufficient for you: a language is
problem-oriented if it supports _directly_ the views and the methods which are
customary for the targeted problem area.

>Do  superassemblers include Java, C++, C#, COBOL, Fortran, and PL/I, and
>Eiffel?
In this list only C++ falls in that category.
  Java, as a language, does not deserve any comments. It is enough to point out,
that this rather modern language has no construct for enumeration. I'd say that
Java should be better called NetBasic.
  C# is too immature... but it surely is (and will be, as far as I understand)
platform-dependent. Its objects presume a quite strong (dynamic) support from
the underlying software platform. Therefore it can't be an assembler at all.
Perhaps I should be slightly more formal to avoid naive counter-arguments:
the characteristic features of the C# may be used effectively only with strong
dynamic support provided by the underlying software platform.
  Cobol and Fortran, those titans of the past, are quite different in respect
to the issue. Cobol was strongly problem-oriented language, but Fortran was
much closer to the (portable) assembler in the past. In fact, a mixture of the
Fortran and assembler code was the best cocktail for many things (in the past,
of course).
  PL/I is (was) certainly a problem-oriented language, although it tried to
embrace several broad apllication areas. I know well enough that the PL/I story
is quite controversial, but here I simply express my personal opinion.
  As for Eiffel, I do not know this language (I'm still in doubt, which book
about Eiffel is more suitable for me - I'm interested in that language, but
not in the associated methodology teachings). But all that I read/heard about
it suggests that Eiffel's author recognizes the general software engineering
as a separate problem in its own right, and focused his efforts on that problem.
Therefore I think that the Eiffel language probably is problem-oriented, although
the problem targeted does not belong to a particular application area.

>  Can we say that those that are not superassemblers inlcude Haskell,
>Lisp, APL,  Prolog, and OCAML?
I do not know Haskell and OCAML (although I hope to take a look at Haskell
eventually, mostly because the author of the good compression program bzip2
likes it very much and recommends it persuasively).
  As for the other languages in this list - Lisp, APL and Prolog, I think that
the proper answer should be cautious: they all have a chance to become a part
of some future superassembler, but certainly each of them isn't (and cannot
evolve into) a whole thing. This is especially true for the List and Prolog,
while APL is slightly more shifted towards the problem-orientation.

> And which ones are truly problem-oriented?
Cobol, Fortran, PL/I, APL, Prolog, Pascal, SmallTalk, Snobol...


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia