Add squeezing operator

[akirakyle]

No description provided.

[codecov]

Codecov Report

Merging #114 (2d9282a) into master (ab9995f) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #114      +/-   ##
==========================================
+ Coverage   93.60%   93.61%   +0.01%     
==========================================
  Files          25       25              
  Lines        3067     3072       +5     
==========================================
+ Hits         2871     2876       +5     
  Misses        196      196              

Impacted Files	Coverage Δ
src/QuantumOpticsBase.jl	100.00% <ø> (ø)
src/fock.jl	98.75% <100.00%> (+0.08%)	⬆️

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

[Krastanov]

@akirakyle, a couple of suggestions on this:

• given the work you are doing in Use FastExpm.jl for matrix exponential of SparseSuperOperator #112, should this use a better non-dense exponentiation? Maybe we should wait on Use FastExpm.jl for matrix exponential of SparseSuperOperator #112 before deciding how to proceed here?
• could you add in the docstring the latex math expression for the formula being computed, so that people do not need to worry whether there is a minus sign or a factor of 1/2 somewhere?

[akirakyle]

given the work you are doing in Use FastExpm.jl for matrix exponential of SparseSuperOperator #112, should this use a better non-dense exponentiation? Maybe we should wait on Use FastExpm.jl for matrix exponential of SparseSuperOperator #112 before deciding how to proceed here?

Like displace which is always nonzero everywhere, squeeze always nonzero in half the entries, so I think a dense representation will always be more efficient. However, it may be that using one of the other methods discussed in #112 would be faster than base.exp which is using an eigendecomposition according to its docstring. If I'm going to do some benchmarking, it would be worthwhile to include these two cases as they may warrant a different method than for exponentiation a typical lindbladian.

[Krastanov]

Yup, that is a good reason to merge as is. We can investigate improvements down the line after we know more from #112. This will be merged shortly.