More revisions for numbers.texi

[Stephen J. Turnbull]

OK, that round is done, but I've discovered a few things I have
questions on.

(1) This looks to be a genuine bug: curiously enough,

(= 1/3 (coerce 1/3 'bigfloat)) 
==> t 

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
`bigfloat-maximum-precision'.

(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).
*/ default_float_precision_changed);
  Vdefault_float_precision = make_int (0);

but `bigfloat-max-prec' is currently `most-positive-fixnum', not
ULONG_MAX.

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
of `most-positive-fixnum')?

(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,

(progn
  (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) 
==> t 
(eql x1 x2) 
==> nil 
(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).

Comments?

-- 
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.