Add SortedVector set type

[gdalle]

Add a new pseudoset type SortedVector which is uniformly faster than both BitSet and Set up to 10% sparsity (see Discourse)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.18182% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 73.98%. Comparing base (83cb0b0) to head (001b97f).
Report is 1 commits behind head on main.

Files	Patch %	Lines
src/sortedvector.jl	97.67%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #38      +/-   ##
==========================================
+ Coverage   72.30%   73.98%   +1.67%     
==========================================
  Files           8        9       +1     
  Lines         278      319      +41     
==========================================
+ Hits          201      236      +35     
- Misses         77       83       +6     

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

[adrhill]

Out of curiosity: Do we need to update #4 again? 😉

[gdalle]

Out of curiosity: Do we need to update #4 again? 😉

Oh definitely. They've been blown so far out of the water they don't even see the water

[gdalle]

EDIT: we're not uniformly faster than BitSet, see https://discourse.julialang.org/t/best-data-structure-for-fast-unions-of-large-sets-of-integers/113785/33?u=gdalle

But it's okay cause the user can choose

[adrhill]

In runtests.jl, there are a couple of loops over different set types:

SparseConnectivityTracer.jl/test/runtests.jl

Lines 46 to 48 in 83cb0b0

	@testset "First order" begin
	for S in (BitSet, Set{UInt64})
	@testset "Set type $S" begin

SparseConnectivityTracer.jl/test/runtests.jl

Lines 259 to 262 in 83cb0b0

	@testset "Real-world tests" begin
	include("brusselator.jl")
	for S in (BitSet, Set{UInt64})
	@testset "Set type $S" begin

SortedVector should be tested there as well.

And once HessianTracer is supported via distributive_merge, the same applies to HessianTracer:

SparseConnectivityTracer.jl/test/runtests.jl

Lines 118 to 120 in 83cb0b0

	@testset "Second order" begin
	for S in (BitSet, Set{UInt64})
	@testset "Set type $S" begin

Once this passes, we make SortedVector the DEFAULT_SET_TYPE in src/pattern.jl.

[gdalle]

Once this passes, we make SortedVector the DEFAULT_SET_TYPE in src/pattern.jl.

Keep in mind that BitSet is still faster for denser cases. Should we be asymptotically optimal and let the user tweak for smaller sizes? I think so but it's your call

[gdalle]

Should I get rid of the parametric vector type and just use Vector for simplicity? It's a bit cumbersome and I don't see us using anything else in the short term (as in, next week)

[adrhill]

Keep in mind that BitSet is still faster for denser cases. Should we be asymptotically optimal and let the user tweak for smaller sizes?

The benchmarks on Discourse were primarily on huge input dimensionalities (10e6), whereas I feel the average user interested in sparsity probably deals with smaller problems. I think to select the default, we should benchmark on inputs of dimensionality 10 to 1000. Maybe there is a clear winner regardless of sparsity.

[gdalle]

Depends on #42, merge that one first

[adrhill]

Closes #41.