Inspired by https://github.com/josdejong/mathjs/discussions/2212 and
https://github.com/josdejong/mathjs/issues/2585.
Provides a simple adapter function `adapted` which takes a class
implementing an arithmetical datatype and returns a PocomathInstance
with a new type for that class, invoking the methods of the class
in a standard way for the Pocomath/mathjs operations. (That instance
can then be installed in another to add the new type to any instance
you like, including the default one.)
Uses this facility to bring fraction.js Fraction into Pocomath, and
tests the resulting type.
Currently the "standard" interface for an arithmetical type is heavily modeled
after the design of fraction.js, but with experience with other 3rd-party types
it could be streamlined to something pretty generic (and the Fraction
adaptation could be patched to conform to the resulting "standard"). Or a
proposal along the lines of https://github.com/josdejong/mathjs/discussions/2212
could be adopted, and a shim could be added to fraction.js to conform to
**that** standard.
Resolves#30.
This means that the real and imaginary parts of a Complex must now be
the same type. This seems like a real benefit: a Complex with a number real
part and a bigint imaginary part does not seem sensible.
Note that this is now straining typed-function in (at least) the following
ways:
(1) In this change, it was necessary to remove the logic that the square root
of a negative number calls complex square root, which then calls back
to the number square root in its algorithm. (This was creating a circular
reference in the typed-function which the old implementation of Complex
was somehow sidestepping.)
(2) typed-function could not follow conversions that would be allowed by
uninstantiated templates (e.g. number => Complex<number> if the latter
template has not been instantiated) and so the facility for
instantiating a template was surfaced (and for example is called explicitly
in the demo loader `extendToComplex`. Similarly, this necessitated
making the unary signature of the `complex` conversion function explicit,
rather than just via implicit conversion to Complex.
(3) I find the order of implementations is mattering more in typed-function
definitions, implying that typed-function's sorting algorithm is having
trouble distinguishing alternatives.
But otherwise, the conversion went quite smoothly and I think is a good demo
of the power of this approach. And I expect that it will work even more
smoothly if some of the underlying facilities (subtypes, template types) are
integrated into typed-function.
Includes a full implementation of a type-homogeneous Tuple type, using the template types
feature, as a demonstration/check of its operation.
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #45
Glen Whitney