Just to add to what Brian says. We certainly recognise that the community values full GMP compatibility more than some other aspects of the MPIR design criteria, and we have definitely been giving it more full attention than we used to.
Even so, there are some instances where compatibility will be impossible, e.g. if bugs exist in GMP, or if GMP defines functions which we believe are out of scope for the design criteria of MPIR (e.g. the secure functions Brian mentioned). However, where possible, we will provide a GMP compatibility mode which should in 99% of instances, provide full GMP compatibility (this is currently obtained using --enable-gmpcompat, though we are still working on our GMP 5 compatible interface, so we are currently only compatible with GMP 4 - more will be made of this shortly). In the particular case that you mention, we hope that GMP will likewise deprecate their functions and provide appropriate alternative functions as we believe our reasons for deprecation are sound. However, that is up to them, and if they choose not to, we will usually provide #defines in gmp compatibility mode so that code written for GMP still works with MPIR, though admittedly possibly at a slight performance penalty in some instances, as compared with using MPIR functions directly. Bill. On 18 March 2010 12:00, Cactus <rieman...@googlemail.com> wrote: > > > On Mar 18, 11:21 am, "Chris Saunders" <e...@mountaincable.net> wrote: >> I was reading the documentation on mpz_probab_prime_p. At the bottom of the >> documentation of this function it says "This function is obsolete. It will >> disappear from future MPIR releases." I have not seen the same in the GMP >> documentation for this function. Does this mean that in the future I can >> expect GMP and MPIR to be incompatable? Might I suggest that this would be >> unfortunate. > > Although our general intention is to remain as compatible as possible, > GMP and MPIR will never be completely exchangeable as their are always > going to be a few functions that will exist in one but not in the > other. > > For example, we will never implement the so called 'secure' functions > such as mpn_powm_sec() since we don't consider it sensible to use > either GMP or MPIR where security matters as the code is completely > inappropriate for such uses. > > In the area of trial division and (probable) prime testing, there is > currently some divergence that needs careful consideration. We have > not planned a way ahead on this right now but we do see the > maintenance of a high level of GMP/MPIR compatibility as important > where the path taken by GMP makes sense. > > Brian > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
