Re: Round table! (Re: Lua workshop: call for backup presentations.)

[Stefan Sandberg <keffo.sandberg@...>]

My camcorder is here and currently unused, I've been trying (almost by 
force) to get André Carregal to bring it!

(So everyone just start yelling at him at once!)


// Keffo.


Asko Kauppi wrote:
> ROUND TABLE! :)
>
> Seems we're at it, already?   Take the integer patch in there, too.  
> Merge the two issues, into "Number storage models in Lua" or something.
>
> We should be able to solve out a way, which allows compile-time number 
> processing schemes to be easily swapped, without actual patching of 
> the Lua internals. Many macros there are, are already pointing in this 
> direction (maybe intentionally?).
>
> I would _really_ like to have int32/64 patching merge with Lua, but 
> placing it within the core source as now may well be the wrong 
> approach. Would be better, to keep the arithmetic c files separate, 
> and let the core find them via configured macros.
>
> Getting too deep now, the Rest in Venlo.
>
> HEY: Someone please take a videocam; the round tables should be 
> available online, at least edited!  :)
>
> -asko
>
>
> Andy Stark kirjoitti 24.8.2006 kello 16.07:
>
> > Lua list <lua@bazar2.conectiva.com.br> on Thursday, August 24, 2006 at
> > 11:00 +0000 wrote:
> > > Since bignums are part of Common Lisp they deserve to be on the
> > > roadmap for Lua.  Don't see why we should be wedded to a radix 10
> > > implementation though.
> >
> > The main advantage of decimal arithmetic is that it behaves exactly like
> > paper arithmetic. If you do a sum like 0.99 + 0.01 you get exactly 1 as
> > the result instead of merely getting the result of adding the binary
> > approximations of 0.99 and 0.01. I think we would all save ourselves 
> > a few
> > bugs by adopting BCD, but it is of most value to non-professional
> > programmers who wouldn't easily understand why comparisons sometimes 
> > don't
> > work. (For "non-professionals", think about most users of VoodooPad,
> > Lightroom, games, etc). The ECMAScript 4 (ie, JavaScript 2.0) proposal
> > contains a recommendation to support decimal arithmetic, optionally 
> > as the
> > default numeric type:-
> >
> >     http://developer.mozilla.org/es4/proposals/decimal.html
> >
> > Brendan Eich gave a presentation about the future of JavaScript in May
> > 2006 where he claims that arithmetic inaccuracies are the most 
> > duplicated
> > bug in the Mozilla project:-
> >
> > (Go to page 38 at
> >     http://ajaxian.com/downloads/presentations/eich-ajax-experience-2006/ 
> >
> > )
> >
> > Also, as has already been mentioned, some financial software is legally
> > required to use decimal arithmetic to minimise the chance of fraud. The
> > quirky but clever old language of Rexx has always used decimal 
> > arithmetic
> > as its only numeric type and Python has recently added a decimal 
> > module to
> > its standard library.
> >
> > BCD can be converted to and from a decimal textual representation very
> > quickly and without error. This means that it is often actually faster
> > than binary for programs that do text processing but relatively little
> > arithmetic (think of, say, numeric attributes in an HTML-generating
> > script). Perhaps this might also slightly speed up the compilation of
> > source files written in Lua, but I'm not too sure about that.
> >
> > I think BCD feels like a natural Lua thing and in cases where it's not
> > efficient enough it's easy to replace it with floats or integers. And it
> > will give you something to talk about at the round table ;-)
> >
> > &.
> >
> >
> > ##################################################################################### 
> >
> > This e-mail message has been scanned for Viruses and Content and cleared
> > by MailMarshal.
> > The Blackpool Sixth Form College.
> > #####################################################################################