From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: hreba Newsgroups: comp.lang.ada Subject: Re: Incompatible types for array conversion Date: Wed, 22 Jul 2015 09:57:59 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net JCVNhPc9vq++IMSEFrxYHQttzuc+tqE69tkm0UZQZtwXALWeKp Cancel-Lock: sha1:E1+xq+7n87jTvfRBwSWnSwoBzx8= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:26981 Date: 2015-07-22T09:57:59-03:00 List-Id: 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