Rust bindings and sign of returned score

[Ragnar Groot Koerkamp]

We're writing a rust wrapper around WFA to do some testing.

It seems that there is an inconsistency in the sign of the returned cost:

• for unit and lcs, the returned value is positive: the 'cost' of the alignment.
• for other cases gap_linear and gap_affine and gap_affine_2p, the returned value is negative: the 'score' of the alignment.

You can see this is my code here and here respectively.

I was trying to find some docs on this difference, but the readme does not mention this difference currently. Is it intentional?

[Santiago Marco-Sola]

Hi,

My logic is that edit and LCS distances are always positive in the literature, and weighted distances have the sign of the resulting alignment/CIGAR evaluated under the penalties (for whatever values those have). If we run the WFA using M=0 (and other penalties > 0), this final score should be negative. If you run using bonifying matches, some alignments should get a positive score (try it!).

In any case, if I may, that rush wrapper sounds cool. I would be very happy and grateful to incorporate a rush wrapper into the WFA2-lib (in case you deem it adequate). I don't know if that aligns with your plans, but please give it a thought.

Thanks,

[Ragnar Groot Koerkamp]

Yeah, I see your point. Usually edit and lcs are 'distance' metrics (so positive is cost), whereas any scoring model that allows a bonus for matches is a 'scoring' metric, where positive is better.

I suppose it's fine as it is now, but a line in the readme might be nice.

---

I've been thinking about this rust wrapper. In fact, it's quite simple to make this:

1. clone the WFA2-lib repo and build the static library.
2. Add a [build.rs[(https://github.com/RagnarGrootKoerkamp/astar-pairwise-aligner/blob/master/build.rs#L18) script, telling rust to:
3. Link against libwfa (and libomp now it seems)
4. Use bindgen to automatically create bindings_wfa.rs, a rust equivalent of all objects defined in wavefront/wavefront_align.h.
5. This is then included into the actual project here.

Based on this, I'm not exactly sure what would be the best way to maintain an 'official' version of this.

Ideally, we make a standalone wfa-rust rust crate (package) that we upload to the official archive (https://crates.io), so that anybody who would like to use it can simply add wfa-rust as a dependency to their project.

However, I do not yet have experience with automatically building and linking against external libraries. In particular, users may need to install libwfa.a somewhere on their system themselves, which would be annoying in case of breaking changes in the API (where the library and generated wrapper may go out of sync).

I may spend some time on this later, but for now, just recreating the bindings manually seems simple enough (and other folks who want this hopefully find this issue and can reuse my build script).

[Santiago Marco-Sola]

I may spend some time on this later, but for now, just recreating the bindings manually seems simple enough (and other folks who want this hopefully find this issue and can reuse my build script).

Ok. Why don't you make a pull request to development or bindings with a folder under bindings/rust and the build.rs. We can add some notes and a simple example to guide the users.

How does it sound?