This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]