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

[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
>>
>>
>>
>