Document developer requirements/guidelines for the Number bundle

[gwhitney]

Recently, I have just been throwing any mathjs methods I create into the number bundle with their standard factories, on the theory that if their factory defines implementations for other types, those will just be ignored when the number-only instance is generated.

However, I was working on adding a scalarDivide() function (which would check if one vector is a scalar multiple of another, e.g., scalarDivide([1.5, 3], [1, 2]) = 1.5 but scalarDivide([2, 3], [1, 2]) = undefined), and I went to add it to factoriesNumber and discovered that neither dotMultiply nor dotDivide is in the number bundle. Yet these operations make perfect sense for ordinary arrays of numbers. So, it would be helpful to have some clarification:

1. What is the criterion for a method to be included in the number bundle? Should dotMultiply and dotDivide be added, and the list of functions scanned for others that should be added? Or perhaps are there methods now in the number bundle that should be removed?

2. Is there/could there be automated testing for what is and isn't in the number bundle?

3. When does the implementation need to be changed for inclusion in the number bundle vs. when can the same factory just be included in factoriesNumber as in factoriesAny?

This guidance should be added to the "Implementing a new function" section of the README.

[josdejong]

The idea of the plain number was to have a lightweight version of mathjs without Matrices, Complex number, BigNumber, Unit, etc. Only calculations with primitive types like number and maybe boolean or string.

I think support for Arrays (like in sum) is a bit of a gray area: most mathjs functions require/expect support for Matrices, so it's not easy to separate this an prevent a function working with arrays from accidentally pulling in the DenseMatrix class.

Right now we have to manually decide whether some function is suitable for the plain number implementation.

Maybe we can automatically check by verifying that a function nor it's dependencies pulls in DenseMatrix, SparseMatrix, Complex, BigNumber, or Unit?

[gwhitney]

Maybe we can automatically check by verifying that a function nor it's dependencies pulls in DenseMatrix, SparseMatrix, Complex, BigNumber, or Unit?

If that is a concrete criterion, that's super helpful. Changing this into an issue to create such a node test.

[gwhitney]

Actually, it appears there is in effect already such a test. If any of the above are required as dependencies, the following call in entryGenerator.js (which runs as part of npm run build-and-test) will fail.

generateDependenciesFiles({
    suffix: 'Number',
    factories: factoriesNumber,
    entryFolder: ENTRY_FOLDER
  })

Hence, leaving this open as a documentation-only issue.

[josdejong]

Ah, that's nice that there is already a check for that!