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

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