Overall, I think the proposed change makes sense in the long run, and
Peter presents a good case. But there are some dangers.
Foremost, Clemens argues that a change will potentially brake user code:
while this is true, I think it should be overruled for the long
benefits, if another behaviour is m
Am 2016-04-04 um 18:02 schrieb Peter Luschny:
> > Sage seems to use the definition from Concrete Mathematics by Graham,
>> Knuth and Patashnik:
>> That gives e.g.
>> sage: binomial(-4, 5)
>> -56
>
> Right. GKP call it "upper negation". If you look at my demo-function
> you will see that t
On Monday, April 4, 2016 at 8:39:42 AM UTC-7, Daniel Krenn wrote:
>
> On 2016-04-03 20:03, Peter Luschny wrote:
> > I have already reported the unsatisfactory state of the binomial
> > function as implemented in Sage on 'Ask Sage' and had opened
> > a request for enhancement with ticket #17123
> Sage seems to use the definition from Concrete Mathematics by Graham,
> Knuth and Patashnik:
> That gives e.g.
> sage: binomial(-4, 5)
> -56
Right. GKP call it "upper negation". If you look at my demo-function
you will see that this condition is preserved in the suggested extension
(case 3).
On 2016-04-03 20:03, Peter Luschny wrote:
> I have already reported the unsatisfactory state of the binomial
> function as implemented in Sage on 'Ask Sage' and had opened
> a request for enhancement with ticket #17123.
On this ticket there were arguments against this change of the default
behav
Sage seems to use the definition from Concrete Mathematics by Graham,
Knuth and Patashnik:
binomial(r, k) = r*(r-1)*...*(r-k+1)/(k * (k-1) *...* 1)
if k >= 0 and r any real number, and
binomial(r, k) = 0
if k < 0
That gives e.g.
sage: binomial(-4, 5)
-56
Though Peter's suggestion seems
