2009/1/19 mabshoff <michael.absh...@mathematik.uni-dortmund.de>: > > On Jan 18, 6:46 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > > Hi, > >> Ouch, that sounds painful!! > > Well, it was mostly bloody since I was a couple kilometers away from > clean water or some kind of tissue to apply pressure to stop the > bleeding. The ice I slipped on was rather red. I have photos of the > hand, but I won't post them around here since that would be way OT :) > >> If it is any consolation, I hurt my knee >> after attempting a move called a cork. I came close .... too close >> .... to the ground .... then thwack. It'll recover, but it is a bit >> sore. > > My knee got whacked, too, but in my case it was pure dumbness of > venturing outside into the big blue room. > >> For extended GCD there is a description of an algorithm on page 464 of >> Crandall and Pomerance "Primes: a computational perspective" due to >> Penk which outlines how to get a binary extended GCD algorithm. In >> Stehle and Zimmermann's paper there is a description of an >> asymptotically fast binary recursive GCD algorithm. There's also a >> paper of Cesari 1998 on the same topic. > > Thanks for the references. > >> Basically we can do a similar sort of thing for Moller's ngcd >> function. It's relatively straightforward - should be only about half >> a page of code. Might make a nice project for someone. I originally >> volunteered to do it, but at present haven't found time to get it >> done. > > Ok. Hopefully someone will attach this problem soon. I don't think > this will have too much of an impact on most people's code and the > benefit of having eMPIRe in for the cost of a slower xgcd is well > worth it.
It's not as great an issue for xgcd as it is for gcd, if I understand correctly. > > Given the rather disruptive work on --enable-fat I am curious what the > timeframe for the official release will look like? Do you have any further info on the leak in t-locale. I have tried to replicate it, but without success so far. Can you give me a list of things to type to replicate it. Other than that, the only thing holding up the release is the bug(s) in /mpn/x86_64/fat/fat_entry.asm. > I have no problem > shipping a more current svn revision since it is trivial to do wide > testing and I assume if we do not use --enable-fat in Sage the code in > question does not impact stability/compilation. It shouldn't affect a normal build. I've been pretty careful to avoid touching general code where possible. > Once the K10 code is > in I have thought of using --enable-fat per default in Sage on x86 > based CPUs, especially since I have thought about making an SSE2 > binary of Sage since the Sage binaries build on boxen required SSE3 or > more. For binaries this is a good idea. It is a bad idea when building Sage from source, for performance reasons. The K10 code will go in the next release, not the first release. I am certainly looking forward to getting it out the door, but we should get a solid first release without it first. > > Anyway, it is a pleasure watching the ongoing discussion about fixing > technical problems in the open on mpir-devel, so keep up the great > work :) > Great. Bill. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@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 -~----------~----~----~----~------~----~------~--~---
