[xaa]

My colleague (an editor at Bioinformatics journal) and I were joking the other day about how every other paper title, especially about aligners, seems to include the word "fast" in it. This takes it to a new level.

As a learning exercise, this is interesting and fine. I am trying very hard to suppress the inner "reviewer" right now. Walking away...not comparing this to existing algorithms which are implemented in highly optimized C/C++, or CUDA, or even hardware. About why other authors would go to such extraordinary lengths if high-level languages are suitable. Not going to ask how conclusions can be drawn about the suitability of Javascript for very computationally-intensive tasks without solving the actual alignment problem rather than a subset, let alone comparing to existing tools. Not going to ask about the application of the tool. It's not a paper. I'm breathing. OK.

[keithwhor]

This was certainly not intended as an academic submission, merely a description of a method used. You can breathe. :)

The initial point of the tool / algorithm was to find all potential binding sites for a DNA-binding domain of a protein in 100kbp - 1Mbp genome. (Even those with sequence identity ~50% or less.) This is provided you have a consensus sequence that contains ambiguous nucleotides. (For example, roughly discerned from a sequence logo.) It quickly turned into development of a general bioinformatics library in JavaScript, and a chance to see how far and fast I could push V8 at doing these sequence comparisons.

I would love (at some point) to go into significantly more detail and compare what I've written here with existing tools. If you're willing to offer mentorship or guidance (or know somebody who would be), it would be fantastic to present the information in a more thoroughly peer-reviewed context. Otherwise, the post (and associated library) are meant primarily as learning tools for both biologists and developers.

[xaa]

Alas, alignment is not in my area of expertise, nor of the people I know directly. I'm a heavy user, but not a developer of aligners (except a toy one). You could consider contacting Cole Trapnell or someone well known for making a widely used aligner and propose a collaboration, but that is a hard cold call. On the plus side, it means I probably wouldn't be your reviewer :) (but editors do sometimes get desperate...)

Your initial problem, if you frame it as the desire to simply enumerate all the degenerate sequences and loci, could be solved any number of ways as other commenters have mentioned. Probably I would reach first for a regex. But sure, no crime in learning to implement a new algorithm while also testing the limits of V8. Probably half of my grad school time was spent that way ;)

I think your best bet if you wanted to publish would be to find a use case for in-browser alignment. It would be hard to answer the obvious question, "why not server-side?" though. But who knows, people are somewhat often taking old bioinformatics algorithms and saying "but now you can do it on your phone!!". And they do publish.

But as for matching both speed and accuracy of state-of-the-art aligners with Javascript, it is my considered, scholarly opinion that you have no chance in hell. So you shouldn't present it that way. It would be unnecessary to compare (at least for speed) if you weren't making claims about speed.

[dalke]

Well, yes. "fast" can mean "not as slow as doing it by hand in the most naive way possible".

"Faster", now that's a more interesting title if only because it was compared to something else. (Then again, I reviewed one paper which said the algorithm was faster and more memory efficient than the previous version of itself. But with no numbers.)

"Fastest" is of course much harder to pull off. :)

[xaa]

> I reviewed one paper which said the algorithm was faster and more memory efficient than the previous version of itself. But with no numbers.

The aforementioned colleague says he usually editorially rejects those.

Actually another amusing thing about this title is that actually this is not the first time that "ultra-fast" has been used to describe an aligner in a title. The STAR aligner did too.

No sane reviewer or editor would allow "fastest" unless in the context of "provably fastest" which is probably not within the skillset of most bioinformaticians. If it is just "fastest among the currently available tools" then that claim will be out of date within a year.

[dalke]

The one "fastest" I know of is "Fastest Fourier Transform of the West". The abstract for the 1997 paper starts:

> This paper describes FFTW, a portable C package for computing the one- and multidimensional complex discrete Fourier transform (DFT). FFTW is typically faster than all other publicly available DFT software, including the well-known FFTPACK and the code from Numerical Recipes. More interestingly, FFTW is competitive with or better than proprietary, highly-tuned codes such as Sun’s Performance Library and IBM’s ESSL library.

If a "fastest" paper comes in with a good, robust benchmark and tests against the top performing and the most accepted implementations, then it would be worthwhile. And rare as hen's teeth.

[collyw]

Bioinformaticians love to reinvent the wheel.

[xaa]

Yes, yes they do. I think it is because of the following sequence of events: a) bioinformaticians are usually shitty programmers, therefore b) a lot of the tools are bad, at least from a programming perspective, therefore (?) c) I'll write a new one that will be "better".