"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "bc-1.06.95/FAQ" of archive bc-1.06.95.tar.gz:

As a special service "SfR Fresh" has tried to format the requested source page into HTML format using source code syntax highlighting with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. That can be also achieved for any archive member file by clicking within an archive contents listing on the first character of the file(path) respectively on the according byte size field. 
    1 Because of frequent questions ....... here is the BC FAQ
    2 
    3 
    4 1) Why does BC have its own arbitrary precision number routines 
    5    (found in lib/number.c) rather than using GMP?
    6 
    7 GMP has "integers" (no digits after a decimal), "rational numbers"
    8 (stored as 2 integers) and "floats".  None of these will correctly
    9 represent a POSIX BC number.  Floats are the closest, but will not
   10 behave correctly for many computations.  For example, BC numbers have
   11 a "scale" that represent the number of digits to represent after the
   12 decimal point.  The multiplying two of these numbers requires one to
   13 calculate an exact number of digits after the decimal point regardless
   14 of the number of digits in the integer part.  GMP floats have a
   15 "fixed, but arbitrary" mantissa and so multiplying two floats will end
   16 up dropping digits BC must calculate.
   17 
   18 2) The code "ibase=16; obase=10; FF" outputs FF, not 255.  Isn't this
   19    a bug?
   20 
   21 No.  ibase changed the input base at that point.  The 10 is then in
   22 base 16 and thus is the value 16.  Therefore, both ibase and obase
   23 are 16 (decimal).  And FF (base 16) on input is printed as FF (base 16)
   24 on output.  So how can one get 255?  First, single digit numbers are
   25 not converted using ibase.  So A is always 10 (decimal).  The following
   26 code will always work.  "ibase=F+1; obase=A; FF" and that always prints
   27 255.