Danny Yoo wrote: > > > Hi Kermit, > > Ok, good. You should add this as a comment to the function's header, > so that other people can see this. Here is an example: > > def strongfac(z, w): > """z is the number to be factored. > w is a witness that may help find the factors of z. > """ > ## rest of function body.
Ok. I've added the suggested documentation for strongfac. > >> * What are the outputs? What is the return value of strongfac? >> >> The output is the return value of strongfac. >> fac = [ x, y, difficulty of factoring z using w] >> or >> fac = [0,0,0] if strongfac could not factor z using w. > > Great! Ok, I'm assuming that 'x' and 'y' are two arbitrary factors of > 'z'. Are there other properties about x and y that you want to state, > such as: "x is always prime", or do we make no guarantees about this? > > Yes. That is correct. There is not any expectation that x and y would be prime unless z just happens to be the product of exactly two primes. > > At this point, I'm distilling what you've said into a documentation > string: > > def strongfac(z, w): > """strongfac: number number -> [x, y, difficulty] > > Factors z into two pieces, returning those two pieces as well as the > difficulty in factoring z. w is a witness that may help find the > factors of z. > > If no factors can be found, returns [0, 0, 0]. > """ > ## rest of function body. > > > Does this make sense so far? The point is to make it easy for humans > to understand your program. > > Yes. I've replaced the previously suggested documentation with the above. > >>> # face = [x,y,0] >> [some code cut] >>> # face[0] = x >>> # face[1] = y >>> # face[2] = 0 >> >>> The three assignments to face[0] through face[2] don't do anything >>> effective and clutter the code. >> >> In fact, I knew that. I inserted it in an attempt to overide the >> apparent bug that I saw. >> >> Sometimes it worked. > > This is a bad sign. It should not have worked. *grin* > > Next time you hit something mysterious like this, mention it to the > list. It'll be a good puzzle for the others here to take a look at. > Your code should be as rational as possible. Don't just add code in > hoping that it'll fix some problem: try to understand why it's not > working first. Look for root causes. > > I agree. I reasoned as follows. The root cause is that Python is not returning the correct value of a list. So before I return the list, I will remind Python what's in the list. > > About strongfac(): > > > > Can you try this? Can you try breaking out the square=square test in > a similar way to how I treated the check_p_minus_1() code? > > > I have followed your suggestion and have done so. > > The high level goal here is to turn strongfac() into a very simple > looking function. In pseudocode, it'll look something like: > > ############################ > def strongfac(z, w): > use check_p_minus_1 test and return if it succeeds > use square=square test and return if it succeeds > ... > ############################ > > This will make strongfac very regular to read. It'll also make it > much easier to trace why one of your return values isn't returning > what you want. > you want. Ok. I will work on splitting up the rest of strong fac into a set of functions. I will attempt to maintain a compromise between having too many levels of function calls and having any one function be too long. Kermit < [EMAIL PROTECTED] > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
