platypii

Franz Reichelt clearly failed in his approach, but his idea was not crazy -- today we have wingsuits that can fly.

CTO of Algorithmia here. We've spent a lot of time thinking about the issues of deploying deep learning models. There are a whole set of challenges that crop up when trying to scale these kinds of deployments (not least of which is trying to manage GPU memory).

It would be interesting to compare notes since we have deployed a number of models in production, and seem to focus on a related but different set of challenges. kenny at company dot com.

There's a clear trend in the industry to increasingly rely on cloud services, so it seems reasonable that machine learning would follow the same trend. As long as the compute is in the same data center, data transfer is rarely the bottleneck for these kinds of deep learning algorithms, which is why we designed algorithmia to be able to operate anywhere -- on all the major cloud providers, as well as on premise.

Algorithmia founder here. nvidia-docker is helpful but does not address all the issues with running GPU computing inside of docker. There are driver issues on the host OS, and the real challenge is running multiple GPU jobs inside of separate docker containers and sharing the GPU.

I agree that building models is still definitely a big challenge, but the tooling and knowledge is getting better every day. Either way, our goal with Algorithmia is to create a channel for people to make their models available, and create incentive for people to put in the effort to train really solid, useful models.

Bringing a parachute on a airplane is fine. The problem is there is no good way to exit a modern airliner.

The terms here are necessary to provide the services that we offer via Algorithmia. We need the right to run your code and make it available. It needs to be in perpetuity so that consumers of the API can put it in production with the assurance that it will continue to be available in the future.

That being said, the quoted passage lacks the context of the rest of our terms -- namely, yes, we get the right to make your work available, but in return it's OUR obligation to share the profits with the original authors.

(Kenny @ Algorithmia)

Agreed, but sorting is kind of the "hello world" of algorithms.

It's only WTF if the bounty demands Polynomial time :-)

Weka is definitely more old-school, but it has a LOT of algorithms available. Weka and Mahout are the two biggest ML libraries on the JVM, but we couldn't find any direct head-to-head comparison so this was the result. In the future we plan to also add scikit and mllib and more in the future.

Your point about being difficult to use is exactly the problem that Algorithmia solves.

Fear of AI is widespread: http://www.thinkartificial.org/web/the-fear-of-intelligent-m...

Direct link to HN with tags: http://algorithmia.com/demo/hn

Totally nerd sniped on this one. Will never get those hours back :-)

Meta question: Would it be possible to get 4096?

The best part: the "Privacy" section of the document is blank.

http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...

The data question is something we are taking very seriously. I talked a bit more about this in another comment, but we know that in many cases data is heavy and is often the limiting factor. We are building a robust data platform ontop of Hadoop + Spark, so be able to handle large amounts of data, and so that we can deploy code to where the data is.

That said, I think there are many algorithms that will work as standalone algorithms. Lots of machine learning type algorithms are mostly CPU-bound. There are companies like http://www.kooaba.com that do image recognition as a service over HTTP. Also things like Siri and Google Now seem to work well enough, despite network latency. Thanks for the feedback!

In this post we were trying to focus on the problems we've personally experienced as algorithm developers. The plan is to explain the details of Algorithmia more in future posts, but here's the basic idea:

We want smarter machines, and that means making algorithms more widely available. To achieve that, we're creating a community around algorithm development, where people can contribute code and collaborate with others on that code. Github has done a great job of this, but it is not always trivial to get from a github repo to live code in production. We think that creating a built-in market for algorithms-as-a-service could be a way to reward algorithm developers for their work, and make algorithms easily accessible via REST API.

The types of algorithms we are talking about is not limited by us. My opinion is that the most useful algorithms in the near future will be related to: machine learning, classification, analysis, and optimization. There are also numerous applications for things like image recognition, speech-to-text, and translation, to name a few.

Only if the court can prove whether a program halts or not.

Because that's what is necessary to actually use algorithms in practice if the demand is non-trivial.

The irony is not lost on us :-) We are a small team actively building this site. We will be completely open as soon as possible.

