mllg
how can i figure out which colnames belong to prob and algo params
i would like to get the strings in groups which are the names of the parameters of my probs and algos (in 2 seperate groups)
in BE it was possible to ask about this, and this is super-useful for post processing of results
Is this a duplicate of #97 ?
I plan to not unnest the parameters of problems and algorithms in the next release. Instead you get a column for problem parameters and a column for algorithm parameters, both as a list column. This would solve this issue I guess.
In order to make this work for most people not that familiar with nested data.frames, I will export a helper function to automatically unnest/flatten a specific column (default: all list columns). https://github.com/Rdatatable/data.table/pull/2077 is blocking this currently though.
no this is certainly not a duplicate, the other issue is about me collecting (complex) stuff in list cols.
I plan to not unnest the parameters of problems and algorithms in the next release. Instead you get a column for problem parameters and a column for algorithm parameters, both as a list column. This would solve this issue I guess.
In order to make this work for most people not that familiar with nested data.frames, I will export a helper function to automatically unnest/flatten a specific column (default: all list columns).
yes. you need that helper, otherwise this is a horrible idea. even with the helper you are now making this a LOT less intuitive for many users. gut feeling would be to advise against this.
why not make that an arg options, and the default is the current behavior with flat cols? this also does not break existing code (which would be bad on its own).
why not make that an arg options, and the default is the current behavior with flat cols? this also does not break existing code (which would be bad on its own).
This actually is an argument now, and the default is flat columns if a heuristic thinks that this is possible. As it turned out, this is pretty error prone because it is generally not type safe. I fall into this trap frequently which makes me believe that this approach is bad, and the user should actively say what to do with the columns so I can react with a good error message.