Best Practices for Lua -> "Lua+"?

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Best Practices for Lua -> "Lua+"?

Adrian Perez-4
Hello, long time lurker first time poster

There seem to be a lot of developers out there using Lua as a configuration/extension scripting language for use in realtime applications like games.  We've been evaluating a bunch of languages and Lua has been beating all of them in terms of size, simplicity and execution speed.

In a production environment no language could ever be completely sufficient 'out of the box', and thus the language will need to be manipulated in possibly significant ways.  Examples of these sorts of changes:

* Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)
* Seperating LuaNumber into ints/floats for range/performance reasons
* Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)
* Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)
* Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)
* Adding compile-time replacement of enumerations/flags known in the C/C++ codebase
* Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)

The act of extending lua to a particular "lua+" specific to an application or environment can happen in a bunch of ways and seems to be vital to managing the interaction between script and the rest of the application.  I suspect most of this is done by directly manipulating the language internals.  This approach gives you the most flexibility but ties you pretty tightly to a specific distribution (which is not a huge problem in a short term production environment).  There are some interesting tools like MetaLua that allow you to "script" your language extensions, or you can just pre-process the lua script with another lua script before compilation (there are some good examples on the wiki talking about this).

Does anyone have information they could share about their adventures extending the language?

Thanks,

Adrian


Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Alexander Gladysh
My humble opinions on your list:

>  * Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)

Never. Evil. Non-programmers are not qualified (by definition) to
affect decisions with such heavy consequences.

>  * Seperating LuaNumber into ints/floats for range/performance reasons

Never. Not on embedded platform.

>  * Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)

Never. Evil. Lua is NOT C/C++. The less things would remind of C/C++
the better code would be written.

>  * Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)

Hmm. I remember a recent post on this subject... Can't remember details though.

>  * Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)

LuaJIT?

>  * Adding compile-time replacement of enumerations/flags known in the C/C++ codebase

Doubtful. Only as a last resort to increase performance. Caching in
local variables / upvalues is benefical.

>  * Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)

Thought about it, never had enough time. Still have to try to switch
to some non-default allocator for whole Lua. :-)

So, the bottom line. I'm a conservative PC developer (with respect to
changing the core language at least), and neither my 50KLOC+ of Lua
code for current project (yep, it grows) nor any of my previous ones
have not (yet) reached the point where I would have to optimize it
*that much*.

However, I "adjusted" Lua in two ways:

1. Compiled everything as C++ to simplify writing bindings. (My
project is in C++.) Not a core change, since it is supported by
luaconf.h. However next time I would probably not do that -- I have
enough problems with switching to LuaJIT now (looks like they're on my
side though, still have to investigate that).

2. Added run-time global protection a-la etc/strict.lua, but enforcing
explicit declaration of each global. Not a core change, because done
by the means of the language. Still, I miss an offline validator
(never had time to write one for my specific case -- yes the lack of
time is my problem). But I believe this is not a feature to be built
in the core, but rather a feature for some lint tool.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Asko Kauppi
In reply to this post by Adrian Perez-4

Hi, Adrian.  Nice seeing you back online!

I have a lot to share about my experiences involving development of luaSub. To me, it seems the road is clear and any Lua+ can now be easily crafted, by anyone. There won't be one, but rather a "cloud" of Lua+'s, like dialects of the same natural language.

I like your pragmatic approach on this; no solution should be done just for itself, but as a means to fill existing real needs. Very little of this actually requires current Lua 5.1.3 to be changed.

The two places where I would see change (in Lua proper) to be necessary are:

- lua_Number management

LNUM patch does this, giving existing 'lua_Integer' a more full bodied position next to its cousin 'lua_Number'. In a way that is 100% compatible with existing Lua API and scripts.

- family aware enums

This cannot be efficiently done with current Lua.

Ideally, I would like to see 'tolua' come bundled with Lua itself, since it seems to follow the same minimalistic design goals that Lua has. In my opinion, it could be seen as "the" interfacing tool that's one tier above Lua/C API. And then family aware enums would naturally be handled (automatically) by tolua.

