-
Notifications
You must be signed in to change notification settings - Fork 2
Home
‘What are you wanting to achieve with this funding?’
Currently, there is a great existing library for wolfram<>clojure interop but it’s relative lack of documentation and usability mean that it is, to the best of our knowledge, not widely known or utilized. We hope to address these issues and so bring the ease of wolfram interop towards similar bridges like clojisr and libpython-clj.
Specifically, fundamental goals would be to
- merge recent work
- create comprehensive inline documentation
- create, big-picture, example namespaces: including onboarding tutorial and real-world examples (publically available in visible places like the sci-cloj website)
- ensure easy kernel parallelism (i.e. validate and clearly document the package’s original claim: “…lets multiple Clojure threads execute Mathematica expressions without blocking others.”)
- document how to use external wolfram packages as normal clojure namespaces
- streamline setup so that wolfram symbols are loaded much faster, such that wolfram functions can be used almost as easily as library functions
- start building the foundations for closely integrating wolfram with the emmy symbolic clojure system (https://github.com/mentat-collective/emmy)
‘Why is this project important to the Clojure community?’
Of the areas that the Clojure survey highlighted, this project would address the specific categories of data analysis, documentation and user growth.
Data analysis/processing, as also expressed by the Clojure leadership team, is a key growth area for the language but library coverage can be fragmented, with missing depth of functionality. Having access to specialised algorithms/functions however, can make or break analysis projects and so reestablishing a stable bridge between clojure and a first-in-class analysis language like Wolfram would go a long way in reassuring language choosers that Clojure can always meet their needs, even when there is no pure clojure library available.
Another key community area is the expansion of the community itself. Following on from above, there is a large section of the numerical scientific community who are not programmers but who rely on tools like Mathematica and Matlab and so interop in these areas will be crucial for community cross-over in the future. Generalized language interop is particurly important for safe onboarding of new users and experience suggests that there is a willing ‘market’ for integrating specialist tools within more comfortable general languages like Clojure.
Finally, this project would not only have its own benefits but it could lay the groundwork for future integration with the ‘emmy’ symbolic physics library. The emmy system is bringing open-source symbolic computation to both the back- and front-ends but it is missing key features and advanced libraries. A wolfram bridge could serve as a sure foundation and help create the real possibility of an almost unique physics programming space that clojure would be a great fit for but is not quite ready for.
- Is there a better way of dealing with 2D data than using dtype-next? i.e. is the neanderthal library API intelligible?
(get the spinner otherwise)
- Not easy to find!
- doesn’t do negative numbers
currently looking at plaintextusage in core.clj (look at this)
why do symbols passed have to be alphanumeric? should we provide a conversion function?
https://github.com/JerryI/wolfram-js-frontend
allow for exclusions
- Can I eval plain mathematica syntax via strings? yes
- how to strip namespace from symbols?
- we need this explicitly
- when to use convert and when to use eval?
- what’s the deal with ‘eval’ and ‘evaluator’?
- deal with ‘rules’. can we have a LHS and RHS operator?
- can we use Mathematica functions in thread macros?