This month's most interesting messages:

All from the SETI@home team members at Berkeley. Non-official statements but interesting anyway.

Eric J. Korpela - 2000.08.08 in a.s.s., regarding 2.71:

Eric Heien was supposed to post something regarding why 2.71 is slower. (We're going out to LEO type doppler shift rates now +-50 Hz/s.) I'm quite busy right now and can't post a detailed description or reasoning.

If Eric didn't post anything on the subject, let me know and I'll prompt him to.

Eric J. Korpela - 2000.08.10 in a.s.s., about the announced partnership/fundage:

The biggest change will be in server wetware. We'll finally be able to hire a real Informix DBA, which will hopefully prevent future outages, and perhaps make them shorter. I'm not privvy to all the details of the deal, but my guess is that a large fraction of the funds will go to costs associated with the development of SETI@home II, which will probably include a new server configuration. We're also looking at offloading the science post-processing from the science database server, which would reduce load on it and increase capacity. Whether we will use the new funds for that depends upon a lot of things.

Eric J. Korpela - 2000.08.11 in a.s.s., Who's got 'Bigger Balls'? Distributed.net or Seti@Home?

Last time I checked S@H was an order of magnitude over d.net. On the other hand, they may have trademarked 'the fastest computer on Earth'

Eric Heien - 2000.08.11 in a.s.s., if S@H source code is published:

The actual analysis code is in fact already openly available, however, we still choose not to release the rest of the code for security reasons. Yes, I know security through obscurity isn't the best policy, but it would be *much* easier for people to fake signals and pump up their stats if they knew the exact inner workings of the client, which would create that much more of a hassle for us.

In the old versions, we used the four1 procedure for FFTs from Numerical Recipes in C. You can see the exact code and scientific and mathematical derivations for it in Numerical Recipes in C. It's available at www.nr.com, or you can just jump directly to http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf/c12-2.pdf for the specific section.

The new FFT used in the beta versions (and soon version 3.0) is the Ooura FFT library. You can get the code and benchmarks at http://momonga.t.u-tokyo.ac.jp/~ooura/fft.html.

The new pulse finding code is called the Fast Folding Algorithm (FFA). I'm sure there are several sources and papers for it on the Internet, but the first I saw was http://www.mpifr-bonn.mpg.de/staff/peter/ffades.en.html. This particular analysis routine was written by us, but was based on code that is publicly available (for example, from the above link).

The triplet code is based on ideas developed by some NASA scientists (I don't know their names offhand). The code was actually entirely written here rather than based on other code, but I'm sure there are papers and sample code available somewhere out there for it.

Hope this answers some of the questions everyone out there has had.

Eric Heien - 2000.08.21 in a.s.s., regarding the beta:

I should be sending beta 2.72 out today or tomorrow, and if all goes well with that version, 3.0 should be out a week or two after that.

Eric Heien - 2000.08.24 in a.s.s., a word of thanks to the beta testers:

Hello everyone,

Thanks for the initial beta bug reports. Just this morning we found a memory leak in 2.73 (whoops), so we should be releasing 2.74 today or tomorrow to fix this. If you haven't already downloaded 2.73, you may want to wait. Thanks for your effort in beta testing!