Please export public API for javascript interop about comportex HOT 8 CLOSED

Hi!

Heads-up: I'm hesitant to expose an API if it implies that the software is likely to be in any way stable or has any particular guarantees about its behaviour (hence v0.0.x). The whole thing is an experimental research piece. If you're doing this to experiment, that's fine, as long as you're aware of this context.

How many functions need to be exposed to js will depend on how deeply you want to play with things. If you want to run a basic HTM model and pull out predictions you could get away with just core/regions-in-series, whatever encoders you need, p/htm-step, and core/predictions.

If you want to do anomaly detection you would also want core/column-state-freqs and core/region-seq.

Happy to help with writing these wrappers. It will be a good excuse to finally spec the functions (with clojure.spec) which I definitely want to do anyway.

from comportex.

Hi Felix,

Sounds great! Let's do it! Yeah, I couldn't really find good usage docs. Don't fuss over it not being "production ready". By the time any Open Source project reaches that stage it is often "obsolete" :P Software is fluid, we devs like to play... I think this is a great project with potential and would like to integrate it with some of my JS projects, currently using Aurelia (similar to Angular) with TypeScript. I tried my luck with ClojureScript before but found the learning curve pretty steep (also lack of good docs).

I exported the entry points that seemed reasonable to js.cljc from core and encoders as you mentioned. I don't think I added those for anomaly detection however. The trick is only in converting incoming js data to clj and back. Don't have any experience with that however...

Here is a good run down on how to do it: http://www.spacjer.com/blog/2014/09/12/clojurescript-javascript-interop/

If you could just describe the expected parameters and return values (Types) then we could do it for sure!

Like what is a spec or a htm Typewise? I'd assume the types are defined in protocols, such as:

PHTM - htm param
PRegion - region
...

So essentially the JS calls with an object and we then have to convert these to the records implementing the protocols, right?

from comportex.

An htm object is pretty complex -- you can see a dump of one at https://github.com/htm-community/comportex/wiki/A-sample-workflow-with-the-REPL -- probably best to treat it as a black box from the js side.

from comportex.

I'm continuing your work on a js API here:
floybix/comportex@bdee3ce

Still need functions to retrieve the active and predicted cells.

from comportex.

btw It's not quite as simple as wholesale converting everything with js->clj / clj->js because comportex objects like RegionNetwork, Region, Layer, SynapseGraph etc are tagged record types and that information would be lost in a (naive) conversion. Also it would be slow to run a deep conversion on everything when that is not needed. That's why I'm leaving some values returned by the js API as "black-box" clojure objects.

from comportex.

Good job :) Looking at it now.

Please add instructions on how to run the JS demo in public/comportexjs.html?
Also add descriptions/instructions for each demo in general (if not there?)

  ;; project.clj

  :clean-targets ["public/comportex.js" "public/out"]

  :cljsbuild {:builds
              {:main
               {:source-paths ["src"]
                :jar true
                :compiler {:output-dir "public/out"
                           :output-to "public/comportex.js"}}}}

lein cljsbuild once

Then load up the public/comportexjs.html file in your browser :)

Also please update the changelog. I'd also suggest merging with master at some point as I think this JS API opens up the project to way more interested developers out there...

from comportex.

I made a commit with the things I found missing here:
comportex js-api

from comportex.

Thanks, that's useful. I incorporated those changes and merged into master.

from comportex.