Constructors

[lkdvos]

This PR changes some of the constructors of SparseArrayDOK to more closely resemble their AbstractArray counterparts, by explicitly requiring undef.
Additionally, once #32 are in place, this also ensures that inputs are checked such that unless you provide a fully-qualified type, we will check if all indices are within the correct bounds.
Also additionally, this now automatically works for any AbstractDictionary or AbstractDict, with either Cartesian or Int key types.

Finally, for convenience I also added sprand and sprand! (interface up for debate!) to facilitate easily creating random arrays for testing purposes.

[codecov]

Codecov Report

Attention: Patch coverage is 28.94737% with 27 lines in your changes missing coverage. Please review.

Project coverage is 70.60%. Comparing base (24985a0) to head (e4b3ae4).

Files with missing lines	Patch %	Lines
src/abstractsparsearrayinterface.jl	5.00%	19 Missing ⚠️
src/sparsearraydok.jl	55.55%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #33      +/-   ##
==========================================
- Coverage   75.05%   70.60%   -4.46%     
==========================================
  Files           7        7              
  Lines         421      449      +28     
==========================================
+ Hits          316      317       +1     
- Misses        105      132      +27     

Flag	Coverage Δ
docs	39.68% <28.94%> (-2.42%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mtfishman]

Seems reasonable, I was using constructors like SparseArrayDOK{Float64}(2, 2) interchangeably as a zeros constructor and as SparseArrayDOK{Float64}(undef, 2, 2), probably best to be explicit about that. From that perspective, can we also introduce SparseArraysBase.spzeros? I can't think of better names than sprand and spzeros. Also what about SparseArraysBase.sprandn?

[mtfishman]

A question I have about sprand! is, should it zero out the input first?

[lkdvos]

I added in spzeros and followed the SparseArrays approach of having an optional rfn::Function argument in sprand(!) to allow for having a different type of random entries.
There's now an explicit call to ArrayLayouts.zero! since I don't know if we have an empty! or equivalent function in our interface?

Keep in mind that all of this is somewhat specific to non-stored entries being "zero", since otherwise these implementations become a bit ill-defined...

[mtfishman]

I added in spzeros and followed the SparseArrays approach of having an optional rfn::Function argument in sprand(!) to allow for having a different type of random entries. There's now an explicit call to ArrayLayouts.zero! since I don't know if we have an empty! or equivalent function in our interface?

I think I was using ArrayLayouts.zero! for that purpose. Not sure if there is a need to define our own SparseArraysBase.zero!, maybe that would be good and we could call out to ArrayLayouts.zero! as needed (I think overloading ArrayLayouts.zero! is important since it is part of the ArrayLayouts.jl matrix multiplication code logic, which we are using for sparse array matrix multiplication). I wouldn't want to use the name empty! since the fact that it empties the storage is an implementation detail, and it may not even do that for certain sparse array types, like DiagonalArray.

Keep in mind that all of this is somewhat specific to non-stored entries being "zero", since otherwise these implementations become a bit ill-defined...

Good point, we should start to keep track of which functions assume non-stored entries are zero and document that, and maybe check for it in functions that assume that. Maybe what we need is a trait function like SparseArraysBase.is_unstored_zero(a::AbstractArray). I've been using getunstoredindex as a way to check if the non-stored values are zero (like in the map! function) but that isn't a good idea if it is expensive to construct the zero entry, like if it is a large zero array. However, that could serve as a default definition and then sparse array types could overload SparseArraysBase.is_unstored_zero and store that information in the type/struct.

[mtfishman]

Should we call this Registrator.yml since that is what it is called in ITensorActions?

[lkdvos]

We definitely can, I have no strong opinions about this. (But let me know, because then we also have to update ITensorPkgSkeleton)

[mtfishman]

I would prefer that, I think it would be simpler to have a convention that workflows are named after the shared ones in ITensorActions.

More changes requested.