As to most other issues you've presented, luaSub is my answer to the customization needs without patching. Like MetaLua, only it tries to be closer to the existing 'lua' command line tool (now 'luas', with two new flags -s and -o).

Some of the issues you raise raise my eyebrows:

* Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)

Really?  :)

* Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)

Why would this need anything in the language itself? Please shed more light.

* Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)

luaSub can be used for this, though such a mod hasn't been implemented by me. I'd just use "local _math_xxx" etc. instead of "math.xxx" Would be transparent to the scripts.

* Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)

This was discussed on the list recently, and I don't remember a clear solution having surfaced.

All in all, I very much welcome people to join use and tuning of luaSub. I'll be in charge of the C code if bugs are found. Using it is a piece of cake, and gives Lua the + you are requesting. :)

-asko




Adrian Perez kirjoitti 21.3.2008 kello 23:48:
Hello, long time lurker first time poster

There seem to be a lot of developers out there using Lua as a configuration/extension scripting language for use in realtime applications like games. We've been evaluating a bunch of languages and Lua has been beating all of them in terms of size, simplicity and execution speed.

In a production environment no language could ever be completely sufficient 'out of the box', and thus the language will need to be manipulated in possibly significant ways. Examples of these sorts of changes:

* Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)

* Seperating LuaNumber into ints/floats for range/performance reasons


* Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)


* Adding automatic support for index-based "string identifiers" (used to localize strings, refer to specific animations, etc)


* Adding compile-time expansion of known types (so rather than a table search for a known interface function you'd inject a constant offset into a function array)


* Adding compile-time replacement of enumerations/flags known in the C/C++ codebase


* Adding a specific allocation/management pattern for single-frame temporaries (like intermediate results in vector math calculations)

The act of extending lua to a particular "lua+" specific to an application or environment can happen in a bunch of ways and seems to be vital to managing the interaction between script and the rest of the application. I suspect most of this is done by directly manipulating the language internals. This approach gives you the most flexibility but ties you pretty tightly to a specific distribution (which is not a huge problem in a short term production environment). There are some interesting tools like MetaLua that allow you to "script" your language extensions, or you can just pre- process the lua script with another lua script before compilation (there are some good examples on the wiki talking about this).



Does anyone have information they could share about their adventures extending the language?

Thanks,

Adrian


Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Asko Kauppi
In reply to this post by Alexander Gladysh

* Seperating LuaNumber into ints/floats for range/performance reasons

Never. Not on embedded platform.

Why do you oppose this?

It must be a misunderstanding, there is no downside that I can see. I don't think Adrian meant different Lua side number types (not required).

-asko



Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Miles Bader-2
In reply to this post by Adrian Perez-4
Adrian Perez <[hidden email]> writes:
> * Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)
> * Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)

I think sometimes you need to learn when to say "no"...

[People will gripe about _anything_ which is the slightest bit different
than what they used before -- but they'll stop soon enough if the new
behavior is reasonable.  And Lua's syntax is most certainly very
reasonable.]

-Miles

-- 
Quotation, n. The act of repeating erroneously the words of another. The words
erroneously repeated.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

steve donovan
Yes, it isn't that difficult to make Lua look like another language,
but the difficulty comes when people expect the same semantics ;)
Easy to 'skin' Lua to look like JavaScript, but boy, it will bite
people who are expecting the same forgiving number-string
autoconversions.

It is IMHO a good idea that scripting languages keep distinct syntax
so that users know that this is a different animal.

Besides, I can't ever see why someone would miss '&&' !

steve d.

