So, what does the actual rendering? Are you saying all of it is written in Clj with no C/Java/?? rendering engine???
@jsa-aerial: thing is super impressive itās pretty much built from the ground up with few dependencies. Visualisation and data science are very much intertwined and it would make a great native visualisation package. My main issue is that itās developed using tangle/org mode and I have no idea how to contribute to the project.
1 Like
No longer true. Author switched to a normal repo last year on the no org branch.
@jsa-aerial
Iāve been using it as a supplement to quil with some deferred rendering stuff, although thereās both a minimal webgl backend and a java opengl backend (and some projected rendering to 2d svg). Theyāre more of the camera, lights, triangles and shaders minimalism, with working examples using the thi.ng libraries to compute the inputs in a higher level fashion. Lots of control though.
3 Likes
Not a big fan of the DEVS formalism for my work. Evaluated simpy years back but dumped it in favor of custom solution (and some other external considerations). I remember seeing some ill advertised libs in scala and java (mostly from academia). I was pretty impressed with JaamSim (although itās oop and heavy on mutation) talking to folks at WinterSim years back; they were aiming at competing with proprietary software while remaining open source. āData Scienceā tends to generally ignore discrete event sim and optimization (bread and butter Ops Research fields) in my experience. They may remain niche/external, or poorly defined terms may end up encompassing both into āData Scienceā at some point.
I intend to wrap my incanter fork around kixi.stats in the near future (no idea if upstream would dig that). Great library (also portable cljc).
So how is it going to develop? Are we creating a subsection of forums so that we can discuss for each part?
I think the current master branch has moved away from org-mode(?). I have considered starting to use org-mode myself lately, but this is the reason why we opted against it. It is kind of the best literate programming environment though. Do you still have plans to evolve hydrox?
1 Like
Hey everybody!
Really nice to see all the shared interests here. I am maintaining Anglican and I am curious to hear peopleās needs and interests. I am also in general working with Clojure in backend and frontend settings besides my research and think it is a nice fit. The recent Anglican version for example runs also in ClojureScript.
Best,
Christian
5 Likes
thi.ng creates SVG or webgl itself.
2 Likes
As a user and sponsor of kixi.stats Iād be into that. I worry a bit about carrying on with incanter as it is just so big.
As a company we definitely do cohort component, DES and MCMC so weād like to see more stuff there. Not everything is a neural network. 
(I kid! I kid! pls donāt hit me actual data scientists!)
@joinr Do you think it is worth factoring out your DES stuff from spork into its own library?
1 Like
@Neo, re
There are several options to consider ā let us discuss this under that separate topic:
@whilo I think Iād like to understand when I should be using Anglican and when I should be using other Bayesian and probabilistic tools. With all of these I think there are trade offs around speed or fitting in with particular frameworks or expressiveness that we need to think about. Knowing where each of our options fits would be great.
hydrox has evolved (twice) though Iām using more of a repl based bulk namespace approach as opposed to a file-watch approach (I found it inconsistent and needed resetting once in a while). The current landscape for docs isnāt too bad with cljdocs.
Are there any crossovers between anglican and bayadera? itād be really helpful to have some sort of a comparison matrix between not just the pp libraries but also the ml ones as well. I understand āconjā and āassocā really well. Itād be great to have some of the more difficult concepts simplified, explained and compared.
I really like the API of kixi.stats, for what itās worth.
I also love Karstenās thing libraries and have long championed them to the clojure community, but would caution us to look carefully at the feature set of VEGA. geom is a great foundation that certainly could serve this purpose, but we should be clear on how much work is involved to bring it to feature parity with VEGA.
Ah, the implementation of kixi.stats (api and guts) is all @henrygarner so he should get the kudos.
I agree that VEGA based things would be a very good place to concentrate our efforts, especially given the grammar of graphics and grammar of interaction that theyāve thought about and appears very successful.
If we want to spend a lot of time having fun we could make that grammar also work with thi.ng (which Iām a fan of as well). I donāt think we should be betting on thi.ng directly at the moment.
3 Likes
We continue the discussion with some better granularity at Zulip, under the data-science stream.
For background on Zulip, see this discussion.
It is recommended to know a bit about Zulipās concepts of streams and topics.
See you there!
Do you think it is worth factoring out your DES stuff from spork into its own library?
For various values of āworthā 
spork is an intentionally accreted monolith, the bits of which are in various states of use (and active development). Itās definitely designed for modularity though, and Iāve looked at breaking out bits into separate libraries (but lack the external motivation) either manually or automatically. In practice, the DES stuff uses/exploits bits of the ecosystem, like an entity component system, behavior trees, and some minor stats libraries. In the mid-long run, Iād shift towards using something to extract the dependencies during publication. I also need to port some rudimentary examples (currently half baked). Iām more concerned with production than adoption at the moment though (although happy to answer questions).
Personally, Iām more interested in refactoring and applying fixes to Incanter since we continue to leverage it in internal processes. I got bogged down in refactoring the plotting implementation (all multimethods and macros, heavily tied to JFreeChart too, which involved munging through the JfreeChart docs). Iām looking hard at adding a vega backend with a compatible porcelain API from incanter.charts (rendering to browser/html, or javafx webview to eschew spinning up a server). Incanter is big, but itās also modular (via lein-modules), so itās manageable IMO.
1 Like
Iām an Emacs Org Mode user, I usually do some simple statistics on Org Mode āLiterate Programmingā. I have an suggestion, might create an GitHub README/Wiki page for Clojure Data Science, add link to library, and add detailed description about library. Maybe add some Clojure Data Science useful knowledge there. So people can find information easily. Put all info in one place would help newbie find what they want. WDYT? Looking information around is diffcult for me.
2 Likes
Thanks @stardiviner! Emacs Org Mode is beautiful.
That is a great idea, we are working on a website ā will share in a few days to get some feedback.
Hi!
We made this questionnaire to prepare for the Clojure data science online meeting.
Your response here will be extremely helpful!
Please note that no question is mandatory ā e.g., you do not have to say even your name.
Thanks!
Well, my compliments to the chef
1 Like