Since I wrote the bigfloat package in 1974 or so, I was
distressed that this bug shows up. The way it was done was
the fpscan program I wrote, to use for reading bigfloats,
was not being used. Instead a program in nparse was being
used, which, in a comment, lies. A fix is to insert a
call to simplifya, as shown in lower case. The comment
now tells the truth.
The change means that the number is being computed exactly
in rational form and then converted to bfloat. The other
version computed (for example) 1/10 as a bigfloat, and multiplied
together the pieces.
Is there a reason to do this as previously done? sort of. You don't
really want to make 1.0b1000 into a 1000 digit integer and then to
a float. But what fpscan does is it computes using $bfloat, but to
a carefully computed extra precision.
Instead of the simplifya, one could copy the code from fpscan to
boost the precision so that the power of 10 is computed more accurately.
This is still not as accurate in all cases as just a single division.
So for now, I recommend just doing this:
(oh, convert to lower case...)
RJF
(DEFUN MAKE-NUMBER (DATA)
(SETQ DATA (NREVERSE DATA))
(IF (NOT (EQUAL (NTH 3. DATA) '(#\B)))
(READLIST (APPLY #'APPEND DATA))
;; For bigfloats, turn them into rational numbers then convert to
bigfloat
($BFLOAT (simplifya `((MTIMES) ((MPLUS) ,(READLIST (or (FIRST
DATA) '(#\0)))
((MTIMES) ,(READLIST (or (THIRD DATA) '(#\0)))
((MEXPT) 10. ,(f- (LENGTH (THIRD DATA))))))
((MEXPT) 10. ,(FUNCALL (IF (char= (FIRST (FIFTH DATA))
#\-) #'- #'+)
(READLIST (SIXTH DATA))))) nil))))