Talk:Modular exponentiation

message: Plugging in 3, 10 and 7.1 for the variables base, exponent and modulous yield 1.74 instead of 6.  — Preceding unsigned comment added by 223.206.114.1 (talk) 04:43, 13 August 2011 (UTC)
thread_title:  Left-to-Right algorithm work with a fractional modulus? 

message: A base of 10, a exponent of 3 and a modulus of 7.1 (1000 % 7.1) yields 1.74 instead of 6.  — Preceding unsigned comment added by 223.206.114.1 (talk) 01:32, 13 August 2011 (UTC)
thread_title:  Binary modular algorithm and fractional modulus 

message: The article currently states
: c \equiv b^e \pmod{m}
:...
:If b, e, and m are non-negative and b < m, then a unique solution c exists and has the property 0 ≤ c < m.
I don't understand the point of "b<m". Would it be OK to replace that sentence with
:If b, e, and m are non-negative, then a unique solution c exists and has the property 0 ≤ c < m.
or is there something I'm missing?
--70.189.77.59 17:36, 16 October 2006 (UTC)
replies: text: I'm note sure about in that specific context, but the "memory-efficient" algorithm, at least (as given), won't work if b >= m, because, according to the thing about it, be (mod m) = (be-1*b) (mod m) = ((be-1 (mod m))*(b (mod m))) (mod m). The "c" variable contains the iterative value of be-1 (mod m), but the algorithm as shown doesn't do b (mod m), which isn't neccessary anyway if b is < m. B.Mearns*, KSC 19:00, 1 March 2007 (UTC)
thread_title:  "unique solution" 

message: What restrictions do I need on b and e and m must be, in order to avoid an ambiguous system?
(An ambiguous system allows 2 different b values produce onto the same c value, allows 2 different plaintexts to produce the same ciphertext -- Bob would be unable to figure out which plaintext message Alice intended to send).
(Is there some other article that discusses ambiguity of modular exponentiation?)
To be unambigous, b must be 0 ≤ b < m because of the pigeonhole principle.
But 0 ≤ b < m is not sufficient -- for example, both
:  1^2 mod 4 = 1
:  3^2 mod 4 = 1
.
Is it enough to set e prime (RSA mentions that the prime 2^16 + 1 = "65537 is a commonly used value for e"), and make sure m is not a multiple of e?
--70.189.77.59 17:36, 16 October 2006 (UTC)
thread_title:  avoiding ambiguity 

message: please someone remove that section. the algorithm is just a re-written version of the C# code. contrary to the claim, it is inefficient and not suited for hardware implementation . it seems the only reason it is there is to please the python zealots. 213.80.27.34 (talk) 12:09, 28 November 2007 (UTC)
replies: text: I removed the reference to cleverness; the author seems entirely too pleased with himself. This article is about modular exponentiation, there is no reason to consider regular exponentiation in the example code, and the original implementation also "cleverly" uses a single variable. I see no reason to include the python, even if it is cleaned up. The C++ could probably be made a little clearer with the use of actual variable names, and by using normal operators instead of bitwise ones. Flying Bishop (talk) 18:30, 27 August 2008 (UTC)
replies: text: I'm going to remove the entire section.  The IP that originally added it has been inactive for over a year and a half.  The section has recently been tagged with a lot of OR and FACT tags, which really should have been there since the explanations were added (thanks, bishop!), and I doubt they will be answered.  Also, as Flying Bishop noted, there is no need to consider general exponentiation (without a modulus) in this article. Pfagerburg (talk) 04:23, 11 September 2008 (UTC)
thread_title:  optimized example ?? 

message: Fractional modulo used with binary algorithm yielding incorrect results?
Given base = 10, exponent = 3 and modulus of 7.1 returns 1.74 instead of 6.
result = 1
Loop 1:
result = (1 * 10) MOD 7.1 = 2.9
exp >> 1 = 1
base = (10 * 10) MOD 7.1 = .6
Loop 2:
result = (2.9 * .6) MOD 7.1 = 1.74
exp>> = 0
result = 1.74  — Preceding unsigned comment added by 223.206.114.1 (talk) 15:02, 12 August 2011 (UTC)
replies: text: True. Multiplication operation with a fractional modulus isn't associative, so this algorithm doesn't work with it. -- X7q (talk) 15:33, 12 August 2011 (UTC)
thread_title:  Fractional modulo 

message: : c \equiv (a \cdot b) \pmod{m}
: c \equiv (a \cdot (b\ (\mbox{mod}\ m))) \pmod{m}
This isn't completely obvious (to me!), is there a link to another wikipedia page that might show why this is always the case? I can see it is now I've tried it out on paper...Thanks for the great article by the way! Lionfish0 (talk) 17:12, 26 January 2012 (UTC)
replies: text: This wasn't obvious for me either, although I have a master in physics. I could also reproduce it on paper, but it would be nice to reference an explanation. Ansiwen (talk) 16:23, 4 September 2018 (UTC)
thread_title: ...This algorithm makes use of the fact that, given two integers a and b, the following two equations are equivalent...

message: Given that the article states that "even when the numbers involved are enormous", it should take into account that multiplication of large numbers may not be computable directly on the processor. Thus, the runtimes should be depending on the efficiency of the multiplication algorithm: as in http://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations.
Per.Zut (talk) 10:14, 5 August 2013 (UTC)
thread_title:  Constant multiplication 

message: In general, if one needs to calculate b^e \bmod m for arbitrary given b, e, m, then it makes sense first to reduce the exponent to e \bmod {\varphi(m)} because of Euler's theorem. In many application, e.g. in cryptography, you will already have e < \varphi(m), and this reduction does not improve efficiency.  — Preceding unsigned comment added by Wstomv (talk • contribs) 22:11, 21 January 2016 (UTC)
replies: text: In order to compute \varphi(m) you need the factorization of m and, in general,  this looks harder than calculating b^e \bmod m  with the methods described in the page.78.15.205.250 (talk) 10:34, 8 April 2016 (UTC)
replies: text: On the other hand there are cryptographic methods based on just that.  It's baffling that the totient is not mentioned at all in this article.  — jdorje (talk) 07:43, 13 May 2016 (UTC)
thread_title:  Mention Euler's Theorem 

message: I rewrote the example of raising a number to the 13 th power.
First, percents didn't belong there because percent is a modulus operator in specific computer languages. Second, I found the example with the four bullet points very hard to follow.
So, I wrote the basic algorithm following the example of raising a number to the 13 th power. The original example kept squaring the original base b; I used the unnecessary variable x so the explanation could explain what power of b was being computed. I then followed the algorithmic description with a rewrite of the original example with numbers b = 4, e = 13, modulus m = 497. I don't feel this numeric example makes things clearer, but I'll let other people decide whether to delete it. MathPerson (talk) 15:07, 6 April 2017 (UTC)
thread_title:  Right-to-left binary method 

message: This ultra naive algorithm is not a "method" and it has zero citations. I barely understand why it's worth mentioning, let alone dedicate multiple paragraphs and fully worked-out example with pseudocode to boot. The only purpose this can possibly serve is conceptual understanding, it is not used in the real world. Can it be condensed? Rubydesic (talk) 07:53, 10 February 2024 (UTC)
replies: text: Like in the explanation in this post, it builds up to more efficient methods. The memory efficient one is the starting point. It explains how to use the product rule of modular arithmetic in the most simple case. 84.198.41.61 (talk) 12:17, 25 February 2024 (UTC)
thread_title:  What is up with this "Memory Efficient Method" featured prominently as the second section in the article?