Bounds checking

[Martin De Kauwe]

> assert all(x >= 0 for x in (a, b, c, d, e, f, g, h, i, j))

yep neat!



> Why don't you do the range check *before* storing it in state? That way
> you can identify the calculation that was wrong, instead of merely
> noticing that at some point some unknown calculation went wrong.

I guess no reason really. I suppose in my mind I was thinking it was
an unlikely safeguard but I liked the idea of adding so would just do
it at the end of a time step. In reality I think there is practically
no difference and this way it is done once, in a single location vs.
potential 10 separate checks? I don't see the advantage?

> You're looking at every single attribute, including those of super
> classes, when you only want to check "10 or so" attributes. That's
> probably not wise. At the very least, dir() will be a fairly expensive
> call.

yes your right, sorry I was just trying to post a quick example to go
with my question. I would use a list of the attributes to check.

>
> If you insist on checking state *after* the value is stored, instead of
> preventing it from being stored in the first place, it is better to make
> the state object responsible for doing it's own bounds checking. That way
> only the state object needs to be updated when you change those ten
> attributes, instead of some arbitrary number of places scattered all
> throughout your code.

yes I think this is what I was getting at, I will look at your
suggestion thanks.