On Mon, Sep 3, 2018 at 12:07 PM, Lorenzo Donati wrote:
The problem is that math.huge it is not guaranteed to be, semantically, infinity.
Even for a non-standard floating point numbers implementation (for example, without infinite values), Lua guarantees that "math.huge" is larger than any other FP value.
For a sane FP implementation, this means that such a number would be large enough, so we can hope it would be greater than the length of longest string you could create in Lua VM.
Hence, there would be no problems with using "math.huge" as appropriate value for "far-far-away-position-in-a-string".
There exist non-standard FP implementations that potentially could be problematic as their maximal number is rather small.
For example, ARM CPUs support "half-precision" 16-bit infinity-less format (1 sign + 5 exponent + 10 significand) which is able to represent numbers up to 131008.0
A string could have length > 128 KBytes, so this is a potential problem.
But ARM manual says: "The __fp16 type is a storage format only. For purposes of arithmetic and other operations, __fp16 values in C or C++ expressions are automatically promoted to float."
So, there is no sane reason to build Lua for ARM with 16-bit FP numbers.
There exist a lot of non-standard FP formats
http://www.quadibloc.com/comp/cp0201.htm and happily almost all of them have 8 bits for exponent, that means their maximal finite number is about 10^38 or more (so, no problem!).
