Re: Fixed-point LUA_NUMBER

[Asko Kauppi <askok@...>]

Isn't fixed point code just using int32/64, and making input/output  
of numbers seem they're fractional?  Like 1000 -> 1.0 or just 1.

As to your question, if you're in charge of all the modules, and they  
are a limited number, you'd be just fine defining LUA_NUMBER. Just  
grep all occurences of 'tonumber', 'lua_Number' etc. and check  
they'll work with your code.

I would simply #define LUA_NUMBER int (or long) and change the number  
input/output functions. Including the ones reading in Lua tokens, so  
1 in the source would be 1000 (or so) in the int/long.

To Daniel: if Enrico is ready to live without some math features, the  
Lua code should work "just right" in most cases.

- ok
+ ok
* needs adjustment (/ fixed one)
/ needs adjustment (* fixed one, before the divide)
^, pow needs adjustment (may be complicated)
log, ldexp, log10, exp :(
min, max ok
*cos*, *sin*, *tan* :(
deg,rad doable
random, randomseed doable
ceil, floor doable
abs ok
sqrt doable
%, mod, modf doable

That gives the rough picture. Personally, I would do fixed only if I  
intend to live without a math lib altogether (there goes math.sqrt);  
if the device is _that_ small. And I think this is how the possible  
LNUM_FIXED mode should be.

Leaving us:

- + * / ^ % min max deg rad ceil floor abs

Is that enough?  :)

-asko


Enrico Colombini kirjoitti 16.10.2007 kello 12:29:

> Asko Kauppi wrote:
> > Depends on your need of maths, since things s.a. sin, cos et.al.  
> > will lose their usefulness pretty immediately. I would actually  
> > leave such undefined for a fixed-point Lua implementation.
>
> Yes, that's to be expected.
>
> > The C API would be problematic; unless you keep 'lua_Number' as a  
> > familiar double and only do the conversion within the core.
>
> This would be problem #1. Could you be more specific about the  
> mechanisms that would break?
>
> > You wouldn't be aware of how addon modules deal with lua_Number,
> > and you wouldn't really even want to know. :)
>
> I wouldn't use any external module... nor many of the standard libs.
>
> > This means you wouldn't just get away with redefining LUA_NUMBER.
>
> Well, it was too good to be true :-)
>
> > If you get it to work, I'd be interested to add fixed point maths  
> > into the Numbers patch. And to hear performance comparisons  
> > against a hybrid float+int32 approach.
>
> Unfortunately, the fixed-point code is not mine and not public  
> either, but should I try this road I'll give some stats. At the  
> moment it's just a hypothesis among many.
>
>   Enrico