Develop Reference

Actual performance benefits of distance squared vs distance

When calculating the distance between two 3D points in Java, I can compute the distance, or the distance squared between them, avoiding a call to Math.sqrt.
Natively, I've read that sqrt is only a quarter of the speed of multiplication which makes the inconvenience of using the distance squared not worthwhile.
In Java, what is the absolute performance difference between multiplication and calculating a square root?

I Initially wanted to add this as a comment, but it started to get too bid, so here goes:
Try it yourself. Make a loop with 10.000 iterations where you simply calculate a*a + b*b and another separate loop where you calculate Math.sqrt(a*a + b*a). Time it and you'll know. Calculating a square root is an iterative process on its own where the digital (computer bits) square root converges closer to the real square root of the given number until it's sufficiently close (as soon as the difference between each iteration is less than some really small value). There are multiple algorithms out there beside the one the Math library uses and their speed depends on the input and how the algorithm is designed. Stick with Math.sqrt(...) in my opinion, can't go wrong and it's been tested by a LOT of people.
Although this can be done very fast for one square root, there's a definite observable time difference.
On a side note: I cannot think of a reason to calculate the square root more than once, usually at the end. If you want to know the distance between points, just use the squared value of that distance as a default and make comparisons/summations/subtractions or whatever you want based on that default.
PS: Provide more code if you want a more "practical" answer

Normalize output of fft using Libgdx in Android, from accelerometer data

I use the FFT function from the Libgdx library for a project in Android, where I process the accelerometer signal for create a signal spectrum.
I need to normalize the output from accelerometer data, i read there isn't a "correct" way to do this but is conventional. Someone use dividing by 1/N in FFT, other by 1/sqrt(N).
I didn't understand if this is conventional for who implements the library, this mean that every library have his normalization factor, or is conventional for the user than I can decide for aesthetic representation.
If it depends on library, which is the normalization factor for FFT in LIBGDX library?
Edit1: I searched already inside documentation but I found nothing. Here is it: http://libgdx-android.com/docs/api/com/badlogic/gdx/audio/analysis/FFT.html

I was about to say "just check the documentation", but it turns out that it's terrible, and doesn't say one way or the other!
Still, you could determine the scale factor empirically. Just run an FFT on all-ones dataset. There will be one non-zero bin in the output. There are three likely values of this bin:
1.0: The scale was 1/N
sqrt(N): The scale was 1/sqrt(N)
N: The scale was 1
You can do the same trick for the inverse FFT, although it's redundant. The forward and inverse scale factors must multiply to 1/N.

There's a specific normalization depending on if you want the spectrum or power spectral density. Oli provided a good test for determining the 1/N, 1/sqrt(N) or no scaling that the library performs.
Here's a document that explains everything in great detail along with a comprehensive comparison of window functions.
http://edoc.mpg.de/395068

Fast multi-body gravity algorithm?

I am writing a program to simulate an n-body gravity system, whose precision is arbitrarily good depending on how small a step of "time" I take between each step. Right now, it runs very quickly for up to 500 bodies, but after that it gets very slow since it has to run through an algorithm determining the force applied between each pair of bodies for every iteration. This is of complexity n(n+1)/2 = O(n^2), so it's not surprising that it gets very bad very quickly. I guess the most costly operation is that I determine the distance between each pair by taking a square root. So, in pseudo code, this is how my algorithm currently runs:
for (i = 1 to number of bodies - 1) {
for (j = i to number of bodies) {
(determining the force between the two objects i and j,
whose most costly operation is a square root)
}
}
So, is there any way I can optimize this? Any fancy algorithms to reuse the distances used in past iterations with fast modification? Are there any lossy ways to reduce this problem? Perhaps by ignoring the relationships between objects whose x or y coordinates (it's in 2 dimensions) exceed a certain amount, as determined by the product of their masses? Sorry if it sounds like I'm rambling, but is there anything I could do to make this faster? I would prefer to keep it arbitrarily precise, but if there are solutions that can reduce the complexity of this problem at the cost of a bit of precision, I'd be interested to hear it.
Thanks.

Take a look at this question. You can divide your objects into a grid, and use the fact that many faraway objects can be treated as a single object for a good approximation. The mass of a cell is equal to the sum of the masses of the objects it contains. The centre of mass of a cell can be treated as the centre of the cell itself, or more accurately the barycenter of the objects it contains. In the average case, I think this gives you O(n log n) performance, rather than O(n2), because you still need to calculate the force of gravity on each of n objects, but each object only interacts individually with those nearby.
Assuming you’re calculating the distance with r2 = x2 + y2, and then calculating the force with F = Gm1m2 / r2, you don’t need to perform a square root at all. If you do need the actual distance, you can use a fast inverse square root. You could also used fixed-point arithmetic.

One good lossy approach would be to run a clustering algorithm to cluster the bodies together.
There are some clustering algorithms that are fairly fast, and the trick will be to not run the clustering algorithm every tick. Instead run it every C ticks (C>1).
Then for each cluster, calculate the forces between all bodies in the cluster, and then for each cluster calculate the forces between the clusters.
This will be lossy but I think it is a good approach.
You'll have to fiddle with:
which clustering algorithm to use: Some are faster, some are more accurate. Some are deterministic, some are not.
how often to run the clustering algorithm: running it less will be faster, running it more will be more accurate.
how small/large to make the clusters: most clustering algorithms allow you some input on the size of the clusters. The larger you allow the clusters to be, the faster but less accurate the output will be.
So it's going to be a game of speed vs accuracy, but at least this way you will be able to sacrafice a bit of accuracy for some speed gains - with your current approach there's nothing you can really tweak at all.

You may want to try a less precise version of square root. You probably don't need a full double precision. Especially if the order of magnitude of your coordinate system is normally the same, then you can use a truncated taylor series to estimate the square root operation pretty quickly without giving up too much in efficiency.

There is a very good approximation to the n-body problem that is much faster (O(n log n) vs O(n²) for the naive algorithm) called Barnes Hut. Space is subdivided into a hierarchical grid, and when computing force contribution for distant masses, several masses can be considered as one. There is an accuracy parameter that can be tweaked depending on how much your willing to sacrifice accuracy for computation speed.

Java: Calculate distance between a large number of locations and performance

I'm creating an application that will tell a user how far away a large number of points are from their current position.
Each point has a longitude and latitude.
I've read over this article
http://www.movable-type.co.uk/scripts/latlong.html
and seen this post
Calculate distance in meters when you know longitude and latitude in java
There are a number of calculations (50-200) that need carried about.
If speed is more important than the accuracy of these calculations, which one is best?

this is O(n)
Dont worry about performance. unless every single calculation takes too long (which it isnt).

As Imre said this is O(n), or linear, meaning that no matter how the values differ or how many times you do it the calculations in the algorithm will take the same amount of time for each iteration. However, I disagree in the context that the Spherical Law of Cosines has less actual variables and calculations being performed in the algorithm meaning that less resources are being used. Hence, I would choose that one because the only thing that will differ speed would be the computer resources available. (note: although it will be barely noticable unless on a really old/slow machine)
Verdict based on opinion: Spherical Law of Cosines

The two links that you posted use the same spherical geometry formula to calculate the distances, so I would not expect there to be a significant difference between their running speed. Also, they are not really computationally expensive, so I would not expect it to be a problem, even on the scale of a few hundred iterations, if you are running on modern hardware.

Using exponential smoothing with NaN values

I have a sample of some kind that can create somewhat noisy output. The sample is the result of some image processing from a camera, which indicates the heading of a blob of a certain color. It is an angle from around -45° to +45°, or a NaN, which means that the blob is not actually in view.
In order to combat the noisy data, I felt that exponential smoothing would do the trick. However, I'm not sure how to handle the NaN values.
On the one hand, involving them in the math would result in a NaN average, which would then prevent any meaningful results. On the other hand, ignoring NaN values completely would mean that a "no-detection" scenario would never be reported. And just to complicate things, the data is also noisy in that it can get false NaN value, which ideally would be smoothed somehow to prevent random noise.
Any ideas about how I could implement such an exponential smoother?

How about keeping two distributions? The first one can be your smoothed blob heading as usual, except if you get a NaN you instead just enter whatever the last seen non-NaN value was (or some other default); the other is a "NaN-distribution", which simply gets a 0 for every non-NaN value and 1 for every NaN (or something like that).
This way, even if it gets obscured, your primary distribution will keep predicting based on "last known heading", without getting garbage data or messing up the smoothing, but you'll also get a simultaneous spike on the NaN-distribution letting you know that something's up.

Well, it really depends on what you are doing with the smoothed data. One thing you might try is to have an exponentially weighted smoothing of the blob velocity in addition to its location, where NaNs contribute a value of zero. When you encounter a NaN, you can then replace it with the projected position based on the previous position and the smoothed velocity. By smoothing the velocity you can prevent a whole sequence of NaNs from producing a completely crazily large or small value. This can result in values being out of [-45,45], which should capture that it is out of view and the side to which it left the view. Now, you will have to actually verify that this gives good results in your computer vision algorithm. If not, you might also want to try replacing NaNs with the previous value, or with zero, or to simply ignore the NaNs and see what works best.