Incompatible types for array conversion

Incompatible types for array conversion

[hreba]

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:

package Basic is
    type Real is new Interfaces.IEEE_Float_64;
    type Length is new Real;

    package Positions is new Gen.Vectors (3, Length);
    package Directions is new Gen.Vectors (3, Real);

    subtype Position is Positions.Vector;
    subtype Direction is Directions.Vector;

    function "*" (l: Direction; r: Length) return Position;
end Basic;

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?

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

Re: Incompatible types for array conversion

[Niklas Holsti]

On 15-07-22 04: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:
>
> package Basic is
>     type Real is new Interfaces.IEEE_Float_64;
>     type Length is new Real;
>
>     package Positions is new Gen.Vectors (3, Length);
>     package Directions is new Gen.Vectors (3, Real);
>
>     subtype Position is Positions.Vector;
>     subtype Direction is Directions.Vector;
>
>     function "*" (l: Direction; r: Length) return Position;
> end Basic;
>
> 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?

The conversion is rejected because of the conversion condition in RM 4.6 
(24.5/2): "The component subtypes shall statically match". The component 
(sub)types are Real and Length, which are different types, although 
Length is derived from Real. If you change the declaration of Length to be

    subtype Length is Real;

the conversion becomes legal.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Incompatible types for array conversion

[Georg Bauhaus]

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.

