octave-maintainers
[Top][All Lists]
Advanced

[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 15:00:42 +0200

On Fri, Sep 3, 2010 at 11:09 PM, Judd Storrs <address@hidden> wrote:
> On Fri, Sep 3, 2010 at 3:53 PM, Jaroslav Hajek <address@hidden> wrote:
>>
>> I think you didn't quite understand my view of this. I don't think of
>> df.as.cell(I,J) as a method, but rather along the lines that
>> df.as.cell is a virtual object that holds the dataframe data (without
>> headers) converted as a cell, which then can normally be indexed.
>>
>> I basically agree that as_cell (df (I,J)) is more standard, I merely
>> pointed out that the former has a potential performance advantage.
>
> Probably something like as_cell(df){I,J} would have the same performance
> advantages and also avoid hand-written dispatch code.
>

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 question now is whether the cost of forming the intermediary
dataframe is high enough to justify an alternative syntax with
superior performance. Perhaps not. Right now, however, as_cell (df)
doesn't work anyway.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]