Issues in qiskit-alt: a Julia backend for Qiskit.

[jlapeyre]

Description

qiskit-alt is a high-performance Julia backend for Qiskit with a Python frontend. It is quite new and experimental. It is not distributed as part of Qiskit. The main application is computing a qubit Hamiltonian from the specification of an electronic structure problem.

There are a number of projects available, small and large. The appropriate project depends on the experience of the mentee. There are a number of issues in the qiskit-alt repo. But, the project is divided into several other repos, most of which are hosted here. These repos have their own issues. A major part of the effort is improving deployment options of Julia with the Python project. These issues are in julia_project

Note that much of the work happens on the Python side. So, if you know some Python, but don't yet know Julia, you can still contribute.

Deliverables

Open a pull request that closes an issue and work through getting it merged. Alternatively, start by opening a new issue; for instance as a sub-issue of a more open ended one.

Mentors details

• Mentor 1
  • Name: John Lapeyre
  • GitHub ID: @jlapeyre
  • What they do: Qiskit development
• Mentor 2
  • Name: Jim Garrison
  • GitHub ID: @garrison
  • What they do: Qiskit applications development

Number of mentees

2

Type of mentees

• Mentee *
  • Required:
    • Some coding and github skills.
    • Desire to contribute to an open-source project.
  • Nice to have:
    • Python experience
    • Julia experience
    • Quantum computing knowledge

[gunchamalik]

@jlapeyre I have basic knowledge pf python, but no knowledge of Julia. I am interested in learning and contributing to this project.

[jlapeyre]

Hi @gunchamalik, thanks for reaching out! We will contact you very soon.

[jlapeyre]

Here is one possible topic:

There are two separate ways for Julia and Python to communicate dynamically. One is via PyCall.jl / pyjulia. The other (more recent) is via PythonCall.jl / juliacall. It would be great if a single candidate were the clear winner. It's not clear that one way is better than the other; they do have different features.

We need to find out whether to support one way or the other, or both, and if so how. A good bit of infrastructure for investigating this is in place. (I need to push some changes today or tomorrow to make this visible)

I'll refer to the communication methods as PyCall.jl and PythonCall.jl which are the Julia modules, but the corresponding Python modules are implied.

Some possibilities are

• Support both PyCall.jl and PythonCall.jl as backends to a single user-facing API. This is probably not a good idea. The semantics of the two systems are sufficiently different to require a fair amount of complexity to handle this. All future additions to the Julia code in qiskit_alt would have to support this.
• Support both PyCall.jl and PythonCall.jl, but in parallel. That is, some code would use one backend and some the other. This might be confusing because the semantics and coding styles might be different and cause lack of clarity in the code base. The user need not see this because it shouldn't be difficult to provide a uniform pure-python interface.
  However, more importantly, the two systems handle wrapping and converting data differently. So they can't always interact transparently without yet more conversion.
• Support only one of the two PyCall.jl or PythonCall.jl. This requires some implementation and benchmarking (and thinking!) to inform the decision for one system or the other.

I will follow up here with a link to the latest version of qiskit_alt, which is set up for investigating the topics above.

[rafal-pracht]

# 16 Julia - Qiskit.pdf

[gunchamalik]

Julia Backend for Qiskit - Checkpoint 1.pdf

[saharbenrached]

#16 Issues in qiskit-alt: a Julia backend for Qiskit.pdf

[MozammilQ]

This is my checkpoint-1's small presentation:
#16 Issues in qiskit-alt: a Julia backend for Qiskit.pdf