This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: gsl Development Query
- To: gsl-discuss at sources dot redhat dot com
- Subject: Re: gsl Development Query
- From: "E. Robert Tisdale" <edwin at netwood dot net>
- Date: Thu, 31 Aug 2000 23:22:52 +0000
Brian Gough writes:
> E. Robert Tisdale writes:
>
> > The GSL should allow application programmers
> > to create FFT objects like the "plan" object in FFTW.
> > The overhead of creating an FFT object is amortized
> > over several invocations of an FFT of a particular length.
>
> Yes, this is how it works --
> see the documentation for gsl_fft_complex_alloc
> in the manual for details.
The FFT object (what you call a gsl_fft_wavetable_complex) is OK.
But then you go on to itemize the private members:
typedef struct {
size_t n;
size_t nf;
size_t factor[64];
gsl_complex *twiddle[64];
gsl_complex *trig;
double *scratch;
} gsl_fft_wavetable_complex;
Why did you do this?
It isn't necessary for the application programmer
to have any of this information.
You present it in the manual as if it is part of the API.
Did you really need to make a commitment
to this particular algorithm
and this particular data representation?
I don't think so.
I think that you've painted yourself into a corner
and you will be obliged to support this particular
data representation and the implied algorithm forever.
There is almost never any one best algorithm
much less one best implementation of anything
in numerical computing.
No matter how gifted and careful you are,
your implementation and/or data representation
is likely to be suboptimal on some platform.
It is best to hide as many details
of the data representation and/or implementation
so that you or some other programmer can re-implement
the functionality without breaking
any of the applications which depend upon it.
If, on the other hand, you only meant to describe
the data representation and algorithm
that you were implementing, you should have
separated it from the specification of the API --
preferably, in another document.