Many thanks for your comments and question. I agree that the axis argument is confusing: while axis 0 generally means rows and axis 1 generally means columns, there are plenty of places where this association becomes stretched or seems inverted. However, as much as possible, StaticFrame follows NumPy to resolve such potentially arbitrary choices: thus axis 0 and 1 have the same meaning in np.sum() as in sf.Frame.sum(). Given NumPy's long history, following NumPy rather than inventing a new notation seems practical.
Note that in some cases StaticFrame offers more numerous and narrow interfaces that remove the need for an axis argument entirely. For example, there is no axis argument in sf.Frame.drop: instead, __getitem__, loc, and iloc interfaces are exposed on sf.Frame.drop. So a column named "a" can be dropped with sf.Frame.drop['a'], or all columns including and after "a", and all rows including and after "b", can be dropped with sf.Frame.drop.loc['b':, 'a':].
Thank you for the reply! I understand the value of not breaking away from the numpy tradition. Coming up with alternative interfaces which eliminate the need for an axis argument in the first place (when possible) seems like a good way to improve ergonomics while being reasonably conservative about this.
The different semantics of axis in pandas.drop vs. e.g. .sum is my go-to example of this inconsistency, so I did notice when playing around with static-frame that its version of .drop elegantly avoids axis altogether :) Well done!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Many thanks for your comments and question. I agree that the
axisargument is confusing: whileaxis0 generally means rows andaxis1 generally means columns, there are plenty of places where this association becomes stretched or seems inverted. However, as much as possible, StaticFrame follows NumPy to resolve such potentially arbitrary choices: thusaxis0 and 1 have the same meaning innp.sum()as insf.Frame.sum(). Given NumPy's long history, following NumPy rather than inventing a new notation seems practical.Note that in some cases StaticFrame offers more numerous and narrow interfaces that remove the need for an
axisargument entirely. For example, there is noaxisargument insf.Frame.drop: instead,__getitem__,loc, andilocinterfaces are exposed onsf.Frame.drop. So a column named "a" can be dropped withsf.Frame.drop['a'], or all columns including and after "a", and all rows including and after "b", can be dropped withsf.Frame.drop.loc['b':, 'a':].Thank you for the reply! I understand the value of not breaking away from the
numpytradition. Coming up with alternative interfaces which eliminate the need for anaxisargument in the first place (when possible) seems like a good way to improve ergonomics while being reasonably conservative about this.The different semantics of
axisinpandas.dropvs. e.g..sumis my go-to example of this inconsistency, so I did notice when playing around withstatic-framethat its version of.dropelegantly avoidsaxisaltogether :) Well done!