## "Fossies" - the Fresh Open Source Software Archive

### Member "bc-1.06.95/FAQ" (21 Apr 2006, 1335 Bytes) of package /linux/misc/old/bc-1.06.95.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "FAQ": 1.07_vs_1.07.1.

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.