Re: math operations with base#prefix

[Kerin Millar]

On Mon, 18 Sep 2023 04:56:18 +0200
alex xmb ratchev <fxmbsw7@gmail.com> wrote:

> On Mon, Sep 18, 2023, 04:03 Kerin Millar <kfm@plushkava.net> wrote:
> 
> > Hi Victor,
> >
> > On Sun, 17 Sep 2023, at 8:59 PM, Victor Pasko wrote:
> > > Hi,
> > >
> > > Could you please take a look at attached bug.bash.
> > >
> > > Maybe, not all math combinations were presented there or the test has
> > > duplications somehow.
> > > Here are results of several runs with test# as argument
> > >
> > >
> > > *% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)
> > >
> > > Good test without argument but others with errors :(
> > > *% ./bug.bash*
> > >
> > > res1=010 good 010 base8
> > > res2=03 good 03 base8
> > > res=17 good result 17 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > res1=8 good result 8 base10
> > > res1=10 good result 10
> > > res1=10 good result 10
> > > res1=010 good result 010 base8
> > > base10-res1=10 good result 10
> > > res1=16 good result 16
> > >
> > >
> > > *% ./bug.bash 1*
> > > TESTCASE=1
> > > res1=010 good 010 base8
> > > res2=03 good 03 base8
> > > res=17 good result 17 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > ./bug.bash: line 29: let: res = base10#010 + base10#03 * 3: syntax error:
> > > invalid arithmetic operator (error token is "#010 + base10#03 * 3")
> >
> > This seems like a misinterpretation of the manual. The manual states that
> > numbers "take the form [base#]n, where the optional base is a decimal
> > number between 2 and 64 representing the arithmetic base". As such,
> > "base10" is not a decimal number between 2 and 64, whereas "10" would be.
> >
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > res1=8 good result 8 base10
> > > res1=10 good result 10
> > > res1=10 good result 10
> > > res1=010 good result 010 base8
> > > base10-res1=10 good result 10
> > > res1=16 good result 16
> > >
> > >
> > > *% ./bug.bash 2*
> > > TESTCASE=2
> > > res1=010 good 010 base8
> > > res2=03 good 03 base8
> > > res=17 good result 17 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > base10-res=19 good result 19 base10 (res1+3*res2)
> > > ./bug.bash: line 35: let: res = 10#res1: value too great for base (error
> > > token is "10#res1")
> >
> > For numbers in the form "[base#]n", it isn't practically possible for n to
> > be specified using a variable without prefixing it with a sigil (so that it
> > is treated as a parameter expansion and injected). There is a very good
> > reason for this: numbers in a base higher than 10 can require alphabetical
> > letters to be expressed. Consider the following example.
> >
> > $ echo $(( 16#ff ))
> > 255
> >
> 
> some were prefixed with 0 which make those also not work

You're probably thinking of the 'September' issue but it isn't true. Consider 
the declarations of res1 and res2.

res1=010 # base8 number
res2=03 # base8 number

The comments make it clear that Victor is expecting for those to be treated as 
base 8 (octal). At least, without qualifying the base. There is no issue there; 
both are perfectly valid octal numbers.

$ echo $(( 010 )) $(( 03 ))
8 3

On the other hand, the base number in "base#n" notation may not have leading 
zeroes.

$ echo $(( 064#1 ))
bash: 064#1: invalid number (error token is "064#1")

However, that particular mistake is never made in the program.

-- 
Kerin Millar