In message <[EMAIL PROTECTED]>, Otto Moerbeek writes: > > On Mon, 29 Jan 2007, Igor Sobrado wrote: > > > (I suppose that setting obase=10 after setting the input base to 16d > > means that the output base is set to 0x10...) > > indeed. > > In the last example Solaris does no seem to truncate 0.1 to 0. > > l(0) is supposed to return "a really large" negative number. If you > use base 10 it's easier to see what is going on.
Indeed, l(0)=-\infty (using LaTeX notation), l(1)=0 (it does not depend on the base used for the logarithmic function, it is just a consequence of the formal definition of the logarithmic function) and l(\infty)=\infty. 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. :-) Best wishes, Igor.
