Re: math operations with base#prefix

[Kerin Millar]

On Tue, 19 Sep 2023 21:29:32 +0200
alex xmb ratchev <fxmbsw7@gmail.com> wrote:

> On Tue, Sep 19, 2023, 21:14 Kerin Millar <kfm@plushkava.net> wrote:
> 
> > On Wed, 20 Sep 2023 01:41:30 +0700
> > Robert Elz <kre@munnari.OZ.AU> wrote:
> >
> > >     Date:        Tue, 19 Sep 2023 18:09:13 +0100
> > >     From:        Kerin Millar <kfm@plushkava.net>
> > >     Message-ID:  <20230919180913.bd90c16b908ab7966888fa08@plushkava.net>
> > >
> > >   | >   | On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote:
> > >   | >   | > in let "<>" and $((<>)) constructs all variables should be
> > >   | >   | > evaluated
> > >
> > >   | This assertion would be more compelling had you explained at some
> > point
> > >   | during the ensuing treatise how to potentially square the request
> > being
> > >   | made with the base#n notation, as presently implemented by bash.
> > >
> > > I didn't even consider that case plausible, or what was intended, but now
> > > I can see that maybe it was - but that could never work.  Not (quite) for
> > > the reason that you gave (or even Chet's explanation, though if he had
> > > explained why it is like it is, the explanation might have been like I
> > > am about to give), but because the syntax simply doesn't work out like
> > that.
> > >
> > > Given a token of x#y that's not a variable, variables have no #'s in
> > their
> > > names, so one cannot be expecting that (this would mean something
> > entirely
> > > different if actually written) ${x#y} to be evaluated in that case.
> > >
> > > So, the only way to get variables out of that would be to split it into
> > > two (or three) tokens, x and #y or x # and y.   One might parse it like
> > > that, and then evaluate x and y as variables, but if that were done, now
> > > we'd have 3 tokens, not the one (representing a number in some other
> > base)
> > > to deal with, say 11 # 97 (where the 11 and 97 are now integers, not
> > strings).
> > >
> > > That's not what was desired, which was 11#97 as one token (106 decimal,
> > if
> > > my mental arithmetic is correct), and the only way to get it back would
> > be
> > > to invent a new (very high priority, must be higher than unary '-' for
> > > example) # operator, which takes a base as its left operand, and a value
> > > as its right, and somehow reinterprets the value in that base - but
> > that's
> > > essentially impossible, as we now have binary 97, which might have
> > originally
> > > been 0141 or 0x61 -   11#0141 is an entirely different thing from 11#97
> > > and at this stage we simply wouldn't know which was intended.
> > >
> > > So that method can't work either.
> > >
> > > The $x#$y form works, as that (everything in $(( )) or other similar
> > > contexts) is being treated just like inside a double quoted string.
> > > Those get expanded first before being used, in this case as 11#97 (just
> > > as strings, variable expansion has no idea of the context, nor does it
> > > generally care what characters it produces) as a char sequence in the
> > > effectively double quoted string.   The arith parser can then parse that,
> > > and see it has a specific base, and value - if y had been 0141 it would
> > have
> > > been parsing 11#0141 instead, unlike a simple reference of 'y' in the
> > > expression, where all of 0x61 97 and 0141 turn into the binary value "97"
> > > for arithmetic to operate on).
> > >
> > > That's why I never even considered that might have been what was being
> > > requested, it can't work as hoped.
> >
> > It is exactly the nature of the request. I don't know whether you looked
> > at Victor's "bug.bash" script. To recap, it contains a number of arithmetic
> > expressions, beginning with "res = res1 + res2 * 3" (clearly understanding
> > it to be fine). Ultimately, the script solicited a response concerning two
> > particular situations. Firstly, this.
> >
> >   let "res = base10#$res1 + base10#$res2 * 3"
> >
> 
> me to get into the mails topic ..
> .. what are res1 and res2 values

It really doesn't matter (see below).

> 
> Rightly dismissed as invalid syntax so there is nothing more to be said for
> > that.
> >
> > Secondly, this.
> >
> >   # without $-signs before both res
> >   let "res = 10#res1 + 3 * 10#res2"  # let: res = 10#res1: value too great
> > for base (error token is "10#res1")

This is what matters. The implied complaint is that the $ symbols have to be 
there and that they should somehow be optional. In other words, Victor wants 
for "res = 10#res1 + 10#res2" to be able to consider res1 and res2 as 
(variable) identifiers instead of integer constants. Both "res1" and "res2" are 
perfectly valid integer constants for bases between 29 and 64.

$ echo $(( 29#res1 )) $(( 29#res2 ))
671090 671091

That is why bash correctly complains that the value is too great for the base 
of 10. It doesn't matter whether res1 or res2 exist as variables, whether they 
are set or what their values are. The n in base#n notation is always taken as a 
number, so the only way to have n be the value of a variable is to expand it.

-- 
Kerin Millar