Re: math operations with base#prefix

[alex xmb ratchev]

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

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
>