On Sep 5, 2007, at 1:25 PM, John Voight wrote: > Wow Robert, thanks! Talk about real-time recreating the wheel--my > code is quite similar, though I was using floats.
Well, it was pretty quick to write, and I was curious as to the accuracy it would give. I wrote an mpfr-based root refiner too, trying to think of the best place to stick it into the sage library... > > Three questions for ya: > > (1) Is there a reason to use Py_ssize_t instead of int or even > unsigned int? If it's for length, I can't imagine we'd have > polynomials of that huge a degree...! Mostly habit and for consistency, but if int != Py_ssize_t, I'd imagine there could be an assembly op or two saved doing padding the former when its being used as an index (though maybe not). Also, as of a little bit ago, the coercion of an Py_ssize_t uses the __index__ function while coercion to an int truncates. I think the c compiler may complain if you try to assign an int from a Py_ssize_t on a 64- bit platform too. > (2) In my code, I specified an eps which controlled the number of > iterations rather than trying to predict that in advance--makes more > sense, no? There are pros and cons to both cases. Suppose x is the true root and x' is the is the returned value. Your method guarantees a bound on |f (x')| whereas mine guarantee a bound on |x-x'|. (I suppose you could use f'(x') to approximate the error |x-x'| as well). Yours has the advantage that you don't have to input the precision of the initial value, but the disadvantage is that it is not guaranteed to terminate (though it probably will). > (3) In double_newton_raphson, aren't we eating a lot of overhead with > lines like f = list(f) and copying the coefficients from f to coeffs? > I tried to get around this myself, but due to my status as a cherub > SAGE programmer, I couldn't ascertain the right data types to use... Doing f = list(f) is a bit of overhead, though not too much if f is already a list and faster than indexing into a polyomial. (though one could check for that first). Copying the coefficients to coeffs, which is a raw c-array of doubles, saves you a lot of time in the evaluating phase as it now operates on pure c data types instead of calling back to python. (Multiplying 2 c doubles can be nearly two orders of magnitude faster than multiplying 2 python floats). > > Yours, > > John Voight > Assistant Professor of Mathematics > University of Vermont > [EMAIL PROTECTED] > [EMAIL PROTECTED] > http://www.cems.uvm.edu/~voight/ > > > --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
