Change the type of dims for QuantumObject to SVector for type stabilities

[albertomercurio]

Description

With this PR I made a lot of changes, because I basically changed the internal structure of the QuantumObject constructor.

I changed the type of the dims field from Vector{Int} to SVector{N,Int}, where N is the number of subsystems (e.g., two qubits, a qubit and a cavity….).

This change would fix possible type instabilities for functions like ptrace, where the temporary reshaped array depends on the length of the dims field.

Being a static fixed-length vector, the length of the dims field is already known at compile time, improving the performances.

It would also improve performances on functions dealing with dims, for example dfd_mesolve, where the Hilbert space dimension is changed dynamically during a time evolution.

Important

I kept the support for Vector as input, generating a warning string, and then converting it into a SVector

This PR is just a starting point. Here everything works. In the next PRs I will try to optimize the code to take advantage of the power of SVectors.

[codecov]

Codecov Report

Attention: Patch coverage is 98.56115% with 2 lines in your changes missing coverage. Please review.

Project coverage is 93.40%. Comparing base (6579bc1) to head (3be1f68).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/qobj/quantum_object.jl	93.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #217      +/-   ##
==========================================
- Coverage   94.24%   93.40%   -0.85%     
==========================================
  Files          29       29              
  Lines        2171     2197      +26     
==========================================
+ Hits         2046     2052       +6     
- Misses        125      145      +20     

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

[albertomercurio]

As an example, I was doing some benchmarks comparing the current implementation of ptrace and the one with SVector.

This is the result with SVector

julia> g = fock(2, 1)
Quantum Object:   type=Ket   dims=[2]   size=(2,)
2-element Vector{ComplexF64}:
 0.0 + 0.0im
 1.0 + 0.0im

julia> e = fock(2, 0)
Quantum Object:   type=Ket   dims=[2]   size=(2,)
2-element Vector{ComplexF64}:
 1.0 + 0.0im
 0.0 + 0.0im

julia> state = normalize(kron(g, e) + kron(e, g))
Quantum Object:   type=Ket   dims=[2, 2]   size=(4,)
4-element Vector{ComplexF64}:
                0.0 + 0.0im
 0.7071067811865475 + 0.0im
 0.7071067811865475 + 0.0im
                0.0 + 0.0im

julia> ptrace(state, 1)
Quantum Object:   type=Operator   dims=[2]   size=(2, 2)   ishermitian=true
2×2 Matrix{ComplexF64}:
 0.5+0.0im  0.0+0.0im
 0.0+0.0im  0.5+0.0im

julia> @code_warntype ptrace(state, 1)
MethodInstance for QuantumToolbox.ptrace(::QuantumObject{Vector{ComplexF64}, KetQuantumObject, 2}, ::Int64)
  from ptrace(QO::QuantumObject, sel::Int64) @ QuantumToolbox ~/.julia/dev/QuantumToolbox/src/qobj/arithmetic_and_attributes.jl:529
Arguments
  #self#::Core.Const(QuantumToolbox.ptrace)
  QO::QuantumObject{Vector{ComplexF64}, KetQuantumObject, 2}
  sel::Int64
Body::Union{QuantumObject{Matrix{ComplexF64}, BraQuantumObject, 1}, QuantumObject{Matrix{ComplexF64}, OperatorQuantumObject, 1}}
1 ─ %1 = QuantumToolbox.SVector(sel)::StaticArraysCore.SVector{1, Int64}
│   %2 = QuantumToolbox.ptrace(QO, %1)::Union{QuantumObject{Matrix{ComplexF64}, BraQuantumObject, 1}, QuantumObject{Matrix{ComplexF64}, OperatorQuantumObject, 1}}
└──      return %2


julia> using BenchmarkTools

julia> @benchmark ptrace($state, 1)
BenchmarkTools.Trial: 10000 samples with 240 evaluations.
 Range (min … max):  306.850 ns … 208.118 μs  ┊ GC (min … max):  0.00% … 99.70%
 Time  (median):     320.371 ns               ┊ GC (median):     0.00%
 Time  (mean ± σ):   385.384 ns ±   2.132 μs  ┊ GC (mean ± σ):  11.99% ±  5.47%

   ▂▅▄█▆▁                                                        
  ▂██████▇▄▃▂▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▂▃▄▃▂▂▁ ▂
  307 ns           Histogram: frequency by time          469 ns <

 Memory estimate: 736 bytes, allocs estimate: 13.

And this is with the latest stable version

julia> @benchmark ptrace($state, 1)
BenchmarkTools.Trial: 10000 samples with 40 evaluations.
 Range (min … max):  903.350 ns …   4.131 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):       1.137 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):     1.114 μs ± 126.638 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

     ▃▃                              ▂▄▆▇█▇▅▄▂▁                  
  ▂▃▇██▇▄▃▂▂▂▂▂▂▂▂▂▂▁▂▁▂▁▂▁▂▂▂▂▃▃▄▅▇███████████▇▆▅▅▄▄▃▃▃▃▃▂▂▂▂▂ ▄
  903 ns           Histogram: frequency by time         1.27 μs <

 Memory estimate: 1.09 KiB, allocs estimate: 20.

Almost 4 times slower.