[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dataframe dereferencing
From: |
Jaroslav Hajek |
Subject: |
Re: dataframe dereferencing |
Date: |
Sat, 4 Sep 2010 21:24:11 +0200 |
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
- Re: dataframe dereferencing, (continued)
- Re: dataframe dereferencing, Judd Storrs, 2010/09/02
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/03
- Re: dataframe dereferencing, CdeMills, 2010/09/03
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/03
- Re: dataframe dereferencing, Judd Storrs, 2010/09/03
- Re: dataframe dereferencing, Judd Storrs, 2010/09/03
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/03
- Re: dataframe dereferencing, Judd Storrs, 2010/09/03
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/04
- Re: dataframe dereferencing, Judd Storrs, 2010/09/04
- Re: dataframe dereferencing,
Jaroslav Hajek <=
- Re: dataframe dereferencing, CdeMills, 2010/09/06
- Re: dataframe dereferencing, Judd Storrs, 2010/09/06
- Re: dataframe dereferencing, Judd Storrs, 2010/09/06
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/07
- Re: dataframe dereferencing, Judd Storrs, 2010/09/07
- Re: dataframe dereferencing, CdeMills, 2010/09/07
- Re: dataframe dereferencing, Judd Storrs, 2010/09/07
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/08
- Re: dataframe dereferencing, Jaroslav Hajek, 2010/09/08
- Re: dataframe dereferencing, Judd Storrs, 2010/09/08