lua-users home
lua-l archive

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



I wouldn't emphasize the benchmarks at this point, really.

I'd want us to strive towards a system, where all number handling stuff is in a specific .[ch] pair of files (which carries absolutely nothing more). There wouldn't be any harm in doing this, to regular Lua, right?

Let's call this lnum.[ch]

Then, one can have lnum_bcd.[ch], and simply using these in compile/ linkage shall create you a BCD variant of Lua.

Others would be:
	lnum_int.[ch]		Pure integers only
	lnum_intopt.[ch]	Integer optimized, int32|64 + float|double
	lnum_complex.[ch]	a + bi
	...

Such, community provided files can be carried in the etc/ folder, unless the Lua authors want to have them truly integrated.

Lua bytecode identification should possibly be extended, to somehow identify the whole number scheme a precompiled block has. Current int/ float/double detection will fall short. This is easy to do, with a list of 'magic codes' maintained by Lua authors:
	LUA_NUM_FLOAT	0x1
	LUA_NUM_DOUBLE	0x2
	LUA_NUM_LONGDOUBLE	0x3
	...
	LUA_NUM_INT16	0x8
	LUA_NUM_INT32	0x9
	LUA_NUM_INT64	0xa
	...
	LUA_NUM_BCD	0x80
	LUA_NUM_COMPLEX	0x90
	...

MSB/LSB information would need to be separately stored.

-asko


Vijay Aswadhati kirjoitti 25.8.2006 kello 21.40:

On 8/25/06, Andy Start wrote:

I don't think decimal should be seen as a relic of the IBM mainframe age.
It has desirable properties but is inefficient. We used to think of
interpreted languages as desirable/inefficient but in the age of faster
processors, we have Lua and we are all the better off for it.

I agree. And I think it is a worthy subject for the round-table discussion at the workshop. A one number model goes well with the design of Lua's one native number type support. To make the discussion concrete some benchmark results could come in handy for the proponents and opponents. Hint, hint!!


Cheers
Vijay Aswadhati