numericals | dense-numericals: write fast code fast
In case of any inaccuracies, ambiguities or suggestions, please create an issue here.
numericals
/ dense-numericals
brings you the performance of proto-NumPy with the debugging and development abilities of Common Lisp.
numericals
works withcl:array
making it trivial to interface with rest of the lisp ecosystemdense-numericals
works with dense-arrays:array provid a numpy-like array object for common lisp.dense-arrays
itself is fairly extensible, and trivial extensions are provided for static-vectors as well as cl-cuda*.
*Currently dense-numericals
only works with cl:vector
as the backend storage. Create an issue if you'd like dense-numericals to be extended to static-vectors
or cl-cuda
.
Where next?
- What we mean by writing fast code fast?
- Install numericals or dense-numericals
- Compare numericals against other libraries
- See the manual
- History of numericals
- Old documentation page
Limitations
numericals
/ dense-numericals
do not intend to offer a one-stop solution to the numerical computation ecosystem in common lisp. Even planning to do so is delusionary and should be considered a severe case of NIH syndrome. To that extent, we widely adopt:
This is further coupled with multithreading using lparallel and the C-library builtin OpenMP.
As further testament to the profoundly found elsewhere attitude adopted here, we have
numericals
working withcl:array
that can be used in conjunction with other libraries- two systems
numericals/magicl
anddense-numericals/magicl
that are essentially wrappers around magicl
Thus, we intend to provide facilities for writing fast code fast, but at the same time, we want to make use of the existing facilities wherever appropriate.
Note that optimizing code written using numericals and dense-numericals requires that the implementations support CLTL2, either natively, or through cl-environments. Currently, a bug in variable-information on CCL may prevent optimization. Type propagation requires that users write code using peltadot.
Acknowledgements
- Everyone who has contributed to SBCL.
- u/love5an and u/neil-lindquist for the required hand-holding and the gist.
- Paul Khuong for some blog posts.
- guicho271828 for SBCL Wiki as well as numcl.
- All the SLEEF contributors
- All the contributors of c2ffi and cl-autowrap
- u/moon-chilled's sassy comment (Is that the term?)
- It's possible that I could have forgotten to mention somebody - so... yeah... happy number crunching!