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 <gil...@harfang.homelinux.org> wrote: > Hi. > > On Thu, 24 Nov 2016 09:15:10 +0000, Benedikt Ritter wrote: > >> Hello Gilles, >> >> Gilles <gil...@harfang.homelinux.org> 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: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
