Glen Whitney
1c1ba91e48
The interface is a bit clunky, the "author" and the callback "data" have to be specified when adding (an) implementation(s) in order for this to work. But it does, and this is just a PoC, the interface could be cleaned up. |
||
|---|---|---|
| complex | ||
| generic | ||
| number | ||
| test | ||
| .gitignore | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| picomath.js | ||
| picomathInstance.js | ||
| poortf.js | ||
| README.md | ||
Proof of concept for a JavaScript Computer Algebra System
An instance of the system will be an object whose property names are the operator names and whose property values are constant mutable function objects that can have new behaviors added to them.
Calling the system on a property name and 0 or more implementations creates that operator if it doesn't exist and adds the implementations to it, and returns the function object for that name. Thus, it is easy for modules to obtain handles to operations they depend on, and to create/extend an operation (typically just one per file at the moment).
Multiple different instances can coexist and have different collections of operations. Moreover, only the source files for the operations actually desired are ever visited in the import tree, so minimizing a bundle for a specific subset of operations should be quite straightforward.
Hopefully the test cases, especially test/_picomath.js and test/custom.js, will show this off in action.
Note that 'subtract' is implemented as a 'generic' operation, that depends only on the 'add' and 'negate' operations (and so doesn't care what types it is operating on).
This core could be extended with many more operations, and more types could be defined, and additional sub-bundles like number/all.js or clever conditonal loaders like complex/extendByComplex could be defined.
Hopefully this shows promise.