Re: Lua workshop: call for backup presentations.

[Asko Kauppi <askok@...>]

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