Can I trust the module for accuracy? (not precision but accuracy!). I don’t want a module that can represent up to 10^(10^308) with semantics that is not very accurate and not good.
Can I trust the module to have semantics I can predict (and anything with contrary semantic should be documented)?
Why just extend the exponent?
Are you aware you are mixing binary floating point with base-10 exponents? Why not base-2 exponents?
Did you take account of negative exponents? If not, why just positive, and is the exponent offseted by a constant (called ‘biased exponent’)?
What abstract numerical data type is this trying to represent? If it’s an abstract scalar floating point - what’s the exact precision (in bits, digits, etc) of the significand and the exact width of exponent?
Looking at the module and the source code, it doesn’t suggest that you understand floating point semantics very well. You aren’t aware that sqrt(x) and x^0.5 are different for -0.0 and -Infinity. In fact, you don’t seem to have a sufficient understanding of the concept of floor and ceil, the documentation is quite ambiguous “Rounds a number down to the nearest integer” (what does it do for negative floats?), and function named floor actually rounds towards zero (should’ve made that more clear in the documentation if that is intentional) which is in contrast to what I expect floor does given that the semantics of the floor is usually defined as rounding towards negative infinity in lots of programming language standard and in math (Floor Function – from Wolfram MathWorld). Additionally, these functions doesn’t even work for exponents >= 3 because of this if second >= 3 then return Num * sign end in the floor implementation, what’s your reason to have a guard clause of this (I don’t think it is an edge case as it checks if exponent is >= 3 which is common), and the variable name second is an odd choice)? …and this isn’t documented so I’m unsure if this is a bug or an intentional behaviour.
Also, using tostring to check for NaN (which I saw in the __eq method of InfiniteNum) isn’t a good idea nor it will be assured to work as you expect as tostring could return -nan, -nan(ind), nan(snan) etc as tostring is platform and implementation dependent, along the fact that converting a number to strings is quite an expensive process.
That’s my concern with this module.
I think metamethods are used for ergonomics purposes. Why would this be a real problem for a multi-precision library? Sure, it’s not as ergonomic.
Why would this be a deal breaker?
These instructions call functions under the hood if raw operations of these (such as number + number) aren’t available so I don’t think this brings any advantages other than ergonomics.
