On Thu, Mar 16, 2006 at 02:45:16PM +0100, Francesco P. Lovergine wrote:
On Fri, Mar 17, 2006 at 02:27:45AM +1300, Hamish wrote:
>
> Now we (theoretically) can compile GRASS with TclTk 8.4, maybe someone
> who knows how can help to bring FFTW into the modern era as well, i.e.
> to use fftw3 not fftw2.
>
> #ifdef 's to remain backwards compat with v.2 ?
>
Markus surely can answer better. Anyway, at least it requires updating
to the new API for 3.1 in gmath. It's not rocket science...
--
Francesco P. Lovergine
IMHO fftw2 dependency is a pain since fftw3 is standard now.
Also, we want to modify in GRASS 6.1, so we can remove the
backwards compat with v.2.
I vote for updating to fftw3 without backwards compatibility
to not complicate the things (and to make it happen).
> > Now we (theoretically) can compile GRASS with TclTk 8.4, maybe someone
> > who knows how can help to bring FFTW into the modern era as well, i.e.
> > to use fftw3 not fftw2.
> >
> > #ifdef 's to remain backwards compat with v.2 ?
> >
>
> Markus surely can answer better. Anyway, at least it requires updating
> to the new API for 3.1 in gmath. It's not rocket science...
>
> --
> Francesco P. Lovergine
IMHO fftw2 dependency is a pain since fftw3 is standard now.
Also, we want to modify in GRASS 6.1, so we can remove the
backwards compat with v.2.
I vote for updating to fftw3 without backwards compatibility
to not complicate the things (and to make it happen).
> > > maybe someone who knows how can help to bring FFTW into the
> > > modern era as well, i.e. to use fftw3 not fftw2.
> > >
> > > #ifdef 's to remain backwards compat with v.2 ?
> >
> > Markus surely can answer better. Anyway, at least it requires
> > updating to the new API for 3.1 in gmath. It's not rocket
> > science...
..
> IMHO fftw2 dependency is a pain since fftw3 is standard now.
> Also, we want to modify in GRASS 6.1, so we can remove the
> backwards compat with v.2.
>
> I vote for updating to fftw3 without backwards compatibility
> to not complicate the things (and to make it happen).
I've commited fixes to support both 2.x and 3.x.
i.fft, i.ifft work for me using Debian/Stable's fftw3-dev package.
No noticeable time speedup vs. fftw2 on my test data (both ~5sec).
On Fri, Mar 17, 2006 at 09:19:14PM +0000, Glynn Clements wrote:
Markus Neteler wrote:
> > > Now we (theoretically) can compile GRASS with TclTk 8.4, maybe someone
> > > who knows how can help to bring FFTW into the modern era as well, i.e.
> > > to use fftw3 not fftw2.
> > >
> > > #ifdef 's to remain backwards compat with v.2 ?
> > >
> >
> > Markus surely can answer better. Anyway, at least it requires updating
> > to the new API for 3.1 in gmath. It's not rocket science...
> >
> > --
> > Francesco P. Lovergine
>
> IMHO fftw2 dependency is a pain since fftw3 is standard now.
> Also, we want to modify in GRASS 6.1, so we can remove the
> backwards compat with v.2.
>
> I vote for updating to fftw3 without backwards compatibility
> to not complicate the things (and to make it happen).
I've commited fixes to support both 2.x and 3.x.
Thanks, Glynn!
This is a great help for packaging GRASS.
> > > > Now we (theoretically) can compile GRASS with TclTk 8.4, maybe someone
> > > > who knows how can help to bring FFTW into the modern era as well, i.e.
> > > > to use fftw3 not fftw2.
> > > >
> > > > #ifdef 's to remain backwards compat with v.2 ?
> > > >
> > >
> > > Markus surely can answer better. Anyway, at least it requires updating
> > > to the new API for 3.1 in gmath. It's not rocket science...
> > >
> > > --
> > > Francesco P. Lovergine
> >
> > IMHO fftw2 dependency is a pain since fftw3 is standard now.
> > Also, we want to modify in GRASS 6.1, so we can remove the
> > backwards compat with v.2.
> >
> > I vote for updating to fftw3 without backwards compatibility
> > to not complicate the things (and to make it happen).
>
> I've commited fixes to support both 2.x and 3.x.
Thanks, Glynn!
This is a great help for packaging GRASS.
Should we backport it to 6.0.x?
Probably. It should be "safe", i.e. not have any effect if FFTW 3.x
isn't present.