* setup linting with eslint-config-standard, prettier
* [autofix] npm run lint -- --fix with new setup
* [manual] fix types/ directory errors
* [manual] fix linting errors in test/ directory
* [manual] fix single linting error in src/
* revert ts-expect-error comment change
* error on .only in mocha tests
* fix test description typo
* move some short objects to single line
* add and gitignore eslintcache
* individually suppress ts any
* set --max-warnings to 0
* extract matrices to constants
* update ts-expect-error comments
* Fix#2532: matrix index symbol `end` not working when used inside a sub-expression
* Refactor IndexNode.prototype._compile: remove redundant logic
* Throw a runtime exception when the context of an IndexNode is not a Matrix, Array, or string
* Describe the behavior of variable `end` nested indices
* Oopsie, fix linting issues
* Add a unit test to validate that `end` resolves to the inner context in case of nested indices
This is a sequel to #2531. Uniformizes the signatures of ceil, fix, floor,
and round, and updates the TypeScript declarations to match. Adds the
optional "number of places" argument to the chain versions of ceil, fix,
and floor. Adds TypeScript tests for all rounding functions.
Also corrects the TypeScript declaration for `bignumber()` and introduces
a couple more common abbreviations for TypeScript types.
Fixes the number-only implementations of floor, ceil, fix, and nthRoot
to match the full implementation behavior on numbers, and tests this for
floor.
Includes some minor documentation updates and additional unit tests for
the rounding functions.
Reverts inclusion in AUTHORS of incorrect email for one contributor,
that occurred in #2531.
Resolves#2526.
Resolves#2529.
* Optimize `det`
Use Bareiss algorithm.
The performance is preserved but lessen the round-off errors.
* Optimize `det`
Use index mapping instead of swapping the rows directly.
Run the benchmark to compare the performance.
* Edit test file
Replace `approx.equal` with `assert.strictEqual`.
The test will fail with the previously implemented LU decomposition.
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
* fix(combinatorics): Improve precision of stirlingS2
Previously the computation of stirlingS2 used the closed form, which
suffers numerically by dividing a sum of very large terms by a large
factorial, causing roundoff errors for unnecessarily small inputs.
This commit switches to using the recurrence relation for the stirling
numbers of the second kind, and caching the partial results for future
calls. This has the advantage that all intermediate results are smaller
than the final value.
Also adds tests for much larger values of the stirlingS2 function and of
bellNumbers, whose computation depends on stirlingS2.
Resolves#2508.
* fix(stirlingS2): Correct lint errors.
Incorporating unit offsets into the internal "value" of the unit
causes more problems than it solves. This commit ends that practice
and instead only uses the offset when converting units or when
computing the absolute value of a unit.
Further, it makes it an error to compute the sign of a unit with an
offset, since that is inherently ambiguous: there is no way to tell
whether "-5 degC" is a temperature change, in which case it is definitely
negative, or if it is a specific temperature of something, in which case
it is "positive" in the sense of being above absolute zero.
(Unclear how valuable this latter concept is anyway, given that there are
no negative temperatures possible in that sense...)
Adds several tests for the various problems the former practice caused,
including all four basic arithmetic operations on units with offsets.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* fix(FunctionNode): Improve error message when a non-function is called
Also adds tests for as many different varieties of function calls
and their associate messages when the entity being called is not
a function as I could come up with.
Resolves#2493.
* feat(format): Add a truncate option to limit result length.
Also uses the new option in FunctionNode.js to limit the length of the value
portion of its new error messages. (As requested in review)
* docs: Add 'truncate' option to the list in the exported version of 'format'
Also adds the test case that revealed the problem and corrects the other test
case that could have found it except the tolerance had been cranked up very
high.
Resolves#2478.
Resolves#2427.
Also adds tests verifying that creating a fraction from two numbers
requires them both to be integers, and slightly updates documentation.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
Resolves#1633
Co-authored-by: Hjortur Jonasson <hjorturjonasson@gmail.com>
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
Co-authored-by: Glen Whitney <glen@studioinfinity.org>
* doc(map): Clarify the arguments to the callback
Also make the message when there is a type mismatch more detailed.
Resolves#2436.
* test(map): Add tests relevant to new documentation
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
This change fixes a typing problem in complexEigs.js in which
real-valued norms were inadvertently being typed as complex numbers.
Resolves#2439
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* feat(FunctionNode): allow function parameters to be called
This change is implemented by checking if a function symbol is in
the arg list, and if so delaying its analysis until evaluation time,
at which point it is extracted from the arguments and called as
appropriate depending on its rawArgs property.
Also adds a few tests, documents the new facility, and documents the
handling of free variables in a function definition, which was previously
left undescribed.
Resolves#2441.
Resolves#2442.
* chore: correct lint violations (sorry)
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* fix(simplify): Collect like factors in sums and cancel like terms in sums
Since polynomials like `x*(2x+x^2)` are usually written out as polynomials
`2x^2+x^3`, adds rules to be more eager to move factors into sums to
collect like factors. To complement this, adds a rule extracting
negative powers from a sum. Together, these accomplish canceling
a common factor in numerator and denominator:
(a*k + b*k^2)/k^4 -> k^-4*(a*k + b*k^2) -> a*k^-3 + b*k^-2 -> k^-3*(a + k*b)
-> (a + k*b)/k^3
Resolves#1423.
* fix(simplify): Adjust for #2394
* chore: Rebase and mark rules with assumptions
This commit should update this PR to be fully compatible with the
current development mainline. Will remove 'WIP'.
* chore(simplify): Additional test cases from PR review
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* docs: Enhance generation to pick up functions with a prefix
For example, prior to this commit, docgenerator.js would miss
simplify.resolve because it is not a direct key of the math
object.
Also incorporates any "throws" attributes in the comments into
the generated documentation, and uses this to document the
new error-case behavior of simplify.resolve to be added in the next
commit.
* fix(resolve): Detect and throw errors for reference loops
Also extends resolve to work inside all node types. Adds tests
for both changes.
* docs: Add embedded docs for simplify.resolve et al.
To support finding the embedded doc from the `math.simplify.resolve`
function itself, required extending the search for objects with
documentation one level deeper in the `help()` function. Added test for
this search.
Also added support for documenting throws in embedded docs.
* refactor(simplify): Move resolve and simplifyCore to top-level
Also reverts changes searching for docs and embedded docs one level
down in the naming hierarchy.
Also splits tests for resolve and simplifyCore into their own files,
reflecting their new top-level status.
* fix(resolve): Remaining changes as requested
Also removed a stray blank line inadvertently introduced in
docgenerator.js
* refactor: Declare resolve and simplifyCore as dependencies of simplify
... rather than explicitly loading them, which is unnecessary now that they
are at top level.
* fix: Add dependencies to factoriesNumber
Also register simplifyCore as a dependency to rationalize
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
Note for this to work in a broad variety of contexts, has to also allow
identical expressions to cancel regardless of whether subtraction is
always defined; but this seems safe in general, that x-x is 0 even if x
does not generally have an additive inverse (for example, when working
in the positive context).
Resolves#1260.
Prior to this change, combinations(42,21) did not return an integer,
despite its value being well below MAX_SAFE_INTEGER. Now the
multiplications and divisions are balanced to try to keep the
intermediate results within the safe range.
Adds a couple of tests for larger values of combinations().
Resolves#2413.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* feat(simplify): Allow context option
If the options argument has a key 'context', it value is interpreted
as a context specifying various (non-default) properties of operators.
This context is propagated to all rules and all matching.
Adds some initial tests that the context option affects the behavior
of simplify appropriately. Not all can be activated until in a future
commit we add the ability for the application of a rule to be contingent
on aspects of the context.
Note that the enhanced rule matching necessary to support rules
constrained by non-default operator properties led to a couple of
changes to the output of rationalize() as well. Since the new output
seemed to better match what a person would typical write for the
rationalized form, this commit changed the test rather than attempted
to preserve the exact prior order of terms.
* feat(simplifyCore): strip all parentheses
Prior to this commit, simplifyCore stripped internal parentheses, but
would leave top-level ones. But top-level parentheses don't carry any
semantics, and no tests other than the ones that explicitly checked for
the retention of top-level parentheses were affected by this change.
Not making a special case for the top level also notably streamlined the
code in simplifyCore.
Adds tests for the new parenthesis-stripping behavior, as well as for
other node types that were added earlier but which did not yet have
simplifyCore tests.
* refactor(simplifyCore): Strip any node marked as trivial in context
This replaces special-case tests for unary + and parentheses, and
paves the way for example for 'abs' being marked trivial in a
putative positiveContext
* refactor(simplify): Rename 'context' parameter to rules and document it.
The new name is 'imposeContext' -- the motivation for the change is to
distinguish the parameter for 'assuming', which will be added as a new
parameter to control rule application based on context.
* feat(simplify): Allow context-based conditions on rule application.
Adds a new property of rules specified as objects: `assuming`. Its
value should be a context, and every property specified in that context
must match the incoming context, or else the rule will not be applied.
Updates the constant floating rules to require their operators be commutative,
as a test of the feature, and adds a unit test for this.
* feat(simplify): annotate rules with underlying assumptions
Also activates a number of tests of simplifications that should
or should not occur in various contexts.
To get all tests to pass, I could no longer find a rule ordering
that worked in all cases, without the ability to mark an individual
rule as applying repeatedly until just that rule stabilized. So this
commit also adds that ability, and uses it to eliminate the tricky rule
of expanding n1 + (n2 + n3)*(-1) to n1 + n2*(-1) + n3*(-1) late in the
rule ordering, in favor of the more intuitive (complete) expansion of
(n1 + n2)*(-1) to n1*(-1) + n2*(-1) early in the rule ordering, before
constant folding and gathering of like terms.
* feat(simplify): Add contexts for specific domains
In particular, adds a `simplify.realContext` and a `simplify.positiveContext`
which (attempt to) guarantee that no simplifications that change the value
of the expression, on any real number or any positive real number,
respectively, will occur.
Adds multiple tests for these contexts, including verification that the
simplification in either context does not change some example values of
any of the expressions in any simplify test.
This testing uncovered that it is unaryPlus that must be marked as trivial
for simplifyCore to work properly, so that marking is added as well.
* chore: Alter value consistency tests for browsers/older Node
The problem was NaN != NaN in some JavaScripts but not others,
so test for "both values NaN" explicitly before using deepEqual.
* fix: Implement requested changes from review
Added documentation about scope and context in top-level algebra functions
page; made variable name less abbreviated; performed suggested refactoring.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
This function returns the number of leaves in the parse tree of an
expression. The motivation is to provide an initial complexity measure
that could be used to decide whether or not to apply some simplification
rules. Docs, embedded docs, and test cases are provided.
Resolves#2389.
* fix(simplify): Correct regression in simplify
Also adds a 'debugConsole' option to simplify() so that it is possible
to see the effect of each rule. This was critical to identifying the problem,
which was that recent changes ended up with `simplifyConstant` in the
wrong position in the list of rules. Correcting that also removed the need
for the two rules coalescing negations with constants.
Resolves#2393.
* fix(simplify): Correct another regression based on rule ordering
Disccovered that `x - (y-y+x)` had also stopped simplifying due
to recent changes, again because of re-ordering of the rules. So
added it to the tests, and fixed the rule ordering (adding a more
extensive comment about it). A big part of the reason that rule
ordering is so sensitive is that the reduction engine only checks
once in each pass for each rule whether it matches. So an alternate
fix to changing the rule ordering back would have been to re-check
each rule after it's applied (in case its application created new
instances of the rule) but since the re-ordering worked, that seemed
simpler as a fix for now.
* fix(simplify): Allow simplify to work in arrays, objects, and indexing
Mostly ArrayNode, ObjectNode, AccessorNode, and IndexNode nodes are
simply transparent to simplification -- they simply allow it to occur
within subexpressions. Then main exception is that if an array or object
is indexed by a constant, the expression can be replaced by the
corresponding subitem, e.g. `[3,4,5][2]` simplifies to `4`.
This at least partially resolves#1913 (see my latest comment there).
* fix(simplify): Resolve operations on constant arrays
This involves allowing ArrayNodes containing only constant entries
to temporarily convert to Matrix type inside of simplifyConstant, so that
function and operator calls can occur on them.
I also had to add a special case for the function `size` because
it can be computed even on symbolic arrays, since the result depends
only on the shape, not the entries.
Deals with additional cases of #1913; unclear if there are remaining
aspects of that issue on which further work is desirable.
* chore: fix alphabetization of dependencies
And restores inadvertent deletion of a blank line.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
The key is that the rule-matching engine is optimized for finding matches
on the lefts of terms, but the central term-collection rule
`n1*n3 + n2*n3 -> (n1+n2)*n3` was written with the key common term rightmost.
Reversing this rule to `n3*n1 + n3*n2 -> n3*(n1+n2)` therefore does most
of the work of improving like-term collection. It also better corresponds
to typical mathematical presentation: common terms tend to be pulled out
to the left in common practice.
Floating constants to the right of a product initially (before they are
moved back to the left for human-preferred output) and ensuring that
negations are subsumed into constants whenever possible did the rest.
Also, rule context was not being propagated into the simplification
engine; this commit corrects that.
Resolves#1179.
Resolves#1290.
Co-authored-by: Jos de Jong <wjosdejong@gmail.com>
* fix(simplify): Leave string constants as strings.
Note that because the `size` built-in function called on a string returns
a Matrix, which is represented in math.js expressions as an Array, this
commit has to add ArrayNode as a dependency of `simplify` (and hence
also of `rationalize`).
In addition, it requires changing the handling of ArrayNodes
and AccessorNodes in `simplifyConstant` from "unimplemented" to just a
pass-through (since a full implementation of simplification in Arrays and
indexing seemed beyond the scope of this change, but `simplify` must not
throw an error on `size("foo")`). Hence, this commit also adds skipped unit
tests for some expressions with arrays and indexing that should ultimately
simplify.
It also removes the skip on the test group "should not change the value of
numbers when converting to fractions (3)" since all of those tests already
appear to pass.
Resolves#2152.
Changes the behavior in #1913 from throwing an error to allowing Arrays and
indexes but not simplifying inside them.
* chore: Fix lint and remove explanatory comment
