Re: need uint64, is setting lua_Number to long double a bad idea?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: need uint64, is setting lua_Number to long double a bad idea?
- From: askok@...
- Date: 2006年7月22日 04:17:21 +0300
Did some fixing to the patch, long hex values can now be
printed out by:
print( string.format("%x",v) )
-->
faaaca297e488e35
The remaining - and quite foundational - issue is that due
to not wanting to change "outside interfaces" in the
patch, Lua VM constants are still only using numbers
(float/double) and not integers. This is very annoying in
Sam's situation, and prevents use of the now built-in 0x
notation (had forgotten, but it actually is there, and
works...)
So, currently:
Lua 5.1 Copyright (C) 1994-2006 Lua.org, PUC-Rio
print(0xfaaaca297e488e35)
1.8062471535084e+19
print(0xfaaaca29 * 2^32 + 0x7e488e35)
1.8062471535084e+19
a=0xfaaaca29
print(a*2^32 + 0x7e488e35)
-384272538625601995
The last is "right", and works because assignment to 'a'
causes the value to be stored as an integer, and
calculations fit within the int64 range.
Fixing the above two would mean, that integer detection is
done already at lvm.c, and causes changes in the VM
bytecode (basically just exposing the integer type at that
level).
I would feel this is something Lua authors should do, if
they were to sometime integrate my integer patch with
mainline code; I feel hesitant walking past that bridge..
-asko
On 2006年7月21日 23:35:28 +0300
Asko Kauppi <askok@dnainternet.net> wrote:
The only way to get to these patches is by svn checkout
(sorry, no Google! :)
svn co svn://slugak.dyndns.org/public/lua-patches
They were developed on 5.0.2 but are currently applied
to 5.1. Some might work on both.
Hex input/output shouldn't be harder than any hex syntax
patching of Lua, but it's not the work of the same
patch. They can be "aware" of each other, though, so
that 0xFAAACA297E488E35 becomes possible if (and only
if) 64-bit integers are actually supported.
Decimal unsigned 64-bit input/output is much a no-go;
integers are _not_ a separate type when it comes to Lua
scripts, and C API. They are simply a high precision
subgroup of Lua numbers, and must therefore be signed.
18062471535083949621 presents a number outside of that
integer precision region, and would end up being
1.8062471535084e+19.
0xFAAACA297E488E35 would become -384272538625601995, or
so it does with the code below (run with doubles,
int64):
(one further notion, if you need integer wrap-around
from 0x8000...0000 to 0 and back, the patch is not for
you. Numbers don't wrap around, they simply fall into
the less precise FP realm.)
local hex= "FAAACA297E488E35"
local v= 0
for i=1,string.len(hex) do
local v2=0
local c= string.upper( string.sub(hex,i,i) )
if c>='0' and c<='9' then
v2= tonumber(c)
elseif c>='A' and c<='F' then
v2= 10+string.byte(c)-string.byte('A')
else
error( "Not hex: "..c )
end
v= v*16 + v2
end
print(v)
--> -384272538625601995
Sam Roberts kirjoitti 21.7.2006 kello 22.07:
On Fri, Jul 21, 2006 at 09:07:49PM +0300, Asko Kauppi
wrote:
Hmm. The "int patch" discussed on the list a few times
actually
allows you to use int64 and doubles, as well.
This means, you'd get full int64 range for any integer
numbers, and
doubles for the rest.
We use UNSIGNED 64 bit ints, and since they are random,
about 50% of
them will have a bit pattern that will be "negative".
This is why I
haven't looked at the patch before.
I suppose with some casting we can just convert the
signed rep to
unsigned in our C code. But when I want to represent
0xFAAACA297E488E35
in lua source, will I will have to first convert to
decimal,
18062471535083949621, and then do something to figure
out the
representation as a negative?
Maybe you see why long double sounds so interesting to
me! Both signed
AND unsigned 64 bit integer varieties. Wow!
My goal is ease of use of our app domain numerics in
lua, so the issue
of representation in lua source code isn't completely a
seperate
issue.
I understand lua's design rational, I even agree with
it, but I
sure do
miss the convenience of ruby here:
0xFAAACA297E488E35
=わ=わ 18062471535083949621
=わ=わ 0o1752526242457622107065
==
0b1111101010101010110010100010100101111110010010001000111000110101
Even without arbitrary size integers (which would cause
bloat in
the lua
core and is out of the question), the appropriate
representation for a
number depends on the application domain, and hex,
binary, and
octal all
have their places. Lua's strength is application
specific language
apps, so it would fit in, I think.
Interested? :)
Sure I'm interested, I'll definitely give it a try and
see how it
works.
We use lua 5.0.2 (sorry, not my fault), so hopefully it
isn't 5.1
specific.
Where can I find it?
I think thats the other reason I haven't used it yet,
its hard to find
with google!
Thanks,
Sam