Should number(x) always result in a number (if it doesn't throw)?

[gwhitney]

I would think, as the family of functions in the type or constructor group (number, bignumber, bigint, etc.) are represented as the explicit conversions into the named type, that the answer to the title question should clearly be "yes." However, I just realized it is currently not always the case: number(2 gram) returns 2 gram. I certainly expected it to produce 2. However, it is a pattern among several of the number conversions: calling it on a unit value calls the conversion on the numeric value part of the unit and leaves the dimensions of the unit alone, resulting in a unit value.

As someone writing code in which I want a consistent way to ensure the type produced from a user-supplied MaJE formula, I would heartily recommend that number(Unit) be changed either to always throw, or to produce the numeric value of the unit argument in its current units, converted to number type if need be (in other words, compute u.toNumber(u.measuredIn()) in the proposed convention from #3441). For performing a numeric conversion on the numeric value of a unit, #3441 together with the non-throwing proposal would allow unit(number(u), u.measuredIn()); a shorter syntax could be provided if need be, perhaps u.valueTo('number') or something like that.

[josdejong]

The construction functions like number support scalar inputs, but also matrix inputs. So, using number you can convert a matrix with bignumbers into numbers for example. Units are handled in the same spirit: units contain a numeric value, and we can convert the type of this numeric value. When the Complex type would support different numeric types for the real and imaginary value we could do some thing similar.

I think we should not let number(Unit) return the current value, I think that will result in confusing cases, since you cannot predict what value will be returned as soon as you do an operation with units, like number(2cm + 4mm), would that return the value in cm or in mm? So I think it's best to to keep the conversion to number explicit via toNumber(unitOfMeasure).

If we want function number() to always return a number, then we have to drop the current support for matrices and units from the function and move that to separate functions. We could let people use map(matrix, number) for matrices, and then we have to come up with some function name for converting the numerical value of a unit. I'm in doubt though whether that would be helpful to the end user to remove these conveniences.

[gwhitney]

Do we know whether these conveniences are really adding value -- are they ever practically used, or do they just seem nice in theory? They come at a significant cost: we can't really describe or use number as a constructor or explicit converter to the number type, because for that purpose it would need to always return a number, just like Date(...) always returns a Date object, never say an array of Dates or a CalendarItem that has a date in it. And we have a real need for such pure explicit type coercion -- we need to make certain the entity that comes back into our typescript code is really the correct type, regardless of whatever crazy formula our visitor may have typed into the box, or maybe it can throw with an intelligible error message if that's simply impossible.

So we need to add to mathjs a "pure" converter/constructor into the number type. What should we call it? Number is too prone to shadowing/confusion with the JavaScript one. So number makes sense, but it's taken up by this existing function where you can't be sure what type you will get. It's unpredictable, which leads me to another thought: Perhaps when config "predictable" is true, number should always return a number? That would seem to be in line with other uses of "predictable"...

And since we are in process of adding options to the conversion, would you be OK with adding a "predictable" option to the constructors like number as well, that would override the global "predictable" when specified? That would work for us: number(x, {predictable: true}) could be our explicit coercion operation. What do you think?

[josdejong]

I'm not sure about how much it is used in practice. At least there is one user of it, me 😊.

I like the idea of using the option predictable for the contructor functions! The combination of using the global predictable setting and an optional function option predictable will make sure you can mix and match the exact behavior you want 👌.

Changing the behavior of number and others to recon with the global predictable option will be a breaking change, so we need to schedule it for v15 then. I've added this discussion to the list in #3453.

[gwhitney]

OK. This seems like a workable plan. I will see if it is feasible to split a PR with options arguments for the type constructors into a nonbreaking part for v14 and a breaking part for v15 -- I think so.