Running RHEL 5.3 on a 2.6.18-128.el5 kernel. It's a VM.
bc v1.06
bash v3.2.25((1)-release (x86-64-redhat-linux-gnu)

My specific issue is getting bc to properly show decimals. I have a program that receives arbitrary numbers and then does percentage calculations based on what it gets - it is never correct, and troubleshooting bc has lead me to these conclusions:

If I do: echo "scale=2; (1/3)*100" | bc -l

I get: 33.00 (obviously incorrect)

If I do: echo "scale=2; (1/3)*101" | bc -l

I get: 33.33 (given rounding, this is close enough)

If I do: echo "scale=4; (1/3)*100" | bc -l

I get: 33.3300 (obviously incorrect, but it is interesting that bc chose to make the first two decimals correct)

I have tried using the -l option, not using the -l option, providing artificial decimal places for all constants in the equation (just in case bc likes to drop decimals when the input doesn't have them) and so on. I've swapped in printf for echo, and manually run the bc program without piping input. bc is consistently wrong in all cases where I use "100" as the multiplier.



What am I doing wrong?

Same results here on Fedora 15, 2.6.43.5, bc 1.06.95

I did notice that if you do 100*1/3 it works fine though:


No idea why, just providing a potential workaround.

100*1/3 is fine, 100*(1/3) is not.

Weirdness.

It's probably just order of operations and your scale=4. 1/3 is being computed as .3333 (only four decimal places since scale=4), then when multiplied by 100 you get 33.3300. If you do 100*1/3 it does the 100*1 first, giving you 100.0000, then divides that by 3 giving you the full precision 33.3333.

1 members found this post helpful.

After more looking, that's definitely the problem. You can see it when multiplying by 101 as well, but it's not as noticeable.

I would remove the scale from your bc and just let it do the full precision computation, then pipe the result to printf for formatting.