octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60210] [octave forge] (dataframe)


From: Tasos Papastylianou
Subject: [Octave-bug-tracker] [bug #60210] [octave forge] (dataframe)
Date: Thu, 11 Mar 2021 05:12:33 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0

URL:
  <https://savannah.gnu.org/bugs/?60210>

                 Summary: [octave forge] (dataframe) 
                 Project: GNU Octave
            Submitted by: tpapastylianou
            Submitted on: Thu 11 Mar 2021 10:12:30 AM UTC
                Category: Octave Forge Package
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Unexpected Error or Warning
                  Status: None
             Assigned to: None
         Originator Name: Tasos Papastylianou
        Originator Email: 
             Open/Closed: Open
                 Release: 6.2.0
         Discussion Lock: Any
        Operating System: Any

    _______________________________________________________

Details:

Indexing by column name in the dataframe package seems to attempt to match a
given string to substrings in existing names (regardless of position).

This seems to create problems when using an exact column name, which also
exists as a substring in another column.

E.g.


A = dataframe( [1,2;3,4;5,6;7,8], 'colnames', { 'Close', 'Close1' } );
A.Close
error: subsref.m querying name Close returned positions 1
subsref.m querying name  returned positions 
error: called from
    subsref at line 94 column 21


It is unclear if this 'partial matching' behaviour (as opposed to 'exact'
matching) is intentional. Perhaps this was trying to mirror R's ability for
partial matching, but commented-out code (line 83) seems to suggest that it
should be trying to do 'exact' matches instead.

The handling in the case of multiple matches is a bit peculiar in general.
E.g. irrespective of the actual error on line 94, I note in the code that at
line 86:


86: resu = df.x_data{indi}; %# extract colum;


when multiple matches have occured, and thus indi is non-scalar, as in this
case, the above line produces multiple results as a comma-separated-list, but
only the first item in this list is captured into resu.

This means that behaviour may change depending on the order in which the
various matching column names appear in the dataframe. This may be an
intentional design decision, in order to capture only the first matching
column, but we can't be sure since it's not documented to point out whether
this is explicitly the rationale at that line.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60210>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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