https://bugs.freedesktop.org/show_bug.cgi?id=71459
--- Comment #5 from M Welinder <te...@gnome.org> --- Guys, stop defending what LO currently does. It's just plain silly. Take a look at this... http://cgit.freedesktop.org/libreoffice/core/tree/sc/source/core/tool/interpr3.cxx#n448 ...from which we learn: 1. Enter =COMBIN(1e15,1e15-1) and LO will hang for ages. For slightly higher numbers "k--;" won't change the value of k, so that will be an infinite loop. 2. Whoever wrote this didn't know the basics of combinatorics. Notably COMBIN(n,k) = COMBIN(n,n-k). I.e, for efficiency, replace k by n-k if the latter is smaller. 3. The code is doing the divisions in the wrong order. Here's what it does for COMBIN(15,6): 15*14*13*12*11*10 ----------------- 6* 5* 4* 3* 2* 1 (as (15/6) * (14/5) * ... * (10/1) -- note the parentheses. Some of these fractions have rounding errors.) Other than the wrong order of operations, that's not too bad way to compute this. However, it should have been doing 15*14*13*12*11*10 ----------------- 1* 2* 3* 4* 5* 6 (as 15/1*14/2*13/3...*10/6 -- note the lack of parentheses, so the multiplication comes before the division in each step.) Doing things this way means that all numbers stay integers. There will not be any rounding errors unless the final answer is (much) more than 2^53. In the C(15,6)=C(15,9) case, all numbers would fit comfortably in a 16-bit integer. To prevent a hang for C(2^53,2^52), one should check for overflow. But again, COMBIN is a sideshow here. The real issue is the lack of on honest subtraction. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
