[issue4869] random.expovariate(0.0)

Raymond Hettinger added the comment: I concur with Mark. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4869] random.expovariate(0.0)

Mark Dickinson added the comment: Doc fixes in r68378. Closing. -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___

[issue4869] random.expovariate(0.0)

Mark Dickinson added the comment: > to allow lambda=0 is sometimes useful in simulations, meaning that it's > infinite time to the next event, i.e. it never occurs. Thanks; that makes sense. If 1./0. returned inf then expovariate would already do what you want. But rightly or wrongly, Python

[issue4869] random.expovariate(0.0)

Keith Briggs added the comment: That's all true - the only thing in favour of my suggestion is that to allow lambda=0 is sometimes useful in simulations, meaning that it's infinite time to the next event, i.e. it never occurs. A FP infinity would do this without requiring a special case. At le

[issue4869] random.expovariate(0.0)

Mark Dickinson added the comment: I would suggest adding a note to the documentation stating clearly that the parameter should be nonzero. The documentation is also unclear on whether a negative parameter value is permitted, although the current code works exactly the way that I'd expect for

[issue4869] random.expovariate(0.0)

Mark Dickinson added the comment: An exponential distribution with parameter 0 isn't an exponential distribution any more. On the real line, there isn't even a limiting distribution as the parameter approaches 0. Is there really any use for having expovariate degenerate this way? It seems muc

[issue4869] random.expovariate(0.0)

New submission from Keith Briggs : random.expovariate(lambd) should handle lambd=0 cleanly, and probably return a FP infinity. At the moment it gives: ZeroDivisionError: float division -- components: Extension Modules messages: 79346 nosy: kbriggs severity: normal status: open title: r