Zachary P Christensen

@fmvin I don't quite understand what you mean by "just from box". If you mean there is a single function that does what you want for each of those you...

It might make sense to use the Distributions package so you don't have to reinvent everything.

I think there's merit to it if it's part of a larger project incorporating similar things though. I've been toying with the idea of a package like ImageStats, but haven't...

This seems a lot like what we do in ArrayInterfaceCore. We don't have anything that merges device types and we account for a difference in CPU types that are built...

I think the loop vectorization stuff uses it a lot.

As you can see [here](https://github.com/JuliaArrays/ArrayInterface.jl/blob/b1ce7bb443eb82fc281be2989ee2fa5e364fe1d9/lib/ArrayInterfaceCore/src/ArrayInterfaceCore.jl#L354), we could do a better job of handling the actual device types in terms of documentation and additional methods. But we have a pretty good...

We have some nice tricks for avoiding generated methods using Static.jl too BTW. I haven't taken time to really dig in here and try it out, but it's worth thinking...

> Sure! Still, explicit support from the GPU packages would be nicer, right? And it's the only way that allows the user to handle systems with different GPUs cleanly, and...

> However we do this I think we should really aim to establish a single type tree for computing devices across the ecosystem, one that reaches down to different GPU...

I think the GPU side of things might be able to change without any breaking changes for us. We could probably justify some straightforward breaking changes if absolutely necessary if...