The Vector type is simply a generic type for built-in JavaScript Arrays. The parameter type is the type of all of the entries of the Array. The Vector type also supports inhomogeneous arrays by using the special type `Unknown` as the argument type, but note that when computing with inhomogeneous arrays, method dispatch must be performed separately for every entry in a calculation, making all operations considerably slower than on homogeneous Vector instances.
Note also that arithmetic operations on nested Vectors, e.g. `Vector(Vector(NumberT))` are defined so as to interpret such entities as ordinary matrices, represented in row-major format (i.e., the component `Vector(NumberT)` items of such an entity are the _rows_ of the matrix.
Reviewed-on: #28
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
Adds all of the pocomath functions on Complex that do not depend on any unimplemented types or config properties, except quotient and roundquotient, where the design is murky. To get this working, adds some additional features:
* Allows conversions to generic types, with the matched type
determined from the return value of the built convertor
* Adds predicate-based type patterns
* Adds conversion from any non-complex type T to Complex(T)
* Adds check for recursive loops in resolve (a key/signature depending on itself)
Reviewed-on: #24
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
Pursuant to #12. Besides changing the name of onType to match, and only allowing one pattern and result in `match()`,
this PR also arranges that in place of an onType with lots of alternating PATTERN, VALUE, PATTERN, VALUE arguments, one now exports an _array_ of `match(PATTERN, VALUE)` items.
Doesn't quite fully resolve#12, because there is still the question of whether `match(...)` can be left out for a behavior that literally matches anything (current behavior), or whether `match(Passthru, behavior)` should be required for such cases.
Reviewed-on: #22
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
Generic types can be called with argument(s) to produce a new type object, and if all types supplied as arguments are concrete, then the result will be a concrete type. The test of a generic type must determine if the entity is an instance of any specialization of the type; and it must also have a `refine` method that takes such an instance and returns its fully-specialized concrete type. It must also have a method `specializesTo` that takes a concrete type and returns whether that concrete type is a specialization of this generic type.
This commit also defines a generic Complex number type, that can have any type as its Component type (including another Complex number, to create e.g. quaternions), and defines the conversion/constructor function `complex`.
Reviewed-on: #21
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
Establishes a global config object for a TypeDispatcher instance, so far
with just properties representing comparison tolerances. Begins a
"relational" group of functions with basic approximate equality, and
an initial primitive ordering comparison. Ensures that methods that
depend on properties of `config` will be properly updated when those
properties change.
Reviewed-on: #19
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
This PR adds a boolean section, as well as an isNaN predicate on numbers. In a TypeDispatcher, when BooleanT is present, isNaN returns a BooleanT. However, in a numbers-only TypeDispatcher, it returns 1 or 0 instead. Moreover, when booleans are subsequently added to a numbers-only instance, isNaN properly reconfigures itself to return BooleanT.
No predicates that depend on approximate equality testing or a configuration object are implemented in this PR.
This PR also implements type matching and dispatching with implicit conversions, and adds an implicit conversion from BooleanT to NumberT.
Reviewed-on: #17
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
We use [mocha](https://mochajs.org/) as the test framework, as it is
the tool used by mathjs and we would like to make tests as similar
as possible. However, to tighten the linkage between source code and
tests, we adopt a somewhat different file organization: unit tests
for a given source file `blah/foo.js` are in `blah/__test__/foo.spec.js`.
To run all unit tests, execute the script `pnpm test`.
Resolves#3.
Reviewed-on: glen/nanomath#5
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
Resolves#1.
A hand test showed this code can add two plus two, always a major milestone. So we will skip review on this PR since there is currently no testing framework, and proceed immediately to addressing #3.
Reviewed-on: glen/nanomath#4
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Co-committed-by: Glen Whitney <glen@studioinfinity.org>