In this sense, I'd say that Niklas' suggestion, while technically
working, would be papering over a conceptual mistake. (Well,
that is what elegance is about, isn't it?)

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.

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.

In your solution, "new Real" is creating a new and different type.
This is a good choice when representing things that really are different
and should be kept apart easily, with help from the compiler.

Re: Incompatible types for array conversion

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> The conversion is rejected because of the conversion condition in RM
> 4.6 (24.5/2): "The component subtypes shall statically match". The
> component (sub)types are Real and Length, which are different types,
> although Length is derived from Real. If you change the declaration of
> Length to be
>
>    subtype Length is Real;
>
> the conversion becomes legal.

I tried

   generic
      dim:		positive;
      type Real is digits <>;
   package Vectors is
      type Vector is array (1..dim) of Real'Base;

but it still failed. (GPL 2015, FSF 5.1.0)

Re: Incompatible types for array conversion

[Niklas Holsti]

On 15-07-22 10:13 , Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> The conversion is rejected because of the conversion condition in RM
>> 4.6 (24.5/2): "The component subtypes shall statically match". The
>> component (sub)types are Real and Length, which are different types,
>> although Length is derived from Real. If you change the declaration of
>> Length to be
>>
>>     subtype Length is Real;
>>
>> the conversion becomes legal.
>
> I tried
>
>     generic
>        dim:		positive;
>        type Real is digits <>;
>     package Vectors is
>        type Vector is array (1..dim) of Real'Base;
>
> but it still failed. (GPL 2015, FSF 5.1.0)

Did you expect it to work? Real'Base gets rid of any constraints on 
Real, but AIUI does not get rid of the type derivation; if "type Length 
is new Real", Length'Base is not the same as Real'Base -- the "new" 
makes them different.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Incompatible types for array conversion

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 15-07-22 10:13 , Simon Wright wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> The conversion is rejected because of the conversion condition in RM
>>> 4.6 (24.5/2): "The component subtypes shall statically match". The
>>> component (sub)types are Real and Length, which are different types,
>>> although Length is derived from Real. If you change the declaration
>>> of Length to be
>>>
>>>     subtype Length is Real;
>>>
>>> the conversion becomes legal.
>>
>> I tried
>>
>>     generic
>>        dim:		positive;
>>        type Real is digits <>;
>>     package Vectors is
>>        type Vector is array (1..dim) of Real'Base;
>>
>> but it still failed. (GPL 2015, FSF 5.1.0)
>
> Did you expect it to work? Real'Base gets rid of any constraints on
> Real, but AIUI does not get rid of the type derivation; if "type
> Length is new Real", Length'Base is not the same as Real'Base -- the
> "new" makes them different.

Well, who knows what 'statically match' means! (outside the ARG,
anyway). I thought it was worth a try.

Re: Incompatible types for array conversion

[hreba]

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

Re: Incompatible types for array conversion

[hreba]

On 07/22/2015 02:20 AM, Niklas Holsti wrote:
> On 15-07-22 04: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:
>>
>> package Basic is
>>     type Real is new Interfaces.IEEE_Float_64;
>>     type Length is new Real;
>>
>>     package Positions is new Gen.Vectors (3, Length);
>>     package Directions is new Gen.Vectors (3, Real);
>>
>>     subtype Position is Positions.Vector;
>>     subtype Direction is Directions.Vector;
>>
>>     function "*" (l: Direction; r: Length) return Position;
>> end Basic;
>>
>> 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?
>
> The conversion is rejected because of the conversion condition in RM 4.6
> (24.5/2): "The component subtypes shall statically match". The component
> (sub)types are Real and Length, which are different types, although
> Length is derived from Real. If you change the declaration of Length to be
>
>     subtype Length is Real;
>
> the conversion becomes legal.
>

Thanks a lot for the hint!

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

Re: Incompatible types for array conversion

[hreba]

On 07/22/2015 10:00 AM, hreba wrote:
> On 07/22/2015 02:20 AM, Niklas Holsti wrote:
>> On 15-07-22 04: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:
>>>
>>> package Basic is
>>>     type Real is new Interfaces.IEEE_Float_64;
>>>     type Length is new Real;
>>>
>>>     package Positions is new Gen.Vectors (3, Length);
>>>     package Directions is new Gen.Vectors (3, Real);
>>>
>>>     subtype Position is Positions.Vector;
>>>     subtype Direction is Directions.Vector;
>>>
>>>     function "*" (l: Direction; r: Length) return Position;
>>> end Basic;
>>>
>>> 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?
>>
>> The conversion is rejected because of the conversion condition in RM 4.6
>> (24.5/2): "The component subtypes shall statically match". The component
>> (sub)types are Real and Length, which are different types, although
>> Length is derived from Real. If you change the declaration of Length
>> to be
>>
>>     subtype Length is Real;
>>
>> the conversion becomes legal.
>>
>
> Thanks a lot for the hint!
>
Well, I was a little too fast with my response. It works, but it is not 
what I need. I use type Real for physical dimensionless quantities and 
Length for lengths. They must be incompatible, you cannot add them. So I 
came up with a new version of my function:

    function "*" (l: Direction; r: Length) return Position is
    begin
       return Positions."*"
         (Position'(Length(l(1)), Length(l(2)), Length(l(3))), r);
    end "*";

(Thanks God I am working with classical physics and not string theory 
with its 26 dimensions.)

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

Re: Incompatible types for array conversion

[G.B.]

On 22.07.15 14:57, hreba wrote:

>> 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).

OK, naming issue then. If the Position can be interpreted
as a Point determining a direction, that's an excuse
for scalar multiplication with subtype constraints, at
the level of implementation, or some conversions.

A comment would reduce condescension and unforeseen
misunderstanding by non-peers. (If that's wanted.)
Proper types and maybe operations would look cleaner
to me.

> 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.

That's one reason to toss assumptions: if it is not just a scalar
multiplication (respecting units), and you don't use SI aspects,
another type can do. There are packages for this, I believe
Christoph Grein has some online.

Re: Incompatible types for array conversion

[Niklas Holsti]

On 15-07-22 16:22 , hreba wrote:
> On 07/22/2015 10:00 AM, hreba wrote:
>> On 07/22/2015 02:20 AM, Niklas Holsti wrote:
>>> On 15-07-22 04: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:
>>>>
>>>> package Basic is
>>>>     type Real is new Interfaces.IEEE_Float_64;
>>>>     type Length is new Real;
>>>>
>>>>     package Positions is new Gen.Vectors (3, Length);
>>>>     package Directions is new Gen.Vectors (3, Real);
>>>>
>>>>     subtype Position is Positions.Vector;
>>>>     subtype Direction is Directions.Vector;
>>>>
>>>>     function "*" (l: Direction; r: Length) return Position;
>>>> end Basic;
>>>>
>>>> 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?
>>>
>>> The conversion is rejected because of the conversion condition in RM 4.6
>>> (24.5/2): "The component subtypes shall statically match". The component
>>> (sub)types are Real and Length, which are different types, although
>>> Length is derived from Real. If you change the declaration of Length
>>> to be
>>>
>>>     subtype Length is Real;
>>>
>>> the conversion becomes legal.
>>>
>>
>> Thanks a lot for the hint!
>>
> Well, I was a little too fast with my response. It works, but it is not
> what I need. I use type Real for physical dimensionless quantities and
> Length for lengths. They must be incompatible, you cannot add them.

For physical units/dimensions, I believe the best current solution is 
the "aspects" approach in GNAT; see, for example:

https://gcc.gnu.org/onlinedocs/gnat_ugn/Performing-Dimensionality-Analysis-in-GNAT.html

http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf

It is still GNAT-specific, though.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Incompatible types for array conversion

[Dmitry A. Kazakov]

On Wed, 22 Jul 2015 20:50:25 +0300, Niklas Holsti wrote:

> For physical units/dimensions, I believe the best current solution is 
> the "aspects" approach in GNAT; see, for example:
> 
> https://gcc.gnu.org/onlinedocs/gnat_ugn/Performing-Dimensionality-Analysis-in-GNAT.html
> 
> http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf
> 
> It is still GNAT-specific, though.

For not GNAT-specific approach, especially, for engineering rather than
computations, see:

http://www.dmitry-kazakov.de/ada/units.htm

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Incompatible types for array conversion

[hreba]

I am responding to my own post in order to address all of you.

Thanks for your answers, I have learned from them.

My actual project has very few units, so I am happy with my simple 
solution. For any future case with more units I will for sure follow 
your links.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: Incompatible types for array conversion

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly1tg0jrtm.fsf@pushface.org...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 15-07-22 10:13 , Simon Wright wrote:
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>>
>>>> The conversion is rejected because of the conversion condition in RM
>>>> 4.6 (24.5/2): "The component subtypes shall statically match". The
>>>> component (sub)types are Real and Length, which are different types,
>>>> although Length is derived from Real. If you change the declaration
>>>> of Length to be
>>>>
>>>>     subtype Length is Real;
>>>>
>>>> the conversion becomes legal.
>>>
>>> I tried
>>>
>>>     generic
>>>        dim: positive;
>>>        type Real is digits <>;
>>>     package Vectors is
>>>        type Vector is array (1..dim) of Real'Base;
>>>
>>> but it still failed. (GPL 2015, FSF 5.1.0)
>>
>> Did you expect it to work? Real'Base gets rid of any constraints on
>> Real, but AIUI does not get rid of the type derivation; if "type
>> Length is new Real", Length'Base is not the same as Real'Base -- the
>> "new" makes them different.
>
> Well, who knows what 'statically match' means! (outside the ARG,
> anyway). I thought it was worth a try.

It's clearly ;-) explained in ARM 4.9.1. Short summary: it's the same type 
with the same constraint. We use statically match simply so that things that 
are "obviously" the same are treated as such:

    subtype S1 is Int range 1 .. 10;
    subtype S2 is Int range 1 .. 10;

S1 and S2 statically match (as one would hope). But if someone declared 
separate types in Ada (as in "new"), they're really different, and then they 
can never statically match (because they don't match in any way).

Some other parts of type conversions use "convertible", which would allow 
such conversions. I think the rules for array components are too strict, but 
simply using "convertible" doesn't work for various obscure reasons, and 
coming up with a concept just for this case isn't worth it. (We looked at 
this as one of the solutions for AI12-0037-1, but in the end we just changed 
the declarations of the types instead.)

                                  Randy.