Hi, I needed DCT transforms, so I finished implementing them in scipy (both single and double prec): http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf... I followed the definitions of wikipedia/fftw, using the fftpack implementations. I am not sure about naming conventions: - dct2 is the type II DCT, not the 2dimension DCT (multidimensional dcts are not implemented - I don't need them myself) - dct3 and dct2 are inverse from each other (compared to dct/idct notation of matlab; dct2(x, norm=ortho) is the same as matlab dct(x), and dct3(x, norm='ortho') is the same as matlab idct. Unless someone has a better idea/suggestion, I will put those definitions in scipy.fftpack namespace in a couple of days, cheers, David
If it's not too hard, could you also add the multidimensional transform? Thanks, William On Sun, Jan 18, 2009 at 6:18 AM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Hi,
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
I followed the definitions of wikipedia/fftw, using the fftpack implementations. I am not sure about naming conventions: - dct2 is the type II DCT, not the 2dimension DCT (multidimensional dcts are not implemented - I don't need them myself) - dct3 and dct2 are inverse from each other (compared to dct/idct notation of matlab; dct2(x, norm=ortho) is the same as matlab dct(x), and dct3(x, norm='ortho') is the same as matlab idct.
Unless someone has a better idea/suggestion, I will put those definitions in scipy.fftpack namespace in a couple of days,
cheers,
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
william ratcliff wrote:
If it's not too hard, could you also add the multidimensional transform?
Actually, it is a bit hard to do it; not so much the multidimensional aspect itself, but the handling of arbitrary shape and axis (it took me a while to fix and test related bugs for multidimensional fft). Since I just need 1d DCT for myself, and not so much time ATM, I unfortunately can't spend too much time on it, cheers, David
2009/1/18 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
- dct3 and dct2 are inverse from each other (compared to dct/idct notation of matlab; dct2(x, norm=ortho) is the same as matlab dct(x), and dct3(x, norm='ortho') is the same as matlab idct.
While this naming is accurate, it is confusing in relation to the other FFT functions. I prefer "dct" and "idct". Cheers Stéfan
On Mon, Jan 19, 2009 at 12:25 AM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2009/1/18 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
- dct3 and dct2 are inverse from each other (compared to dct/idct notation of matlab; dct2(x, norm=ortho) is the same as matlab dct(x), and dct3(x, norm='ortho') is the same as matlab idct.
While this naming is accurate, it is confusing in relation to the other FFT functions. I prefer "dct" and "idct".
Calling them dct/idct can be confusing as well: dct3(dct2(x)) != x (because of normalization). And what to do for dct1/dct4 - in theory, there are 8 dct possible, and 8 dst as well (I have no use for dst, so I did not implement them, but they should follow at some point). Maybe the type could be an argument: dct(..., type=number) ? David
I like your arguments idea, dct(...,type=number) idct(...,type=number). maybe the type could default to 2 for dct and idct (with the implementation of idct for type 2 being dct of type3). This would make life easier for users. William On Sun, Jan 18, 2009 at 11:30 AM, David Cournapeau <cournape@gmail.com>wrote:
On Mon, Jan 19, 2009 at 12:25 AM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2009/1/18 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
- dct3 and dct2 are inverse from each other (compared to dct/idct notation of matlab; dct2(x, norm=ortho) is the same as matlab dct(x), and dct3(x, norm='ortho') is the same as matlab idct.
While this naming is accurate, it is confusing in relation to the other FFT functions. I prefer "dct" and "idct".
Calling them dct/idct can be confusing as well: dct3(dct2(x)) != x (because of normalization). And what to do for dct1/dct4 - in theory, there are 8 dct possible, and 8 dst as well (I have no use for dst, so I did not implement them, but they should follow at some point).
Maybe the type could be an argument: dct(..., type=number) ?
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
On Sun, Jan 18, 2009 at 6:04 PM, william ratcliff <william.ratcliff@gmail.com> wrote:
I like your arguments idea, dct(...,type=number) idct(...,type=number).
+1
maybe the type could default to 2 for dct and idct (with the implementation of idct for type 2 being dct of type3). This would make life easier for users.
+1 Also, this naming makes it possible to give the 2D and higher-dimensionality DCTs names analogously to the FFT functions.
William
David
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
On Mon, Jan 19, 2009 at 4:46 AM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
On Sun, Jan 18, 2009 at 6:04 PM, william ratcliff <william.ratcliff@gmail.com> wrote:
I like your arguments idea, dct(...,type=number) idct(...,type=number).
+1
maybe the type could default to 2 for dct and idct (with the implementation of idct for type 2 being dct of type3). This would make life easier for users.
+1
Also, this naming makes it possible to give the 2D and higher-dimensionality DCTs names analogously to the FFT functions.
Ok, I implemented the above scheme for DCT I/II/III, the docstring is: def dct(x, type=2, n=None, axis=-1, norm=None): """ Return the Discrete Cosine Transform of arbitrary type sequence x. Parameters ---------- x : array-like input array. type : {1, 2, 3} type of the DCT (see Notes). n : int, optional Length of the transform. axis : int, optional axis over which to compute the transform. norm : {None, 'ortho'} normalization mode (see Notes). Returns ------- y : real ndarray Notes ----- For a single dimension array x, dct(x, norm='ortho') is equal to matlab dct(x). There are theoretically 8 types of the DCT, only the first 3 types are implemented in scipy. 'The' DCT generally refers to DCT type 2, and 'the' Inverse DCT generally refers to DCT type 3. type I ~~~~~~ There are several definitions of the DCT-I; we use the following (for norm=None): for 0 <= k < N, N-1 y[k] = x[0] + (-1)**k x[N-1] + 2 * sum x[n]*cos(pi*k*n/(N-1)) n=0 type II ~~~~~~~ There are several definitions of the DCT-II; we use the following (for norm=None): N-1 y[k] = 2* sum x[n]*cos(pi*k*(2n+1)/(2*N)), 0 <= k < N. n=0 If norm='ortho', y[k] is multiplied by a scaling factor f: f = sqrt(1/(4*N)) if k = 0 f = sqrt(1/(2*N)) otherwise Which makes the corresponding matrix of coefficients orthonormal (OO' = Id). type III ~~~~~~~~ There are several definitions, we use the following (norm=None): N-1 y[k] = x[0] + 2 * sum x[n]*cos(pi*(k+0.5)*n/N), 0 <= k < N. n=0 Or (norm='ortho'), for 0 <= k < N: N-1 y[k] = x[0] / sqrt(N) + sqrt(1/N) * sum x[n]*cos(pi*(k+0.5)*n/N) n=0 The (unnormalized) DCT-III is the inverse of the (unnormalized) DCT-II, up to a factor 2*N. The orthonormalized DCT-III is exactly the inverse of the orthonormalized DCT-II. References ---------- http://en.wikipedia.org/wiki/Discrete_cosine_transform 'A Fast Cosine Transform in One and Two Dimensions', by J. Makhoul, in IEEE Transactions on acoustics, speech and signal processing.
2009/1/19 David Cournapeau <cournape@gmail.com>:
Ok, I implemented the above scheme for DCT I/II/III, the docstring is:
def dct(x, type=2, n=None, axis=-1, norm=None):
I think it would make sense to add a wrapper to idct too, since this is such a common use case. Cheers Stéfan
Stéfan van der Walt wrote:
2009/1/19 David Cournapeau <cournape@gmail.com>:
Ok, I implemented the above scheme for DCT I/II/III, the docstring is:
def dct(x, type=2, n=None, axis=-1, norm=None):
I think it would make sense to add a wrapper to idct too, since this is such a common use case.
Great minds think alike :) It is already implemented, if I understand you correctly: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf... David
2009/1/19 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Stéfan van der Walt wrote:
2009/1/19 David Cournapeau <cournape@gmail.com>:
Ok, I implemented the above scheme for DCT I/II/III, the docstring is:
def dct(x, type=2, n=None, axis=-1, norm=None):
I think it would make sense to add a wrapper to idct too, since this is such a common use case.
Great minds think alike :) It is already implemented, if I understand you correctly:
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
Perfect, thanks! Stéfan
Mon, 19 Jan 2009 17:39:25 +0900, David Cournapeau wrote: [clip]
norm=None): N-1 y[k] = x[0] + (-1)**k x[N-1] + 2 * sum x[n]*cos(pi*k*n/(N-1)) n=0
This seems to be an use case for the math:: directive. Please use it, or make the previous line end with :: so that the text renders as preformatted text. Thanks, -- Pauli Virtanen
On Mon, Jan 19, 2009 at 11:55 AM, Pauli Virtanen <pav@iki.fi> wrote:
Mon, 19 Jan 2009 17:39:25 +0900, David Cournapeau wrote: [clip]
norm=None): N-1 y[k] = x[0] + (-1)**k x[N-1] + 2 * sum x[n]*cos(pi*k*n/(N-1)) n=0
This seems to be an use case for the math:: directive. Please use it, or make the previous line end with :: so that the text renders as preformatted text.
I thought so also. I'll volunteer to do it if David is too busy.
Thanks,
Pauli Virtanen
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
On Mon, Jan 19, 2009 at 8:13 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
On Mon, Jan 19, 2009 at 11:55 AM, Pauli Virtanen <pav@iki.fi> wrote:
Mon, 19 Jan 2009 17:39:25 +0900, David Cournapeau wrote: [clip]
norm=None): N-1 y[k] = x[0] + (-1)**k x[N-1] + 2 * sum x[n]*cos(pi*k*n/(N-1)) n=0
This seems to be an use case for the math:: directive. Please use it, or make the previous line end with :: so that the text renders as preformatted text.
I thought so also. I'll volunteer to do it if David is too busy.
Sure, go ahead. I wrote the formula mostly for reference because there are so many variations in texts - I did not put too much attention to the actual formatting and spelling, David
On Tue, Jan 20, 2009 at 10:17 AM, David Cournapeau <cournape@gmail.com> wrote:
On Mon, Jan 19, 2009 at 8:13 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
I thought so also. I'll volunteer to do it if David is too busy.
Sure, go ahead. I wrote the formula mostly for reference because there are so many variations in texts - I did not put too much attention to the actual formatting and spelling,
David
Okay, I've formatted the maths (with an eye towards keeping it readable also as text) and added a link to the online version of the reference cited. Are the limits in the sums all correct now? -- Tom Grydeland <Tom.Grydeland@(gmail.com)>
On Wed, Jan 21, 2009 at 3:31 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
Okay, I've formatted the maths (with an eye towards keeping it readable also as text) and added a link to the online version of the reference cited.
Are the limits in the sums all correct now?
As promised, I edited the docstrings for maths (using the docs.scipy.org wiki). Since then, changes appear to have been made to the SVN archive without committing the doc edits, so the wiki now shows conflicts. Can somebody with SVN access clean this up, please? Also, please confirm that the limits on the sums are all correct. Regards, -- Tom Grydeland <Tom.Grydeland@(gmail.com)>
Mon, 09 Feb 2009 12:51:58 +0100, Tom Grydeland wrote:
On Wed, Jan 21, 2009 at 3:31 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
Okay, I've formatted the maths (with an eye towards keeping it readable also as text) and added a link to the online version of the reference cited.
Are the limits in the sums all correct now?
As promised, I edited the docstrings for maths (using the docs.scipy.org wiki). Since then, changes appear to have been made to the SVN archive without committing the doc edits, so the wiki now shows conflicts.
Can somebody with SVN access clean this up, please?
The procedure with conflicts in wiki is to resolve them in the wiki, so that the changes can be easily propagated to SVN. Anyone with edit permissions in the wiki can do this, by editing the docstring and resolving the conflicting parts. -- Pauli Virtanen
Tom Grydeland wrote:
On Wed, Jan 21, 2009 at 3:31 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
Okay, I've formatted the maths (with an eye towards keeping it readable also as text) and added a link to the online version of the reference cited.
Are the limits in the sums all correct now?
As promised, I edited the docstrings for maths (using the docs.scipy.org wiki). Since then, changes appear to have been made to the SVN archive without committing the doc edits, so the wiki now shows conflicts.
Can somebody with SVN access clean this up, please?
Also, please confirm that the limits on the sums are all correct.
The limits look correct, now, thank you. I would prefer keeping the non latex formula, though, because they are not readable from the terminal - the latex formula could be kept in a module-level discussion, but I don't think they are appropriate for docstrings. cheers, David
On Mon, Jan 19, 2009 at 11:55 AM, Pauli Virtanen <pav@iki.fi> wrote:
This seems to be an use case for the math:: directive.
On Mon, Jan 19, 2009 at 8:13 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
I thought so also. I'll volunteer to do it if David is too busy.
On Tue, Jan 20, 2009 at 10:17 AM, David Cournapeau <cournape@gmail.com> wrote:
Sure, go ahead.
On Tue, Feb 10, 2009 at 11:07 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
The limits look correct, now, thank you. I would prefer keeping the non latex formula, though, because they are not readable from the terminal - the latex formula could be kept in a module-level discussion, but I don't think they are appropriate for docstrings.
Any way is fine with me, redoing things twice is bad enough, three times is a real drag. The math version is there now, the text version is in the previous revision, do with them as you see fit, I'll go edit something else. Regards, -- Tom Grydeland <Tom.Grydeland@(gmail.com)>
David Cournapeau wrote:
... def dct(x, type=2, n=None, axis=-1, norm=None): maybe this is bike-shedding, but wouldn't def dct(x, type=2, n=None, axis=-1, normalize=False) Where any false means no normalization and any true means do ortho normalization? Or do you forsee non-ortho normalizations being implemented?
--Scott David Daniels Scott.Daniels@Acm.Org
Scott David Daniels wrote:
David Cournapeau wrote:
... def dct(x, type=2, n=None, axis=-1, norm=None):
maybe this is bike-shedding, but wouldn't def dct(x, type=2, n=None, axis=-1, normalize=False) Where any false means no normalization and any true means do ortho normalization? Or do you forsee non-ortho normalizations being implemented?
Yes, several normalization schemes are possible - it is mostly a matter of convention. I implemented one normalization scheme to get the same results as matlab, which I needed for my case. cheers, David
On Sun, Jan 18, 2009 at 12:18 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Hi,
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
Any reason why these would not belong in numpy?
David
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
On Wed, Jan 21, 2009 at 6:49 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
On Sun, Jan 18, 2009 at 12:18 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Hi,
I needed DCT transforms, so I finished implementing them in scipy (both single and double prec):
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/fftpack/realtransf...
Any reason why these would not belong in numpy?
Two reasons: - we generally don't want to expand numpy functionalities. - the code depends on the fftpack library, which is not in numpy. David
On Wed, Jan 21, 2009 at 11:13 AM, David Cournapeau <cournape@gmail.com> wrote:
- the code depends on the fftpack library, which is not in numpy.
http://docs.scipy.org/numpy/docs/numpy.fft.fftpack/
David
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
On Wed, Jan 21, 2009 at 11:32 PM, Tom Grydeland <tom.grydeland@gmail.com> wrote:
On Wed, Jan 21, 2009 at 11:13 AM, David Cournapeau <cournape@gmail.com> wrote:
- the code depends on the fftpack library, which is not in numpy.
Numpy only includes a light version of fftpack, as indicated in the package. It does not contain the code for any DCT nor any single precision code. David
On Wed, Jan 21, 2009 at 4:18 PM, David Cournapeau <cournape@gmail.com> wrote:
Numpy only includes a light version of fftpack, as indicated in the package. It does not contain the code for any DCT nor any single precision code.
Ah, ok, thanks! That explains my confusion. Should the docstrings I wrote for numpy.fft and friends be carried over to scipy.fft?
David
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
participants (7)
-
David Cournapeau -
David Cournapeau -
Pauli Virtanen -
Scott David Daniels -
Stéfan van der Walt -
Tom Grydeland -
william ratcliff