The experimental analysis serves to confirm many of the predictions about lookahead made in section 7.1, and demonstrates how the lookahead requirement might behave in algorithms where we were unable to give more than a lower and upper bound on the lookahead requirement.
The experimental analysis also shows how the dyadic stream multiplication operation can cause massive swelling in the size of the digit representation and can cripple the performance. This problem is one of the reasons this representation is not used as the main one in the calculator.
The profiling experiments show that a significant portion of the execution time and the memory usage comes from just a few basic operations, suggesting that a high performance implementation could be achieved by using highly optimised code for the basic data structures and operations, and that most of the rest of the code has far less of an effect.
The timing experiments show generally poor performance. There are a number of reasons why this might be the case. Firstly that the algorithms themselves are more complex than corresponding floating point ones and examine more of the input than one would usually use in a floating point computation (as shown in the theoretical analysis in section 7.1. Secondly, infinite structures like streams are inherently more complex to manage than fixed sized data structures. Thirdly the functional implementation is not written for performance, and there are likely to be overheads imposed by the compiler used to generate the code used (see chapter 6).