On 3/23/08, Miles Bader <[hidden email]> wrote:
>  > * Extending the language syntax for non-programmers (who may be in love with Python's whitespace behavior)
>
> > * Extending the language syntax for C/C++ programmers (who may be very deeply attached to +=/++/!=)

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Miles Bader
"steve donovan" <[hidden email]> writes:
> Yes, it isn't that difficult to make Lua look like another language,
> but the difficulty comes when people expect the same semantics ;)
> Easy to 'skin' Lua to look like JavaScript, but boy, it will bite
> people who are expecting the same forgiving number-string
> autoconversions.

Just a side note, but please don't edit the quotes so that it looks like
I was advocating such awful changes... :-/

[Especially the bit about whitespace -- I think python is a horrid
language syntactically; the idea of making Lua look like it makes me
shudder....]

-Miles

-- 
Cynic, n. A blackguard whose faulty vision sees things as they are, not as
they ought to be. Hence the custom among the Scythians of plucking out a
cynic's eyes to improve his vision.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Alexander Gladysh
In reply to this post by Asko Kauppi
>  >> * Seperating LuaNumber into ints/floats for range/performance reasons
>  >
>  > Never. Not on embedded platform.
>
>  Why do you oppose this?
>
>  It must be a misunderstanding, there is no downside that I can see.  I
>  don't think Adrian meant different Lua side number types (not required).

Hmm. Sorry, I should have been more elaborate and less rough on that
point. I mean that I never done that because I'm not developing for
FPU-less platform, and have not (yet?) met conditions where I would
believe that my code would *significantly* benefit from such change.
Am I right that we're talking about something like applying LNUM
patch?

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Asko Kauppi

Yes, LNUM patch is at the moment The way to optimize Lua integer performance.

I have yet to hear what Lua authors think of the latest version, but it would seem to me to be beneficial for the whole language to include the patch (or: parts of it).

The current version does not slow down FP platforms. In places, it simplifies the Lua code internally. It has been extensively tested and it comes with a test suite to make sure changes wouldn't break anything.

-asko


Alexander Gladysh kirjoitti 24.3.2008 kello 12:42:
* Seperating LuaNumber into ints/floats for range/performance reasons

Never. Not on embedded platform.

Why do you oppose this?

It must be a misunderstanding, there is no downside that I can see. I don't think Adrian meant different Lua side number types (not required).

Hmm. Sorry, I should have been more elaborate and less rough on that
point. I mean that I never done that because I'm not developing for
FPU-less platform, and have not (yet?) met conditions where I would
believe that my code would *significantly* benefit from such change.
Am I right that we're talking about something like applying LNUM
patch?

Alexander.


Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Alexander Gladysh
On Mon, Mar 24, 2008 at 2:09 PM, Asko Kauppi <[hidden email]> wrote:
>  Yes, LNUM patch is at the moment The way to optimize Lua integer
>  performance.
>
>  I have yet to hear what Lua authors think of the latest version, but
>  it would seem to me to be beneficial for the whole language to include
>  the patch (or: parts of it).
>
>  The current version does not slow down FP platforms. In places, it
>  simplifies the Lua code internally. It has been extensively tested and
>  it comes with a test suite to make sure changes wouldn't break anything.

Good. Then I'll clarify my reply to the OP question on changing core Lua:

> >>>> * Seperating LuaNumber into ints/floats for range/performance
>  >>>> reasons

1. I have no pressing reason to do that right now.
2. However, as I see from performance charts that it would most likely
benefit my code, I'd like to have it in the core language.
3. Speaking about LNUM patch specifically, I would not apply it unless
I have to -- I'm too conservative, and prefer to have unpatched albeit
somewhat slower Lua.

BTW, is LNUM patch compatible with LuaJIT? Is it needed with LuaJIT at
all? When I would have to divert from pure unmodified Lua for
performance reasons, I'll give LuaJIT a try first -- as it seems to
have greater potential in performance gain. While I have no resources
to invest into this switch yet, I eagerly anticipate it.