Sorry for being vague, that wasn't our intention, so much as to focus on laying out the problem that we've experienced personally as algorithm developers. We will be posting more blog posts with much more detail about the system in the near future.

The data question is huge for us. We have built our system on top of Hadoop + Spark in order to handle large amounts of data, and be able to apply computations to it. You're absolutely right that data is very heavy, and often the limiting factor, so we are doing everything we can to both get data into the system (currently with a focus on streaming data, since that gets around the heavy data problem), and getting algorithms to where the data is.

As far as specific algorithms, there are many that could apply. My personal experience is in machine learning algorithms, so I'm personally biased toward those. There are numerous algorithms like Classification, Clustering, Optimization, Anomaly Detection, etc. which are very CPU-intensive. We will be doing a blog post soon with a demo of live algorithms already in our system to give more concrete examples.

I agree that the existing libraries are great, and if anything that success is what we to encourage even more of. We want to build a community around algorithm development, and have a central place for developers to share their work, and collaborate with other developers to make Huge library of algorithms so that everyone can benefit.

The first language we implemented was Java/Scala, largely because of the excellent libraries like Mahout and Weka easily available in Maven Central. But even though the code is there in maven, it is still not trivial to deploy those algorithms as a service. We are trying to make that easier, while at the same time supporting the developers of those libraries in the process.

Being able to run the code locally is in the plans. For the most part, the algorithms in our system are already simply maven packages, or ruby gems, npm packages, etc. Being able to distribute them in binary form is definitely possible. We're still figuring things out right now, but our focus is always on doing right by the algorithm development community.

We are algorithm developers ourselves and our goal is just to make these awesome algorithms that are being developed more widely available.

We are not trying to monopolize basic algorithms. In fact in a free market I don't see how that could happen, since anyone else could come along and implement the same basic CS algorithms and offer a lower price.

The thing that makes us different from say Wikipedia or Github is that we don't provide just source code, but live infrastructure delivering the algorithms as a service. So rather than uploading code to github, and putting the burden on a user cloning the algorithm, setting up virtual servers, deployment systems, load balancers, etc. We handle all that. That way algorithm developers are free to focus on algorithm code, and the infrastructure is taken care of. This infrastructure needs to be paid for however, so our general plan is to charge for using algorithms through the API. It will be up to the developers whether to share source code or not, since they own the IP.

Algorithmia will be like a wiki of algorithms. Or a github. The difference is that the code will also be available live as a service so that other developers can easily make use of them.

We strongly believe in open source, and the source code will generally be available (although we may leave that up to the individual algorithm developers to decide). We are algorithm developers ourselves and our goal is to see more intelligent algorithms used as widely as possible.

Based on my experiences in grad school, I'm not sure it is an exaggeration to say that it's "broken". So much work done solving hard problems, that ends up in academic journals and never seen again. And there's no real incentive for that to change. I think that's broken.

Yes definitely. The code is available for people to learn from, and you will be able to edit the code and see the results immediately. The goal is to all about making algorithms more accessible.

Thanks! Will be coming out with more details about the platform soon. Always interested to hear feedback though.

Doesn't work without the parent having a defined height.

Sorted list + binary search was 2000pts and ran much faster than the hashmap solution.

I like gandi.net. Very clean UI, their motto is "no bullshit" and they live up to it in my experience.

This seems like a cool idea. What I like about it is the way that it assigns a quantifiable value to mathematical proofs, and incentives their production.

Assuming proofs are valuable (which I believe they are), then by creating a market we can learn an approximation of what they are really worth to people.

Also I like that it is another outlet for mathematicians to profit from their skills. The options for pure math as a career are fairly bleek right now (fuck the nsa, academia maybe, not many research jobs in industry). I could see this market as a way to incentive more pure math research.

I have always assumed it was to reduce the likelihood of conflicts with future alarms. For example if I set alarms at 8:00 and 9:00, if I've been snoozing the 8:00 alarm, and snooze is 10 minutes, the two alarms will both fire at 9:00. With 8 or 9 minute intervals that is much less likely, and so its easier to see that maybe they are two different reminders. This probably applies more to phones than old school alarm clocks however.