On Mon, May 4, 2009 at 1:55 AM, mabshoff <mabsh...@googlemail.com> wrote: > > > > On May 3, 5:54 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: >> mabshoff wrote: > > <SNIP> > > Sorry, I forgot to reply to this part of the post since I thought it > was in another independent post. > >> > * For the range of 2^40+1 to 2^46 I am uncomfortable to have it >> > available per default, especially if we don't at least spot check the >> > values via doctesting and it would be getting slow to do so - even for >> > #long. But we could add some keyword to force the upper limit up to a >> > 2^46 - the issue should be revisited post 3.4.2 - maybe even >> > implementing a better algorithm? >> >> I personally can't see the point in stopping the algorithm working at >> 2^40, if it does work at 2^46. > > We don't know it works on every for for 2^46 since we basically have a > sample of two computers. The past has taught me that this isn't even > close to what I would consider acceptable. I have put in the limit of > 2^40 and the doctests to check correctness for 2^n for n in 30..40 and > that will be widely tested. Once that works we can think about > extending the tests or implementing another algorithm. Given a choice > between shipping potentially broken code or limiting Sage's > capabilities I always chose to disable code. We are beating the pants > off every known open implementation prime_pi() and lack MMA by a small > constant factor - that is an excellent improvement for Sage 3.4.2 - no > need to get greedy ;) > >> I realise you can't specifically test >> 2^46 on every occasion, but surely that argument could apply to sine, >> cosine and every other function that exists. It's impractical to check >> every single value that might be thrown at it. Of course, if there is >> reason to believe the algorithm will fail, rather than just become very >> slow, then there is good reason for putting a limit.
+1 in general, but prime_pi is very new code written by a new sage dev who strangely has not made any comments at all about this issue (and the algorithm he implemented is very sensitive to input size). Until we get some feedback from him, I like Michael suggestion. > > No, sin(2^n) and so on for large n is computed via MPFR which is > provably correct (modulo bugs of course) and has been tested by many > people for many, many years and is written by world experts in the > field. I can trust that code as much as I can trust code. > > Cheers, > > Michael > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
