Re: dataframe dereferencing

[Jaroslav Hajek]

On Sat, Sep 4, 2010 at 4:46 PM, Judd Storrs <address@hidden> wrote:
> On Sat, Sep 4, 2010 at 9:00 AM, Jaroslav Hajek <address@hidden> wrote:
>>
>> It wouldn't, I'm afraid. dataframe apparently stores a collection of
>> columns (arrays, which is a good idea), so as_cell(df) would imply
>> conversion of the whole dataframe, which would then be indexed. On the
>> contrary, as_cell (df(I,J)) would first index the dataframe, creating
>> another dataframe to convert to a cell. df.as.cell(I,J) could even
>>
>> skip forming the intermediary dataframe and directly form the result
>> from the appropriate portions of relevant columns.
>
> The point isn't the implementation, it's the syntax.  Without going into
> lots of detail, if you want to think about how as_cell(df(I,J)) can be made
> as efficient as a direct function call e.g. as_cell(df,I,J) you should
> consider what returning an @dataframeview object as the result of df(I,J)
> instead of an full @dataframe (or cell) might achieve.

This is obvious, and I don't even think a view object would be
necessary, especially considering that Octave's arrays can already do
shallow slicing. However, if you go back and read more carefully what
you've written:

>Probably something like as_cell(df){I,J} would have the same performance 
>advantages and also avoid hand-written > dispatch code.

you'll realize that this would be more difficult to optimize. Perhaps
it was just a typo.
Still comparing to direct indexing + conversion in one method, there
is the overhead of creating the temporary object, be it a plain
dataframe or any view. If it's written in m-code, it can't be simply
ignored, although it can still turn out to be negligible in practical
cases.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz