 |
lua-l archive |
|
|
||
|
I just think that math.tointeger and math.floor are in writing much
more cumbersome than //1.
I think "usual users" anyway do all things in float, I have no idea
why this should restrict you in any way to do calculations in Lua.
This warning that 123456789123456789*100000000 would possibly flip to
negative should be quite clear to any user insisting to use int's I
think... .
Though you are right somehow, if a user here just uses "int
representation by accident" (forgetting decimal point - a "simple Lua
user" of course might do this easily), it will be a really bad
surprise for such a user in this case... . But checking for this would
really slow down many things tremendously I am frightened (it would
not be sufficient to check the signs, in fact this would end up in
doing float AND int multiply and then use the int if they agree, and
the float if they disagree... ugghh... the same would apply for
int+int and int-int operations ... in assembly level you can somehow
solve this with checking overflow and carry bit after the int
operation... but as Lua requires c compiler and clearly should run
multi platform such assembly tricks of course are forbidden)... just
there are clear warnings in the Lua user manual concerning usage of
ints.
On Fri, Jan 7, 2022 at 3:46 PM Francisco Olarte <folarte@peoplecall.com> wrote:
>
> Hi:
>
> On Fri, 7 Jan 2022 at 10:49, Flyer31 Test <flyer31@googlemail.com> wrote:
> > There might appear a problem if the float is above int range, so e. g.
> > 1E40 // 1... in Lua32 or 1E80//1 in Lua64.
> >
> > But I think if somebody does this, its somehow "own fault" ...
> > handling int's anyway is somehow always "somehow a bit dangerous
> > concerning overflow issues", but I think this is somehow clear to any
> > user using int's. Usually int's are used for "speed or numerical
> > optimization", or for "bit operations witchcraft" ... and the users
> > who want this are somehow "aware of the risks", such users typically
> > clearly prefer speed against any "overflow security guarding".
>
> It will never occur to anyone using ints, 1E80 is not an int, it is a
> float, whose integer value is equal to itself and not representable in
> 64 bits.
>
> The problems you encounter only occur when people manage their numbers
> carelessly and store ints as floats. If you are working with ints, //
> works as expected and returns an int. People who work with ints would
> check before introducing data from a float into the pipeline (at least
> I do).
>
> //1 to produce an integer is not too useful, just do tointeger. If you
> are working with integers it works reasonably.
>
> The oddest thing, for me, is that in lua 8/3 is done as 8.0 / 3.0,
> while 8*3 is not, It's / which seems to be a martian, not //, but I'm
> used to it:
>
> > print(123456789123456789*100000000, 123456789123456789/100000000, 123456789123456789//100000000)
> -7473169249324075776 1234567891.2346 1234567891
>
> I just avoid doing calculations in Lua.
>
> Francisco Olarte.