[SciPy-Dev] Hankel transforms, again

[Tom Grydeland]

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?

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.


> Thanks!

> Robert Kern

Cheers,

Tom Grydeland