On 9/3/07, John Voight <[EMAIL PROTECTED]> wrote: > Hi Will, > > Thanks, that was fast! If I may ask, what was the problem? Must've > been something not particularly exciting...
Robert Miller implemented root finding for RDF polynomials right before SAGE-2.8.3, and he messed up. Basically SAGE represents polynomials as list with one "endian-ness", and numpy uses the other. So I just reverse the list before passing it into numpy. > Double precision is more than sufficient for my purposes--even floats > (!) are fine, I just need fast and reasonably accurate. Using GSL might also work well for you. It has very fast root finding with doubles. Let me know of if there are still speed or other problems with numpy, and I bet somebody can perhaps improve things quite a lot with GSL (??) -- since then it's a direct C library call. > Craig also whipped up a patch to include those two functions from > Pari--so let's get that into the next release as well. OK, it's in. > Unfortunately, even after the week's optimizations, my number field > enumeration algorithm runs (on meccah) almost 20 times slower on SAGE > than on Magma (181s vs. 9s)--and with identical verbose output. I > just don't see how there can be that much of a difference! But then > again, this was even after I implemented a rather silly shortcut in > Cython to evaluate a polynomial, treated as an array to avoid coercion > overhead which runs almost 3 times as fast as commands like > numpy.poly1d(cfs)(x), and a Newton method which also in many cases > beat the root finding in numpy--but only because of overhead costs. > Note that these trial runs use very little of the number field > machinery: the bottleneck is still real arithmetic and whatever other > overhead is sneaking in... Very frustrating! Done right I'm confident this sort of thing can beat MAGMA. Based on your not understanding what the problem is, maybe you haven't profiled your code? Try using %prun <a command> in the SAGE command line. Also, try posting complete code that *we* can run and look at. MAgma didn't get fast without tons of people carefully running and benchmarking code, then making the slow parts faster (I spent months and months doing that with Allan on my modular symbols code). In certain domains this has already happened with SAGE/Python, but with others its far from happening. What polynomials are you evaluating? If they are double precision, I wonder if making a special GSL-based polynomial class will help a lot? --- William = --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
