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

[Flyer31 Test <flyer31@...>]

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.