Question

Lost on ps1a.py. Can I see any solution? Maybe more than one?

Answer 1

Here is my version:
http://codepad.org/zAxfgZ2i

Answer 2

here is my original - it handles both problems http://dpaste.com/707869/

here is a functional programming version - it only finds the 1000th prime and uses stuff you haven't seen yet: http://dpaste.com/707877/

Answer 3

could you give some explanations on the functional programming version please ?

Answer 4

Here is a slightly modified version of my solution. The main difference between it and the assignment is that it allows you to select the prime you're looking for (i.e. you're not stuck with 1,000 if you don't want to change the code) and along with that it's set up to return proper endings for the number you selected (e.g. 1st, 2nd, 3rd, 4th, ..., nth). Because it relies on user input, it also checks to make sure 'n' is a positive integer.

This solution does not use any abilities from the more advanced lessons (e.g. def), and my understanding is limited to having made it through the first 4 lectures, so it should make pretty decent sense. It only looks for divisors up to one half of each integer candidate because nothing larger than that has any chance of dividing evenly (e.g. if your candidate is 11 you do not need to check any divisors greater than 5.5 [read: 5] because you know anything larger than that can't go into 11 even twice). That speeds things up a lot over solutions that check each divisor up to the value of the integer candidate -- especially for large candidates.

http://pastebin.com/B4ijAfhg

Answer 5

with comments: http://dpaste.com/707983/

Answer 6

hmm that turns out to be slower than a regular for loop test - so it is slower and you can't easily tell what it does by reading it

here is a basic n % x == 0 but optimized: http://dpaste.com/708048/

Answer 7

I woke up yesterday pretty frustrated and promised to myself that I wouldn't see any solution before giving it at least one honest try. After 4 hours of pen & paper drama I managed to get this: http://dpaste.com/708136/ I would love to hear your thoughts about it.

Answer 8

Now that you have spent a lot of time to try to mmake your own code, why not compare it with some of the samples given here ? You will find it very useful.
And you could also see if the output of your code is right (is 7919 the 1000th prime?). If not, try with a smallest number (for example 3 or 4), and try to see what your program is doing wrong.

Answer 9

http://codepad.org/zAxfgZ2i The problem I see here is that it uses functions (which are explained on lesson 4) and this problem is planned to be solved with tools given on lessons 1 and 2. Same happens with: http://dpaste.com/708048/

Answer 10

Here's a version that respects point #4: "If the candidate is prime, print out some information so you know where you are in the computation (...)" http://codepad.org/2UuP4nsg

Answer 11

What I would like to see next are ps1b solutions. Such as this one: http://code.google.com/p/versorge/source/browse/trunk/workspace/mit600/src/ps1b.py?r=232

Answer 12

quick question: I'm comparing results with mine ( http://codepad.org/IYdYLlvv) and there must be something wrong with my solution cause it returns small differences on logsum starting around 10.000. Where's the problem?

Answer 13

http://codepad.org/IYdYLlvv there, last link included closing paren

Answer 14

are you sure that you are only finding primes?
and are you adding to logsum when you find a prime?

Answer 15

I have no idea. All I know is that it gives the same results until 10.000. If it weren't computing primes then it would be a huge coincidence that it adds the same value up to that number.

Answer 16

could it be an accumulation of rounding errors or floating point errors?
if the program successfully finds primes less than say 8000 and accumulates their logs then it should continue that behavior. the program doesn't care how big the numbers are as long as they meet the criteria

Answer 17

so for primes less than 10 and 50 i get a different sum but interestingly, for primes less than 20 is get the same sum. here are my results for 10, 20 and 50: sum [list of primes] http://dpaste.com/708488/

print statements at strategic locations are a big aid in debugging - also, if you can preserve the primes that you found or more importantly the numbers that you are including in your sum, you can inspect them after-the-fact - both of those will help you see what is going

i think i found part of the problem by inspecting the results. i'll give you a chance to solve it yourself so you can get a feel for debugging techniques - which unfortunately we all must become proficient at.

Answer 18

If I enter 10.000 in both of those scripts: 1) I get 9895.99137916 using http://code.google.com/p/versorge/source/browse/trunk/workspace/mit600/src/ps1b.py?r=232 and 9905.20241928 using mine. 2) I printed the log of each new prime number (great tip) and I found out that my script adds a final 9.21104012709 which I don't know where it comes from. /// The same happens for integer 10: it adds a weird 2.3978952728 as the last log. I don't know how to debug this.

Answer 19

hmmmm i wonder what the anti(?)log of 2.3978952728 is.
i wonder what the anti(?)log of 9.21104012709 is
.....

Answer 20

It's adding log(11) (for the 10 example):
11
2.3978952728

I still don't get why is adding log(11). Code states: while testno<n (...) It shouldn't add that log.

Answer 21

11 is the next prime > ten and
math.exp(9.21104012709) is 10007 which is the next prime > 10000

it appears to be allowing one more prime to be found.

i put a print statement in the inner loop to print n, testno, divisor
http://codepad.org/xTd681Hp

Answer 22

sometimes after you can see what is happening (using print statements) you need to walk through your code 'by-hand' and figure it out

Answer 23

It was a flow of execution issue. Here's the final solution: http://pastebin.com/UcS06eQD Thanks bwCA.