One function I am not personally interested in is the new side-channel attack resistant function. A general purpose library like MPIR seems to be the wrong place for something like that. It would also give the impression that somehow MPIR is supposed to be used for secure purposes, which it most definitely is not. It's designed for performance.
Who knows, perhaps GMP is planning on much more of this sort of thing. If there was a massive outcry and lots of people actually wanted this sort of thing in MPIR too, well I'd consider it. But I personally am not interested in that. I'd prefer to put our time into parallel stuff (if we can find the volunteers to work on it). What do people think? The rest of the functionality looks straightforward enough, or we already have it. The biggest challenge for us is actually asymptotically fast division. But I just don't want to do this twice, and we really need very solid FFT code first, which is why I worked around the clock on that for a few weeks to get it out of the way over Christmas. Bill. 2010/1/9 Bill Hart <goodwillh...@googlemail.com>: > At a talk I gave recently, one of the participants expressed quite a > bit of surprise that MPIR really was intended to be a drop-in > replacement for GMP. I think many people don't even really realise > that. > > As for the bit counts, I definitely want to support those. I've > actually started doing that already in one of my other projects > (FLINT-Lite). Similarly, wherever they have dropped overlap > requirements, that is good for us too. > > And to the extent that the new functionality is not too hard to > support, why not. > > But let's see what people say. > > Bill. > > 2010/1/9 Cactus <rieman...@googlemail.com>: >> Now that GMP 5 has been released, we will have to make a decision on >> whether to make changes to MPIR or ive up GMP compatibility. An >> outline of the features in GMP 5 is given here: >> >> http://gmplib.org/gmp5.0.html >> >> There is a new type used for bit counnts and a small number of user >> visible functions that we don't have in MPIR. I don't think that any >> of these will be hard to provide but I may be wrong. GMP 5 also >> changes the specifications of several functions in respect of operand >> overlaps. >> >> I would be interested in people's views on how they would like to see >> MPIR evolve in this respect. >> >> 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.
