A contribution to GMP
Dear Developers, I like using GMP in my research and the main drawback of current library is a very limited set of float functions. I see that implementing these is listed in developing plans. I have developed a set of following functions and I would like to share code with you and (if possible) to contribute to GMP. void mpf_atan(mpf_t rop, const mpf_t op) void mpf_asin(mpf_t rop, const mpf_t op) void mpf_asinh(mpf_t rop, const mpf_t op) void mpf_sin(mpf_t rop, const mpf_t op) void mpf_cos(mpf_t rop, const mpf_t op) void mpf_sinh(mpf_t rop, const mpf_t op) void mpf_cosh(mpf_t rop, const mpf_t op) void mpf_tan(mpf_t rop, const mpf_t op) void mpf_tanh(mpf_t rop, const mpf_t op) void mpf_exp(mpf_t rop, const mpf_t op) void mpf_log(mpf_t rop, const mpf_t op) void mpf_log10(mpf_t rop, const mpf_t op) void mpf_pow(mpf_t rop, const mpf_t op1, const mpf_t op2) void mpf_secant(mpf_t rop, void (*f)(mpf_t,const mpf_t), const mpf_t op1, const mpf_t op2) The code with commented functions and example main() is placed here: http://www.komsta.net/gmp.c This file contains some internal functions called with modified parameters by another ones to prevent code duplication: void mpf_arcsin(mpf_t rop, const mpf_t op, int plusminus) void mpf_trig(mpf_t rop, const mpf_t op, int one, int plusminus) All names should be self explaining except of mpf_secant, which solves f(x) = 0 in some interval numerically by secant method. It needs to be given a function void f(mpf_t rop, const mpf_t op) which computes rop from op as y = f(x). I have planned to create mpf_atan2, however it should use pi number in certain cases, so I suspended developing due to lack of function creating pi with desired precision. My functions use typical algorithms (mainly Taylor Series) so their efficiency should be enough for most computations unless we require billions of digits. If you like the code you can put it into further versions of GMP - I release it under GNU LGPL and if possible I would appreciate credit in source code and contributor list. Of course I cannot guarantee that everything works 100% fine, but I have done all my best. Regards, Lukasz -- Lukasz Komsta, PhD, DSc Department of Medicinal Chemistry Medical University of Lublin, Poland http://www.komsta.net/ ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: A contribution to GMP
Użytkownik Marc Glisse napisał: r sharing. Are you aware of the MPFR library? GMP's mpf_t type is a legacy type and we recommend people use MPFR for new projects. And if you are aware of it, how does your code compare, and what are the main motivations for sticking with mpf_t? I know about MPFR and noticed some time ago that it contains such functions, but I have not tested this library as I had no time to switch my codes to it. However, I will do it soon. I developed my functions during several long evenings to deal with some problems on computational cluster with installed GMP, not forcing administrator to install MPFR. I do not know if there is a trend to suspend GMP in floating point partand urge users to switch to MPFR - if so, my work was only for fun. However, I cannot deduce such feeling from GMP page and plans page include developing of such functions. If they can be somehow used, its my pleasure. I am just installing MPFR under Cygwin and will play a bit with MPFR, noticing about my conclusions. Regards, Lukasz Komsta ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: A contribution to GMP
On Wed, 23 Oct 2013, Lukasz Komsta wrote: I know about MPFR and noticed some time ago that it contains such functions, but I have not tested this library as I had no time to switch my codes to it. However, I will do it soon. I developed my functions during several long evenings to deal with some problems on computational cluster with installed GMP, not forcing administrator to install MPFR. I do not know if there is a trend to suspend GMP in floating point partand urge users to switch to MPFR - if so, my work was only for fun. However, I cannot deduce such feeling from GMP page On the homepage gmplib.org: Externally supported: High-level floating-point accurately rounding arithmetic functions (mpfr). See the mpfr site for more information. Starting with GMP 4.2, mpfr is released separately from GMP. (New projects should consider using mpfr instead of GMP's own mpf.) and plans page include developing of such functions. The projects.html page? Below that item, it says Note that the mpfr functions already provide these functions, and that we usually recommend new programs to use mpfr instead of mpf. In my opinion, it doesn't make sense to duplicate the work in GMP and MPFR and that item should disappear, but I am only speaking for myself here, you can wait and see if others have comments. If they can be somehow used, its my pleasure. Maybe some parts of the code could be used to improve some MPFR functions? I am just installing MPFR under Cygwin and will play a bit with MPFR, noticing about my conclusions. Let us (and the mpfr developers) know how it goes. Thanks again for contributing, -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: A contribution to GMP
Marc Glisse marc.gli...@inria.fr writes: On the homepage gmplib.org: Externally supported: High-level floating-point accurately rounding arithmetic functions (mpfr). See the mpfr site for more information. Starting with GMP 4.2, mpfr is released separately from GMP. (New projects should consider using mpfr instead of GMP's own mpf.) We might want to re-phrase it somewhat, perhaps just consider - seriously consider, or even New projects should use mpfr since mpf is slower, less complete, and not actively developed. In my opinion, it doesn't make sense to duplicate the work in GMP and MPFR and that item should disappear, but I am only speaking for myself here, you can wait and see if others have comments. I don't want to work on integrating any new mpf developments. But if one of the other committers want to do that, I won't try to veto it. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Massive test failures for haswell-freebsd9
Regarding http://gmplib.org/devel/tm-date.html. Some of you might have spotted build errors for solaris, with -fat. This is due to a static allocation of their m4. I've worked around it, so next build round should pass. A much worse error happens with Intel Haswell under FreeBSD 8 ad 9; here almost all GMP test fail. It is also m4 that is the culprit here. FreeBSD m4's eval function is quite broken in that the 2nd and 3rd arguments are completely ignored: fbsd$ echo 'eval(12245853,16)' | m4 12245853 The correct output for that example is BADB5D... The result is that incorrect opcodes are generated for some Haswell specific instructions. It is ironic that we handle these insns with m4 mainly because FreeBSD insists on using an antique assembler, so we hit a 2nd bug when working around the 1st... (I reported this bug 1.5 years ago to FreeBSD, when we first were bitten by it. They've fixed it in their upcming 10.0 release, but left it unfixed in 8.3, 8.4, 9.0, and 9.1.) -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
