Re: [eigen] Feature suggestion: interior row and column ranges [patch attached]

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

I still prefer middleRows() over all of these...

2010/6/27 Manoj Rajagopalan <rmanoj@xxxxxxxxx>:
>
> How about
> (a) interiorRows()

How is interior better than middle?  It seems to have the same kind of
problem, it doesn't fit better for the case where we're taking e.g.
all rows.

> (b) consecutiveRows()
> (c) contiguousRows()

All our blocks are consecutive, contiguous. Using that name for that
method would suggest that it goes otherwise for others.

> (d) rowBlock()
>     => For consistency, topRows() --> topBlock(),  leftCols() --> leftBlock()
> (e) rowSlice()   (data visualization terminology)
>     => For consistency, topRows() --> topSlice(),  leftCols() --> leftSlice()
> (f) rowPanel()  (following Goto's nomenclature)
>     => For consistency, topRows() --> topPanel(), leftCols() --> leftPanel()

The 's' in 'rows' is really important to mean that we're taking
multiple whole rows. rowSlice() could be confusing as it could mean
e.g. a slice in a row.
Also I would like to avoid renaming the existing methods like
topRows(). The name has been up for debate a couple of months ago but
now, days before the beta, it's cumbersome to rename.

If there is really no good name for this method, let's just not add
it. After all, the user can do the same with explicitly constructed
Block objects. Adding a method only adds value if it has a good name.

Benoit

>
>
> BTW, the (start,count) spec for the rows or cols can be changed to
> (start,1+end) or (start,end) and "range" still used without loss of clarity.
> For example rowRange(3,6) or rowRange(3,5) for rows 3,4,5 (0-based indexing).
>
> -- Manoj
>
>
> On Sunday 27 June 2010 09:04:49 am Benoit Jacob wrote:
>> Another extremely important point in favor of "middle" is that it was
>> already used in the BASIC keyword MID to get a substring in a string.
>>
>> 2010/6/27 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> > Thanks for all these proposals.... I had the same feeling than you
>> > regarding the word "range" which, for me, is implicitly defined by a
>> > start and end positions instead of a start+count.  Like Manoj,
>> > middleRows makes me think that the rows are centered. The word "inner"
>> > is already used to speak about inner/outer vectors or inner/outer
>> > strides. So using innerRows would be too confusing. Sorry to be so
>> > negative ;) so finally among all these proposals, middleRows is maybe
>> > the least worse....
>> >
>> > gael
>> >
>> > On Sun, Jun 27, 2010 at 11:01 AM, FMDSPAM <fmdspam@xxxxxxxxx> wrote:
>> >>  As you said: Ideally the naming is clash free, consistent and of little
>> >> surprise.
>> >> Because I didn't  know Eigen or the English language well enough I'm
>> >> totally undecided.
>> >>
>> >> But let me post some Sunday morning thoughts:
>> >>
>> >> geometric names:
>> >> topRows - middleRows - bottomRows,   leftCols - middleCols - rightCols
>> >>
>> >> block names:
>> >> topRows - blockRows - bottomRows,         leftCols - blockCols -
>> >> rightCols
>> >>
>> >> sequential names:
>> >> startRows - innerRows - endRows,    startCols - innerCols - endCols
>> >> or
>> >> firstRows - middleRows - lastRows,    firstCols - middleCols - lastCols
>> >>
>> >> oldie names: headRows - ???Rows - tailRows
>> >>
>> >> What, if there are range expression object types? Would that be possible
>> >> w/o runtime costs?:
>> >> Something in the lines of:
>> >> blockRange<startrow, endrow, startcol, endcol> brange
>> >> indexRange<start, end> irange
>> >>
>> >>   topRows(3)   -> blockRange brange1(1,3,Dynamic,Dynamic)
>> >> bottomRows(3)   -> blockRange brange2(-3,-1,Dynamic,Dynamic)
>> >>  innerRows(3,2) -> blockRange brange3(3,3+2,Dynamic, Dynamic)
>> >>
>> >> =>
>> >> cout << "A(3..5,:) =\n" << A(brange3) << endl;
>> >> or
>> >> indexRange<3,2> irange1;
>> >> cout << "A(3..5,:) =\n" << A.rows(irange1) << endl;
>> >>
>> >> Cheers
>> >> Frank
>> >>
>> >> P.S.
>> >> I'm eager
>
>
>
>