JuliennedArrays.jl
JuliennedArrays.jl copied to clipboard
Slice exported from Base
As of 1.9, so figure out what what to do about that...
If I can make a suggestion, it would be nice if:
- Any features in this package missing from base were added there--which I believe is just
Align--and - This package provides all the
Slicescode if the Julia version in use is pre-1.9. That way, code relying on the newSlicesobject can be kept compatible with pre-1.9 just by adding this as a dependency.
Thanks for the suggestion! I'm not sure about 1, I think that would be up to base. I haven't checked whether Slices in base does more or less things than the Slices that's here. I'm tempted to just rename the Slices here, but I also don't want to break anyone's code.
No great suggestions, but if https://github.com/JuliaLang/Compat.jl/pull/663 is ever merged then Compat will provide the new Slices type.
Thanks for the suggestion! I'm not sure about 1, I think that would be up to base. I haven't checked whether
Slicesin base does more or less things than theSlicesthat's here. I'm tempted to just rename theSliceshere, but I also don't want to break anyone's code.
I think it's nearly identical, but @simonbyrne would know better than me.
@bramtayl I've checked, and the only differences are:
- The
Slicesin Base don't implementAlign. - The
Slicesin Base are constructed usingeachslice, and don't have a constructor methodSlices(array, dims...). I'm guessing both the additional constructor andAlignwould be welcomed as pull requests, butAligncan stay here if not.
Making old JuliennedArrays code compatible with 1.9 would just require adding a Slices constructor to base, and then having this package define Slices only for versions before 1.9.
Ok. Sure, PR's welcome. If you want to submit a PR to base for align, feel free, but I haven't had to much luck with similar PR's.
The eager Align is stack, and my understanding is that people were not so keen on adding a lazy version. While a view from eachcol is almost always as good as a dense array, this is not true of the fragmented view made by things like Align.
The eager
Alignisstack, and my understanding is that people were not so keen on adding a lazy version. While a view fromeachcolis almost always as good as a dense array, this is not true of the fragmented view made by things likeAlign.
That makes some sense, but what's the problem with having both? Sometimes copying is less efficient than returning a lazy view. Julia provides lazy versions of some other functions, like map vs Iterators.map, for exactly this reason.
Looks like there's not much interest in a PR to base; in that case, I think the package should be able to just implement a Slices constructor following the old syntax that forwards the method to Base, to avoid breaking any packages.