Release 1.0

[dlfivefifty]

Planning the next version to be v1.0. So lets get any last minute breaking changes merged into this branch.

@jishnub @putianyi889 Let me know what you want to include. I don't think we'll add a "size" template variable for now (that can be 2.0) so just looking for more minor PRs.

[putianyi889]

I'm thinking of removing Ones and using general Fill instead. In which situation is Ones necessary?

[dlfivefifty]

It’s used all over the place, eg Eye

[dlfivefifty]

Note the multiplicative identity is definitely as fundamental as the additive identity, so if there’s a role for Zeros then there’s also one for Ones

[putianyi889]

Diagonal(Fill) could work like UniformScaling and cover what Eye does, no?

Fill does require one or two more lines to execute though

[jishnub]

Ones differs from Fill(1,...) because the constant is encoded in the type. Often, this makes constant-propagation easier when using Ones vs using Fill(1...).

[putianyi889]

#223 is the only thing on my wishlist atm

[jishnub]

Perhaps we should add a Zeros(::Type, size...) constructor similar to zeros(::Type, size...)? This would make switching between the two easier. Similarly, for Ones.

[putianyi889]

Perhaps we should add a Zeros(::Type, size...) constructor similar to zeros(::Type, size...)?

Basically #94

[dlfivefifty]

No because it’s important in places like LazyArrays simplify that multiplication by Eye is a no-op. If it were a general Fill then it becomes a multiplication.

also, it’s necessary that cumsum(::Ones) returns a AbstractUnitRange

[dlfivefifty]

Sounds good! That's not even a breaking change so can be merged before 1.0

[dlfivefifty]

#223 is the only thing on my wishlist atm

Do you mean just for Symmetric? Or other types like AbstractTriangular?

It's pretty easy to just add those and see if any ambiguities arise downstream.

[putianyi889]

Do you mean just for Symmetric

Toeplitz actually

[codecov]

Codecov Report

Merging #231 (d8e1f9a) into master (dc8aa6e) will increase coverage by 0.95%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master      #231      +/-   ##
===========================================
+ Coverage   99.04%   100.00%   +0.95%     
===========================================
  Files           4         5       +1     
  Lines         630       649      +19     
===========================================
+ Hits          624       649      +25     
+ Misses          6         0       -6     

Impacted Files	Coverage Δ
src/FillArrays.jl	100.00% <100.00%> (+0.31%)	⬆️
src/fillalgebra.jl	100.00% <100.00%> (+1.09%)	⬆️
src/fillbroadcast.jl	100.00% <100.00%> (+2.32%)	⬆️
src/oneelement.jl	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[dlfivefifty]

I think the simple way to handle that is add FillArrays.jl as a dependency to ToeplitzMatrices.jl and add the overloads there

[putianyi889]

add FillArrays.jl as a dependency to ToeplitzMatrices.jl

That doesn't quite make sense unless there are other interactions between them. I would write a function in my script if I have to use it.

On the other hand, the issue was caused by fixing the incompatibility with StaticArrays, so adding StaticArrays to FillArrays would be easier since it would allow +(Zeros, AbstractArray)

[jishnub]

On the other hand, the issue was caused by fixing the incompatibility with StaticArrays

It wasn't only StaticArrays, e.g. LazyArrays was also impacted, and I'm guessing other packages that overload + for their own array types might also have been broken. Defining +(Zeros, AbstractArray) automatically makes +(AbstractArray, MyAray) ambiguous for Zeros + MyArray. Ideally we wouldn't want to add such methods, and broadcasting might be a way to achieve what you want without running into ambiguities.

[putianyi889]

It wasn't only StaticArrays, e.g. LazyArrays was also impacted

Looks like StaticArrays and LazyArrays have ambiguity as well?

"Glue" mini packages could work, since to avoid the ambiguities, both packages should think of which method is better and be set prior. As for Julia 1.9 we might have like "Intercompatibility.jl" to focuse on resolving ambiguities.

julia> x = Vcat(1:2)
vcat(2-element UnitRange{Int64}):
 1
 2

julia> y = SVector(1,2)
2-element SVector{2, Int64} with indices SOneTo(2):
 1
 2

julia> x+y
ERROR: MethodError: +(::ApplyArray{Int64, 1, typeof(vcat), Tuple{UnitRange{Int64}}}, ::SVector{2, Int64}) is ambiguous. Candidates:
  +(a::AbstractArray, b::StaticArray) in StaticArrays at C:\Users\pty\.julia\packages\StaticArrays\a4r2v\src\linalg.jl:13
  +(A::Vcat, B::AbstractArray) in LazyArrays at C:\Users\pty\.julia\packages\LazyArrays\VJHIG\src\lazyconcat.jl:628
Possible fix, define
  +(::Vcat, ::StaticArray)
Stacktrace:
 [1] top-level scope
   @ REPL[35]:1

[dlfivefifty]

LazyArrays depends on StaticArrays already so no need for a glue package, just fix those ambiguities in Julia.

The Vcat example is another case that could be done at the broadcast level but that takes a significant amount of thought

[putianyi889]

Let a slice of Eye be OneElement?

[putianyi889]

I wonder if Requires.jl can fix the ambiguities.

[dlfivefifty]

Let a slice of Eye be OneElement?

A made a draft PR: #238

But on second thought: this behaviour could be true for all Diagonal matrices. Are we sure we want it for just Eye (and friends)?

[putianyi889]

I didn't know OneElement allows for any value. Yes, all Diagonals work.

[dlfivefifty]

Codecov is 💯 🎉 The perfect package 😂

[dlfivefifty]

I'm going through my packages and updating them, to make sure no more issues come up. Once this is done (say tomorrow) I'll tag.