We probably should look around for other stupid conditions we can relax too. For example, I think it might be possible to drop the requirements for odd values in the gcd function, though I haven't checked this out fully yet. At least the gcd_1 function doesn't require it any more. Actually, not allowing aliasing for mpn_tdiv_qr probably made sense and wasn't stupid at all when it looked like allowing qxn to be non-zero was going to be a hit. When it was hardly if ever used anywhere, even in the rest of the library, then it probably didn't make any sense.
At least we have to ensure qxn is 0 before allowing aliasing? I suppose having an mpir_n function which doesn't have a qxn and which allows aliasing, couldn't be a bad thing. Then again, isn't this precisely what mpn_divrem does? Bill. 2009/8/28 Bill Hart <[email protected]> > The thing is, allowing aliasing doesn't violate the rules in the > documentation. The documentation says that aliasing is not allowed and if > the user respects that, then providing a function which does allow aliasing > will not break their code. > I would bet money however, that if we keep our mouths shut, TG will > document mpn_tdiv_qr as allowing aliasing in the next release. He's moving > towards relaxing as many stupid conditions on his mpn functions as he can. > > I'm not opposed to having an mpir_n layer, or whatever, of course. > > Bill. > > 2009/8/28 Jason Moxham <[email protected]> > > >> On Thursday 27 August 2009 16:59:38 Cactus wrote: >> > The mpn_divrem function in GMP/MPIR has been declared obsolete for >> > several years now and there is a plan to remove it in MPIR 1.3. >> > >> > However while mpn_divrem overwrites the input numerator with the >> > output remainder, its proposed replacement - mpn_tdiv_qr - specifies a >> > location for the remainder and also states that no memory overlaps are >> > allowed between its operands. As a result, specifying the numerator >> > as the location for the remainder in mpn_tdiv_qr is illegal and this >> > forces the use of temporaries in any replacement of mpn_divrem with >> > mpn_tdiv_qr. >> > >> > But in reality the current mpn_tdiv_qr code does allow the output >> > remainder to replace the input numerator. Moreover a number of GMP and >> > MPIR functions actually depend on this behaviour. >> > >> > In my view we should implement mpn_tdiv_qr in a way that allows the >> > remainder to overwrite the numerator since this is often important for >> > efficiency. Hence I would like to suggest that we change the >> > documentation of mpn_tdiv_qr to allow this behaviour. >> > >> > Does anyone have a view on this? >> >> If we do guarantee that mpn_tdiv_qr allows overlaps , then I'm not sure >> how >> much use it will be , will people use that feature if GMP does not do the >> same. I'm increasingly coming to the conclusion that it would be better if >> we "start again" with a new layer mpir_mpn_* etc , here we would have free >> reign to improve what we want and not worry about backwards compatibility. >> Of >> course most of this new layer would be the same as the old mpn_* layer so >> it >> can just consist of a few macros. We would use this layer internally , and >> we >> could export a stable subset to the user. >> >> >> > >> > >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
