[AC 21.5] MPIR support
APPROVE COMMIT 21.5
On Mon, Jun 17, 2013 at 7:54 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
+＠item ratio
+Then ＠code{ratiop(x)} is false for all x. Any attempt to create a ratio
+causes an error to be raised. We would eventually like to define our
+own structure consisting of two ＠code{Lisp_Object}s, which are presumed
+to be integers (i.e., either fixnums or bignums).
I don't agree with this. If we really want ratios to always be
available, we should require one of the libraries, and bundle it if
necessary. But I'm not sure it's not more trouble than it's worth. I
agree that ratios are much more Lispy than floats, but really, given
that everybody has floats in hardware, aren't they good enough?
Yes, I was recycling some old text here. On second thought, I agree
with you. If you want ratios, use one of the 3rd party libraries. I
have removed this text.
On second thought, doesn't calc already provide this?
It does. It's very slow, ,though.
SXEmacs apparently supports a pile of other numeric libraries. Is
it
worth asking for volunteers to add those?
I'm not sure it is. The BSDs all have BSD MP. Pretty much every
Linux distribution has GMP, and many have MPIR. GMP and MPIR are both
available on Windows, as well as several commercial Unices. I'm not
sure who we would be targeting with other numeric libraries.
Performance hasn't really been an issue in the past. It might become
more of an issue if some applications pop up that use bignums, ratios,
or bigfloats heavily. So far I have not seen any such applications,
though.
+C code should use one of the following macros to create a Lisp
integer,
+depending on the type of the C integer to be converted.
+＠itemize ＠bullet
+＠item
+＠code{make_fixnum(x)} if x is guaranteed to fit into a Lisp fixnum.
This is an optimization?
If the compiler can tell that the parameter is always in the fixnum
range, then a decent C optimizer should compile the two forms down to
the same code. If the compiler can't tell, but the human programmer
can, then it is an optimization. I think of it as more signaling my
intentions to other programmers: "I intend this to be used for fixnum
computations only."
I have added some text to clarify this point.
+＠item
+＠code{make_integer(x)} if x is a signed C integer of any type.
+＠item
+＠code{make_unsigned_integer(x)} if x is an unsigned C integer of any type.
+＠end itemize
I believe these make fixnums when possible. That should be noted here.
Done.
Which library, if either, do you recommend? If the recommendation
is
a strong preference, maybe it's worth noting here with your name and a
date attached. Something like
I don't have a preference. I have seen MPIR programmers claim that
MPIR is faster and uses less memory than GMP, but I have no data
either way. I suspect that a typical XEmacs load won't stress either
library, so the difference is probably nothing to write home about.
For that reason, I decline to give a preference at this time.
I am attaching the revised patch which I will commit shortly.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
Attachments:
- xemacs-number.patch (application/octet-stream — 45.8 KB)