Obviously, having faster core language would only delay such switch,
and such switch would only delay heavy algorithmic optimization -- but
both delays may be significant.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Alexander Gladysh
In reply to this post by steve donovan
On Mon, Mar 24, 2008 at 12:38 PM, steve donovan
<[hidden email]> wrote:
> Yes, it isn't that difficult to make Lua look like another language,
>  but the difficulty comes when people expect the same semantics ;)
>  Easy to 'skin' Lua to look like JavaScript, but boy, it will bite
>  people who are expecting the same forgiving number-string
>  autoconversions.
>
>  It is IMHO a good idea that scripting languages keep distinct syntax
>  so that users know that this is a different animal.

Very good idea indeed. I personally always stumble things like on !=
vs ~= and on if (...) vs if ...then differences. But that stumble
allows my mind to do a context switch and to start thinking in Lua
after coding in C++ and vice versa. Such context switch allows both
(quite different!) programming paradigms to coexist in my mind.

If both languages would look identically, I guess, I'd be very
frustated trying to wrap my head around paradigm differences.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Asko Kauppi
In reply to this post by Alexander Gladysh

LuaJIT is certainly the way to try to optimize Lua speed as a whole. But LuaJIT is currently limited to certain platforms (x86 32-bit only?), whereas LNUM patch gives benefits on most platforms, and embedded platforms especially. I'd say they are alternative approaches.

-asko


Alexander Gladysh kirjoitti 24.3.2008 kello 13:36:
On Mon, Mar 24, 2008 at 2:09 PM, Asko Kauppi <[hidden email]> wrote:
Yes, LNUM patch is at the moment The way to optimize Lua integer
performance.

I have yet to hear what Lua authors think of the latest version, but
it would seem to me to be beneficial for the whole language to include
the patch (or: parts of it).

The current version does not slow down FP platforms. In places, it
simplifies the Lua code internally. It has been extensively tested and it comes with a test suite to make sure changes wouldn't break anything.

Good. Then I'll clarify my reply to the OP question on changing core Lua:

* Seperating LuaNumber into ints/floats for range/performance
reasons

1. I have no pressing reason to do that right now.
2. However, as I see from performance charts that it would most likely
benefit my code, I'd like to have it in the core language.
3. Speaking about LNUM patch specifically, I would not apply it unless
I have to -- I'm too conservative, and prefer to have unpatched albeit
somewhat slower Lua.

BTW, is LNUM patch compatible with LuaJIT? Is it needed with LuaJIT at
all? When I would have to divert from pure unmodified Lua for
performance reasons, I'll give LuaJIT a try first -- as it seems to
have greater potential in performance gain. While I have no resources
to invest into this switch yet, I eagerly anticipate it.

Obviously, having faster core language would only delay such switch,
and such switch would only delay heavy algorithmic optimization -- but
both delays may be significant.

Alexander.


Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Asko Kauppi
In reply to this post by Alexander Gladysh

Alexander Gladysh kirjoitti 24.3.2008 kello 13:42:
On Mon, Mar 24, 2008 at 12:38 PM, steve donovan
<[hidden email]> wrote:
Yes, it isn't that difficult to make Lua look like another language,
but the difficulty comes when people expect the same semantics ;)
Easy to 'skin' Lua to look like JavaScript, but boy, it will bite
people who are expecting the same forgiving number-string
autoconversions.

It is IMHO a good idea that scripting languages keep distinct syntax
so that users know that this is a different animal.

Very good idea indeed. I personally always stumble things like on !=
vs ~= and on if (...) vs if ...then differences. But that stumble
allows my mind to do a context switch and to start thinking in Lua
after coding in C++ and vice versa. Such context switch allows both
(quite different!) programming paradigms to coexist in my mind.

If both languages would look identically, I guess, I'd be very
frustated trying to wrap my head around paradigm differences.

Alexander.

You're right. One language I've never found myself liking, maybe exactly for this reason, is Objective-C. I can read it, even write it, but since the context changes happen line wise within the source code, it's too double minded. At least to me.

To those not familiar with Objective-C, it tries to marry C and Smalltalk within the same source files. One has strict types; the other dynamic. Like embedding your Lua code within C sources, line by line.

