search

QuantumBFS / Yao.jl

Extensible, Efficient Quantum Algorithm Design for Humans.
https://yaoquantum.org
Other
926 stars 123 forks source link

Integration with other packages #157

Open jlapeyre opened 5 years ago

jlapeyre commented 5 years ago

QuantumGlue.jl implements the most basic conversion between DefaultRegister and a QuantumOptics.jl type. I am doing this mostly as a way to get an overview of Julia's quantum package landscape. I wonder how this fits with your plans. I don't want to duplicate effort.

Roger-luo commented 5 years ago

Thanks for letting us know. We currently do not have plan to integrate with QuantumOptics.jl, (we have some other features with higher priority and lack of developers...). It would be great to have something help the conversion between Yao and other packages. Please feel free to file us an issue if you have any further question about the package.

However, please notice the difference between AbstractRegister family and Ket:

a register is actually a rank-3 tensor stored in matrix form, the description can be found in docs https://quantumbfs.github.io/Yao.jl/latest/man/registers/

Sometimes, we might just need the state of active qubits, and the desired result might not be correct when we have a batch size.

For future consistency (we are implementing CUDA support), I would suggest you to use rank3 (return the rank-3 tensor with a 3 dimensional array) or state interface (return the stored raw value of the state) to get the state rather than using dot, then basically all the subtype AbstractRegister can be converted.

And in the future (this year), we might separate each part of Yao and make Yao a meta-package, so you will be able to have a smaller dependency :-)

GiggleLiu commented 5 years ago

Thanks, the only concern is we are going to move abstract types and part of abstract methods into a base package before the end of this year.

Apparently, we need some standards for quantum simulations, e.g. Pauli Gates have different names in Yao.jl, QuantumOptics.jl and Cliffords.jl, making related things departed. Comparing with python, Julia's multiple dispatch encourages better type tree design. I wonder if it is possible to work out a reasonable abstraction together with QuantumGlue and QuantumOptics, this is quite important for a constructive Julia ecosystem, and maybe better than glue?

@Roger-luo , shall we open a base package repo not only for Yao.jl but also for other quantum simulation packages at a proper place, so that we can hear constructive advices earlier?

jlapeyre commented 5 years ago

Hi. Thanks for the comments. I did make a change or two following your suggestions. I read about the batches and active qubits, but did not see an easy way make them work with Ket.

I wonder if it is possible to work out a reasonable abstraction together with QuantumGlue and QuantumOptics, this is quite important for a constructive Julia ecosystem, and maybe better than glue?

Yes, Julia quantum packages are somewhat fragmented. The glue package is exploratory. Using some common conventions or codes would be great. As usual, it's a matter of developer hours.

Roger-luo commented 5 years ago

Indeed, they are designed for different purpose. I would suggest to convert a register with batch size 1 (batch size is usually a type parameter, so it can be dispatched) to ket and convert a register with many batches to a vector of ket.