lua-users home
lua-l archive

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

Thank you for support.

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".

On Fri, Jan 7, 2022 at 9:00 AM Lorenzo Donati
<> wrote:
> On 03/01/2022 19:28, Flyer31 Test wrote:
> > Hi,
> > if in some furture version integer division // 1 would produce integer
> > result, this would be very nice.
> >
> > Now only int // int produces integer, but float // int produces float,
> > which somehow is a bit "ugly" for the result of an integer division.
> >
> > (I can of course write math.floor(2.5) instead of 2.5//1, but I
> > somehow would like the second writing much more...).
> >
> Mmm, funnily I never noticed this.
> I'm an old timer (since Lua 5.1) user, and although I welcomed the new
> operators in Lua 5.3, I never used // much.
> I really wonder why // produces a float at all. It would make sense to
> always produce an integer.
> Just having the oddball case of just "// 1" producing an integer goes
> against the principle of least surprise and probably could slow things
> down: every time the engine needed to perform // it would have to check
> whether or not to convert its result according to its 2nd operand.
> I'd rather prefer to change the semantics of // to always return an
> integer, unless someone convince me the current behavior is more useful.
> After all if you write "//" you probably want an integer, not a float
> with integer value.
> Cheers!
> -- Lorenzo