-asko

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Roberto Ierusalimschy
In reply to this post by Asko Kauppi
> Yes, LNUM patch is at the moment The way to optimize Lua integer 
> performance.
>
> I have yet to hear what Lua authors think of the latest version, but it 
> would seem to me to be beneficial for the whole language to include the 
> patch (or: parts of it).

The patch is quite useful, but I am still not comfortable with the idea
of two kinds of numbers. The problem is that, although the difference is
mostly invisible, it is not completely invisible. For instance, consider
the following fragment (ran under (double int64)):

  y = 1
  for i=1,60 do y=y*2 end
  x = (y*1000)/1000
  print(x == y, x+1 == y+1)   --> true    false


I know this is a rather artificial example, but I find the result somewhat
unsettling.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Mark Hamburg-4
on 3/24/08 3:23 PM, Roberto Ierusalimschy at [hidden email] wrote:

>> Yes, LNUM patch is at the moment The way to optimize Lua integer
>> performance.
>> 
>> I have yet to hear what Lua authors think of the latest version, but it
>> would seem to me to be beneficial for the whole language to include the
>> patch (or: parts of it).
> 
> The patch is quite useful, but I am still not comfortable with the idea
> of two kinds of numbers. The problem is that, although the difference is
> mostly invisible, it is not completely invisible. For instance, consider
> the following fragment (ran under (double int64)):
> 
>   y = 1
>   for i=1,60 do y=y*2 end
>   x = (y*1000)/1000
>   print(x == y, x+1 == y+1)   --> true    false
> 
> 
> I know this is a rather artificial example, but I find the result somewhat
> unsettling.

I think the only way this becomes viable is if integers are just a more
"efficient" storage format for floating point values.

Mark



Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

Irayo
Mark Hamburg wrote:
I know this is a rather artificial example, but I find the result somewhat
unsettling.

I think the only way this becomes viable is if integers are just a more
"efficient" storage format for floating point values.

Mark

Yes, and the people who are going to be using the LNUM patch and programming for the embedded systems for which it is most useful (for speed and storage reasons; 'efficiency') will probably be experienced enough to avoid possible errors arising from the conversions.

If you're developing using an LNUM-patched Lua, it'd be a good idea to always test your code under unmodified Lua as well as the LNUM-patched version to make sure there are no discrepancies in the results. Test suites, although extensive, can only go so far, and there are bound to be specific cases (as Roberto showed) that can escape the otherwise passive change. Testing your own code in both number systems is the most thorough way to identify any bugs that are caused by it.

--
Irayo


Reply | Threaded
Open this post in threaded view
|

Re: Best Practices for Lua -> "Lua+"?

steve donovan
In reply to this post by Miles Bader
My apologies if it appeared that a sensible person like you would want
such things. It is my compulsive refactoring gene kicking in again.

steve d.

On Mon, Mar 24, 2008 at 12:32 PM, Miles Bader <[hidden email]> wrote:
> "steve donovan" <[hidden email]> writes:
>  > Yes, it isn't that difficult to make Lua look like another language,
>  > but the difficulty comes when people expect the same semantics ;)
>  > Easy to 'skin' Lua to look like JavaScript, but boy, it will bite
>  > people who are expecting the same forgiving number-string
>  > autoconversions.
>
>  Just a side note, but please don't edit the quotes so that it looks like
>  I was advocating such awful changes... :-/
>
>  [Especially the bit about whitespace -- I think python is a horrid
>  language syntactically; the idea of making Lua look like it makes me
>  shudder....]
>
>  -Miles
>
>  --
>  Cynic, n. A blackguard whose faulty vision sees things as they are, not as
>  they ought to be. Hence the custom among the Scythians of plucking out a
>  cynic's eyes to improve his vision.
>

Reply | Threaded
Open this post in threaded view
|

At the edge of LNUM patch

