Bounds checking

[Jean-Michel Pichavant]

Martin De Kauwe wrote:
> On Mar 21, 9:43 pm, Jean-Michel Pichavant <jeanmic... at sequans.com>
> wrote:
>   
>> 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.
>>     
>
> Hi,
>
> Yes you make a good point. I think what I was trying to get across is
> there are certain scenarios which can't physically happen and they are
> straight forward to check for. I just thought it might be nice to add
> a check for these. However you make a good case and I definitely take
> your point. I guess I should look into unitary tests then (any
> suggestions?)
>
> ta.
>   

if your python version < 2.7:
    http://pypi.python.org/pypi/unittest2

http://docs.python.org/library/unittest.html

This is the standard way of writing unitary tests in python (AKA pyunit)

JM