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

[Flyer31 Test <flyer31@...>]

After thinking over night on this, and especially the remark of
Francisco concerning this sign flip in 123456789123456789 * 100000000
and that he does not like to do calculations in Lua "generally" I
would have the following remarks:

The adding of int numbers to Lua mainly has two purposes / advantages:
- allowing "bit arithmetics witchcraft", especially easy support of
bitwise and / or for masking / reading bits
- allowing number arithmetics with full integer 64 bit resolution
(resp. 32 bits in Lua32).

If I think further about the possible applications, I think the
clearly dominant thing here is the "bit witchcraft thing", as e. g.
typical netword TCIP addressing uses ints and alone for this of course
very important and widely spread appliction the suport of int is a
sort of "must" for a modern language - this clearly is needed I think
by an appreciable percentage of Lua software, clearly in the multi 10%
range... .

The "number arithmetics with full int resolution" I think compared to
this "bit witchcraft thing" is MUCH less important - it will be
important mainly for poeple who want to count timers or who want to
count encoder signals or so, but I cannot imagine that these would be
more than 1% of Lua users.

Supporting "int number arithmetics" in int style has this clear
disadvantage / risk of sign inversion in case of overflow. Just after
thinkiing a bit more about this and if I think especially about
non-experienced users, I think this sign inversion danger is a "crazy
danger" - clearly more than 50% of Lua users will hate any risk of
sign inversion in calculations terribly.

To come around this, I would finally dare to do the following quite
"deep change" in some future Lua version:
- use the standard arithmetic binary operators +, -, * , /, ^
EXCLUSIVELY in float number stlye (which means the both number
arguments are used in float rep, the float operation is used, and the
result ALWAYS float.with typical float overflow checking, so sign
inversion IMPOSSIBLE).
- use COMPLETELY NEW binary operators specifically for int: //, **, ++
(and of course >> and <<) EXCLUSIVELY in int number style (which means
both number arguments are converted to int rep, the int operation is
used and the result is ALWAYS int WITHOUT overflow checking, so sign
inversion POSSIBLE). (of course -- does NOT work, as it is used for
line comment already, but this is no real drawback: As I explained
above already I think less than 1% of Lua users will be interested in
int arithmetics //, **, ++, and those are then anyway people who know
very well about the possible dangers of int arithmetics, and they then
of course can write a++ -b  for int operation a-b.

This would be nice I think and very helpful... . Also speeding up the
binary operations, as in this case then no further result precautions
or lengthy argument checkings are necssary (except of course that
int's must be converted to floats for the standard arithmetics, and
floats must be converted to ints for the int arithmetics... but this
anyway needs to be done and can no be circumvented...).

By the way for "bit witchraft", it would be very nice if the math
library would support the VERY useful ARM commands clz and rbit  e. g.
math.clz and math.rbit (Count leading zeros and reverse bits). I know
that especially "good old Intel CPU''s" are lazy here and partly do
not support this, and still no standardized c/c++ coding available for
this - but these two are really VERY useful for bit representation
checking and if not available in a standardized way by basic software,
very nerving  and time consuming for loops are needed).

On Sat, Jan 8, 2022 at 12:00 AM Benjamin Riggs
<riggs@entropicengineering.com> wrote:
>
> I'm rather new to Lua (here because I'm embedding it in a hardware product), but I see that integers were introduced in Lua 5.3 (or omitted from the 5.2 manual) and, apparently with them, confusion about types. If someone has a link to a thread discussing the change, I'm curious to see the justifications for the added complexity.
>
> On Fri, Jan 7, 2022 at 12:06 PM Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:
>>
>> On Fri, Jan 7, 2022 at 11:01 AM Lorenzo Donati wrote:
>>>
>>> "// 1" producing an integer goes
>>> against the principle of least surprise
>>
>>
>> IMO, the least surprise here would be to treat // as a one-line comment  ;-)
>> After many years of programming in Pascal I failed to convince my brains that // might be an arithmetic operator.
>> People with a C background should feel the same :-)
>>
>
>
> --
> Benjamin Riggs
> Pronouns: He / Him
> Founder & CEO
> Entropic Engineering LLC
> 670 Transfer Rd
> St Paul, MN 55114
> (612) 284-1152 Ext. 8128
> https://entropicengineering.com