For several years, I had to teach and write about optimizing codes for a variety of platforms: a Cray X-MP (and later C90), a Convex 3800, an IBM SP (POWER3), a Cray T3E, a Compaq Alpha EV6 system, etc.

In a way, the vector processors were straightforward, because usually you had a big interleaved main memory, which you could regard as an large cache memory. With RISC architectures the picture was much more difficult. Of course, the compilers got better all the time, but always when a new architecture came to the market, the first compilers were quite inefficient.

In the final years of my career in code optimization (I moved to other topics about there years ago), I made a simple example in linear algebra to show the benefit of code optimization. I used this example in several user quides, where I wrote or edited the chapter on optimization. The example started with an unoptimized code, which produced about 1-4 megaflop/s (millions of floating-point operations per second). By several steps I finally arrived at the final version, which called machine-specific suproutine libraries. This code typically achieved 150-250 megaflop/s. Thus the final code was about 50-100 times faster than the original.

Nowadays I'm not keen on comparing the performance of systems, because often the speed is more dependent on the style of coding and the quality of the compiler than the actual speed of the processor. Sometimes a code developed originally for processor A performs really poorly on processor B.

In any case, there is not much point in making detailed benchmarks of current personal computers. The speed of the processor should be more that sufficient for most tasks. When the application feels slow, it is more often a matter of bad coding than lack of speed in the processor.

By the way, it may be a singularly Finnish trait that when giving positive feedback we tend to insult the recipient a bit. This way the recipient feels that you didn't offer you encouragement only because you wanted to be polite.

The weblog community differs in the way feedback is given and received. There is the referrals tracking mechanism. Also, it is customary to link to the original sources which make giving and receiving feedback an easy task.

Having immediate feedback on your writing (and your thoughts) encourages you to keep on writing. The feedback also helps in the creative process. In micropublishing like weblogs you don't have to publish a polished text, you can start with half-ready ideas and get feedback where to go from there. The weblog community is not individual writers fighting for the place on the printed page.

Once in a while I have received feedback which has helped me to improve as a writer. There have been the editors of books, journals and magazines. Sometimes a reader has contacted me for further advice, for example on Fortran programming, code optimization, or numerical methods. Sometimes I even have received corrections or suggestions for additional exercises for a book.

It seems easiest to comment on facts, not opinions. I have received almost no feedback on my opinion pieces, except from close friends. Perhaps this also is a Finnish trait?

• Valiente: Algorithms on Trees and Graphs
• Calude: Information and Randomness (Second Edition)
• Toth: Glimpses of Algebra and Geometry (Second Edition)
• Assayag et al. (Ed.): Mathematics and Music

The biggest disappoinment was the book on Mathematics and Music, which is a collection of diverse mathematical articles. Perhaps the book would be interesting to mathematicians who are also musicians. But the book lacks a coherence in approaching the topic, and it is not an introduction to the subject matter. I have tried to find a reviewer for this book, but without success so far.

During the last four years I have reviewed about 60 books in the Tietoyhteys magazine, where I have been editing the book review column. Most of the reviews have been written by me, although I have been fortunate to find a couple of colleagues interested in reviewing books. Writing a book review is never a straightforward task, but it can be very rewarding. Writing a review forces you to ask: Did I understand what the writer intended to say? Often you find that you didn't.