dense-numericals
Numerical Computing library with https://github.com/digikar99/dense-arrays as the front-end (by digikar99)
dense-arrays
Numpy like array object for common lisp (by digikar99)
dense-numericals | dense-arrays | |
---|---|---|
2 | 7 | |
0 | 23 | |
- | - | |
0.0 | 5.6 | |
almost 3 years ago | about 1 month ago | |
Common Lisp | Common Lisp | |
- | - |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dense-numericals
Posts with mentions or reviews of dense-numericals.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-05-21.
-
polymorphic-functions - Possibly AOT dispatch on argument types with support for optional and keyword argument dispatch
An example where this has been put to use is at dense-numericals - so, we have the one-arg-fn as the basic polymorph that actually does the dispatching. But since the remaining polymorphs (sin, cos, tan, etc; the ones in the macrolet) are what I'll call parametric, by simply defining these for type t, these are defined for anything that the one-arg-fn is defined for, thus enabling both optimal compilation without dispatch overheads, as well as no compiled code repetition; without this, one would have required about 7 polymorphs for each of the 14 or so functions in this file.
dense-arrays
Posts with mentions or reviews of dense-arrays.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-09-20.
- dense-arrays: Numpy like array object for common lisp
-
Image classification in CL? Help with starting point
*I have not; I have a couple of WIP/alpha-stage libraries like dense-arrays and numericals that could be useful; once I find the time, I want to think about if these or its dependencies can be integrated into the existing libraries including antik mentioned by awesome-cl.
-
Machine Learning in Lisp
Personally, I've been relying on the stream-based method using py4cl/2, mostly because I did not - and perhaps do not - have the knowledge and time to dig into the CFFI based method. The limitation is that this would get you less than 10000 python interactions per second. That is sufficient if you will be running a long running python task - and I have successfully run trivial ML programs using it, but any intensive array processing gets in the way. For this later task, there are a few emerging libraries like numcl and array-operations without SIMD (yet), and numericals using SIMD. For reasons mentioned on the readme, I recently cooked up dense-arrays. This has interchangeable backends and can also use cl-cuda. But barring that, the developer overhead of actually setting up native-CFFI ecosystem is still too high, and I'm back to py4cl/2 for tasks beyond array processing.
-
polymorphic-functions - Possibly AOT dispatch on argument types with support for optional and keyword argument dispatch
Currently I have put successfully this to use at dense-numericals - which I created over dense-arrays after finding CL arrays to be not that suitable, as compared to numpy or julia. Now, dense-numericals relies on passing the array pointer to C functions. However, IIUC, this runs into issues for what if the GC moves the arrays while the computation is still not done; is this worry valid? I think I ran into this while running multithreaded tests on CCL, ending up in segfaults.
-
Confused about array runtime type checking in SBCL
Shameless unstable plug: I think it should be possible to provide type checking with a different backend that does not upgrade the types at https://github.com/digikar99/dense-arrays - the backend things are themselves unstable though.
-
Past, Present, and Future of Lisp
In semi-production, ideally the problems are best represented using state diagrams, but I don't see a way to comfortably represent graphs in textual formats. The best I see is list of lists, which doesn't feel significantly better than the spaghetti code it currently is (for instance this and this - but these are just about one function each in a larger system, so not totally worth a DSL, unless there existed a defacto state-diagram DSL which everyone could be expected to know.
What are some alternatives?
When comparing dense-numericals and dense-arrays you can also consider the following projects:
numericals - CFFI enabled SIMD powered simple-math numerical operations on arrays for Common Lisp [still experimental]
array-operations - Common Lisp library that facilitates working with Common Lisp arrays.
cl-parametric-types - (BETA) C++-style templates for Common Lisp
py4cl - Call python from Common Lisp
cffi - The Common Foreign Function Interface
py4cl2 - Call python from Common Lisp
specialization-store - A different type of generic function for common lisp.
awesome-cl - A curated list of awesome Common Lisp frameworks, libraries and other shiny stuff.
hy - A dialect of Lisp that's embedded in Python
dense-numericals vs numericals
dense-arrays vs array-operations
dense-numericals vs cl-parametric-types
dense-arrays vs py4cl
dense-numericals vs cffi
dense-arrays vs numericals
dense-arrays vs py4cl2
dense-arrays vs cl-parametric-types
dense-arrays vs specialization-store
dense-arrays vs awesome-cl
dense-arrays vs hy
dense-arrays vs cffi