Re: dataframe dereferencing

[Jaroslav Hajek]

On Tue, Sep 7, 2010 at 5:04 PM, CdeMills <address@hidden> wrote:
>
>
> Judd Storrs-2 wrote:
>>
>> On Tue, Sep 7, 2010 at 2:10 AM, Jaroslav Hajek <address@hidden> wrote:
>>
>>> Also, to access individual elements, overload {I,J} to give the
>>> corresponding element(s) directly.
>>>
>>
>> It seems like sometimes you would want to treat the dataframe as a matrix
>> and sometimes you would want to treat it as a cell array. For example,
>> maybe
>> you want to call some function that works generically on cell arrays or on
>> matrices without rewriting the functions to have special cases for
>> dataframes.
>>
>> Additionally, how does one extract a range as a matrix without specifying
>> a
>> type? If df{1:3,1:3} always returns a cell array and df(1:3,1:3) always
>> returns a dataframe, I think we'd be stuck with constantly annotating
>> types
>> either by sometype(df(1:3,1:3)) or df(1:3,1:3).sometype which seems
>> somewhat
>> tedious. I suppose something like native(df(1:3,1:3)) or
>> df(1:3,1:3).native
>> could be used to tell dataframe not to convert types, but I think were
>> stuck
>> again with requiring functions to know about the dataframe interface?
>>
>
> For the first point, this is why I think that dataframe subreferencing
> should be polymorphic, even if it breaks the principle of least surprise.
> This permit to use dataframes with all numeric functions expecting numeric
> matrices as input, without knowing they use df. In such view, it is the
> programmer which has to make sure that the referenced elements are all of
> the same type.

Which functions? Unless the function starts with indexing the matrix,
you're not getting anywhere with this.


>
> The problem with something(dataframe(some_range)) is that we have (Jaroslav,
> correct me if I'm wrong), two steps: a call to @dataframe/subrefs, then a
> call so @dataframe/something, provided the first call returned a dataframe.

Yes.

> OTOH, is the chaining determined at run time ?

Yes.

> I mean, before determining
> which 'something' is called, the program has to determine the class of
> df(some_range).

Yes.

> So we could make things simpler if df(some_range) knows its
> context, i.e. the function calling it. Is it possible in 3.2

No.

> -- will it be possible in 3.4 ?
>

No.

We've been discussing this before. Yes, handling *both* indexing and
conversion at once is more efficient. I don't think it's simpler, at
least not from a user's point of view (i.e. simpler to type and
remember). But I suspect that an index -> conversion approach would
not be that much slower. Especially when using a contiguous row range,
where Octave would use lazy copies.

Yes, unfortunately with my design you would alway have to write
as_matrix(df(I,J)). Automatic conversions are, in general, convenient
when working interactively from a console, but they often become a
burden when building general codes.

Sparse matrices are a good example. In old and even not-so-old
versions of Matlab, S(i,j) for a sparse S and scalar i,j returned a
scalar. Now they changed it to sparse 1x1 matrix. The point is that
even if it's convenient for element-wise work, it's cumbersome because
when indexing a sparse matrix using S(I,J) you have to insert checks
for special cases when isscalar(I) && isscalar(J) && ! islogical(I) &&
! islogical(J). Incidentally, Octave has been doing it right as long
as I know it.

On the contrary, sparse matrices are seldom operated by elements via
loops (because it's inefficient, even in Matlab), so it's not that
much of a sacrifice. But I suppose dataframes would often be worked
with interactively.

I'd say you just keep your design and let's see what will come of it.
I don't know about Judd, but I haven't yet even tried to use the
dataframe class, so my suggestions lack practical basis.

regards

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