Martin De Kauwe wrote:
On Mar 21, 9:43 pm, Jean-Michel Pichavant
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 ev
On Mar 21, 9:43 pm, Jean-Michel Pichavant
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.
>
> >
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 teste
On Mar 19, 8:40 pm, Steven D'Aprano wrote:
> On Sat, 19 Mar 2011 01:38:10 -0700, Martin De Kauwe wrote:
> >> 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
On Sat, 19 Mar 2011 01:38:10 -0700, Martin De Kauwe wrote:
>> 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 rea
> 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 wo
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
> dir() has to do a bit a computation. I would be tempted to give 'state'
> a set of attributes to check. Call it 'nonnegatives'.
> for attr in nonnegatives:
> if ...
>
> This allows for attributes not subject to that check.
>
> --
> Terry Jan Reedy
Agreed. I was trying to just write a
On Fri, 18 Mar 2011 15:35:40 -0700, Martin De Kauwe wrote:
>> Don't check for bounds, fix any bug in the code that would set your
>> values out of bounds and use asserts while debugging.
>>
>>
> whilst that is a nice idea in practice this just is not a practical
> solution.
Sorry, are you trying
;s
probably not wise. At the very least, dir() will be a fairly expensive
call.
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.
On 3/18/2011 10:24 AM, Martin De Kauwe wrote:
def bounds_check(state):
""" check state values are> 0 """
for attr in dir(state):
if not attr.startswith('__') and getattr(state, attr)< 0.0:
print "Error state values< 0: %s" % (attr)
dir() has to do a bit a com
Actually, I'd probably create a class with 3 arguments - an initial value, a
lower bound, and an upper bound, give it a _check method, and call _check
from the various operator methods. The class would otherwise impersonate an
int.
In code that isn't performance-critical, it's better to check for
> Offhand, my only quibble is that sys.exit is not helpful for debugging.
> Much better to raise an error:
>
> if not self.funcTable.get(attribute, lambda x: True)(value):
> raise ValueError ('error out of bound')
>
> or define a subclass of ValueError just for this purpose.
> Don't check for bounds, fix any bug in the code that would set your
> values out of bounds and use asserts while debugging.
>
whilst that is a nice idea in practice this just is not a practical
solution.
> Otherwise if you really need dynamic checks, it will cost you cpu, for
> sure.
Yes I a
On Fri, Mar 18, 2011 at 3:01 PM, Jean-Michel Pichavant <
jeanmic...@sequans.com> wrote:
>
> Don't check for bounds, fix any bug in the code that would set your values
> out of bounds and use asserts while debugging.
>
> Otherwise if you really need dynamic checks, it will cost you cpu, for
> sure.
> def bounds_check(state):
> """ check state values are > 0 """
> for attr in dir(state):
> if not attr.startswith('__') and getattr(state, attr) < 0.0:
> print "Error state values < 0: %s" % (attr)
> sys.exit()
Not that related to the question. But it's usua
Jean-Michel Pichavant wrote:
> Martin De Kauwe wrote:
> Don't check for bounds, fix any bug in the code that would set your
> values out of bounds and use asserts while debugging.
[ ... ]
> def __setattr__(self, attribute, value):
>if not self.funcTable.get(attribute, lambda x: True)(v
Martin De Kauwe wrote:
Hi,
if one has a set of values which should never step outside certain
bounds (for example if the values were negative then they wouldn't be
physically meaningful) is there a nice way to bounds check? I
potentially have 10 or so values I would like to check at the end of
e
What sort of checks are you making ? - in general greater than/less than
tend to be fairly optimal, although you might be able to do a faster "is
negative" test
Katie
On Fri, Mar 18, 2011 at 2:24 PM, Martin De Kauwe wrote:
> Hi,
>
> if one has a set of values which should never step outside ce
Hi,
if one has a set of values which should never step outside certain
bounds (for example if the values were negative then they wouldn't be
physically meaningful) is there a nice way to bounds check? I
potentially have 10 or so values I would like to check at the end of
each iteration. However as
20 matches
Mail list logo
