Re: [eigen] block of dense-block should again be block

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

Here is a radical proposal:

let all direct-access block() methods return a Map, not a Block.

Thus, Block would be only for the non-direct-access case anymore.
Should be renamed to something making that explicit.

People would thus no longer explicitly create a Block<MatrixXd, 4, 4>
object, instead they would create a typename BlockReturnType<MatrixXd,
4, 4>::Type object, which (they don't need to know) is a typedef for
Map<Matrix4f, outerstride...>

The MapBase class could thus be removed (merged into Map).

Benoit


2010/6/27 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> Gael, thinking more about this, our current solution with MapBase is
> almost "good", the only remaining issue is that MapBase doesn't reduce
> the number of types instantiated. We need to make sure that if two
> Block/Map types amount to the same, then they _are_ the same type.
>
> Benoit
>
> 2010/6/27 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 2010/6/27 Manoj Rajagopalan <rmanoj@xxxxxxxxx>:
>>> Hi,
>>>
>>>   I have a dense matrix(expression). When I create a block out of it and
>>> another block out of this block, I should get an object of type
>>> Block<some-DenseBase-derivative>. Currently, I get
>>> Block<Block<some-DenseBase-derivative> >. Studying the code, this is the
>>> natural way to cover all cases but can the block-of-block-of-X be collapsed
>>> to just block-of-X when X is dense? AFAIK this should also apply to all X
>>> besides dense (please correct me).
>>
>> Overloading block() and friends in the Block class to return simple
>> Block<...> instead of Block<Block<...>> would be a quite good idea, as
>> it would reduce the number of Block types instantiated. Internally
>> we're inheriting MapBase anyway, so this idea is already implemented
>> internally, but reducing the number of Block types would be valuable
>> as it could result in shorter compilation and smaller executables.
>>
>> As for user expectations, I guess that in both ways some users will be
>> surprised, can't please everybody. Such contraction of expression
>> types(Block<Block<T>> into Block<T>) would be rather unique, so of
>> course it would surprise people, which is not very good.
>>
>> Users who construct named Block objects are advanced users anyway.
>>
>>>   If the associativity (endomorphism on the space of data-types, actually)
>>
>> This flew 10 km above my head... a tiny white dot in the clear blue
>> sky. What is an endomorphism, with respect to what structure?
>>
>>> holds for all types X, then can a member function be introduced into class
>>> Block that solves this problem? I thought I would try this and send a patch
>>> but I am not sure the endomorphism will hold for all expression types X that
>>> Block<> could apply to.
>>
>> A patch would consist in finding a way to reimplement all
>> block-returning methods on Block, with minimal number of LOC. Need to
>> find a way to do that as automatically as possible. A patch doing all
>> that manually would be very scary. This also needs a greatly expanded
>> unit test on taking all sorts of blocks on blocks.
>>
>>>   As a user I suggest that the documentation should warn users about this
>>> case if this feature is not implemented.
>>
>> Sorry, but I still don't agree that fact that .block().block() returns
>> a Block<Block<... needs a warning. Having it return a Block<...
>> instead, would be preferable for the sake of reducing template
>> istantiations, but would not AFAICS be any more intuitive.
>>
>> Benoit
>>
>>>
>>> Thanks,
>>> Manoj
>>>
>>>
>>>
>>
>