precision of bc/dc and properties of logarithms (was: neatroff for Russian)

[G. Branden Robinson]

[dropped Oliver from CC]

Hi Alex,

At 2023-04-28T01:41:20+0200, Alejandro Colomar wrote:
> >     $ python3 -c "import math; print(math.log(1114112, 2))"
> >     20.087462841250343
> 
> You don't need python3 for that:
> 
> $ echo 'l(1114112) / l(2)' | bc -l
> 20.08746284125033940845
> 
> You might notice there's a difference in the decimals.  bc(1) is the
> more accurate, according to Wolfram Alpha.  (My physical calculator
> doesn't have enough precision to contrast).  All digits provided by
> bc(1) are correct, while python3 is printing more than it's capable
> of.  I guess python3 is using a 'double', which usually has around 15
> digits of precission.  bc(1) on the contrary, is likely to be using
> 'long double', for being able to provide so many digits.

bc is a wrapper around dc, which touts itself as having
arbitrary-precision.

I'd have used bc, but I forgot one of the properties of logarithms.
Shame on me!

log_a(x) = log_b(x) / log_b(a)

> Of course, bc(1) is way smaller:
> 
> $ ls $(which python3.11) -lh
> -rwxr-xr-x 1 root root 6.6M Mar 13 13:18 /usr/bin/python3.11
> $ ls $(which bc) -lh
> -rwxr-xr-x 1 root root 95K Sep  5  2021 /usr/bin/bc
> 
> And of course it's faster:
> 
> $ time echo 'l(1114112) / l(2)' | bc -l
> 20.08746284125033940845

Even with a fork() and exec() to launch dc, and even counting dc's own
size,[1] it's _still_ smaller and faster compared to Python.  :P

Regards,
Branden

[1] Oh, wait.  GNU bc is not a wrapper.  Per its man page:

  DIFFERENCES
    This version of bc was implemented from the POSIX P1003.2/D11 draft
    and contains several differences and extensions relative to the
    draft and traditional implementations.  It is not implemented in the
    traditional way using dc(1).  This version is a single process which
    parses and runs a byte code translation of the program.

signature.asc
Description: PGP signature