Re: [eigen] ideas about the corner types

[Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>]

On Fri, Feb 5, 2010 at 4:51 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
>
>
> On Fri, Feb 5, 2010 at 4:01 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2010/2/5 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> >
>> >
>> > On Fri, Feb 5, 2010 at 11:43 AM, Thomas Capricelli
>> > <orzel@xxxxxxxxxxxxxxx>
>> > wrote:
>> >>
>> >>
>> >> Something i dont understand: why do we need to use a trick to make a
>> >> compile-time parameter to look like a runtime one ?
>> >> Why not (as is done in other parts of eigen) do corner<TopLeft>(3,3)
>> >> and
>> >> makes this explicit ?
>> >
>> > sure, ideally I would prefer your suggestion but c++ is such that the
>> > trick
>> > has the advantage of not needing the template prefix (in template code):
>> >
>> > m.corner(TopLeft,3,3)
>> >
>> > vs
>> >
>> > m.template corner<TopLeft>(3,3)
>>
>> Still, Thomas has a point since elsewhere in Eigen we're just using
>> template parameters. Perhaps we should be consistent. I guess that the
>> biggest argument in favor of my corner() proposal here is to keep the
>> same API as Eigen2... as you say, one could keep the current function
>> unchanged in              Eigen2support and move to an "officially"
>> templated one...
>>
>> Notice that _every_ templated method could be replaced by an
>> _implicitly templated one in this way_, general int parameters could
>> be wrapped in a CompileTime<int> empty struct, etc... so we just have
>> to make a choice, to use such tricks or to use plain template methods,
>> and be consistent with that... thanks for the reminder.
>
> right.
>
> there is also a naming issue to add Bottom, Top as we cannot reuse corner
> for that.
>
> So let me suggest a completely different API for all the sub matrices:
>
> m(Bottom(rows))
> m(Bottom<Rows>())
> m(TopLeft(rows,cols))
> m(TopLeft<Rows,Cols>())
> m(Block(i,j,rows,cols))
> m(Block<Rows,Cols>(i,j))
>
> if TopLeft, Bottom, Block (yes there is a name clash with the Block expr but
> that's a detail), etc. inherit the same base class (CRTP powered), we can
> have a single overload of operator() for these cases. The computation of the
> actual block parameters would be respectively done by the Bottom, TopLeft,
> Block, etc. classes. So it seems to me that would even simplify the
> implementation.
>
> This way we could even add Ranges:
> m(Range(i_start,i_end), Range(j_start,j_end))
>
> and Indexes (this one requires a special expression, but it's just to show
> the API consistency).
> vec(Indexes(some_vector_of_integer))
>
> This is just a rough idea which is btw closer to what you would do with
> MatLab.
>
> Let's see our your reaction...


I like this.  The only thing I am a bit undecided about is about this
being the behavior of the operator() instead of a method (e.g. sub()
or something).
The advantage of this being the operator() is that it is closer to
Matlab's syntax.
However on the other hand this might make the code less explicit and
clear, but that is just a personal opinion.

If I read this code:

mat(i, j) *= 3;

I must know whether i and j are ints or expressions, to know what is
happening.  And me personally I would be biased to think I'm changing
one single coefficient.
But well, that's just a tiny detail.  In general:
+1 for this way of accessing submatrices or subvectors.

ricard

>
> gael
>
>>
>> Benoit
>>
>> >
>> > gael.
>> >
>> >>
>> >> (The trick could still be used in the eigen2 compatibility stuff to
>> >> keep
>> >> the old api)
>> >>
>> >> Thomas
>> >> --
>> >> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
>> >> http://www.freehackers.org/thomas
>> >>
>> >> In data venerdì 05 febbraio 2010 10:45:21, Benoit Jacob ha scritto:
>> >> > >> Currently matrix.corner(TopLeft,3,3) takes TopLeft as a runtime
>> >> > >> parameter. This is based around the assumption that the compiler
>> >> > >> resolves this at compile time. In practice that seems to work
>> >> > >> although
>> >> > >> I only checked GCC. Here's an idea to resolve this at runtime: let
>> >> > >> TopLeft be an object of type CornerType<TopLeft_t>, etc.. taking a
>> >> > >> common template CornerType type allows to write the function only
>> >> > >> once, yet have a guarantee that that stuff resolves at compile
>> >> > >> time.
>> >> > >
>> >> > > Sounds good, and that does not change the API right ?
>> >> >
>> >> > No API change, assuming that nobody was perverse enough to actually
>> >> > pass a runtime variable, whose value actually isn't known at compile
>> >> > time, as the corner type.
>> >>
>> >>
>> >
>>
>>
>
>
>
>



-- 
ricard
http://www.ricardmarxer.com
http://www.caligraft.com