On Fri, Oct 2, 2009 at 5:32 PM, Fredrik Johansson <fredrik.johans...@gmail.com> wrote: > > On Sat, Oct 3, 2009 at 12:58 AM, rjf <fate...@gmail.com> wrote: >> >> Reading the bug report it seemed to me that the code was determining >> in some way that terms could be dropped off the sum because they were >> too small to contribute, and then >> stopped adding them in. Is that the "simple implementation bug"? Or is >> that an additional bad idea? > > The summation code basically adds terms that are close together > exactly (using a big integer mantissa) and discards terms that are > much smaller. If the first pass over the terms results in a large > cancellation, the summation is restarted at higher precision and > eventually (if necessary) the smaller terms will be included as well. > > The bug was due to a basic, dumb error in the formula used to > determine "much smaller", and the reason the bug wasn't detected > before by any tests is that it only triggered in some cases (indeed, > in a platform dependent way) and with precisions or numbers around 40 > digits or larger.
Fredrik has done a superb job by implementing all the evalf stuff in sympy in 2008 as part of GSoC. It contains lots of nontrivial things. Thanks for that. I pushed your patch in --- I think it should be fixed now. As to new release of sympy, we'll be working on that after Mateusz comes here to Reno in a week. Ondrej P.S. (for the sympy list), it's about this bug: http://code.google.com/p/sympy/issues/detail?id=1659 --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
