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
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.
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.
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.
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.