Talk:Evaluate binomial coefficients
Task Needs Refinement
The task needs more work. I've made the math look nicer, but it would help if we had some particular values to try to calculate too; I've done binom(60,30), but that requires a non-trivial component somewhere — even the result won't fit in 32-bit ints, let alone any intermediate values — so I don't know if it is really suitable as an actual task. –Donal Fellows 00:39, 12 April 2010 (UTC)
- I've refined this task a bit, and made it binom(5,3), okay? --Alegend 01:03, 12 April 2010 (UTC)
- That's great. Thanks! –Donal Fellows 12:52, 12 April 2010 (UTC)
- Welcome! :D --Alegend 21:00, 12 April 2010 (UTC)
- In my times binomial coefficients were calculated using asymptotic series, which is of course a way different task. --Dmitry-kazakov 09:53, 27 June 2010 (UTC)
Type Double inadeqate
The binomial coefficients are of type Integer. If you use type Double instead (as in Java translated from Python), for instance binomCoeff(49, 6) gives 1.3983816000000002E7
Task Title
Starting a task with the word "Evaluate" is unhelpful - all tasks involve evaluating. I suggest renaming this "Binomial coefficient".
Edits on April 17 2016 left formulae invisible on OS X Chrome & Safari
One problem will be the introduction of redundant white space flanking the Latex expressions inside Math tags. There may be others, but visibility should be restored by reverting the contents of Math tags to their pre-April 17 state.
Please desist from deleting Functional Python examples
Paddy or Donald (User:Paddy3118), please curb your appetite for deletionary vandalism, if you can. The example which you deleted as 'obfuscation' was deliberately clearer than the incumbent, explicitly labelling the implicit products and factorials. It was also, unlike the existing functional version, compatible with Python 3, which requires an import of reduce. Finally, it was better optimised for code reuse.
There is no need for a resurgence of this destructive and gratuitous campaign – it is certainly not constructive, or good for Rosetta Code – and I have restored the deleted original. You did something similar recently to an example deriving cartesian products from the applicative abstraction. (Undeterred, apparently, by the fact that I was the author of the Cartesian Products task :-) Functional programming is clearly not an area in which your expertise or enthusiasm are particularly concentrated, but that doesn't really seem to be a sufficient reason for aggressively deleting examples of it without warning. Does deletion really give such a thrill ? Perhaps you could usefully consider getting such thrills elsewhere ? Hout (talk) 10:57, 21 February 2019 (UTC)
- You continue to write bad Python under the mistaken guise of it being "functional" and so OK. There is no need to introduce more functions to hide trivial calls to builtins such as range, and no need to go to the trouble of adding comments above each function for what should be in a docstring.
- It reads like some other languages code, poorly translated into run-able but not idiomatic Python.
- I suggest you improve your code generation Hout. --Paddy3118 (talk) 15:42, 21 February 2019 (UTC)
- The quality of code is a function of what it is optimised for. Mine is optimised for reliability, high levels of code reuse, and speed of writing. Perhaps there is a context for which yours is well optimised (more for the parade ground than for the real battle-ground is my impression) but it would not work well in mine (not least because it appears to yield the wrong result with slightly surprising frequency. Perhaps you feel that its (occasionally chimeral) adherence to a cherished style is adequate compensation for this uncertain reliability ?).
- More constructively, the terms which you mutter during your deletion frenzies ('obfuscated', 'convoluted') may well express a structuring difference between imperative and functional modes of coding. Writing imperative code has the advantage of requiring very few concepts (sequence, branching, mutation and looping), which give it a usefully low entry barrier.
Functional coding has much less need of sequence, and even less of mutation or looping, but it does require a number of other concepts – significantly more than are needed to practise the imperative mode. The higher conceptual entry barrier of functional method has been shown to yield faster coding and lower bug counts, but can of course be a source of confusion and perhaps even irritation to those who haven't needed or wanted to cross it.