antoine.monmayrant+scilab |
Hello all,
From what I understand of fast Fourier transforms, fftshift and ifftshift should be almost identical. The only difference is when there are an odd number of elements in the dimension along which the shift is performed (ie fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). However, it seems that in scilab6.x fftshift and ifftshift are based on completely different codes and do not accept the same arguments. In particular, with fftshift, one can specify the dimension along which to perform the shift, while it is not the case for ifftshift. I think some update of ifftshift would be welcome. I propose to use the code below (myifftshift), where I just changed "ceil" by "floor" in the definition if fftshift. What do you think, does it look right to you? Cheers, Antoine function x = myifftshift(x,job) if argn(2)<2 then job="all",end deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]") if job=="r" then job=1,elseif job=="c" then job=2,end ind=list() if job=="all" then for sk=size(x),ind($+1)=fun(sk),end else for sk=size(x),ind($+1)=:,end; ind(job)=fun(size(x,job)) end x=x(ind(:)) endfunction _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Hello Antoine,
fttshift() switches all halves along all dimensions. This is mandatory. So for instance in 2D, opposite quadrants (wrt the center) are switched. In 3D, opposite cubes are switched. etc. To me, the current implementation is right: --> m=grand(3,5,"uin",0,9) m = 2. 5. 9. 3. 0. 2. 4. 5. 5. 6. 4. 1. 8. 5. 9. --> fftshift(m) ans = 5. 9. 4. 1. 8. 3. 0. 2. 5. 9. 5. 6. 2. 4. 5. --> ifftshift(fftshift(m)) ans = 2. 5. 9. 3. 0. 2. 4. 5. 5. 6. 4. 1. 8. 5. 9. --> and(ifftshift(fftshift(m))==m) ans = T BR Samuel ----- Mail d'origine ----- De: antoine monmayrant+scilab <[hidden email]> À: International users mailing list for Scilab. <[hidden email]>, List dedicated to development questions <[hidden email]> Envoyé: Tue, 09 Oct 2018 11:02:20 +0200 (CEST) Objet: [Scilab-users] fftshift and ifftshift are way too different Hello all, From what I understand of fast Fourier transforms, fftshift and ifftshift should be almost identical. The only difference is when there are an odd number of elements in the dimension along which the shift is performed (ie fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). However, it seems that in scilab6.x fftshift and ifftshift are based on completely different codes and do not accept the same arguments. In particular, with fftshift, one can specify the dimension along which to perform the shift, while it is not the case for ifftshift. I think some update of ifftshift would be welcome. I propose to use the code below (myifftshift), where I just changed "ceil" by "floor" in the definition if fftshift. What do you think, does it look right to you? Cheers, Antoine function x = myifftshift(x,job) if argn(2)<2 then job="all",end deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]") if job=="r" then job=1,elseif job=="c" then job=2,end ind=list() if job=="all" then for sk=size(x),ind($+1)=fun(sk),end else for sk=size(x),ind($+1)=:,end; ind(job)=fun(size(x,job)) end x=x(ind(:)) endfunction _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Antoine Monmayrant |
Hello Samuel,
Sorry I might not have made myself clear: fft and fftshift provide the ability to perform transform along only one of the dimensions of a multidimensional array. Something like S(x,y,z) --[FFT along 3rd dim]--> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). In that case, you need to perform fft and eventually fftshift along only the dimension of the transform. ifftshift should also provide the same possibility to perform the inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). This is a basic signal processing requirement in my field. Cheers, Antoine Le 09/10/2018 à 16:05, [hidden email] a écrit : > Hello Antoine, > > fttshift() switches all halves along all dimensions. This is mandatory. > So for instance in 2D, opposite quadrants (wrt the center) are switched. > In 3D, opposite cubes are switched. etc. > > To me, the current implementation is right: > > --> m=grand(3,5,"uin",0,9) > m = > 2. 5. 9. 3. 0. > 2. 4. 5. 5. 6. > 4. 1. 8. 5. 9. > > --> fftshift(m) > ans = > 5. 9. 4. 1. 8. > 3. 0. 2. 5. 9. > 5. 6. 2. 4. 5. > > --> ifftshift(fftshift(m)) > ans = > 2. 5. 9. 3. 0. > 2. 4. 5. 5. 6. > 4. 1. 8. 5. 9. > > --> and(ifftshift(fftshift(m))==m) > ans = > T > > BR > Samuel > > ----- Mail d'origine ----- > De: antoine monmayrant+scilab <[hidden email]> > À: International users mailing list for Scilab. <[hidden email]>, List dedicated to development questions <[hidden email]> > Envoyé: Tue, 09 Oct 2018 11:02:20 +0200 (CEST) > Objet: [Scilab-users] fftshift and ifftshift are way too different > > Hello all, > > From what I understand of fast Fourier transforms, fftshift and > ifftshift should be almost identical. > The only difference is when there are an odd number of elements in the > dimension along which the shift is performed (ie > fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])). > However, it seems that in scilab6.x fftshift and ifftshift are based on > completely different codes and do not accept the same arguments. > In particular, with fftshift, one can specify the dimension along which > to perform the shift, while it is not the case for ifftshift. > I think some update of ifftshift would be welcome. > I propose to use the code below (myifftshift), where I just changed > "ceil" by "floor" in the definition if fftshift. > What do you think, does it look right to you? > > Cheers, > > Antoine > > function x = myifftshift(x,job) > if argn(2)<2 then job="all",end > deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]") > if job=="r" then job=1,elseif job=="c" then job=2,end > ind=list() > if job=="all" then > for sk=size(x),ind($+1)=fun(sk),end > else > for sk=size(x),ind($+1)=:,end; > ind(job)=fun(size(x,job)) > end > x=x(ind(:)) > endfunction > _______________________________________________ > users mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/users > _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 09/10/2018 à 21:52, antoine monmayrant a écrit :
> Hello Samuel, > > Sorry I might not have made myself clear: fft and fftshift provide the > ability to perform transform along only one of the dimensions of a > multidimensional array. > Something like S(x,y,z) --[FFT along 3rd dim]--> > ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). > In that case, you need to perform fft and eventually fftshift along > only the dimension of the transform. > ifftshift should also provide the same possibility to perform the > inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> > iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). > > This is a basic signal processing requirement in my field. Hello Antoine, Yes, you are right: in case of directional FFT and odd number of elements along the chosen direction, ifftshift can't presently be used. Could you please post the same remark on bugzilla? This bug/wish is not yet reported. IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. BTW, still IMO, fftshift and ifftshift should rather be merged in a single function. It's the same code, except a floor<=>ceil. This should deserve just an option, not a separate dedicated function. I guess that this separation likely comes from a kind of abusive Matlab-like mimicry. Best regards Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 10/10/2018 à 08:47, Samuel Gougeon a
écrit :
Le 09/10/2018 à 21:52, antoine monmayrant a écrit :OK, I'll put it in my TODO-list. Yes, I agree. But I don't see how we can merge the two without increasing the huge halo of confusion that blurs the help pages and use of fft-related functions¹ ². The first idea that came to my mind was to make one single fftshift function where: - if dim>0, you do direct shift (ie for a direct Fourier transform) along dimension dim; - if dim<0, you do inverse shift (ie for an inverse Fourier transform) along dimension |dim|. But as "-1" means direct fft and "+1" inverse fft, mixing fft and fftshift would be a real mess. Antoine ¹ One I just discovered yesterday: the help page for fft is not listed in "Scilab Help >> Signal Processing > Transforms " ! Only ifft is listed, cool, he? Of course, ifft points to "Scilab Help >> Signal Processing > Transforms > fft". Idem for dst, ... ² Oh, and this one cool too: in the fft help page: "incr a vector of positive numbers with integer values, or a vector of positive integers. See the Description part for details." but the Description never says what the heck "incr" is, does and means.... Arghhh. It only appears once in an example of a "previous syntax".
-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 10/10/2018 à 09:21, [hidden email]
a écrit :
You know, the most numerous pages we have about basically the same feature, the more inconsistencies between them we can get. The first idea that came to my mind was to make one single fftshift function where: I am not too convinced using the sign of dim to set the direction of the shift, because the dim sign could be used to something else more useful (and general) when dealing with an hypermatrix (to be discussed elsewhere). But as "-1" means direct fft and "+1" inverse fft, mixing fft and fftshift would be a real mess.Yes, having chosen the sign of the exponent as a flag to set the direction is not very handy/clear. But we must do with it now... Basically, flipdim() could do the same, by implementing new "fft"|"ifft" values for its blockSize option.
It is listed, but it depends on the way you get the list:
This is due to the bug
11633. It occurs when a page has multiple <refname>
(titles) About ifft() and fft2(): to me, these both functions are
completely useless. They do nothing more than what fft() can do. ² Oh, and this one cool too: in the fft help page: It is written:
When 3 pages have to be written and maintained (in ideally 5 different languages en fr ja pt ru) instead of one, then the time and care than can be invested to write excellent pages is expectedly 3 times shorter for each one of them... _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
In reply to this post by Samuel GOUGEON
Le 10/10/2018 à 08:47, Samuel Gougeon a écrit :
> Le 09/10/2018 à 21:52, antoine monmayrant a écrit : >> Hello Samuel, >> >> Sorry I might not have made myself clear: fft and fftshift provide >> the ability to perform transform along only one of the dimensions of >> a multidimensional array. >> Something like S(x,y,z) --[FFT along 3rd dim]--> >> ffthift(ffft(S(x,y,z), -1,3),3)=Ŝ(x,y,kz). >> In that case, you need to perform fft and eventually fftshift along >> only the dimension of the transform. >> ifftshift should also provide the same possibility to perform the >> inverse transform: Ŝ(x,y,kz) --[IFFT along 3rd dim]--> >> iffthift(ffft(Ŝ(x,y,kz), +1,3),3)=S(x,y,z). >> >> This is a basic signal processing requirement in my field. > > Hello Antoine, > > Yes, you are right: in case of directional FFT and odd number of > elements along the chosen direction, ifftshift can't presently be used. > Could you please post the same remark on bugzilla? This bug/wish is > not yet reported. > > IMO we may propose and include it in Scilab as soon as for Scilab 6.0.2. > > BTW, still IMO, fftshift and ifftshift should rather be merged in a > single function. > It's the same code, except a floor<=>ceil. This should deserve just an > option, not a separate dedicated function. > I guess that this separation likely comes from a kind of abusive > Matlab-like mimicry. > > Best regards > Samuel > > _______________________________________________ > users mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/users > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 10/10/2018 à 12:39, [hidden email]
a écrit :
Le 10/10/2018 à 08:47, Samuel Gougeon a écrit : This complementary feature is now implemented and proposed for Scilab 6.0.2 there. BR Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Antoine Monmayrant |
Le 06/11/2018 à 10:52, Samuel Gougeon a
écrit :
Nice!
-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Free forum by Nabble | Edit this page |