lua-users home
lua-l archive

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

I am by no means advocating a special integer divide operator, not required.

Let me make this clear: with LNUM patch, 12 and 12.0 are the _same_ number. They may be stored internally differently, but they equal in value, and they are the same table index as well. So basically, for such small numbers, one would not really be able to tell the difference.

Before 2008, I used to have LNUM patch always return FP results to an integer, if possible. This, however, slowed down _all_ FP operations slightly, and was never feeling 'right'. The current way does feel right for me, and I bet if someone just slid the feature into Lua, no one would even recognize it in the first year or two.. :)


On Tue, 25 Mar 2008 13:54:47 +0100
 "Grellier, Thierry" <> wrote:
	a= 12
b= 12/5 -- drops to FP realm ^^^ could also have 12\5 not to drop to FP realm or well come back to integer realm (x\1)?
            Well what to do with 12.4\2.1 ?
Or can we assert that \ only works for integer realm,
            So would bitwise operators?

-----Original Message-----
[] On Behalf Of Asko Kauppi
Sent: Tuesday, March 25, 2008 11:45 AM
To: Lua list
Subject: Re: At the edge of LNUM patch

Personally, I don't think it's any worse than the current (unpatched Lua, doubles):

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

Is it?  :)

This only happens when integer arithmetics exceeds its natural boundaries (instead of overflow to negative integers).

The need for the patch "everywhere" is mainly a simplicity issue. What I know Roberto would dislike is a lot of ifdef's, and having int32/64 mode always there takes some of these away. I do think the boundary issues will need a few lines somewhere in the manual. But that's all; to me the benefits do outweight those few lines.

Numbers provided as integers are treated with signed integer accuracy. If mathematical results fall into floating point, the values will remain in 'floating point realm' unless they're explicitly taken back by 'tonumber(x)'.

	a= 12
	b= 12/5		-- drops to FP realm
	c= b*5		-- 12.0 (FP realm)
	d= tonumber(b*5)	-- 12 (integer realm)

One needs to care about number accuracy only at the edges of integer realm. Otherwise, numbers work just the same whether they are internally stored as integers (12) or floating point values (12.0).

Something like that..


Alex Davies kirjoitti 25.3.2008 kello 11:39:
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