Re: Arithmetic expression: interest in unsigned right shift?

[Martin D Kealey]

On Sun, 17 Jul 2022 at 17:01, Robert Elz <kre@munnari.oz.au> wrote:

> For just getting the word size, a better solution would be to request a
> new predefined variable (eg: BASH_ARITH_BITS) which contains the number
> of bits used for arithmetic.   Inventing new mechanisms so you can compute
> it dynamically is crazy - it will not change while bash is running.
>

Of course this isn't the sole purpose for introducing the >>> operator;
it's merely an illustration of how it might be useful.

And nor is this me "inventing a new mechanism" to compute MAXINT. It's been
a well-known technique since 2's complement became popular in the 1960's,
and is covered in any decent CS courses on assembler and/or compiler
optimization.

Obviously I wouldn't write (~0>>>1) everywhere I needed the value, that
would be crazy; I would write (( MAXINT = ~0 >>> 1 )) exactly once at the
top of any script that needs MAXINT.

Conversely, BASH_ARITH_BITS doesn't actually remove the need to write ((
MAXINT = ( 1 << BASH_ARITH_BITS - 1 ) - 1 )) which to my eyes looks less
readable than my version, on account of nesting binary operators 3 times as
deeply and being textually twice as long to boot.

Most of the rest of what you are suggesting doesn't belong in shell arith,
> you should be using a language suited to numeric computing (FORTRAN?)
> for most of that, not shell scripting.    Use the right tool for the job.
>

If "complicated maths" doesn't belong in a shell, then Bash stopped meeting
that definition of "a shell" some time last century when the
exponentiation, conditional, increment, and decrement operators were added.

What does or doesn't belong in a given class of language is, by now,
largely a matter of personal preference, born from experience in dealing
with problems. If anything, the last quarter of a century has been marked
by convergence between most of the popular languages; for all its sins, few
popular languages now deviate significantly from the expression syntax
established by C in the 1970's, except where necessary to accommodate other
changes. (In the case at hand, C decides whether to use signed or unsigned
shift depending on the static type of the left operand; Bash has no notion
of a "type", and so adding a >>> operator is a reasonable alternative.)

One doesn't have to be writing a ray-tracer or theorem prover to find uses
for better arithmetic in one's preferred interactive or "glue" language. We
are not considering classes of problems that take billions of arithmetic
operations to solve.

If the job at hand involves managing files, or gluing together other
programs, or providing an interactive command-line, then a shell is
definitely the right tool for the job. I rarely encounter a task that
doesn't involve at least *some* arithmetic, and so I *very strongly*
disagree with the notion that "arithmetic doesn't belong in the shell". IMO
not having decent arithmetic capabilities is frankly inexcusable in ANY
language.

I admit that suggesting complex numbers was whimsy, but they're far from
the hardest thing on my list - and nothing there is actually hard, though
some items may be large. Rather, the difficulty is in assessing the human
factors and choosing which path to take.

If a shell doesn't use floating point or bignums, and doesn't warn on
overflow, then its users will have to learn some fairly arcane rules to
have any hope of not being surprised by its behaviour. In my book that
ranks such a shell as *more* complicated than one that does use floating
point (or bignums).

Case in point: just a few days ago we had a bug report from someone
complaining that the exponentiation operator gave the wrong result, because
they didn't notice or didn't understand the caveat that all arithmetic is
modulo 2-to-the-power-of-some-number.

-Martin

PS: As an example of why I consider arithmetic built into the shell to be
indispensable, I wrote a menu-style tab completion function for Bash [
https://github.com/kurahaupo/zcomp], which has to draw a table with rows
and columns, all while tracking the cursor position. If I'd had to
implement that using external commands for arithmetic, it would have been
more error-prone to write, harder to debug, illegible to future maintainers
(including myself), and above all, noticeably less responsive to the user
(there can be thousands of arithmetic steps per keypress).