[SciPy-Dev] Hankel transforms, again

[Robert Kern]

On Mon, Feb 17, 2014 at 2:45 PM, Tom Grydeland <tom.grydeland at gmail.com> wrote:
>
> On 2014-02-14, at 13:15, Robert Kern <robert.kern at gmail.com> wrote:
>
>> On Fri, Feb 14, 2014 at 9:45 AM, Tom Grydeland <tom.grydeland at gmail.com> wrote:
>>> Hi developers,
>>>
>>> This is a repost of a message from December 2008 which gave no useful answers.  Since then, I’ve had 4-5 requests for the code from people who had a need for it.  It’s not a massive demand, but enough that perhaps you’ll consider my offer again.
>>>
>>> Since the previous posting, I’ve also included alternative filters thanks to Fan-Nian Kong that are shorter and more accurate when the function makes significant changes in more limited intervals. I’m not including the code (since it is mostly thousands of lines of tables), but I will provide the files to anyone who’s interested.
>>
>> Yes, I think we'd be interested. Please do make a PR. Before you do,
>> please double-check the licensing on the new code that you have added.
>> It does look like Anderson's original code is in the public domain
>> (the paper being published as part of Anderson's work at the USGS as a
>> federal employee), so that part is in the clear. Just so we are clear,
>> the lack of copyright statements (work by US federal employees aside)
>> usually means that you have *no license* to redistribute the work, not
>> that there are no restrictions on redistribution.
>
> Hello again,
>
> To the last point first: I agree that Anderson’s work is in the public domain.
>
> I contacted Fannian Kong regarding terms for his filters, whether he would be willing to put them in the public domain or release them under a BSD-style license.  I explained that in either case others were free to use them, even for profit, without any compensation.
>
> I got the following reply:
>
> ——————————
> Copy right things are complicated things to me. Please treat those material as published results from an open journal. So, as long as the journal paper is quoted as the reference, everybody can use the journal results.
> ——————————
>
> Frankly, I don’t know if that is enough that we can include these filters or not. Opinions?

Short answer: no, that's too vague of a statement, and he might be
wanting more restrictions than we are prepared to place on code in
scipy. The BSD license that we use for scipy does not require anyone
to cite the journal article. We will include a citation in our code,
certainly, but we can make no guarantee that any downstream users of
these functions will include that citation in their code or papers
that use this code. We do include *encouragement* for users of such
functions to cite the journal article when the original author wishes
it. The BSD license does require that the copyright notice remain
attached to the code, though, and that may be enough for him.

We would need a positive statement from him that we can redistribute
his code under a BSD license. If he does not take the time to read and
understand the consequences of the BSD license, I would not be
comfortable taking that statement of his as assenting to it.

That said, the bulk of this code appears to just be tables of
constants with a few fairly trivial function calls. Under US law,
these aren't really copyrightable, but under EU law, the tables might
be (it seems Fan-Nian Kong works in Norway). Can these tables be
recreated somehow besides copying the data files on his website? Is
there an algorithm for doing so? If you can rewrite the code from just
the description of the algorithm in the paper and not by translating
the MATLAB code from his site, then we are in the clear, IMO. (IANAL.
TINLA.) Since he does seem to want citations, we should include the
citation in the docstrings and encourage users of those functions to
cite it too.

> To the first point:  I’ll require a few hints and pointers.
>
> If the original function is f and its transform F, then F(b) = ([f(y/b)]^t * w)/b, where y and w are vectors of a certain length (801 for Anderson; 61, 121 or 241 for Kong — these are the tables I mentioned previously).  In other words, each transformed point requires a certain number of function evaluations.  Orders 0 and 1 transforms differ only in the weighting vectors w, so if both are needed, much is saved by computing both at once on the same grid.
>
> In my application I would typically transform a number of functions to the same offsets b, so I would call one method on a transform object to set up a ‘k’ grid ( = y/b), evaluate my function(s) on that grid, and then call a ‘transform’ method with these function evaluations to obtain the transformed quantities F(b).  This is sufficiently different from what one would use for other types of integral transforms that I’m open to other suggestions when it comes to interfaces.
>
> Also, I don’t see an obvious place where this should live.  I’m thinking SciPy rather than NumPy, but it is not obviously a fit for any of the existing top-level namespaces.  The closest thing is fftpack, but this isn’t part of fftpack. Arguments could be made for ndimage or signal also, but not very convincingly.

I would opt for scipy.signal. The interface can be whatever you find
the most useful. If we can build on top of that an interface similar
to other transforms, albeit inefficiently, so much the better, but let
your actual use cases drive the interface.

-- 
Robert Kern