[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