Re: need uint64, is setting lua_Number to long double a bad idea?

[Asko Kauppi <askok@...>]

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