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 -~----------~----~----~----~------~----~------~--~---
