On Mar 21, 9:43 pm, Jean-Michel Pichavant <jeanmic...@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. -- http://mail.python.org/mailman/listinfo/python-list
