[Tutor] Actual code that illustrates problem

[Kermit Rose]

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  <  kermit at polaris.net  >