case do problem
Tracubik
iterations=0;
count=0;
REPEAT;
iterations = iterations+1;
...
IF (genericCondition) THEN count=count+1;
...
CASE count OF:
1: m = 1
2: m = 10
3: m = 100
UNTIL count = 4 OR iterations = 20
i do something like this:
iterations = 0
count = 0
m_Switch = (1,10,100)
while True:
iterations +=1
...
if (genericCondition):
count +=1
...
try:
m = m_Switch[count-1]
except: pass
if count = 4 or iterations = 20
the problem is that when count = 4 m_Switch[4-1] have no value, so i use
the try..except.
Is there a better solution to solve this problem? and, generally
speaking, the try..except block slow down the execution of the program or
not?
Thank you in advance
Nico
Tracubik
when count=4 i haven't to change the m value, so i have to do nothing or
something like m = m
Nico
Alf P. Steinbach
> hi, i've to convert from Pascal this code:
>
> iterations=0;
> count=0;
> REPEAT;
> iterations = iterations+1;
> ...
> IF (genericCondition) THEN count=count+1;
> ...
> CASE count OF:
> 1: m = 1
> 2: m = 10
> 3: m = 100
Uhm, is this syntactically valid Pascal? As I recall, every Pascal construct was
delimited in some way. Once I had the complete Pascal syntax in my head, but
alas, not anymore...
> UNTIL count = 4 OR iterations = 20
>
> i do something like this:
>
> iterations = 0
> count = 0
>
> m_Switch = (1,10,100)
>
> while True:
> iterations +=1
> ...
> if (genericCondition):
> count +=1
> ...
> try:
> m = m_Switch[count-1]
> except: pass
> if count = 4 or iterations = 20
>
> the problem is that when count = 4 m_Switch[4-1] have no value, so i use
> the try..except.
iterations = 0
count = 0
while not( count == 4 or iterations == 20 ):
iterations += 1
# ...
if generic_condition:
count += 1
# ...
m = (1, 10, 100, 100)[count]
> Is there a better solution to solve this problem?
Define "better". Do you mean faster, more clear, shorter, using less memory, what?
Above I've assumed that you want to get rid of the try block, since that's what
you're asking about:
> and, generally
> speaking, the try..except block slow down the execution of the program or
> not?
Probably, but don't think about it. Python programming is at a level where that
kind of efficiency doesn't count. Or, ideally it shouldn't count.
Cheers & hth.,
- Alf
Alf P. Steinbach
Add one extra 100 there.
Alf P. Steinbach
Oh dear, it's one of those days.
if 1 <= count <= 3:
m = (1, 10, 100)[count - 1]
MRAB
m_Switch = {1: 1, 2: 10, 3: 100}
and then catch the KeyError.
Don't use a bare 'except', catch the specific exception you want to
catch, and don't worry about the speed unless you discover that it's
real problem.
Gregory Ewing
> * Tracubik:
>
>> iterations=0;
>> count=0;
>> REPEAT;
>> iterations = iterations+1;
>> ...
>> IF (genericCondition) THEN count=count+1;
>> ...
>> CASE count OF:
>> 1: m = 1
>> 2: m = 10
>> 3: m = 100
>
> Uhm, is this syntactically valid Pascal? As I recall, every Pascal
> construct was delimited in some way.
I think it's okay. Pascal's control structures such as
if-then and while-do mostly take single statements and
didn't have an ending keyword. If you want multiple
statements in the body you have to put begin-end around
them.
Putting a semicolon after REPEAT is stylistically a
bit odd, but it's not wrong.
--
Greg
Andre Engels
> and, generally
> speaking, the try..except block slow down the execution of the program or
> not?
Try...except tends to be slow when the exception does occur, fast when
it does not. Apart from that, if these
fraction-of-a-fraction-of-a-second gains are important to you, Python
is not the programming language for you.
In Python, it seems to be common to do optimization after rather than
during the main coding, and then only when it is necessary and only
where it matters. That is:
1. Program your solution without looking much at speed issues
2. Check if it is fast enough. If so, ready.
3. If not, see which parts of the program are being slow
4. Optimize only those parts of the program that have been identified in step 3
--
André Engels, andre...@gmail.com
Peter Otten
> hi, i've to convert from Pascal this code:
program loop;
function generic_condition: boolean;
begin
generic_condition := random > 0.7
end;
procedure loop;
var
iterations, count, m: integer;
begin
iterations := 0;
count := 0;
m := 0;
repeat
iterations := iterations+1;
(*...*)
writeln(iterations:2, count:2, m:4);
(*...*)
if generic_condition then
inc(count);
(*...*)
case count of
1: m := 1;
2: m := 10;
3: m := 100
end
until (count = 4) or (iterations = 20)
end;
begin
loop;
writeln("That's all, folks")
end.
Hey, I have a Pascal compiler just one apt-get away ;)
Here's how I'd translate the above, without trying to be too clever:
from random import random
def generic_condition():
return random() > 0.7
def loop():
count = 0
m = 0
lookup = {1: 1, 2: 10, 3: 100}
for iterations in range(20): # off by one
# ...
print "%2d %1d %3d" % (iterations, count, m)
# ...
if generic_condition():
count += 1
# ...
m = lookup.get(count, m)
if count == 4:
break
if __name__ == "__main__":
loop()
print "That's all, folks"
Something must be wrong with me today because I find the Pascal code /more/
readable...
Peter
MRAB
should be separated by semicolons (the case-statement itself ends with
'end').
Tracubik
i was think the same, Pascal seem to generate a great more readable code.
I'm a newbie, so my opinion is probably wrong, but i still think that
don't have CASE OF and REPEAT UNTIL code block return in difficult-to-
read code.
>
> Peter
Nico
Michael Rudolf
That is probably a side-effect of literal code translation.
No one would write something like you did when he writes in python the
first place.
Hmmm lets see...
We have somewhat obscure and complicated logic.
If we cannot get rid of it, lets hide it:
class Loop:
def __init__(self, maxiterations=0, maxcount=1, m=0):
assert generic_condition.__call__
self.maxiterations = maxiterations
self.maxcount = maxcount
self.m=m
self.count=0
self.iterations=0
def __iter__(self):
while True:
yield self.next()
def next(self):
self.iterations+=1
if self.iterations > self.maxiterations:
raise StopIteration
if generic_condition():
self.count += 1
if self.count >= self.maxcount:
raise StopIteration
self.m = (None,1,10,100)[self.count]
return self, self.m
##### So we have:
#from complicatedlogic import Loop
from random import random
def generic_condition():
return random() > 0.7
if __name__ == '__main__':
for loop, m in Loop(maxiterations=20, maxcount=4):
print("%2d %1d %3d" % (loop.iterations, loop.count, m))
print("That's all, folks")
better? worse? I honestly do not know.
Note that while this is valid py3 and runs as intended, there might be
some off-by-one or something left.
Also, this is of course not production level code ;)
Regards,
Michael
Gregory Ewing
> Something must be wrong with me today because I find the Pascal code /more/
> readable...
Actually I don't find either of them very readable. The
control flow is pretty convoluted either way. It might
be better if it used real-life variable and function
names to give some context, though.
--
Greg