Asko Kauppi
In reply to this post by Roberto Ierusalimschy

The example is good, and it shows the "graceful" decent from integer realm to floating point realm.

My reasoning for "100% backwards complience" on this patch is that it only affects accuracy of calculations, and never makes it worse than unpatched Lua is.

Let's see through the steps below (double int64):

> y=1
> for i=1,60 do y=y*2 end
> print(y)
1152921504606846976

This number is <= 2^63-1 so it's stored with full accuracy as int64.

> x= (y*1000)/1000
> print(x)
1.1529215046068e+18

The *1000 takes the number off the int64 range, into floating point realm.

Such a "step down" most likely loses some accuracy, and also numbers fallen to FP realm will stay there for future calculations.

This is why the last line behaves the way it does: in this particular case int64->double conversion lost no accuracy, and x==y although one is FP and the other is int64. In places where the programmer _knows_ "lifting" back to integer realm is necessary, they should do a 'tonumber()' that lifts the number back into integer realm.

> print( x==y, x+1 == y+1 )
true	false

'x' was in FP realm (x+1==x), 'y' was in int64 realm.

But:

> x= tonumber(x)
> print(x)
1152921504606846976
> print( x==y, x+1 == y+1 )
true	true

It is true that this is a corner case where use of the patch can be detected by applications. Even then, the logic is in my opinion easy to follow, and the reasons behind this behaviour (not slowing down each FP operation) are imho solid. Note that earlier LNUM (<2008) used to lift results automatically back to integer realm, but this called for _each_ FP operation to be checked separately, which slowed FP ops by some percentage. I think the current way is better, since most calculations in practise are either happening in integer realm, or FP realm.

-asko


Roberto Ierusalimschy kirjoitti 25.3.2008 kello 0:23:
Yes, LNUM patch is at the moment The way to optimize Lua integer
performance.

I have yet to hear what Lua authors think of the latest version, but it would seem to me to be beneficial for the whole language to include the
patch (or: parts of it).

The patch is quite useful, but I am still not comfortable with the idea of two kinds of numbers. The problem is that, although the difference is mostly invisible, it is not completely invisible. For instance, consider
the following fragment (ran under (double int64)):

y = 1
for i=1,60 do y=y*2 end
x = (y*1000)/1000
print(x == y, x+1 == y+1)   --> true    false


I know this is a rather artificial example, but I find the result somewhat
unsettling.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: At the edge of LNUM patch

Alex Davies
I'm pretty sure Roberto understands -why- it's happening, it's just a question of whether:

assert(x == y) -- passes
assert(x+1 == y+1) -- fails

is acceptable. Because it is impossible to tell from within lua if x and y are different types internally or not, and in the case they are, they'll perform differently to if they're not. Could cause problems with scientific calculations - remember that the pentiums (in)famous FDIV bug would have never been a problem outside of these kind of applications.

Granted, it's a rare occurence. But it's a gotcha that would be, as far as I can tell, unique to Lua. And lets not forget that 64 bit arithmetic on x86 is hardly faster then floating point ops, meaning that this extra precision (which is only sometimes available) is the only gain from the patch.

Personally though I think the patch is essential processors without FPUs, or when using single precision floats (mantissa isn't wide enough), but I don't understand the need for it elsewhere... although that's probably just me.

- Alex
Reply | Threaded
Open this post in threaded view
|

Re: At the edge of LNUM patch

Klaus Ripke
On Tue, Mar 25, 2008 at 06:39:17PM +0900, Alex Davies wrote:
> I'm pretty sure Roberto understands -why- it's happening, it's just a 
> question of whether:
> 
> assert(x == y) -- passes
> assert(x+1 == y+1) -- fails
> 
> is acceptable.

One has to live with all kinds of weird things
even when using standard FP alone.

Let x be  FP number with x~=x+1, but y==y+1 for y=x+1. Then
assert(x+1==y+1) -- passes
assert(x==y) -- fails


cheers

123