Algorithm Development is Broken

The "{area/field/business} is broken" template is broken (well, I don't know if ever worked). Algorithm development is not broken - it's specialized work and it's largely done by people with specialized backgrounds. Maybe that's not ideal, and maybe you can improve it, but saying "it's broken" is lazy and false.

What's the monetization strategy here? It would be a major step backwards for the industry if it turns out the plan here is to try to make money off of what is currently a public resource. I'd hate to see researchers having to decide if they want to publish their results or just make some cash by creating a closed source API with your service. You guys should make it clear if source code will always be available or if this is basically going to be a land-rush for people to provide an API for all the standard CS algorithms with you monetizing access to them.

I first thought this is a Wiki for Algorithms with sample code in different languages.<p>Well, this site is apparently a marketplace for algorithms.<p>If anyone is more interested in open Wikis, I found what two sites using Google:<p>* RosettaCode.org (code in many languages): <a href="http://rosettacode.org/wiki/Sorting_algorithms/Merge_sort" rel="nofollow">http:&#x2F;&#x2F;rosettacode.org&#x2F;wiki&#x2F;Sorting_algorithms&#x2F;Merge_sort</a><p>* Algorithmist.com: <a href="http://www.algorithmist.com/index.php/Main_Page" rel="nofollow">http:&#x2F;&#x2F;www.algorithmist.com&#x2F;index.php&#x2F;Main_Page</a>

Hm, sounds interesting but vague. I don&#x27;t really understand how it will work.<p>How is data for the algorithms provided? A lot of times it is big. And messy, and proprietary. There seems to be an implicit assumption that you can just plug different algorithms to different data sets. But I can&#x27;t think of a project where that has been the case.<p>I also doubt that &quot;algorithms&quot; are the bottleneck in a lot of projects. I&#x27;m not an expert, but I have some personal experience to back up what people say about &quot;data trumping algorithms&quot; (e.g. Peter Norvig and others have written about this)<p>I would like to hear about some more concrete examples &#x2F; success stories. &quot;Algorithms&quot; is just too vague. I think if this becomes successful, it will be by first narrowing it to a particular domain, and then generalizing it again.

I can&#x27;t figure out how such a system is supposed to work. Anyone have any ideas?<p>For example, a couple of years ago I worked on an algorithm to find the maximum common subgraph of a set of 2 or more molecular graphs. More specifically, I wanted the largest subgraph in M of N graphs (M&lt;=N), I wanted to define the atom match criteria, and I wanted to require that rings not be broken in the subgraph. (Chemists love rings.)<p>I did it the old-fashioned way. I read papers, I investigated similar systems, I implemented various implementation details, and I did a lot of testing.<p>How would I find such an algorithm using this system?<p>There are only a few people who develop this sort of algorithm. Why might I expect that this system is a better resource than traditional means?

Funny he mentions LDA. A company I founded and sold (Algo Anywhere, which started off as a Generalized Algorithms as a Service company) was a recommendation engine as a service business built on top of LDA. The papers out there are dense, but LDA is actually pretty easy to get information on. Check out Gensim in pythonland.<p>The thing with algorithms is that you really have to think. 200 lines of code might take two months to really grok. Especially because the people in the field make certain assumptions when they start, and sometimes even just one of those assumptions takes two weeks to understand and research.<p>You can&#x27;t just jump into PhD level research and expect to understand it right away.<p>I don&#x27;t know if algorithmia will help solve this problem, but I wish them all the best of luck. Getting actual code next to research is super important and useful.

Yes algorithm development <i>is</i> broken, but not quite in the way that the OP suggests.<p>People tend to focus on initial algorithm development, because that is the academically prestigious intellectually stimulating bit, but the job is really about how to turn algorithms into cash; a much broader problem than the narrow slice that people typically obsess over.<p>A huge (and frequently overlooked) part of that job is the communication and coordination role between business development and algorithm development. The volume of communication and level of detail required cannot be overstated.<p>Another huge part of the job is actually turning a piece of research into a functioning product. Whilst a large part of the OP&#x27;s proposition is intended to address this problem, (kudos) I think that his solution falls short in a big way: It omits the largest part of the solution, which is where the business learns about the algorithm and how the behaviour and performance characteristics of the algorithm interact with the business&#x27; problem domain. I.e. how does the business build sufficient expertise and knowledge of their product to be able to effectively sell it. All of these are human problems, mainly oriented around communications and learning.<p>Having said all that, I would like to encourage the OP in his efforts. I think that it is something that is worth doing, and I really hope he is able to build a business around this idea. I think that technology can help support all of these activities, and this is actually something that I have wanted to do myself for very a long time, so Kudos to the OP for actually taking the chance, going out and doing it!

This was (partly) solved in mathematical software with TOMS and Netlib:<p><a href="http://toms.acm.org/" rel="nofollow">http:&#x2F;&#x2F;toms.acm.org&#x2F;</a><p><a href="http://www.netlib.org/" rel="nofollow">http:&#x2F;&#x2F;www.netlib.org&#x2F;</a><p>However, if you want to do something non-trivial and you want it done right, hire a computer scientist or mathematician. No amount of crowd will help if no one in the crowd has a clue what they&#x27;re doing.

1) Will there be limits on the size of data sets&#x2F; what size data are you optimizing for? Some algos focus on hundreds of records, some on billions, and the ideal system for either are quite different (small data works great by transferring data back and forth over http, data with hundreds of thousands of records and up... not so much).<p>2) Same question as above, but for processing times. Some algos are aimed at operating on the fly and might take ~1 second or less. Others (many that I deal with quite often), might run for days, or even weeks. What sort of processes are you optimizing for, and are long running procs on the radar?<p>It is an interesting idea, but there is a high bar when competing against my language&#x27;s package manager, and the 10s of thousands of &quot;algorithms&quot; already out there. Best of luck!

