Xref: utzoo comp.lang.fortran:1717 comp.lang.c++:2462
Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!mailrus!ncar!gatech!gt-eedsp!baud
From: baud@gt-eedsp.UUCP (Kurt Baudendistel)
Newsgroups: comp.lang.fortran,comp.lang.c++
Subject: Re: Fast Fourier Transformer
Message-ID: <593@gt-eedsp.UUCP>
Date: 19 Jan 89 20:22:56 GMT
References: <518@cs-spool.calgary.UUCP> <6217@thorin.cs.unc.edu>
Reply-To: baud@gt-eedsp.UUCP (Kurt Baudendistel)
Organization: School of Electrical Engineering, Ga. Tech, Atlanta, GA  30332
Lines: 30

In article <6217@thorin.cs.unc.edu> coggins@coggins.UUCP (Dr. James Coggins) writes:
>I have a C++ class definition for 1D and 2D FFTs.
>The constructor for the class builds a bunch of tables that make
>application of the transforms very fast.  Then there are forward
>and inverse messages to apply the operations.  These messages take
>images as arguments.
>
>Some people think that a class has to be based on some data item.
>They forget that algorithm is a noun.  An algorithm that is of
>interest as an object of study itself can form a nice class. I call
>these process encapsulations, or enzymes.  My FFT server is a prime
>example, but there are many others.

i use a similar approach in that i define a class <T>Twiddle that defines
a set of twiddle factors to use in conjunction with an fft function.
however, i've defined a data item and a friend function that uses this
data type, thus basing the class on the data type as is the ``usual''
approach. 

i'd be interested to hear more about the definition of algorithmic classes
and how they fit into the object-oriented paradigm.  since such classes
purely functional, should we consider them more of a functional programming
technique than an object-oriented one? or are these characteristics
complementary?

-- 
Kurt Baudendistel --- GRA
Georgia Tech, School of Electrical Engineering, Atlanta, GA  30332
uucp:  ...!{allegra,hplabs,ulysses}!gatech!gt-eedsp!baud
internet: baud%gt-eedsp@gatech.edu