Re: math operations with base#prefix

[Kerin Millar]

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"

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")

I explained in my initial post that the sigils are required because "res1" and 
"res2" will otherwise be treated as integer values that (in this case) happen 
not to be within the scope of the specified base. Victor did not respond to 
this post but responded to a subsequent post by Chet, opining that $ should be 
"optional" regardless. That is the point at which I concluded that the matter 
had not been thought through.

Anyway, thank you for the additional commentary.

-- 
Kerin Millar