Re: Incompatible types for array conversion

[hreba <f_hreba@yahoo.com.br>]

On 07/22/2015 03:49 AM, Georg Bauhaus wrote:
> On 22.07.15 03:19, hreba wrote:
>> I have a generic vector package:
>>
>> generic
>>     dim:        positive;
>>     type Real is digits <>;
>> package Vectors is
>>     type Vector is array (1..dim) of Real;
>>     function "*" (a: Vector; b: Real) return Vector;
>> end Vectors;
>>
>> In another package I want to model the definition of a (physical)
>> position vector by its direction and module:
>>
>> (...)
>> Now my attempt to define this function:
>>
>>     function "*" (l: Direction; r: Length) return Position is
>>     begin return Positions."*"(Position(l), r); end "*";
>>
>> gets me the error message in the subject line.
>>
>> Do I have to convert the vector element by element in a loop or is
>> there a more elegant way?
>
> There are ways to have the implementation perform exactly
> the operations needed to produce the result that is needed.
> Nothing inelegant in that; on the contrary, I find the
> attempt to convert a Direction into a Position rather disturbing!
>
> That's exactly turning the accidental relationship due to
> assumed similarity of component types into a relationship
> of Direction and Position that does not exist in the physical world.
> Type error ;-) caused by assumptions about the implementation
> dictating specification.

Wrong. It is common in physics to multiply a dimensionless direction 
vector (typically a unit vector) with a scalar of some dimension 
(length, velocity, whatever). The result is a vector with this dimension.

> Vectors."*" announces to multiply a Vector of Reals by a Real,
> returning a Vector of Reals, not converting anything on the way.
> Maybe the word "Real" still sounds generic, but the instance
> types aren't.

This is an intensional separation of abstraction levels. Package vectors 
describes mathematical vectors (i.e. elements of a vector space, not 
just sequences of numbers). Units (e.g. meters) come into play only in 
clients of this package as in "Basic".
>
> Maybe rethink the solution. I think it could be made adequately
> flexible, by, for example, considering Position as a vector of discrete
> numbers in city block space and Direction having one of four possible
> values only, in that city block space. Then, devise the operations
> needed. Go back to Position and Direction in a more Euclidean
> space, allocating a good choice of digits and ranges to each
> of the types.
>
I declared vectors of real types because I need to describe real 
mathematical numbers (classical continuous physical quantities). There 
might be a reason to rethink the solution in future, but in a way 
different to your suggestion: my current implementation allows 
multiplication of a Position variable with a Length variable resulting 
in a Position vector. The physically correct dimension would be length 
squared instead of length. Up to now I can live without that.

-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil