The simplest way to achieve what you want is to compute the sin, and then do the sort. Anything else you could do would be more complex, even if you could cobble up a solution. And since the sin and sort functions are so easy and fast to use, why is there a problem?
Sigh. CAN you do it? Well, technically yes. Is it any faster, any simpler? Not really. Again, is there really a good reason to not want to just compute the sin?
The point is, to recognize the sin function is periodic over an interval of length 2*pi, AND it is monotonic over the interval [-pi/2,pi/2].
We would effectively need to use the simple identities
sin(x + 2*k*pi) = sin(x)
for any integer k. That gets you into an inteval of length 2*pi. As well, we would need this one:
sin(pi - x) = sin(x)
How can you use that information?
For example, I'll pick a large set of random numbers.
They will be spread out over a rather large interval, so any prediction of the sort order, merely from x will be difficult. Not impossible. Anyway, now apply those identities in a careful way.
xhat(xhat > pi/2) = pi - xhat(xhat > pi/2);
xhat(xhat < -pi/2) = -pi - xhat(xhat < -pi/2);
Now, test to see if the sort indices from sort(xhat) are the same as those from sort(sin(x)).
We can also see that now all elements live in the interval [-pi/2,pi/2], so as long as I used the above identities properly, the sort tags must now behave as desired since sin(x) is monotonic on that interval.
Is there any real gain? I seriously doubt there is much, if any. We could probably test the amount of time needed. I would not be at all surprised if just doing the sort on sin(x) was not just as easy. But whatever floats your boat. If you want to know why what I did works, well, just spend some time thinking about those identities, and how they apply to what I did.
