First of all, resign yourself to the fact that this will probably take a long time to solve. I had a bug a few years ago that took almost a year to fix, because it was so time consuming to reproduce.
One tip is to make sure your code compiles without warnings, and passes static analysis. Get a peer review as well. You might have something like a race condition with a 0.001% chance of occurring. Static analysis tools can help you find those types of bugs.
Make sure your code is super clean. Eliminate all the repetition, and make your functions small. Take out any and all optimizations you may have done, and replace it with code that is so dead simple to read, any bugs will stick out like a sore thumb. Only after your code works should you put optimizations back in, one by one with a test in between each. The code that is hardest for you to read is the code most likely to contain a bug.
Write a ton of unit tests, that cover all your boundary cases of your accounted-for error. The most likely scenario is you accidentally made a mistake with one of them.
The next thing you can do is write some extra code to help you detect and narrow down the bug. Load it up with assertions and log entries. Automate the detection of the bug in your intermediate results, perhaps by comparing it with a slower but more reliable algorithm. Write code to check for conditions that should be impossible to hit, then set a breakpoint if it does. Make it possible to save and restart your algorithm from an intermediate state.
Another interesting technique I recently saw demonstrated to great effect in this excellent TED talk is to create a visualization. The human brain can find patterns and anomalies much, much more easily in visual form.
I will emphasize again the need to be patient. If you try to rush and try to take shortcuts, it will likely take you longer. Don't be afraid to make big changes for the sole purpose of debugging. You won't waste your previous effort, that's what source control is for.