[MATH] [Complex] FFT

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[MATH] [Complex] FFT

Eric Barnhill
Since FFT discussions appear to have begun...I have long noticed that the
FFT in CM is only a Radix-4 implementation.

Bernd, is improving the performance of the CM FFT be something that
interests you?

Either way, I should be able to pick up activity here in a couple of weeks,
and I could look into adding some more options such as prime radices, as
part of drafting the Complex package.

One possibility might be a "FourierStrategy" object. My impression from
newer FFT implementations such as CuFFT is that users can either set a
strategy for their FFT, or use a default strategy, or use auto-detect for
the strategy, which has a bit more cost.

Best,
Eric



On Thu, Nov 24, 2016 at 1:20 PM, Gilles <[hidden email]>
wrote:

> Hi.
>
> On Thu, 24 Nov 2016 09:15:10 +0000, Benedikt Ritter wrote:
>
>> Hello Gilles,
>>
>> Gilles <[hidden email]> schrieb am Mi., 23. Nov. 2016 um
>> 14:34 Uhr:
>>
>> Hi Bernd, Eric (and others).
>>>
>>>
>>> I was about to request a JIRA project for the "filter" component.[1]
>>>
>>>
>> We usually use the sandbox jira project and just add a new component
>> there,
>>
>
> Seemingly this did not happen with [text]:
>   https://issues.apache.org/jira/browse/TEXT
>
> because we never know whether snadbox components will eventually become
>> proper components.
>>
>
> Sure.
>
> Would that work for you?
>>
>
> I couldn't strongly argue, but unless Apache is short on JIRA resources,
> it looks nicer (and longer-term for something that is likely to become
> a component) to have direct identification like "TEXT-23" rather than
> "SANDBOX-4235"...
>
>
> Regards,
> Gilles
>
>
> Benedikt
>>
>>
>>
>>> The name "FILTER" is not taken (as a JIRA project) but it would
>>> be better if we are sure that the name will stick (rather than have
>>> to later change the JIRA id or keep one that would not be close to
>>> the component's name.
>>>
>>> How about "Sig(nal) Proc(essing)"?
>>>
>>> Alternatively, would there be any sense to develop this codebase as
>>> a module within the "Commons Complex" project.[2]
>>> IOW, is it foreseen that "Filter" will depend on any code other than
>>> what is going to end up in the "Complex" project?[3]
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] Currently, an empty directory in the "sandbox" SVN repository.
>>> [2] Currently, an empty git repository.
>>> [3] AFAICT: Classes from
>>>        o.a.c.math4.complex
>>>        o.a.c.math4.analysis.solvers
>>>        o.a.c.math4.transform
>>>      packages.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [MATH] [Complex] FFT

Gilles Sadowski
Hi.

JIRA project is available:
   https://issues.apache.org/jira/browse/COMPLEX


Regards,
Gilles

On Thu, 24 Nov 2016 13:33:45 +0100, Eric Barnhill wrote:

> Since FFT discussions appear to have begun...I have long noticed that
> the
> FFT in CM is only a Radix-4 implementation.
>
> Bernd, is improving the performance of the CM FFT be something that
> interests you?
>
> Either way, I should be able to pick up activity here in a couple of
> weeks,
> and I could look into adding some more options such as prime radices,
> as
> part of drafting the Complex package.
>
> One possibility might be a "FourierStrategy" object. My impression
> from
> newer FFT implementations such as CuFFT is that users can either set
> a
> strategy for their FFT, or use a default strategy, or use auto-detect
> for
> the strategy, which has a bit more cost.
>
> Best,
> Eric
>
>
>
> On Thu, Nov 24, 2016 at 1:20 PM, Gilles
> <[hidden email]>
> wrote:
>
>> Hi.
>>
>> On Thu, 24 Nov 2016 09:15:10 +0000, Benedikt Ritter wrote:
>>
>>> Hello Gilles,
>>>
>>> Gilles <[hidden email]> schrieb am Mi., 23. Nov. 2016
>>> um
>>> 14:34 Uhr:
>>>
>>> Hi Bernd, Eric (and others).
>>>>
>>>>
>>>> I was about to request a JIRA project for the "filter"
>>>> component.[1]
>>>>
>>>>
>>> We usually use the sandbox jira project and just add a new
>>> component
>>> there,
>>>
>>
>> Seemingly this did not happen with [text]:
>>   https://issues.apache.org/jira/browse/TEXT
>>
>> because we never know whether snadbox components will eventually
>> become
>>> proper components.
>>>
>>
>> Sure.
>>
>> Would that work for you?
>>>
>>
>> I couldn't strongly argue, but unless Apache is short on JIRA
>> resources,
>> it looks nicer (and longer-term for something that is likely to
>> become
>> a component) to have direct identification like "TEXT-23" rather
>> than
>> "SANDBOX-4235"...
>>
>>
>> Regards,
>> Gilles
>>
>>
>> Benedikt
>>>
>>>
>>>
>>>> The name "FILTER" is not taken (as a JIRA project) but it would
>>>> be better if we are sure that the name will stick (rather than
>>>> have
>>>> to later change the JIRA id or keep one that would not be close to
>>>> the component's name.
>>>>
>>>> How about "Sig(nal) Proc(essing)"?
>>>>
>>>> Alternatively, would there be any sense to develop this codebase
>>>> as
>>>> a module within the "Commons Complex" project.[2]
>>>> IOW, is it foreseen that "Filter" will depend on any code other
>>>> than
>>>> what is going to end up in the "Complex" project?[3]
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1] Currently, an empty directory in the "sandbox" SVN repository.
>>>> [2] Currently, an empty git repository.
>>>> [3] AFAICT: Classes from
>>>>        o.a.c.math4.complex
>>>>        o.a.c.math4.analysis.solvers
>>>>        o.a.c.math4.transform
>>>>      packages.
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]