ENH: `sgnlog()` and `sgnlogspace()`

Hi all, I am the author of pymrt, a library for working with quantitative MRI.

I have been recently refactoring the code base and I am now trying to put the more general functionalities into separate libraries. Right now these functions are in flyingcircus.num: https://bitbucket.org/norok2/flyingcircus/src/master/flyingcircus/num.py

I think that a number of these functions – e.g. unsqueeze(), ndim_slice(), etc. – might be a good fit for either numpy or scipy. The code is, as of now, fairly well documented in the docstrings and doctested. However, I do understand that numpy/scipy have adopted a different style than me. Therefore, before undertaking the effort of preparing that code for numpy I would like to understand if there is any interest in merging those functions in numpy.

In an effort to keep all this as atomic as possible, I would eventually write separate issues for each of the unrelated functions, unless I receive comments against this practice in this thread.

The functions I would like to pull first are:

1. sgnlog(x) which is just the log(x) * sign(x)
2. sgnlogspace() for generating logarithmically spaced points

Compared to the existing log(x) and logspace(x), they have the advantage that the base of the logarithm can be specified as a parameter. Another important difference between logspace() and sgnlogspace(), is that in sgnlogspace() the start and stop arguments do not refer to the exponent but to the actual start and stop.

[rkern]

I’ve needed them in the past, but rarely, and I found it straightforward enough to compose them from the available primitives. We are actively trying not to expand numpy’s already-crowded namespace, I think that leans towards not including them.

Briefly scanning over num.py, I don’t see anything that leaps out to me given that rubric. However, I do think that scipy.special might be a good home for sgnlog() (base-e only), sgnlog2() and maybe sgnlog10() if implemented as ufuncs. Some of the other functions in num.py might have a good home in various parts of scipy.

[WarrenWeckesser]

@norok2, thanks for proposing your enhancement to NumPy. After reviewing the above comments, and considering that no NumPy devs have expressed interest in adding these functions to NumPy in the last three years, I’m closing the issue.