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
> 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 r
> 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
On Fri, 18 Mar 2011 07:24:33 -0700, 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
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
19 matches
Mail list logo
