Re: Incompatible types for array conversion

["G.B." <bauhaus@futureapps.invalid>]

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.