aria

Yes this does dynamic nets, the model is the same as PyTorch, you build a graph for each input(s). I think Cortex is in the Keras-style of model (only layer abstractions and not "dynamic" in the sense we talk about neural nets) and isn't dynamic, but I could be missing something. The examples seem to all be in that mold: https://github.com/thinktopic/cortex/blob/master/examples/ca...

I'll try! I've got a full time management job so this was a fun way to code again. The library is pretty small and I think easy to follow if you want to learn

Definitely doing the standard back-prop algorithm. Check out the code, it's pretty straightforward and the whole lib is about 2,500 lines

Author here, happy to answer any questions!

Author here. This is coming up. Will do OpenCL first and then CUDA.

Author here, happy to answer questions and hopefully convince someone to give the library a try.

The interesting part of BFGS is that it directly approximates H^{-1} rather than H.

Want to try a refresh, I think it ought to be fixed now. Thanks

In practice you only need to do $H^{-1} g$; L-BFGS stores the {s_k} and {y_k} vectors which allow you to do the $H^{-1} g$ directly rather than needing to ever form the hessian or its inverse. There are techniques that aren't BFGS-based which approximate the hessian rather than the inverse and in that case you'd be better off solving.

Typo is fixed, thanks!

I think that's explicitly mentioned in the Quasi-Newton section that you only need to implicitly multiply and not form the matrix.

What browser are you in? It just using MathJax and appears to work in WebKit and Firefox.

Author here, happy to answer any questions.

Question 1: What is the first bit in your unique 33-bit string? Question 2: What is the first bit in your unique 33-bit string? ...

Author here. Happy to answer any questions!

Thanks! I definitely have personally run into the issue a lot and our Clojure teams at Prismatic struggled with commenting discipline. We find schemas are easier to maintain and apply, plus they save a lot of time during dev and testing.

Thanks! Yeah I think a traditional type system wouldn't make sense for Clojure, you need something that can describe data structures more succinctly, which is what we were shooting for

Definitely an inspiration. The core utility of Schema is that the declarations are still data and can be utilized in code. I think we'll have some interesting applications of this idea soon...

Thanks so much. We spent a long time thinking about how to have the benefits of types in a Clojure-y data-oriented way. The advantage of having Schemas as data is that we can use Clojure code to process them and generate things like Objective-C classes (https://github.com/Prismatic/schema/blob/d82bf0b049fc1205a81...) and Avro specifications. It will be our glue to declarations in other languages.

Author here. Happy to answer any questions or comments.

Author here. Happy to answer any questions!

I could be wrong, but I don't think Incanter has any Clojure-native means of generic operations over arrays at all.

Have any icon ideas? Was thinking ["hip","hip"] or hiphip[]

Indeed, the core logic of HipHip is the same for all primitive types and macros generate type-hinted versions for each primitive type.

Definitely not the same thing. Take a look at our earlier graph post. http://blog.getprismatic.com/blog/2013/2/1/graph-abstraction...

Graph would be possible, but not as clean in Python. Consider switching up drugs. Clojure is way more potent man.

We internally have a nice component/widget abstraction we use which is not quite MVC, but we think cleans up a lot of web development. We will release in the near future once we perfect it.

On mobile devices, we were hitting significant performance barriers from DOM and class manipulation. YMMV but it seems DOM performance is an issue on non-beefy boxes.

Other languages can totally have macros, but unless you have homoiconicity, which lisp languages do, macros aren't easy to use or support. In ClojureScript, macros are built into the language.

No. We're not trying to do something pure on top of the DOM. That isn't feasible for performant manipulation. Being functional is about more than just immutability.

We use standard manipulation.

ClojureScript generates a little more ephemeral garbage than native JavaScript and the Clojure data structures are slower, but in reality, the bottlenecks tend to be things which cross the DOM barrier and macros can make those bits much more efficiently. So it's not a free lunch, but it's very very cheap and tasty.