>>> Igor Sobrado 29-Jan-07 14:36 >>>
>
> But I want to note that the difference between Solaris' bc and
> the bc flavours available on NetBSD (GNU bc) and OpenBSD (its own bc
> implementation) for numbers near zero is probably a bug.
>
> In fact, Solaris' bc returns comparable numbers for l(0.1) and
> l(0.10000000000000000000000000000000000000000000000000001) -I think
> that it is the expected behaviour- but both NetBSD and OpenBSD bc flavours
> return very different numbers (the right one for 0.100000...0001, but
> -\infty, -FFFFFF... on hexadecimal base, for 0.1.
>
> I suppose that this difference for values returned by the logarithm
> of these numbers is not expected from SU rules, even if truncation
> of decimal numbers is the right behaviour.
>
> In short, Solaris' bc returns -2.C5C85FDF473... (in base 16) for
> both l(0.1) and l(0.100000...001), both NetBSD and OpenBSD return
> -2.C5C85FDF473... for l(0.100000...001) but -\infty for l(0.1).
>
> It looks like a different bug to me, but I am not an expert at all
> on bc. :-)
What is happening here is that when you enter
ibase=16
l(0.1)
you get "0.0" passed to the l() function, which gives -infinity. (I
would call that the expected result under the circumstances.)
If you enter
ibase=16
l(0.10)
you get "0.06" passed to the l() function, which then gives you the
sort of result you were expecting.
In other words, bc(1) works internally in base 10, and converts numbers
entered in another base into a decimal number with the same precision
before processing those numbers. And, of course, using very coarse
precisions can result in results wildly different to those expected.
Maybe this just warrants a CAVEAT in the man page?
Tom
