glen
/
pocomath
2
1
Fork 0
Code Issues 3 Pull Requests Projects Releases Wiki Activity
pocomath/src/complex/add.mjs

9 lines
196 B
JavaScript
Raw Normal View History

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 18:56:12 +00:00
export * from './Types/Complex.mjs'
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: https://code.studioinfinity.org/glen/pocomath/pulls/15
2022-07-22 20:49:14 +00:00
export const add = {
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 15:27:44 +00:00
'Complex<T>,Complex<T>': ({
'self(T,T)': me,
'complex(T,T)': cplx
}) => (w,z) => cplx(me(w.re, z.re), me(w.im, z.im))
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: https://code.studioinfinity.org/glen/pocomath/pulls/15
2022-07-22 20:49:14 +00:00
}