lua-users home
lua-l archive

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

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?  :)


Enrico Colombini kirjoitti 16.10.2007 kello 12:29:

Asko Kauppi wrote:
Depends on your need of maths, since things s.a. sin, cos 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.