Re: [glas] MTL3 design ? [was MTL project site is up]
From: Guntram Berti (berti_at_[hidden])
Date: 2005-02-02 13:26:29
On Wed, Feb 02, 2005 at 05:43:35PM +0100, Toon Knapen wrote:
> So since assigning stack-based vectors of different sizes produces a
> (compile-time) error, it is not unexpected that assigning a vector
> (heap-based or other) to a vector of a different size generates an error
> (compile-time or run-time): generally assignments between vectors of
> different sizes result in an error.
On first thought, I would agree with that ... having an error in one
case (stack based) and not in the other case (heap-based) seems inconsistent.
However, I guess that stack-based and heap-based vectors will play very different
roles: Stack-based vectors will be small and used for "local" problems
(e.g. 3-vectors for velocities) whereas for the global solution vector one
would use heap-based vectors.
So perhaps one could make the decision error-or-not a policy parameter?
I think it will not be uncommon to wish to forbid even assignment between
vectors of equal size, for example if one represents cell-based and the other
one vertex-based quantities (speaking FEM). So one could introduce mechanisms
to forbid assigment at compile time (i.e. making those vectors different types).
> Additionally I think it would be more intuitive for mathematicians if we
> require vectors to have the same size before assigning them
> (mathematicians? anyone?)
Of course, mathematically ... it makes no sense to assign vectors of different sizes.
But that's not the only criterion, I think.
However, it may be convenient, for example if we need to reference a vector before
we can possibly know its size.
glas::vector v; // uninitialized
graphics_listener(v); // something that watches the vector values
v = solution(t0 + dt);
Just a bad example which comes to my mind.
Could probably done more elegantly without the need to assign different sized vectors.
Another example (distributed vectors):
global_vector gv = ....
local_vector lv = gv; // lv represents only the local part of gv
// and has different size.
Of course, in this case, the semantics of assigning differently sized vectors
is obvious (and they will even have different types!).
(In fact, I think, the vectors in this case are playing the role of a mathematical function
- again, think FEM - and assigment of functions with different domain of definition could be given a
well-defined semantics, especially if the domain of the rhs includes the domain of the lhs,
as is the case in the example.)
There may of course be a point in forcing the user to use an explicit conversion step
in this example.
> >>We can't do the same with other objects, and there's no
> >>obvious reason to impose an incompatibility restriction.
> resizing a vector comes with a (big) cost. I'm afraid that if the
> resizing is done under the hood, people will be surprised by the
> performance(-penalties) they get.
That's why I think this decision should be built into the type of the vector
in a configurable way. As I pointed out above, there may be other reasons to
forbid/allow assignment besides size.
-- ============================================================ Guntram Berti -- NEC C&C Research Labs O__ == Rathausallee 10, D-53757 St. Augustin, Germany c/ /'_ == ++49 +2241 92 52 -32(voice) -99(fax) (*) \(*) == ------------ http://www.ccrl-nece.de/~berti - berti_at_[hidden] ============================================================