[SciPy-dev] Definition of gammaln(x) for negative x

Robert Kern robert.kern@gmail....
Mon Nov 3 12:07:10 CST 2008

On Mon, Nov 3, 2008 at 11:53, G-J van Rooyen <gvrooyen@gmail.com> wrote:
>>> Creating a second, differently-named function (e.g. gammaln2) that
>>> returns magnitude and sign information is probably just as bad as
>>> having varying return types.
>>> So which of the above is the lesser evil? Or is there an elegant solution?
>> The latter. By far. I'm not sure why you think it would be just as bad
>> as having varying return types.
> It just seems to me that
>   Y = gammaln(X)
> and
>   (Y, sign) = gammaln(X,'sign')
> are conceptually identical to
>   Y = gammaln(X)
> and
>   (Y,sign) = gammaln_sign(X)
> The latter just absorbs the mode argument into the alternative
> function name. But since they're equivalent to me, and you have a
> clear preference for the latter, I'll go with the second option :)

Well, there are a couple of issues.

1) These are ufuncs, not regular functions, so they have limited
options for signatures. Basically, there is no room for options like

2) There is a reasonable rule elucidated by Guido van Rossum: If you
are using a boolean argument, and you always expect to use literals as
the argument, just make different functions instead, especially if it
changes the number of returned values. The boolean switch (and the
changing number of return values) basically makes two different
functions. The usual mechanism for the programmer to decide between
two different functions is to use two different names.

Now, a case can be made as an exception to the latter rule for things
like the full_output= argument to the scipy.optimize functions. There
are a number of these functions, and the full_output= behavior is
actually a fairly small bit of the functionality for each of the
functions. In this case, though, it's just one function, and the
difference in behavior is substantial.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco

More information about the Scipy-dev mailing list