<div dir="ltr">> I don't think this "lazy _mgr attribute" is comparable in complexity with the consolidated BlockManager<div><br></div><div>Not on its own, no.  But my prior is that this isn't the last thing that will merit its own special case.</div><div><br></div><div>> I think it clear that a BlockManager with only 1D arrays/blocks <i>can</i> be simpler as one with interleaved/consolidated blocks.</div><div><br></div><div>Absolutely agree.  I've spent a big chunk of the last year dealing with BlockManager code and have no great love for it.</div><div><br></div><div>> But this is also only one of the arguments. Complexity alone is not a reason to not do something; it's the general trade-off with what you gain or lose with it.</div><div><br></div><div>The main upsides I see are a) internal complexity reduction, b) downstream library upsides, c) clearer view vs copy semantics, d) perf improvements from making fewer copies, e) clear "dict of Series" data model.</div><div><br></div><div>The main downside is potential performance degradation (at the extreme end e.g. <a href="https://github.com/pandas-dev/pandas/issues/24990">3000x</a> for arithmetic).  As Wes commented some of that can be ameliorated with compiled code but that cuts against the complexity reduction.</div><div><br></div><div>I am looking for ways to quantify these tradeoffs so we can make an informed decision.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 12:57 PM Joris Van den Bossche <<a href="mailto:jorisvandenbossche@gmail.com">jorisvandenbossche@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 May 2020 at 23:00, Tom Augspurger <<a href="mailto:tom.augspurger88@gmail.com" target="_blank">tom.augspurger88@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 26, 2020 at 3:50 PM Brock Mendel <<a href="mailto:jbrockmendel@gmail.com" target="_blank">jbrockmendel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">> It allows to create a "DataFrame" from an ndarray without creating a BlockManager, and it allows accessing this original ndarray:<br><br><div>This is a neat proof of concept, but it cuts against the "decreases complexity" argument.  Is there a viable way to quantify (even very roughly) the complexity effect of going all-1D?</div></div></blockquote><div><br></div><div>That complexity is at least localized to a single attribute. That's quite different from the 1D & 2D blocks situation, where many methods (though fewer than a year ago) need to be concerned with whether the array in a block is 1D or 2D, or whether the DataFrame is consolidated, homogenous, ...<br></div><div> </div></div></div></blockquote><div>I don't think this "lazy _mgr attribute" is comparable in complexity with the consolidated BlockManager. Furthermore: it's targeted to a very specific and limited use case (and eg also doesn't need to be the default, I think).</div><div>Now, exactly quantifying the effect of going all-1D, that's of course hard. But just one example: all code that deals with blknos/blklocs (the mapping between the position in the consolidated blocks and the position in the dataframe), which is a significant part of managers.py, could be simplified considerably.<br></div><div><br></div><div>But anyway: I think it clear that a BlockManager with only 1D arrays/blocks <i>can</i> be simpler as one with interleaved/consolidated blocks. But this is also only one of the arguments. Complexity alone is not a reason to not do something; it's the general trade-off with what you gain or lose with it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>A couple ideas for ways to simplify this decision-making problem:</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2) IIUC going all-1D will cause column indexing to always return views. Elsewhere you have noted that this is a breaking API change which merited discussion in its own right.  xref <a href="https://github.com/pandas-dev/pandas/issues/33780" target="_blank">#33780</a>.  My takeaway from this part of the last dev call was that people were generally positive on the all-views idea, but were wary of how to handle the potential deprecation.</div></div></blockquote><div><br></div><div>This type of change would merit a major version bump. If possible, we'd ideally have some kind of option to disable consolidation / enable splitting, which would allow for users to test their code on older versions.<br></div></div></div></blockquote><div><br></div><div>Yes, going to an all-1D-BlockManager would be something for a major version bump, eg pandas 2.0. So I think that is the perfect opportunity to do such a change of making column selections always views.<br></div><div> </div></div></div>
</blockquote></div>