From: John Suters (johnds_at_[hidden])
Date: 2001-10-31 17:01:34
> transform algorithms might be useful when working with quaternions, for
Blimey. What are they? All I want to do is multiply in O(nlg(n)) :)
> If I understand what you meant in your proposal, you would start with a
> vector V containing n elements (lets say for simplicity its a power of
> two right now); and at the end, V would contain n different elements.
> You've lost the original vector. So if you wanted to (or had to because
> of a function signature) keep the original values, you would have to
> make a copy. This should be avoided.
Yes, again I agree in principle. My motivation was efficient multiplication,
as I've now noted in other replies. I should have said in the first place.
My assumption (because it was what I was doing) was that the user would have
copied the input if needed. I suppose my motivation was to avoid creating
new vectors if at all possible - hence VECTOR& rather than const VECTOR&.
> Instead, the input and output should be considered wholly separate, and
> the production of the output should not modify in any way the input.
> If I misunderstood your proposal, I apologize.
No you didn't. My application domain is restrictive.
> In mathematics, the fourier transform is a mapping from one continuous
> function of n variables to another continuous function of n conjugate
> variables. In computing, we discretize these functions, and the FFT
> algorithms provide some fast ways of doing this when we have
> discretized the function in 2^m steps. But there is no a priori reason
> that a user of a fourier transform will have at his disposal an easily
> accessible power of two; or they may know something about the function
> they are inputting, and thus know that only a specific range of the
> conjugate variables will be of interest.
Ah. Okay. Perhaps I should go back and study my texts a bit more, but I
>>think<< that I'm only really interested in FFT rather than the general
fourier transform (which is theoretically easier to write, yes?).
> I am not suggesting that you write the algorithms to deal with these
> things; that would be hard. All I am suggesting is that we consider the
> interface such that it might be generalized in these directions, for
> differently inclined users.
> George Heintzelman
> Info: http://www.boost.org Unsubscribe:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk