Overload common operations for Hilbert objects

Created by: gcarleo

At some point I was experimenting with overloading operators in Hilbert objects (#191 )

This allowed to do things like

#20 qubits from tensor product
hi = nk.hilbert.Qubit() ** 20

#40 qubits
hi *=hi

#50 qubits... 
hi1=hi*nk.hilbert.Qubit(n=10)

It might be nice to do this again, also because now it should be very easy to do in pure python

added enhancement help wanted labels

Created by: PhilipVinc

Julia does it. I like Julia. We should do it too. Il 21 mag 2020, 22:15 +0200, Giuseppe Carleo notifications@github.com, ha scritto:

At some point I was experimenting with overloading operators in Hilbert objects (#191 ) This allowed to do things like #20 qubits from tensor product hi = nk.hilbert.Qubit() ** 20

#40 (closed) qubits hi *=hi

#50 qubits... hi1=hi*nk.hilbert.Qubit(n=10) It might be nice to do this again, also because now it should be very easy to do in pure python — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Created by: VolodyaCO

Is there any plan to write netket in Julia in the future?

Created by: gcarleo

Nope.

Created by: gcarleo

Mainly for 2 reasons:

1. Ecosystem: all major deep learning frameworks (PyTorch, Tensorflow, JAX...) are in python and the main tools used for data science are in python
2. Performance: using numba, one can effectively reduce/eliminate python overhead and be in par with C++ performance. That's one of the main reasons why we were able to remove C++ code in 3.0.

At this point then I don't see a strong case for Julia. If 2 wasn't effective, and this might be the case for other applications, I would agree that it would be worth exploring a change of language (or just keep pybind11 C++ bindings).

Of course we could still write a wrapper or just make netket usable from Julia... I am sure that @PhilipVinc would love that

Created by: PhilipVinc

(@gcarleo will hate me for saying that but before falling into the netket attraction sphere I had written a Julia package that implements most of the same things.) A bunch of stuff are very similar, like the representation of operators, but then the implementations diverge a bit.

The main problem with Julia is the lack of a performant AD framework supporting complex numbers. The differentiate everything approach of Zygote leads to very bad performance for the VMC use-case, because of the overhead and the fact we use relatively small networks compared to ML standard use cases. BackwardDiff.jl is very efficient, but as soon as he sees a complex number he freaks out. I guess now you could use AutoDiff.jl. But to use them efficiently, you need something like jax's vmap.

Julia ATM lacks a proper vmap. There are efforts to write super-generic vmap in Julia that can parallelise even your morning coffee, but we don't need their generality for our use case and they will still take ~ an year to develop...

Still, I have used my code in conjunction with DifferentialEquations.jl and it's been amazing.

I think that once those two issues are solved a performant implementation of VMC in Julia can be written without too many complications. moreover it will be super lightweight. By combining Flux's Functors with generic Chains, we would not need to write much.

In the meantime, if you ever wanted to wrap it through PyCall.jl I can guide you and help you out a bit. It's extremely easy to wrap a python package.

Created by: gcarleo

Guys, I really don't have an opinion against Julia, the language, itself. It's nice to see that there have been developments also in their AD and I am sure that they will soon catch up.

I am just saying that rewriting netket in Julia now (when we have literally just finished rewriting it!) seems to me not the right decision. If you want, in addition to points 1 and 2 (that are very strong arguments, in my opinion, and won't change any time soon) there are also points

3. Maintainability and consistency: we can't just write and rewrite the apis or (even worse) change language every year, otherwise people using the project will just get crazy and we will get crazy ourselves rewriting the same things several times!

4. Support: It has happened only relatively recently that python has acquired the ability to get seamless support on platforms going from Mac/Linux/Windows laptops to HPC clusters (for example through conda). To me, that is an essential requirement for the deployment of an open-source project that aims at being as inclusive as possible. I am not too familiar with the state of things on the Julia side, but the last time (quite recently) I tried to install the interpreter on my mac I had a few glitches and issues. I am 100% sure that these inconsistencies will be solved, because the project is still in its early stage, but it should also be considered that Python already has a stellar ecosystem and support.

Again, these are 4 points I believe are reasonable (please tell me if they are not) but I don't have a dogmatic position on this. To me, this is purely a matter of convenience at the moment, I would be happy to reconsider this in a year from now or so.

It should also be considered that on the python side there is a lot of activity to get jit and type annotations work effectively (not only numba, that is already an amazing project, but also the development of mypyc ). In this sense, it is true that python can be slow, but it is also true that to a large extent this problem is already easily solvable (and solved) by adopting the right tools and (often, as per numba) it does not even require a change in coding style. I still haven't found a case where I was urged to change language entirely because I just couldn't make it fast enough for the things I needed.

So, let's see in a year how things will evolve on both sides, and then we will reconsider this!

Created by: PhilipVinc

Closed by #520

closed