Glas List: 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.

cheers
--guntram

-- 
============================================================
Guntram Berti -- NEC C&C Research Labs              O__  ==
Rathausallee 10, D-53757 St. Augustin, Germany     c/ /'_ == 
++49 [phone]  -32(voice) -99(fax)             (*) \(*) ==
                                                  ------------ 
http://www.ccrl-nece.de/~berti - berti_at_[hidden]
============================================================