Hi all, In r18159 representation of floating point numbers in the LNUM patch was changed from double to float. This has side effects which I find very hard to justify. 32-bit integer cannot be represented as a single-precision floating point number without loss of precision.
We've run into this problem trying to perform calculations with seconds
since Epoch:
>> function err()
>>> local t = os.time()
>>> print(string.format("%d %d\n", t, t + math.floor(1)))
>>> end
>> err()
> 1286308158 1286308096
Also:
>> x = 1234567890
>> y = x - 1.0
>> print(x - y)
> 0
>> print(string.format("%d\n", y))
> 1234567936
This is hard to workaround becuase no built-in function can bring back
integer representation once the computation was "spoiled" by the
floating point result. In our case it required writing an external C
function.
Are you sure that some corner case in LuCI isn't affected too? Do 10%
memory savings justify this horribly counterintuitive and error-prone
behavior?
--
Best regards,
Rooslan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
