WIP: "Actual" symbolic evaluation demo #2475
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is not intended for merging as-is, but serves as an alternate demonstration (vis-a-vis issue #2437) that essentially all the ingredients already exist in mathjs for evaluation in which all undefined variables evaluate to symbols, therefore possibly returning an expression (Node) rather than a concrete value (while still evaluating all the way to concrete values when possible). Moreover, mathematical manipulation of symbolic expressions can be supported without circularity and without modifying numerous source files. This PR does however depend on a small addition to typed-function.js, see josdejong/typed-function#125. See (or run) examples/symbolic_evaluation.mjs for further details on this.
gwhitney
changed the title
gwhitney
added a commit
that referenced
this pull request
Mar 15, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
josdejong
pushed a commit
that referenced
this pull request
Mar 15, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
Apr 13, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
Apr 30, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
May 12, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
May 31, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
May 31, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
Jul 13, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
gwhitney
added a commit
that referenced
this pull request
Jul 15, 2022
This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470).
josdejong
added a commit
that referenced
this pull request
Jul 19, 2022
* refactor: Remove the automatic conversion from number to string. (#2482) This is a breaking change. However, nothing in the unit tests or examples actually depended on such a conversion, and it's difficult to construct situations in which it's necessary. The best such example is e.g. `count(57)` which formerly gave the number of digits in its numeric argument. Of course, after this commit, that behavior can still be obtained by the just slightly longer expression `count(string(57))` The change is proposed in preparation for an addition of new facilities/ handlers to allow symbolic computation in a couple of different ways (see #2475 and #2470). * feat(simplifyCore): convert equivalent function calls into operators (#2466) * feat(simplifyCore): convert equivalent function calls into operators Resolves #2415. * docs: Every operator has a function form Also documents the new behavior of simplifyCore to convert function calls into any equivalent operator form they may have. Also fixes the syntax errors so that simplifyCore will successfully doctest. * docs: Fix table syntax for operator->function correspondence * fix(parse): Implement amended "Rule 2" As per the discussion in #2370, the amended "Rule 2" is "when having a division followed by an implicit multiplication, the division gets higher precedence over the implicit multiplication when (a) the numerator is a constant with optionally a prefix operator (-, +, ~), and (b) the denominator is a constant." This commit implements that behavior and adds tests for it. Resolves #2370. * fix: OperatorNode.toString() outputs match implicit multiplication parsing Also greatly extends the tests on OperatorNode.toString() and .toTex(), and ensures that all tests are performed on both. (toHTML() is still a testing stepchild.) Also fixes other small bugs in .toString() and .toTex() revealed by the new tests. Resolves #1431. * test(parse): More cases of implicit multiplication * refactor: Alter the precedence of implicit multiplication This greatly simplifies OperatorNode:calculateNecessaryParentheses, as opposed to trying to correct for the change in precedence after the fact. * Fix broken unit test * Replace `options && options.implicit` with `options?.implicit` * Replace `options?.implicit` with `options && options.implicit` again, it breaks the Node 12 tests * chore: Prevent confusion with standard matrix functions. (#2465) * chore: Prevent consfusion with standard matrix functions. Prior to this commit, many functions operated elementwise on matrices even though in standard mathematical usage they have a different meaning on square matrices. Since the elementwise operation is easily recoverable using `math.map`, this commit removes the elementwise operation on arrays and matrices from these functions. Affected functions include all trigonometric functions, exp, log, gamma, square, sqrt, cube, and cbrt. Resolves #2440. * chore(typescript): Revise usages in light of changes sqrt() is now correctly typed as `number | Complex` and so must be explicitly cast to number when called on a positive and used where a Complex is disallowed; sqrt() no longer applies to matrices at all. * feat: Provide better error messages for v10 -> v11 transition Uses new `typed.onMismatch` handler so that matrix calls that used to work will suggest a replacement. * Fix #2412: let function diff return an empty matrix when the input contains only one element (#2422) * Fix #2412: let function diff return an empty matrix when the input has only one element * Undo changes in History in this fixme * Add TypeScript definitions for src/utils/is.js (#2432) This is a first step toward full publication of these functions, that were already being exported by mathjs but had not yet had the associated actions (documentation/available in parser/typed, etc.) Also, makes most of them into TypeScript type guards, and adds Matrix as a constructor type. Resolved #2431. Co-authored-by: Glen Whitney <[email protected]> * test: add two-dimensional test cases for diff of length 1 Co-authored-by: Chris Chudzicki <[email protected]> Co-authored-by: Glen Whitney <[email protected]> * Refactor/simplify core cleanup (#2490) * refactor: don't simplify constants in simplifyCore Keeps the operation of simplifyCore cleanly separate from simplifyConstant. * fix; handle multiple consecutive operations in simplifyCore() Also adds support for logical operators. Resolves #2484. * feat: export simplifyConstant Now that simplifyCore does not do any constant folding, clients may wish to access that behavior via simplifyConstant. Moreover, exporting it makes it easier to use in custom rule lists for simplify(). Also adds docs, embedded docs, and tests for simplifyConstant(). Also fixes simplifyCore() on logical functions (they always return boolean, rather than "short-circuiting"). Resolves #2459. * refactor: Rename matrix algorithms to stay sane in next refactor * refactor: Create a generator for boilerplate matrix versions of operations This reduces code length and duplication, and significantly reduces the number of instances of 'this' that will require replacement when moving on top of typed-function v3. * refactor: add automatic conversion from string to Node Eliminates many `this` calls in src/function/algebra, which will help conversion to typed-function v3a. Also make `resolve` into a typed function so that it will now work on strings as well, and adds a test that it does. * refactor: Use temporary conversions to simplify typed-function definitions Specifically, temporarily converting Object to Map eases the definition of 'simplify' and a new, generally ignored type 'identifier' (a subtype of 'string') with a temporary conversion to 'SymbolNode' simplifies the definition of 'derivative'. These refactors eliminate multiple instances of this, which will ease conversion to typed-function v3a. * refactor: Speed up utils/is.js typeOf function In preparation for using it as the function selector for the Unit class. Also fixes the inconsistency between the `typed` type hierarchy 'function' and typeOf returning 'Function' in favor of 'function', again to minimize the special cases in typeOf * feat(Unit): Add a method giving the (string name of the) type of the value E.g. `math.unit('5cm').valType()` returns `number`. Also uses this for an internal method that directly gives the number converter for a Unit. Also fixes lint errors from previous commit (not clean, I know, I forgot that build-and-test does not run lint). Adds tests for unit.valType() * refactor: Eliminate hyperbolic functions operating on angles There is no mathematical meaning to a hyperbolic function operating on an angle (the proper units of its argument is actually area), and it eliminates a number of uses of `this`, so remove such arguments. * refactor: Remove miscellaneous unnecessary typed-function this refs * refactor: Adapt to typed-function v3a Mostly this involves replaceing instances of 'this' with used of (preferably) typed.referTo() or typed.referToSelf(). Some repeated batterns of boilerpolate signatures within different divisions of functions (bitwise, relational, trigonometry) were factored out into their own files and reused in several of the individual functions. * tests: Only require that derivative tests mention the proper node type * refactor: remove typed.ignore * chore: Update to typed-function 3.0 Also had to deal with new typing for `resolve()` in that it now accepts strings and Matrices; added tests for the new possibilities for `resolve()`, and eliminated empty comments from the Node representation of parsed strings as they can't really be doing anyone any good and they are a pain for testing. Also updates the TypeScript declarations and tests for `resolve()` * chore: Object.hasOwn not supported in Node 14 Also removes 'resolve' from the known failing doc tests, now that it handles strings. * chore: Drop ES5 / IE 11 support. * fix(types): Remove no-longer-implementd matrix overloads * test(identifier): As requested in review item 2 * refactor(Unit): valType => valueType as per review item 3 * test(hasNumericValue): Test boolean arguments as per review item 4 * refactor(Node): Use class syntax rather than assigning prototypes This change simplifies the typeOf() function, because now all subclasses of Node have the expected constructor name. Also, reformats the documentation of the typeOf() function so that the doc test of that function will serve as an exhaustive test that the bundle returns the proper types. * Prevent chain functions from matching stored value with a rest parameter (#2559) * chore: Prevent confusion with standard matrix functions. (#2465) * chore: Prevent consfusion with standard matrix functions. Prior to this commit, many functions operated elementwise on matrices even though in standard mathematical usage they have a different meaning on square matrices. Since the elementwise operation is easily recoverable using `math.map`, this commit removes the elementwise operation on arrays and matrices from these functions. Affected functions include all trigonometric functions, exp, log, gamma, square, sqrt, cube, and cbrt. Resolves #2440. * chore(typescript): Revise usages in light of changes sqrt() is now correctly typed as `number | Complex` and so must be explicitly cast to number when called on a positive and used where a Complex is disallowed; sqrt() no longer applies to matrices at all. * feat: Provide better error messages for v10 -> v11 transition Uses new `typed.onMismatch` handler so that matrix calls that used to work will suggest a replacement. * fix: prevent chain from matching rest parameter with stored value Since the revised code needs the isTypedFunction predicate, switch to using the typed-function implementation for that throughout mathjs, rather than rolling our own here. Also adds a test that chain() no longer allows this kind of usage. Removes the two type declarations in types/index.d.ts that were allowing this sort of "split rest" call and added tests that such calls are forbidden. Adds to the chaining documentation page that such "split" calls are not allowed. * chore: Refresh this PR to reflect underlying changes Also addresses the review request with a detailed comment on the correctness of a new code section. Note that it reverts some changes to the TypeScript signatures of the matrix functions ones() and zeros() -- they do not actually have a typed-function signature of two numbers and an optional format specifically for two dimensions. What they have is a single rest parameter, from which the format is extracted if present. Hence, due to the ban on breaking rest parameters, it is not valid to call math.chain(3).zeros(2) to make a 3-by-2 matrix of zeros, which seems like a perfectly valid ban as the division of the dimensions is very confusing; this should be written as math.chain([3,2]).zeros(). The TypeScript signatures are fixed accordingly, along with the edge case of no arguments to ones() and zeros() at all, which does work to produce the "empty matrix". * Unit test `typeOf` on the minified bundle (currently failing) * Update AUTHORS * Improve testing of typeOf on browser bundle (WIP) * fix #2621: Module "mathjs" has no exported member "count" .ts(2305) (#2622) * fix #2621: Module "mathjs" has no exported member "count" .ts(2305) * feat: Update comments of count * feat: update the signature for count * feat: add usage example for count and sum * chore: Ensure type info remains in bundling Co-authored-by: Glen Whitney <[email protected]> Co-authored-by: Chris Chudzicki <[email protected]> Co-authored-by: Hansuku <[email protected]>
|
With [email protected], all of the ingredients to complete this implementation are in place, and I would be happy to do so, although I would like to complete the Pocomath proof-of-concept first and have a decision reached as to whether mathjs will be transforming in some way along those lines to be able to decide whether it's better to do this before or after such a reorganization. |
|
In any case, this appears to be a preferable route to #2470, which I will close in favor of this. |
|
👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is not intended for merging as-is, but serves as an
alternate demonstration (vis-a-vis issue #2437) that essentially all
the ingredients already exist in mathjs for evaluation in which all
undefined variables evaluate to symbols, therefore possibly returning
an expression (Node) rather than a concrete value (while still
evaluating all the way to concrete values when possible).
Moreover, mathematical manipulation of symbolic expressions can be
supported without circularity and without modifying numerous source
files.
This PR does however depend on a small addition to typed-function.js,
see josdejong/typed-function#125.
See (or run) examples/symbolic_evaluation.mjs for further details on this.
(Note this demo depends on the unmerged PR to simplifyCore, so it appears to have several more changes than it truly does.)