> Sorry, are you trying to say that it is not practical to write correct > code that isn't buggy? Well, you're honest, at least, still I can't help > but feel that you're admitting defeat before even starting.
No. What I am saying is the code is written has been well tested and *appears* to be working well. However the code is complicated and there is potential for bugs. I think I am just been practical here, evidently I can't think of everything, but there are some clear and obvious errors that would be worth checking for. I can only explain this in the terms of the code (sorry)...but for example the model estimates plant photosynthesis and then allocates the carbon. So one clear example is that the model cuts back carbon production if there is water stress for the plant. This involves "removing" carbon from the state. Clearly if you ended up in a situation where there is negative carbon in a leaf, i.e. the leaf doesn't exist well this is not physically possible and would be a code issue. Whilst this is unlikely I think it would be nice to have a catch for it. Another example would be the amount of soil water available to the plant, again there can be zero but not negative soil water. It wouldn't be meaningful. I hope that makes sense? thanks -- http://mail.python.org/mailman/listinfo/python-list
