All struct fields should be (concretely) typed (potentially with a type parameter) [$200]

[Krastanov]

Bug bounty logistic details (click to expand)

To claim exclusive time to work on this bounty either post a comment here or message [email protected] with:

• your name
• github username
• (optional) a brief list of previous pertinent projects you have engaged in

Currently the project is claimed by no one until ....

If you want to, you can work on this project without making a claim, however claims are encouraged to give you and other contributors peace of mind. Whoever has made a claim takes precedence when solutions are considered.

You can always propose your own funded project, if you would like to contribute something of value that is not yet covered by an official bounty.

Project: All struct fields should be (concretely) typed (potentially with a type parameter) [$200]

Many of the symbolic types in this library are rather clumsily defined, without much attention being paid to the types of their fields. The goal of this bounty is to specify them and parameterize them as much as possible and reasonable, in preparation for next steps like the use of sum types and Unityper.jl. This forum discussion might provide useful background.

Required skills: Understanding of Symbolics.jl and Julia's type system

Reviewer: Stefan Krastanov

Duration: 1 month

Payout procedure:

The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.

Click here for more details about the bug bounty program.

[R-ohit-B-isht]

@Krastanov can i take this?

[Krastanov]

Hi, Rohit! Do you have past experience with the julia language? This is a somewhat idiomatic topic that would be easy for someone knowing the language, but not obvious otherwise.

[thofma]

Is someone working on this? If not, I would like to take a stab at this.

[Krastanov]

Pardon the slow response, last week was a summer workshop. This one is indeed still open and unclaimed. A couple of notes though:

• I have a review backlog from last week so I might be a bit slow to provide reviews
• This particular bounty might suffer from frequent merge conflicts as it is pretty invasive
• This one is a bit ill defined, but the goal here is to avoid underspecified types so future work that moves these structures to an "abstract data type" / "sum type" framework is easier

[akirakyle]

Hey @Krastanov would it make sense to roll this issue into actually migrating the all the QuantumSymbolics.jl types to an algebraic data type library? I recently experimented with migrating SymbolicUtils.jl to Moshi.jl in the branch here https://github.com/JuliaSymbolics/SymbolicUtils.jl/pull/676 and I think the approach taken to ADTs in Moshi.jl is actually pretty elegant and seems to be quite performant.

I would be happy to take this task on, especially since changes here would already be necessary to support my proposed breaking changes to QuantumInterface.jl in https://github.com/qojulia/QuantumInterface.jl/issues/26 (gentle reminder about responding that issue at some point!). I also started playing around with this library a bit recently as I have some aspirations to teach it support for evaluating various special case closed forms of BCH which are necessary for rotating frame transformations in optical systems.

[Krastanov]

Hi, Akira! Long-term moving to Moshi does make a lot of sense. I am a bit worried about being early adopters though. I know that Roger and the Symbolics.jl folks are generally interested in this happening and I am very please to see that you are already working in that direction. If that PR of yours gets merged, I would indeed like to assign this bounty to you -- however let's first wait to see how https://github.com/JuliaSymbolics/SymbolicUtils.jl/pull/676 goes.

[Krastanov]

@akirakyle , are you still working on this one? I would like to open it up again if you are not engaged with it currently.

[akirakyle]

I am not currently working on this so feel free to open up the bug bounty

[hz-xiaxz]

I have some curiosity in digging into this, also to learn about ADT and pattern matching. I have background for quantum mechanics and high performance julia programming. Before progressing, I had a glance in the basic_ops_homogenous.jl, and with some help of GEMINI. Do we want something like this with Moshi.jl?

using Moshi

# Define the ADT for Symbolic Operators
@data SymbolicOperator{B<:Basis} <: Symbolic{AbstractOperator} begin
    
    @withmetadata struct Op
        name::Symbol
        basis::B
    end

    @withmetadata struct ScaledOp
        coeff::Union{Number, Symbolic{<:Number}}
        obj::SymbolicOperator{B}
    end

    @withmetadata struct AddOp
        terms::Tuple{Vararg{SymbolicOperator{B}}}
    end

    @withmetadata struct MulOp
        terms::Tuple{Vararg{SymbolicOperator{B}}}
    end

    @withmetadata struct TensorOp
        terms::Tuple{Vararg{SymbolicOperator}}
    end

    @withmetadata struct ZeroOp end
end

and finally replace the pattern matching in rules.jl?

[Krastanov]

Hi, @hz-xiaxz ! In broad strokes, the answers to your questions are yes. However, SymbolicUtils recently had a breaking release where much of the internal interface was reworked. Symbolics will have a related breaking release as well. We should first go through the steps necessary to support the latest version of SymbolicUtils and Symbolics, and only then start working on moving to Moshi. It would also be important for this work to be done in many small PRs instead of one large mega-PR as otherwise it would be very difficult to review.

If you would like to tackle all or parts of this, please do not hesitate to jump in. Help would be much appreciated.

[hz-xiaxz]

I see, I'll wait until https://github.com/JuliaSymbolics/Symbolics.jl/pull/1649 is merged, then see how I can help.

[Krastanov]

Thank you, that would be very much appreciated, and we should have bounty funds for related tasks.