kellerfuchs added the comment:
> Given that people clarified they prefer comb(), and that people conspicuously
> didn't comment on it being entirely-opaque to people who do not elready know
> what it is, I guess there is indeed consensus.
commit afb3d36e82b8d690a410fa9dca
kellerfuchs added the comment:
@Steven
> > This involved a few changes, which seem to reflect the consensus here:
> > - raise ValueError if k>n ;
> > - rename the function to math.combinations.
> [...]
> > As far as I can tell from the discussions here, Steven an
kellerfuchs added the comment:
@Raymond Hettinger
> Let's name this comb() instead of binomial() please (as requested by me,
> Mark, and Tim).
(Replying here to keep the discussion in a single place.)
As far as I can tell from the discussions here, Steven and you stated a
pre
kellerfuchs added the comment:
So, I rebased Yash's and my branches, and merged them together. The result is
still in PR#11018.
This involved a few changes, which seem to reflect the consensus here:
- raise ValueError if k>n ;
- rename the function to math.comb
kellerfuchs added the comment:
> Start with an initial patch that implements this simplest possible
> implementation, accompanied by clean documentation and thorough testing.
>
> Once everyone has agreed on the API (i.e. calling it "comb()", how to handle
> var
kellerfuchs added the comment:
Hi everyone,
Sorry for the lack of reply, I severely underestimated how exhausting the
holiday season would be.
Catching up with the comments right now.
--
___
Python tracker
<https://bugs.python.org/issue35
kellerfuchs added the comment:
@Steven D'Aprano:
> all call this nCr, and nPr for the permutation version. This matches
> the notation taught in secondary school maths classes in Australia.
> That's common and familiar notation for secondary school students, but
> pe
kellerfuchs added the comment:
> I'd personally prefer that floats not be accepted; I think this was a
> misfeature of `factorial` that we shouldn't compound.
OK; I only went with that because I assumed there were Good Reasons© that
factorial did it, but if rejecting integ
kellerfuchs added the comment:
@Mark Dickinson:
> You don't mean the "k=0" part of that, right?
Indeed not; the tests in the PR actually assert binomial(n, n) == binomial(n,
0) == 1.
--
___
Python tracker
<https://bugs.
kellerfuchs added the comment:
@Serhiy Storchaka:
> I think that it is better to add this function in a new module imath, which
> could contain other integer functions
imath is a fine idea, and you already started a discussion in python-ideas@,
but it's a much bigger undertakin
kellerfuchs added the comment:
@Raymond Hettinger:
> it's worth considering whether the function should be called "binomial",
> "choose", "combinations", or "comb"
Here goes the bike shed! :)
Kidding, this is a pretty important ergonomics/d
Change by kellerfuchs :
--
keywords: +patch
pull_requests: +10253
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35431>
___
___
Py
kellerfuchs added the comment:
Yes, that was a copypasta mistake (and I also import factorial needlessly) as
the file I prototyped it in had some other code for testing my proposed
implementation. :)
--
___
Python tracker
<ht
New submission from kellerfuchs :
A recuring pain point, for me and for many others who use Python for
mathematical computations, is that the standard library does not provide a
function for computing binomial coefficients.
I would like to suggest adding a function, in the math module, with
14 matches
Mail list logo
