Re: math operations with base#prefix

[alex xmb ratchev]

On Tue, Sep 19, 2023, 22:08 alex xmb ratchev <fxmbsw7@gmail.com> wrote:

>
>
> On Tue, Sep 19, 2023, 21:54 Kerin Millar <kfm@plushkava.net> wrote:
>
>> 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")
>>
>
> so u mean a $ sign requirement ?
> i didnt get the base values , i tried simple one
> i faced the ' without $ it doesnt work '
>
> 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
>
>
> optional as in make default values in if empty ?
>
> ~ $ b1=29 b2=39 a1=29 a2=29 c1=$[ b1 ? b1 : 10 ] c2=$[ b2 ? b2 : 10 ] t1="
> $a1#$c1 * $a2#$c1 " r1=$[ t ] ; echo $r1
> 4489
>

can i lightly suggest once more bash to use bignum libs

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