allow iterables in fftshift and ifftshift

[JKrehl]

In the case of shifting multiple but not all axis of a multidimensional array now requires multiple fftshift commands (which, if I am correct, includes multiple array copys). The map-function is abstract enough to allow both iterables and scalar arguments, so I see no reason to not include this behaviour.

Please excuse any misuse of GIT and its functions.

[ViralBShah]

Cc @stevengj

[tkelman]

Thanks for the contribution! Would you mind adding a test or two for this new functionality?

[JKrehl]

Certainly
Are these test sufficient?

Since this functionality is quite abstract and devolves to map's abilities to interpret the argument it would be unnecessary to test every probable use-case.

[stevengj]

LGTM.

[yuyichao]

This seems to be a very strange use of map.

[JKrehl]

The map rather blatenly replaces a for-loop and was chosen simply for brevity of the code. The instruction itself is so simple that the visual structuring by a for-loop is, in my opinion, not needed.

The only difference between the two in interpreting iterable arguments are strings. In the end, it doesn't matter to the use-cases I can envisage so I don't care whether it is a map or a for-loop.

If that is the aspect you are aiming at.

[yuyichao]

map allocates an array to store the result.

[stevengj]

(You could also call foreach, which unlike map does not allocate an array.)

[JKrehl]

Yes, it does. Although a few small arrays of nothingness should not hurt, they are still needless allocations.

Thank, I was not aware of the existence of foreach.
Moving to a for-loop also eliminates the abstract function, for whatever that is worth.

[tkelman]

Looks like we just lost track of this one, was there any objection to it?

[StefanKarpinski]

cc: @stevengj – seems like a quick review for you might do here

[stevengj]

LGTM.

[StefanKarpinski]

Looks like we can't merge this on GitHub since the branch is gone. I guess we should manually reconstruct this and commit it (with credit to @JKrehl), unless @JKrehl is willing to do so.

[JKrehl]

Can do: https://github.com/JKrehl/julia/tree/JKrehl/fftshift
Does it need to have the exactly same name as the original one? Or can someone change the branch attached to the PR?

(I'm slowly getting the hang of this branching-thingy.)

[tkelman]

restoring the original branch name might let us reopen this pr. otherwise we could open a new one.

[JKrehl]

reopened it in #20461
Not having deleted the branch via GitHub's web-interface GitHub considers it gone for good.