v13 breaking changes

[josdejong]

This issue will keep track on the various discussions we have about the architectural changes we want to implement in mathjs v13. Please comment if there are more topics to discuss

• Change isZero, isPositive, and isNegative to respect config.epsilon Determinant with small numbers fix #3139
• Change the behavior of the internal nearlyEqual to align with Python and Julia
  • Nearly equal with relative and absolute tolerance #3152
  • isZero() does not respect config.epsilon #2838
• TypeScript support:
  • Status: proposal to go for a hybrid JS+TS approach
  • Discussion: Add a TypeScript declaration generator for a typed-function? typed-function#123
• The core architecture with factory functions
  • Status: @gwhitney has created a satisfying POC with an alternative core architecture that solves the current pain points, see https://code.studioinfinity.org/glen/pocomath
  • Discussions:
    • base concept: [Design question] I don't like `factory`. Why don't we just use modules? #2741
    • the exact API: https://code.studioinfinity.org/glen/pocomath/issues/55
• Implement BigInt support
• Publish with fraction.js 5.0.0? See Error with fraction.js rawify/Fraction.js#68

[josdejong]

FYI: I've renamed this topic from "v12 breaking changes". to "v13 breaking changes". The topics we plan here are still far from finished, and there will be a small breaking release in between. See #3032.

[gwhitney]

Yup, #3032 looks like enough for a breaking release to my eyes as well. And I hate to, but I will make a prognostication: you might as well rename this "v15 breaking changes" now :-/ The stuff in the opening comment of this issue is of overwhelming magnitude. For the record, I hope this prognostication to turn out false, and will make my best effort for it to. :-)

[josdejong]

😂 yeah I'll keep incrementing the version number, we'll see. This topic just helps me to keep track on the breaking things we have in the pipeline, the exact version number is not that important to me.

[gwhitney]

Might we want to include incorporation of an overall internationalization scheme (see discussion #3055) into mathjs at this level? With mathjs' age and scope, it feels well overdue...
In fact, while I am thinking about it, I will go so far as to suggest that https://github.com/globalizejs/globalize looks like a plausible i18n library we might use.

[josdejong]

Yes I would love to improve on that. Do you expect breaking changes when implementing internationalization? It feels more like a new feature to me, and can probably be backward compatible.

[josdejong]

We may indeed just do internationalization on the fly when refactoring mathjs.

[gwhitney]

Do you expect breaking changes when implementing internationalization?

Well, I expect the results of the help() function to change if the user's locale does not specify the English language, so that in some sense is a breaking change. And to support that, I imagine the entire way the results of help() are recorded in the code will change -- presumably they will be moved to translation files. That's more of an "internal breaking change," i.e. something we might want to do as part of a major refactor, as you point out in your second note.

[josdejong]

That's true. Makes sense to mark it as a breaking change.