Hello list,
I ran into quite similar issues when porting our daemon code to Backfire:
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio (float int32)
> print(tonumber(math.max(1234567890, 0)))
1234567936
The math library most likely casts all ints to floats. Using float
instead of double as floating point representation causes this erratic
behaviour. Most of the embedded processors used in wifi SoCs lack
dedicated floating point hardware, which might be the reason for
switching to float. I however prefer slower but predictable (double)
calculations to faster unpredictable (float) ones.
Best regards,
Bart Van Der Meerssche.
On 10/05/2010 10:03 PM, Rooslan S. Khayrov wrote:
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?
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
