[Tutor] in-built square root function

[Timothy M. Brauch]

> So you're saying that (x + 1)%y is the same as (x%y) + 1? or just for
> the one instance with the example values I gave?  Because in the
> interpreter I get

Well, yes and no, it depends on if it is a human thinking about a field, or
a machine doing the calculations.

> >>> pow(45, 89, 3) + 1
> 1
> >>> (45**89)%3 + 1
> 1L
> >>> ((45**89) + 1)%3
> 1L
>
> but I also get
>
> >>> (3%2) + 1
> 2
> >>> (3 + 1)%2
> 0
>
> which is one example showing that (x%y) + 1 is not necessarily equal to
> (x + 1)%y.

Yes, what you got was correct.  But, if you are living in %2, then the only
possible answers are (0,1), so 2=0.  I was thinking about the solution in
human terms of a field, not necessarily how a computer would actually do the
calculation.  I have that problem sometimes.  Like I said, the % command
doesn't always give you answers you might expect, but you can convince
yourself that the anser you get is correct.  I guess I was imagining
((x%y)+1)%y.  Sorry, that's the algebraist in me rearing its ugly head.

> That's why I was curious about buit-in pow's z argument:  Yes, it may be
> more efficient for long modulo division but only for certain dividends
> (namely, those which can be expressed as an integer base to an integer
> power, per the Python Library Reference).  If I'm being dense and
> missing something really obvious then I sincerely apologize.

This problem really only comes up with if you look at (x%y)+n, where it adds
up to some number greater than y.  In the world of mathematics, though,
(x%y)+1 is equal to (x+1)%y, depending on which field you live in.

I guess for really large numbers you could do something like
pow(pow(45,89,3)+1,1,3) or even (pow(45,89,3)+1)%3, since the after the pow
function, you answer should be fairly easy to handle.

 - Tim