lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Yes, exactly as Lisa put it.

My use of "integer patch" name was probably misleading, it really is either "non-FPU optimization 
patch" or "integer optimization patch".

You can freely set it up in any combination of:
- int32 / int64
- float / double

In your situation, you'd opt for int32 and float, which both eat 32 bits.

The benefits:
- integer speed for integer operations
- integer precision throughout the int32 range
- transparent int/float conversions, but only when needed (i.e if doing 2/3, or maxint+1)

I really think this would be Your Thing for the ache. And it wouldn't shake any of the upper Lua layers, 
not even Lua/C API. A bit. :)

In that way, you can compare it to the array optimization of Lua 1..N tables. The upper layers won't see 
a thing. 

-asko



Lainaus Lisa Parratt <lisa@thecommune.org.uk>:

> Gavin Wraith wrote:
> > In message <1144309597.4434c75d4577d@webmail.dnainternet.net> you
> wrote:
> >  
> >> Just use the "integer patch" from Wiki power patch pages.
> > 
> > I am afraid you have either misunderstood what I wrote or not read
> > it carefully.
> 
> Unless I'm mistaken the integer patch makes numbers use an integer if 
> they're an integer, or a real if they're not. There wouldn't be a need 
> for a patch if it were merely replacing numbers with integers, since 
> that's already a configuration option.
> 
> I don't see it as viable to patch in support for a new numeric type - 
> neither the language nor the implementation is designed to support it. 
> It would need a vast quantity of the code base to be overhauled.
> 
> -- 
> Lisa
>