On Sun, 17 Jul 2022 at 17:01, Robert Elz <k...@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).
