Dear list, I would like to open a discussion on how to merge my (fairly extensive) fixes to the gruntz algorithm. As far as I understand release is currently top priority, so merging a large change might seem a no-go (and I shall not assume to know better ^^), but I think shipping quite badly broken code is not very satisfying either. Let me press on under the working assumption that there is interest of getting this in quickly.
Currently the fixes are spread out over three pull request, where each contains (depends on) the former: [1] [2] [3]. As a short recap, [1] adds series expansions for multivariate functions and then uses this to be able to compute series expansions of atan2. IMHO this pull request is really straight-forward. The main aim of [2] is to compute certain limits of gamma functions. For this it adds support for asymptotic expansions of functions (near oo), adds the stirling expansion of the loggamma function, and extends gruntz to use this. While doing so I hit a number of bugs which I fixed, and these fixes are included in [2]. But eventually I realised that there are really many fairly fundamental bugs which I deferred fixing. Finally [3] fixes all bugs I could find. The main method to uncover them was to add a selection of (fairly complicated) limits from gruntz' thesis which the algorithm should be able to handle. A word about the status of these pull requests: [1] and [2] are rebased over current master and ready to be reviewed/tested/pushed in. [3] is ready to be reviewed but not rebased over master, in fact not even over the latest version of [2]. The reason is described in the pull request. I see three strategies for merging this: (1) "Waterfall". Review [1], I do any requested changes, then you push it in. Same for [2]. Then I cherry-pick [3] on top of master (might take a few hours), and when that is done proceed as before with [3]. (2) "Compromise". Push in [1] moderately quickly. I then rebase all of [3] (i.e. including 2) into a sane state so that it can be reviewed as a whole. (3) "All-in-one". I rebase all of [3] (i.e. including [2] including [1]) on top of master, and everything is rebased together. I don't really see what speaks for (3), just included it for completeness. Personally I prefer (2), mainly because I won't have to cherry-pick [3] over a possibly diverged [2]. I think it also makes sense from a technical perspective because some commits from [3] override commits from [2] (i.e. I did some fixes for [2] and then did some more fixes in [3] to the same code). In any case, I will do whichever method you prefer. If you want to defer this until after release, I'm fine too. [1] https://github.com/sympy/sympy/pull/198 [2] https://github.com/sympy/sympy/pull/216 [3] https://github.com/sympy/sympy/pull/236 -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
