Rene de Visser wrote:
Designing the data structures to store the calculation results seems to be non-trivial, so I guess I should do this first.
I think that part of the problem is that when you need to be able to reference results from the inside of a calculation (or any sort of expression) you need to be able to refer to them somehow. One of the easier ways of doing this would be to bung them into some sort of data structure, alternatives would be to use a spreadsheet type abstraction that allows you to pull things out. Someone posted a reference to an interesting paper that you may be able to build on: http://citeseer.ist.psu.edu/carlsson02monads.html It's probably not going to be a trivial translation, but once you've written your calculations in this style, you should be able to get at out the intermediate values easily. At least I wrote something similar in Java a few years ago that did similar things, and it was quite a nice of abstraction to work with. I guess it's not going to matter much for you, but the problem of using some specific data structure is that it's probably going to be very closely related to the structure of the code. If you need to change the code in any non-trivial way the data structure is going to have to change and all of the code that deals with the data structure will as well. Because your report is probably going to have to change in sync with the calcs this probably isn't going to be much of a problem, but in other situations it can be a bit of a pain.
Then maybe the solution to the other problem will be apparent.
I think your main problem is that you need some way of labeling the intermediate results so you can refer to them later when you need them in the report. One you've worked out how you're going to do that, everything else should fall into place. Hope that helps! Sam