2

When I run:

fval=1.40 ; echo "scale=0 ; 1000 * ${fval}" | bc

I get the result:

1400.00

With my specified value for scale, I expect no decimal digits.

Does anyone else have this issue?

Version: bc 1.07.1

Ubuntu 22.04.4 LTS

(Upgrade of Ubuntu MATE from 20.04 LTS to 22.04.04 LTS, not a fresh install)

kos
  • 41,378
Eric Marceau
  • 187
  • 2
    FYI: By going by rules I was taught back at school in mathematics; the result was always supposed to be set by the value of input, ie. you start with a real value with 2 digits of decimals, thus at high school we were expected to produce a real value with 2 digits of answer. – guiverc Sep 10 '24 at 04:08
  • I understand the stated expectations regarding normal Real Number maths. I was trying to get an integer result. The "scale" function is supposed to provide that, if explicitly assigned the value of 0. It does not in this case, which is why I perceive it to be a bug. I also perceive the below solution, however workable ( better than using "| cut -f1 -d." ), is nonetheless a kludge, in my mind. But I can work with that, and have updated my personal script with that usage. – Eric Marceau Sep 10 '24 at 17:21

1 Answers1

9

Not a bug. From man bc:

Unless specifically mentioned the scale of the result is the maximum scale of the expressions involved.

And, further down below:

expr * expr
The result of the expression is the product of the two expressions.

expr / expr
The result of the expression is the quotient of the two expressions. The scale of the result is the value of the variable scale.

So, the fact that "The scale of the result is the value of the variable scale" is not explicitly stated (unlike when describing expr / expr), already means that expr * expr is not expected to honor scale.

Also, the fact that in case of expr * expr "the result is the maximum scale of the expressions involved" can be confirmed empirically:

% fval=1.40 ; echo "scale=0 ; 1000 * ${fval}" | bc
1400.00 # two decimal digits as in fval
% fval=1.400 ; echo "scale=0 ; 1000 * ${fval}" | bc
1400.000 # three decimal digits as in fval
% fval=1.400 ; echo "scale=0 ; 1000.0000 * ${fval}" | bc
1400.0000 # four decimal digits as in 1000.0000

To obtain the wanted behavior, you could add a meaningless division (note that since scale defaults to 0 you might as well omit it):

fval=1.40 ; echo "1000 * ${fval} / 1" | bc

% fval=1.40 ; echo "1000 * ${fval} / 1" | bc
1400
kos
  • 41,378
  • 1
    The man page (under EXPRESSIONS) does actually state "Unless specifically mentioned the scale of the result is the maximum scale of the expressions involved." I think? – steeldriver Sep 10 '24 at 12:16
  • @steeldriver Indeed, thanks, I honestly didn't bother checking too much around (even though admittedly it was just a few lines above, but hey) – kos Sep 10 '24 at 12:45
  • 1
    ... tbh the man page doesn't seem to be particularly well organized (and the texinfo doc not really any better) – steeldriver Sep 10 '24 at 12:55
  • Thank you, @steeldriver. The issue here is the purpose and scope of the "scale" variable. If the default value is zero (not sure why if it has no effect), it is quite understandable that the result would have the same number of decimal places as any of the input items. However, there needs to be a distinction between that implicit adaptive mode ... and a user-specified mode, namely scale=0, to force the output format. I perceive the logic as requiring if scale was "parsed as input-driven" before deciding, for the case of "0", to display the result. Such new logic would not conflict. – Eric Marceau Sep 10 '24 at 17:29