Commit Graph

58 Commits

Author SHA1 Message Date
d76eddc7a5 feat(polynomialRoot): Complete implementation 2022-12-01 12:40:05 -05:00
269b9f5fc6 refactor(core): Resolve partial self-references at Pocomath level 2022-11-30 09:00:39 -05:00
c4b1ac9045 feat(polynomialRoot): Progress commit, quadratic implemented 2022-11-30 08:55:12 -05:00
de52c041e5 feat(polynomialRoot): Initial implementation (linear only) 2022-11-26 17:28:19 -05:00
31add66f4c feat: Return type annotations (#53)
Provides the infrastructure to allow annotating the return types of functions, and does so for essentially every operation in the system (the only known exceptions being add, multiply, etc., on arbitrarily many arguments).

One main infrastructure enhancements are bounded template types, e.g. `T:number` being a template parameter where T can take on the type `number` or any subtype thereof.

A main internal enhancement is that base template types are no longer added to the typed universe; rather, there is a secondary, "meta" typed universe where they live. The primary point/purpose of this change is then the necessary search order for implementations can be much better modeled by typed-function's search order, using the `onMismatch` facility to redirect the search from fully instantiated implementations to the generic catchall implementations for each template (these catchalls live in the meta universe).

Numerous other small improvements and bugfixes were encountered along the way.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #53
2022-08-30 19:36:44 +00:00
207ac4330b doc(README): Add a note about adopting 3rd party types 2022-08-07 16:38:15 +00:00
9267a8df60 Merge pull request 'feat: Generic numerical types' (#50) from numeric_adapter into main
Reviewed-on: #50
2022-08-07 16:34:43 +00:00
bcbb24acd2 feat: Generic numerical types
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.
2022-08-07 09:19:27 -07:00
199ffd2654 doc(README): Add brief notes about new template facilities 2022-08-07 03:34:39 +00:00
28ccbf8d48 Merge pull request 'feat(quaternion): Add convenience quaternion creator function' (#48) from quaternion into main
Reviewed-on: #48
2022-08-07 03:27:46 +00:00
e26df5f4fc feat(quaternion): Add convenience quaternion creator function
Even in the setup just prior to this commit, a quaternion with entries
  of type `number` is simply a `Complex<Complex<number>>`
  So if we provide a convenience wrapper to create sucha thing, we
  instantly have a quaternion data type. All of the operations come for
  "free" if they were properly defined for the `Complex` template.
  Multiplication already was, `abs` needed a little tweak, but there is
  absolutely no "extra" code to support quaternions. (This commit
  does not go through and check all arithmetic functions for proper operation
  and tweak those that still need some generalization.)

  Note that with the recursive template instantiation, a limit had to be placed
  on template instantiation depth. The limit moves deeper as actual arguments
  that are deeper nested instantiations are seen, so as long as one doesn't
  immediately invoke a triply-nested template, for example, the limit will
  never prevent an actual computation. It just prevents a runaway in the types
  that Pocomath thinks it needs to know about. (Basically before, using the
  quaternion creator would produce `Complex<Complex<number>>`. Then when you
  called it again, Pocomath would think "Maybe I will need
  `Complex<Complex<Complex<number>>>`?!" and create that, even though it had
  never seen that, and then another level next time, and so on. The limit
  just stops this progression one level beyond any nesting depth that's
  actually been observed.
2022-08-06 20:13:50 -07:00
40619b9a2e Merge pull request 'refactor(Complex): Now a template type!' (#46) from template_complex into main
Reviewed-on: #46
2022-08-06 15:42:19 +00:00
1444b9828f refactor(Complex): Now a template type!
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.
2022-08-06 08:27:44 -07:00
845a2354c9 feat: Template types (#45)
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
2022-08-05 12:48:57 +00:00
fd32ee1f10 Merge pull request 'feat(install): Allow plain functions' (#44) from install_plain into main
Reviewed-on: #44
2022-08-02 07:50:14 +00:00
8418817f9f feat(install): Allow plain functions 2022-08-02 00:47:37 -07:00
0ce4de086c Merge pull request 'feat(Chain): add computation pipelines like mathjs' (#43) from chainify into main
Reviewed-on: #43
2022-08-01 23:28:32 +00:00
814f660000 feat(Chain): add computation pipelines like mathjs
Also adds a `mean()` operation so there will be at least one operation
  that takes only a rest parameter, to exercise the ban on splitting
  such a parameter between the stored value and new arguments.
  Adds various tests of chains.

  Resolves #32.
2022-08-01 16:24:20 -07:00
46ae7f78ab Merge pull request 'feat(floor): Provide example of op-centric organization' (#42) from op_centric into main
Reviewed-on: #42
2022-08-01 15:30:10 +00:00
7d1a435aa0 feat(floor): Provide example of op-centric organization 2022-08-01 08:28:21 -07:00
fe54bc6004 feat: Template operations (#41)
Relational functions are added using templates, and existing generic functions are made more strict with them. Also a new built-in typeOf function is added, that automatically updates itself.

Resolves #34.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #41
2022-08-01 10:09:32 +00:00
2609310b8e Merge pull request 'feat(Complex): support division' (#40) from complex_division into main
Reviewed-on: #40
2022-07-31 18:09:52 +00:00
102a7c42dc feat(Complex): support division 2022-07-31 11:08:07 -07:00
6775b66686 Merge pull request 'feat: Implement subtypes' (#37) from subtypes into main
Reviewed-on: #37
2022-07-30 12:02:45 +00:00
c429c19dfe feat: Implement subtypes
This should eventually be moved into typed-function itself, but for
  now it can be implemented on top of the existing typed-function.

  Uses subtypes to define (and error-check) gcd and lcm, which are only
  defined for integer arguments.

  Resolves #36.
2022-07-30 04:59:04 -07:00
4d38f4161c Merge pull request 'test: Check for undefined types, as a means to detect typos in type names' (#35) from check_type_names into main
Reviewed-on: #35
2022-07-30 02:45:44 +00:00
81127b8a9b test: Check for undefined types, as a means to detect typos in type names 2022-07-29 19:43:24 -07:00
31d3be277d Merge pull request 'refactor: Simpler merging mechanism' (#33) from merge_instances into main
Reviewed-on: #33
2022-07-29 04:42:05 +00:00
d9d7af961f refactor: Simpler merging mechanism
Merging of Pocomath modules is eased by allowing one PocomathInstance to
  be merged into another. That allows types, for example, to be exported
  as a PocomathInstance (so there is no need for a special identifier
  convention for types; they can be directly added with an installType
  method). Also, larger modules can just be exported as an instance, since
  there is more flexibility and more checking in merging PocomathInstances
  than raw modules.
2022-07-27 22:28:40 -07:00
58fa661a2d Merge pull request 'fix(Types): Move distinct types into distinct identifiers' (#28) from bigint_sqrt into main
Reviewed-on: #28
2022-07-25 19:54:56 +00:00
f68c7bd1fb fix(Types): Move distinct types into distinct identifiers
This allows types to be collected; prior to this commit they
   were conflicting from different modules.

   Uses this fix to extend sqrt to bigint, with the convention
   that it is undefined for non-perfect squares when 'predictable'
   is false and is the "best" approximation to the square root when
   'predictable' is true. Furthermore, for negative bigints, you might
   get a Gaussian integer when predictable is false; or you will just get
   your argument back when 'predictable' is true because what other
   bigint could you give back for a negative bigint?

   Also had to modify tests on the sign in sqrt(Complex) and add functions
   'zero' and 'one' to get types to match, as expected in #27.

   Adds numerous tests.

   Resolves #26.
   Resolves #27.
2022-07-25 11:56:12 -07:00
e5cce2eaff Document new features in README. 2022-07-25 11:44:19 +00:00
b21d2b59fa Merge pull request 'feat: Implement signature-specifc reference' (#25) from specific_signature into main
Reviewed-on: #25
2022-07-25 11:33:50 +00:00
91ec20edd8 feat: Implement signature-specifc reference
Also implements a config object that upon change, lazily invalidates
  all operations that access it.

  Also allows references to signatures with nonexistent types (which
  typed-function does not); they come back as undefined.

  Uses these features to implement sqrt for number and complex.

  Resolves #7.
2022-07-25 04:20:13 -07:00
79f261ff65 Merge pull request 'feat(Types): Improve type spec and ignore signatures that use unknown type' (#23) from forgiving_types into main
Reviewed-on: #23
2022-07-24 19:53:40 +00:00
358f68fbbd feat(Types): Improve type spec and ignore signatures that use unknown type 2022-07-24 12:52:23 -07:00
890752a1e7 Merge pull request 'feat: Switch to function-based specification of dependencies' (#22) from ultimate_notation into main
Reviewed-on: #22
2022-07-23 16:59:21 +00:00
9fb3aa2959 feat: Switch to function-based specification of dependencies
Allows dependencies to be economically expressed and used.
  For example, see the new definition of subtract.
  Credit for the basic idea goes to James Drew, see
  https://stackoverflow.com/a/41525264

  Resolves #21.
2022-07-23 09:55:02 -07:00
d72c443616 feat: Add and illustrate multiple ways of specifying implementations (#19)
Resolves #9.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #19
2022-07-23 05:06:48 +00:00
4fdafc751e feat: Add a couple of ways to install generics safely. (#18)
Resolves #10.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #18
2022-07-23 02:41:59 +00:00
2a60cc0989 Merge pull request 'refactor: Use Object.defineProperty with a getter to invalidate' (#17) from no_invalid into main
Reviewed-on: #17
2022-07-22 22:09:17 +00:00
e6699ce642 refactor: Use Object.defineProperty with a getter to invalidate
Rather than setting a dummy function; this avoids anyone ever storing
  a dummy function.

  Resolves #8.
2022-07-22 15:06:56 -07:00
4a2d53a68a Merge pull request 'fix: Prevent PocomathInstance from clobbering its own methods' (#16) from protect_reserve into main
Reviewed-on: #16
2022-07-22 21:29:17 +00:00
b72212d929 fix: Prevent PocomathInstance from clobbering its own methods
Resolves #6.
2022-07-22 14:25:26 -07:00
0069597a76 fix: Separate typed instance for each PocomathInstance (#15)
Also starts each PocomathInstance with no types at all, and uses the new
  situation to eliminate the need for a Complex "base case".

  Resolves #14.
  Resolves #13.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #15
2022-07-22 20:49:14 +00:00
ed71b15969 Merge pull request 'fix: Avoid files that differ just by case' (#12) from no_case_duplicates into main
Reviewed-on: #12
2022-07-22 16:47:09 +00:00
664f30ddef fix: Avoid files that differ just by case 2022-07-22 09:45:58 -07:00
89f4977e78 doc: Move an incorrectly placed comment 2022-07-20 02:57:46 +00:00
9a63389a4c doc: Fix a couple of typos in README 2022-07-20 02:53:29 +00:00
a16d6a5ce3 feat: Add all remaining features of original Picomath PoC (#5)
Namely, a README describing the proof-of-concept,
  a custom selective loader, and some additional tests.

Co-authored-by: Glen Whitney <glen@studioinfinity.org>
Reviewed-on: #5
2022-07-19 19:37:52 +00:00