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.

Can I suggest that the next time you find something puzzling or unfamiliar (Applicative functors ? Currying ? Monads ?) that in lieu of angry deletion, you experiment instead with eliciting clarity ? Hout (talk) 16:06, 21 February 2019 (UTC)

You continue to add your personal coding style that flouts established Python idioms and features hence its removal. You use personal type hinting, when Python has type hints; (and before that, had an established way of adding such information in docstrings). You add function documentation as comments instead of in a docstring. I have pointed this out to you before - I suggest you update your code generation.

Functional programming and what you think my skill level is, is a diversion on your part; the real issue is you overriding established style for your personal convenience.

--Paddy3118 (talk) 17:37, 21 February 2019 (UTC)

I have improved the functional code by replacing the type information as comments, by the language supported type hints. Typing help(binomialCoefficient) for example, will return typing information in the way to be expected by Python programmers. Your original type comments above function definitions would need equal effort it seems, to add to a function docstring and would at least help in documnting code in the standard way, but even that was not done - it looked like a poor translation from another programming language. (As you know). --Paddy3118 (talk) 23:47, 21 February 2019 (UTC)

I'm sorry Donald, but you must stop vandalizing material of which you have a poor understanding.

The idiom of functional programming is the semantics of math – not arbitrary stylesheet convention. A curried enumFromTo function which returns a list from the limits of an enumeration is not the same as uncurried Python range function whose arguments do not match the limits. It composes differently, and returns a value of a different type.

Removing the semantic type comments (use of which is a very well established convention in functional programming - across different languages) simply lowers the quality of the code for a functional programmer. Your actions are not constructive, and this is clearly not an area of competence for you. Stick to what you know, and avoid gratuitous damage to the code of others. Write the code you personally prefer, and learn to desist from deleting and vandalizing the code of others. We disagree, and are optimising for different things. The Rosetta community will benefit if we write alternative versions, it will not benefit if we go around childishly deleting and defacing things that we disagree with. Enough - this has gone on for far too long, and does no service to your dignity. Hout (talk) 00:02, 22 February 2019 (UTC)

The language is Python. The functional idiom should adapt to the language that it is written in; you go so far, then seek to mask the rest with cries of "the rest doesn't apply to me". Python has a community that knows about docstrings, and type hints and modularisation in a certain way. It allows the comunity to learn faster as more things work as expected. Instead of explaining what does not need explaining, try defending your use of type info as a comment rather than using type hints?

You read as if you state you are above this aspect of Python because your cross-language functionally standard (to a standard never divulged, and only grudgingly admitted as not being from Python) takes precedence.

Its not the functional style of programming I am taking issue with; if someone wrote a class without a docstring and Python type annotations, but preceded it with a comment block with Java-esque type anotations as comments, then I would take issue with that too - because you have the information but haven't gone that extra step to use the Python idioms - it may well look more like som other languages entry, but it's hardly idiomatic for the Python community - not some other languages community; and its disingenuous when entries can be marked as being translated from others. (Even then, a better entry would try and translate idioms too). --Paddy3118 (talk) 00:47, 22 February 2019 (UTC)

Your deletions are absolutely not a 'reversion to Python semantics' – they never moved, nor could they – what you have done is to vandalize and delete the next level of abstraction up - the more mathematical semantics which are a definining feature pure functional programming in any language.

You have also crudely deleted the type semantics comments, making the code less readable, less easily re-used, less reliable, slower to refactor.

The main problem is not, however, your peculiar sense of code quality, which demonstrably places reliability in second place (see your own edit history, and your dependence on others showing you that your code produces the wrong result), or your angry opinion that only one style of programming should ever be practised in Python, or indeed your failure to appreciate that using well-establish abstractions, with shared names, across several languages is:

a) a classic and excellent source of Rosetta insight

b) a well established practice in Python modules (see the reference to Haskell and other languages in the itertools module documentation preface).

The real problem is that you have returned to a very personal, and slightly disturbing, campaign of personal persecution, and to an equation of your personal opinion (and exlusive authority on Python) with divine righteousness, which you apparently believe to fully authorise utterly appalling behaviour, include reckless deletions, impoverishing vandalism, and actual curtailment of the editing rights of those who make a different use of Python, and write it in a different style.

Python is not your biggest problem right now. I think you may need a bit of help. This pattern of cognition and behaviour is bound to be affecting other aspects of your life, and damaging other human relationships. Hout (talk) 05:41, 22 February 2019 (UTC)