The API is interesting but what I really want is to understand the algorithms. Clean, clear reference code in multiple languages with good explanations would be hugely helpful. Is that part of the plan?

Reminds me of the xkcd:<p>1. There are 14 libraries for technical algorithms. 2. We need a meta-library so that we don&#x27;t need to worry about having so many libraries! 3. There are 15 libraries for technical algorithms.

How is the DeepMind purchase in any way a &quot;record sum&quot;? The linked article does not seem to make this claim. I didn&#x27;t even get to your main point and already I don&#x27;t trust you.

Contradiction at it&#x27;s finest: <a href="http://i.imgur.com/BwE2jmj.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;BwE2jmj.png</a> Good idea, but remove the god damn login wall.

I think it is a little disingenuous to say that algorithms get buried in academic literature and are <i>impossible</i> to find. By the nature of research most of these things are made public when published, often times there is no implementation or just a research quality one (which I can guarantee you is almost never useful for the &quot;real world&quot;).<p>For example one day I was interested in implementing HyperLogLog(a set cardinality measure that is useful in data analysis). In about 10m I had all the relevant papers on hand and after skimming them I had a pretty good sense of how to implement it.<p>Similarly if I want to know how to implement a program dependency graph for doing program analysis I can go read a few pages of a paper and get a good description on the algorithm I would need to construct such a thing. I can believe the argument that some of these things are poorly indexed but even a bare minimum of Google searching usually results in useful algorithms. I would argue that often times many of these research algorithms have a bunch of different design decisions that are best explored in the academic literature around them, and an implementation and a few notes is not sufficient exploration.<p>For example I was recently implementing Paxos and there were <i>tons</i> of little details to be extracted from the papers around that had a big impact on the actual implementation we ended up with. The &#x27;Paxos Made Live&#x27; paper from Google had many details that were only relevant&#x2F;true because of engineering decisions made by the team. If one was presented you with an implementation derived solely from that paper there are multiple incorrect assumptions you could derive.<p>An instance of this is made apparent in Paxos Made Live. Google essentially fixes their proposer because the have used Google specific details about the number of participants and their availability. The result is that they direct <i>all</i> traffic to a single node, and don&#x27;t spend a much time talking about leader&#x2F;proposer selection (which could be useful to <i>your</i> needs).<p>I also don&#x27;t buy that an important part is getting the algorithms running as a service. Most so called &quot;algorithms&quot; are nothing more than a subroutine that is need as a piece of a greater whole. I would venture most useful &quot;algorithms&quot; are most likely container data structures and algorithms that operate over them. It seems that these are probably most useful to have as a library. Many libraries have already taken this approach LLVM (algorithms for code generation, albeit not always everything you want), OpenCV for computer vision routines, BLAS for linear algebra, NLOpt for non-linear optimization, and I&#x27;m sure one could come up with many more examples of democratized algorithms.

Two unsolicited suggestions, if I may:<p>1. Make open source releasing of algorithms compulsory, not optional.<p>Think of it from your prospective clients&#x27; perspective: the upside of digging out an algorithm from academic journals and implementing it yourself is that you get to fully understand the source code (since you end up writing it yourself); you can attest its correctness; and you get to stand on the shoulders of giants by tweaking and extending it later, if you wish.<p>Admittedly this might not be seen as that much a benefit for business users, but for many actual users of advanced algorithms in the scientific computing community, having to use proprietary algorithms with restrictions on their use has been seen as a significant step backwards, as manifest during the controversy brewed over the &quot;Numerical Recipes&quot; controversy [1,2,3]. Even if the benefits are more a matter of principle than mere practicality, the palpable distaste for proprietary algorithms in the scientific computing community is something you should at least keep in mind, lest you risk alienating a core user base for your product.<p>2. Formally verify the correctness of every algorithm submitted.<p>This is as crucial as large-scale deployment for many scientific computing users, and it is one of the banes of (and reasons why) implementing the algorithm yourself. Here your product then could really offer a compelling proposition to these users.<p>This would also be beneficial for ensuring the reliability of your API, even if you formally waive liability to the algorithm developers (as you surely do). Else you might find yourself on the other side of securities regulators for a multi-million dollar trading glitch caused by one of your algorithms [4], or something crazy like that.<p>[1] In fact, in the wikipedia article for Numerical Recipes, it is claimed that one of the motivations for the development of the GNU C library was precisely to come up with a free alternative to them! See: <a href="http://en.wikipedia.org/wiki/Numerical_Recipes" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Numerical_Recipes</a><p>[2] <a href="http://aufbix.org/~bolek/download/nr.pdf" rel="nofollow">http:&#x2F;&#x2F;aufbix.org&#x2F;~bolek&#x2F;download&#x2F;nr.pdf</a><p>[3] <a href="http://www.astro.umd.edu/~bjw/software/boycottnr.html" rel="nofollow">http:&#x2F;&#x2F;www.astro.umd.edu&#x2F;~bjw&#x2F;software&#x2F;boycottnr.html</a><p>[4] <a href="http://www.bloomberg.com/news/2013-10-16/knight-capital-agrees-to-pay-12-million-fine-for-2012-errors.html" rel="nofollow">http:&#x2F;&#x2F;www.bloomberg.com&#x2F;news&#x2F;2013-10-16&#x2F;knight-capital-agre...</a>

nice article! looks like a very promising platform.<p>cheers