15.6: is_prime

#1

I got the code to work after some trial and error. However, is there a simpler/more efficient way to run the code? I changed

i = x
to
i = ** (0.5)

after reading a discussion thread about how it would be redundant to test numbers above the square root as they would be divisible by the reverse of what they were before ( Is_prime error ). This makes it more efficient, and while its irrelevant on small-scale tests like these, it matters as the scale grows. So, are there other things I should be looking to do as good practice moving forward?

def is_prime(x):
i = x ** (0.5)

``````if x < 2:
print "%d is not prime" % (x)
return False
elif x == 2:
return True
else:
while i >1:
for y in range(2,x):
if x%y == 0:

print "%d is not prime" % (x)
return False
else:
#print "%d hit the else" % (y)
i -= 1
else:
return True``````

#2

Good question. For starters, put `'more efficient'` on the back burner and learn algorithms. Without knowing the brute force approaches, we can hardly expect to recognize one.

Take for instance sorting. How many ways are there to sort a list? If we could not see the output and were inspecting raw code would we recognize a sorting algorithm? Not if we had never seen one, we wouldnâ€™t. We might not immediately identify the type of sorting, but that sorting is taking place would become evident on penciling (visually parsing) through the code.

When the time comes to put our finished ideas into a committed version, that would be when to look at bench marking and efficiency. Until then, concentrate on code patterns and being able to spot the segments that can be simplified without changing the outcome.

Bottom line, algorithms. Garner a host of knowledge around the ones that already exist so you donâ€™t spend your time re-inventing the wheel, but also challenge yourself before delving into each new chapter. Build upon the idea regardless of wasted resources, make it work, then find ways to simplify it and reduce resource usage. From there efficiency is an easy thing to work out. Leave it to the last in terms of consideration.

• realization
• simplification
• optimization

Development of any program is going to follow these steps. If we look at it from a different perspective, itâ€™s the opposite of thermodynamics. We are bringing order to chaos.

The main thing to keep in mind is that we cannot constrain ourselves with order when ideas are being bounced around. We have to play with them, predict outcomes and analyze the unexpected ones. We must take full liberty with our code and feel complete freedom to overuse resources.

``````realization     =>  proof of concept ->  make it work
simplification  =>  reduce to robust extremes -> build horsepower
optimization    =>  garbage collection, clock ticks, duplication, etc.
``````

Whatever people are saying, donâ€™t make optimization a priority. Youâ€™ll miss too much of the really important (and fun) stuff. Give yourself time to learn and grow and go for the biggest playground.

#3

Thanks for the reply! The idea of going from chaos to order makes sense. As
does the idea that as we contain the chaos, as it were, we loose some of
the creative perspective. Even if itâ€™s not the most efficient way,
experimenting with different approaches to problems allow for different
ideas or approaches in the future when one is trying to simplify.

#4

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.