Remaining tasks about boost-histogram

[HDembinski]

Feel free to split off some issues and assign to me, I just assigned the adaptive operator support to myself.

[HDembinski]

from_numpy is only possible with a special storage, I think, if you do not want to copy the memory.

[HDembinski]

Is it necessary to have from_numpy and to_numpy in boost-histogram? Wouldn't this be convenience in hist?

[HDembinski]

You can also implement such a to-do list with issues tagged by milestones.

[henryiii]

from_numpy is only possible with a special storage, I think, if you do not want to copy the memory.

I actually meant something else; what I was calling "from_numpy" would be three functions that took exactly the same arguments as np.histogram(), np.histogram2d(), and np.histogramNd(). This would allow boost-histogram to be a drop-in replacement for existing code bases. Probably means it was a bad name. What you are referring to would be useful too, though; it might be handled through hist and aghast though.

Wouldn't this be convenience in hist?

If it's lightweight and doesn't add any dependencies, I think it might as well be in boost-histogram. Yes, though, it's more in the scope of hist.

You can also implement such a to-do list with issues tagged by milestones.

Yes, this was quicker for rapid development. As I clean up the low hanging fruit, several items may become issues. I'll probably split the filling off into an issue pretty soon. That's the hardest group and probably the most important.

[HDembinski]

If it's lightweight and doesn't add any dependencies, I think it might as well be in boost-histogram. Yes, though, it's more in the scope of hist.

Good point!

[HDembinski]

Yes, this was quicker for rapid development. As I clean up the low hanging fruit, several items may become issues. I'll probably split the filling off into an issue pretty soon.

Make sense, this is a good workflow.

[HDembinski]

regular_noflow and regular_uoflow should not be public classes. On the Python side, there should only be a regular class which has a private _regular_noflow or _regular_uoflow instance, similarly for the other axis types

[HDembinski]

make_regular and friends can then be removed, since its role is taken over by the new regular that forwards to the private instances. The regular class can be written in pure Python.

[HDembinski]

Likewise it should be done for the specialized histogram classes. There should be one histogram class and several private _histogram_* specializations. make_histogram should then be removed. There is no need to mirror it in Python. The only reason it exists in C++ is because we do not have deduction guides in C++14.

[HDembinski]

threaded_fill should just be fill(... , threads=-1)

[henryiii]

It already is fill(..., threads=0), that changed a while ago... Though I think it's 0 for core-matching.

[henryiii]

I'll be moving all the names to private names soon. I'll move make_histogram as well; I am fine leaving that one public to mimic the C++ but I'm happy to hide it as well (and the Boost docs still say to use make_histogram, so I would consider it the main interface for histograms currently - and GCC 9 is the first C++17 complete GCC, and was released less than a week ago - Clang is not fully there yet).

[henryiii]

All remaining tasks are now available as separate issues. Will continue to check off here too for nostalgic reasons.

[henryiii]

Looks this this is done (one step moved to a later release).