Bounds checking

[Martin De Kauwe]

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.