Re: Wishful request for next version: '// 1' should produce integer

[Flyer31 Test <flyer31@...>]

PS: But instead 2.5//0.1 (or let's more generally discuss the example
2.5//0.2 maybe), you could as well write (2.5/0.2)//1 ... .

Just if many users used such writing 2.5//0.2 so far, then maybe
better do not touch this (never change a running system :)).

On Fri, Jan 7, 2022 at 10:54 AM Flyer31 Test <flyer31@googlemail.com> wrote:
>
> The possibility of 2.5//0.1 is really a surprise to me - sorry, I did
> not think about this application yet.
>
> if this produces the same as 25//1 then of course it will be a bit
> difficult to change such behaviour in future versions I must admit ...
> this really might be useful for some people (as you wrote it for your
> example).
>
> On Fri, Jan 7, 2022 at 9:55 AM Francisco Olarte <folarte@peoplecall.com> wrote:
> >
> > Hi, just my 2¢...
> >
> > On Fri, 7 Jan 2022 at 09:00, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
> > > On 03/01/2022 19:28, Flyer31 Test wrote:
> > > > 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.
> >
> > For th OP:
> > In general float-op-any and any-op-float produce floats, in Lua and in
> > all languages.
> > After all 2.0+1 produces a float too.
> > And // is not an integer division, "Floor division (//) is a division
> > that rounds the quotient towards minus infinity, resulting in the
> > floor of the division of its operands. "
> > ....
> > > 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.
> >
> > This I agree. Although I could tolerate it being optimized away.
> >
> > > 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.
> >
> > Bear in mind // can operate correctly in numbers not representable as
> > integer, i.e.
> >
> > > 1E60//1
> > 1e+60
> >
> > If I want an integer, I would use will use math.tointeger and deal
> > with overflow stuff. math.floor, suggested by OP, is underdocumented
> > but it seems very dangerous to use, except for display purposes, as it
> > varies its return type:
> > > math.floor(1E60)
> > 1e+60
> > > math.floor(1.0)
> > 1
> >
> > I think special casing // will lead to much more confusion than there
> > is now. Specially if you consider you will have to define it not only
> > for the 2.5//1 case, but also for the 1//2.5, 1.0//2.5, 2.5//0.1 and
> > similar stuff, and it will have some new failure modes and corner
> > cases, like 1E70//1E60 or 1E-60//1E-70.
> >
> > BTW, the 2.5//0.1 I've been using it as graph_intervals = data_range
> > // tick_width +1 and similar stuff.
> >
> > Mixed arithmetic is complex, the "use integer if both are integer,
> > float otherwise" way is easy to understand. Lua can still surprise you
> > with things like
> >
> > > 123456789123456789.*100000000
> > 1.2345678912346e+25
> > > 123456789123456789*100000000
> > -7473169249324075776
> > > 12345678912345678900000000
> > 1.2345678912346e+25
> >
> > But this are few and less.
> >
> > Francisco Olarte.