Writing up a column ordering glitch. I've only half looked into this, so some of the details may be wrong.
Calling DataFrameWrapper.to_frame(column_list), if the columns you ask for are in the core table then they are returned in the order listed. But if they are computed columns then the order varies at random.
Here's the function: orca.py#L372.
This is annoying and I can't think of a reason not to make it deterministic. I think this might be a "new" behavior in that it was not originally intended but the way Python handles some underlying data structure changed at some point to cause this.
A work-around is to use DataFrameWrapper.to_frame(column_list)[column_list] when a consistent order is needed. (Although Orca fails gracefully if items from column_list are not defined, while the work-around does not.)
Relatedly, I see in the code that the computed columns are also generated in a random order, which might occasionally cause inconsistent outcomes that would not be controlled by a NumPy random seed.
Writing up a column ordering glitch. I've only half looked into this, so some of the details may be wrong.
Calling
DataFrameWrapper.to_frame(column_list), if the columns you ask for are in the core table then they are returned in the order listed. But if they are computed columns then the order varies at random.Here's the function: orca.py#L372.
This is annoying and I can't think of a reason not to make it deterministic. I think this might be a "new" behavior in that it was not originally intended but the way Python handles some underlying data structure changed at some point to cause this.
A work-around is to use
DataFrameWrapper.to_frame(column_list)[column_list]when a consistent order is needed. (Although Orca fails gracefully if items fromcolumn_listare not defined, while the work-around does not.)Relatedly, I see in the code that the computed columns are also generated in a random order, which might occasionally cause inconsistent outcomes that would not be controlled by a NumPy random seed.