Incompatibility between `number: bigint` and high-precision floating point arithmetic

[gwhitney]

with math.js 14.6.0

math.config({
  number: "bigint", 
  precision: 998,
  relTol: 1e-320,
  absTol: 1e-323,
  numberFallback: "BigNumber"
});

outch, a part of the code doing stuff like :

• math.log10( 0n ) (which before was containing bignumbers) returns errors now "i.toNumber is not a function"
• math.log( 123n ) returns now 4.812184355372417 , before it was returning a bignumber of 998 digits
• floor(log10(( 1n ))) returns now "Number of decimals in function round must be an integer from 0 to 15 inclusive"

I was parsing big integers as bignumber to return long primes and now I get messages like this "Cannot mix BigInt and other types, use explicit conversions"

the price to pay in code update seems very high , and all calculations based on logarithms no longer return the configuration's precision. every constant are now limited to few digits math.pi = 3.141592653589793.

Originally posted by @nycos62 in https://github.com/josdejong/mathjs/discussions/3533#discussioncomment-14504003

These are all bugs; it should be possible to conveniently perform high-precision floating-point arithmetic when (perhaps especially when) numbers default to bigints.

[josdejong]

Good point, we should definitely look into this!

[josdejong]

I created a PR adressing the issue with math.log10( 0n ), see #3555

[josdejong]

I had a look into this, and I think it boils down to the promoteLogarithm function now converting to number when the input is positive or predictable: true, and a complex number when negative.

So, I think the way ahead is to let promoteLogarithm reckon with config.number, and let it either switch to the BigNumber or number implementation depending on the configuration.

EDIT: maybe we can pass the generic log function and numeric to promoteLogarithm so we have flexibility in converting to the right type and then just call the generic function.