Martin De Kauwe wrote:
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.
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
--
http://mail.python.org/mailman/listinfo/python-list
