More revisions for numbers.texi
Stephen J. Turnbull
stephen at xemacs.org
Thu May 20 23:09:38 EDT 2004
OK, that round is done, but I've discovered a few things I have
(1) This looks to be a genuine bug: curiously enough,
(= 1/3 (coerce 1/3 'bigfloat))
which is OK, but
(= 1/3 (coerce 1/3 'float))
|--> Wrong type argument: numberp, 1/3
which is an "oops."
(2) We need to document coercion, especially and how to give bigfloats
precision. Problem: I'd like to avoid recommending use of
`coerce-number' but cl-extra's `coerce' doesn't allow setting of
precision. Can we extend `coerce'?
`coerce', `coerce-number', `default-float-precision', and
`bigfloat-max-prec' need to be documented (I can do most of that,
review appreciated of course), but
(3) I would prefer that `bigfloat-max-prec' be spelled
(4) `default-float-precision' is documented like this
DEFVAR_LISP_MAGIC ("default-float-precision", &Vdefault_float_precision, /*
The default floating-point precision for newly created floating point values.
This should be 0 for the precision of the machine-supported floating point
type (the C double type), or an unsigned integer no greater than
bigfloat-max-prec (currently the size of a C unsigned long).
Vdefault_float_precision = make_int (0);
but `bigfloat-max-prec' is currently `most-positive-fixnum', not
If dumping of bignums is on your immediate agenda, this can stay
(except that ULONG_MAX should be translated as "the maximum value of a
C unsigned long"), I guess. Another possibility is to move the code
that initializes `bigfloat-max-prec' to another function, and call it
at the end of emacs.c:main_1() wrapped in "if (initialized)". Or
dump a fixnum, then duplicate it and make it bigger at runtime.
Anybody who thinks they need ULONG_MAX of precision in bigfloats at
dump time, well, I just don't understand them....
(5) Shouldn't `bigfloat-max-prec' be a constant (see the declaration
(6) Don't we need an API to query the precision of a bigfloat?
(7) Don't we need an API to query the default precision of the
underlying MP library in case `(= default-float-precision 0)'?
Setting it, too, although the already implemented fiddling with
`default-float-precision' would usually be good enough,
(setq default-float-precision my-desired-bigfloat-precision)
(setq default-float-precision 0))
is awful ugly.
(8) In checking what I thought was a typo, I discovered the following:
(setq x1 1.0)
(setq x2 (coerce 1.0 'bigfloat))
(= x1 x2)
(eql x1 x2)
(setq x3 (coerce-number 1.0 'bigfloat 500))
(eql x2 x3)
==> t ;; SURPRISE!
;; let's make absolutely sure
(setq x4 (coerce-number 1.0 'bigfloat 1000))
(eql x3 x4)
==> t ;; SURPRISE!
If that's true, then I think that (eql x1 x4) should be true, too.
That would be consistent with the way that default-float-precision
works. Alternatively, we could make bigfloats of different precision
be different types (as I originally expected) but that has the problem
that we have no way to represent those types (ie, bigfloatp doesn't
take a precision argument).
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the XEmacs-Beta