Bounds checking

[Jean-Michel Pichavant]

Martin De Kauwe wrote:
>> 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
>   
Not that much. You'll spot bugs where negative numbers will be set to 
some attribute but what if 42 is put instead of 43 in one of your 
attribute ? Same consequence, it will mess up with your model but none 
of your check will spot that error.

Try to identify those complicated functions you mentioned, and write 
unitary tests for them. Use a set of input parameters with the expected 
function return value. That way you'll be able to spot errors, whether 
the attribute is negative or not.

JM


PS : writing unitary tests takes time, a lot of time.