I want to ask Maple, for example, for which j the following is true:
10^j mod 543 = 82
How can I ask Maple this?
Also, is there a way to solve for j without a computer?
This is called the The Discrete Logarithm Problem. It is a difficult problem---computationally intensive. See the Wikipedia page. It has discussion of eight algorithms for the problem. The Maple command is numtheory:-mlog.
numtheory:-mlog(82, 10, 543);
Maple responds
12
To obtain all such integers j, use the extended form of the command:
numtheory:-mlog(82, 10, 543, 'c');
Maple again responds with 12, and c is set to 180, meaning that j = 12 + 180*k is a solution for any nonnegative integer k.
Related
The question asks us to solve for x in the given equation c' = x^e mod N, given the fact that we already know c', e , mod N. I looked into my tutorial, bu they only gave us a way to get e, but not for x.
I have manually tried to solve it and got the equation:
log c' = e log x mod N
but I don't know how to put in in Sage Math.
This is from the tutorial to find e:
discrete_log (c',Mod(x,N))
The question is really asking how to find an e-th root of c' modulo N.
Say for example one wants to solve 12 = x^99 modulo 347.
This amounts to finding a 99-th root of 12 modulo 347.
Just set up the ring of integers modulo 347,
sage: A = Zmod(347)
sage: A
Ring of integers modulo 347
give a name to the element 12 in that ring,
sage: a = A(12)
and ask Sage for a 99-th root of this element:
sage: a.nth_root(99)
241
Check that this answers the question:
sage: A(241)^99
12
sage: pow(241, 99, 347)
12
sage: power_mod(241, 99, 347)
12
Samuel's answer is far more comprehensive than this, but if you are looking for a really quick fix, you could use this (naive) function for small moduli:
sage: solve_mod(x^99==12, 347)
[(241,)]
I'm running on R2012a version. I tried to write a function that imitates randi using rand (only rand), producing the same output when the same arguments are passed and the same seed is provided. I tried something with the command window and here's what I got:
>> s = rng;
>> R1 = randi([2 20], 3, 5)
R1 =
2 16 11 15 14
10 17 10 16 14
9 5 14 7 5
>> rng(s)
>> R2 = 2+18*rand(3, 5)
R2 =
2.6200 15.7793 10.8158 14.7686 14.2346
9.8974 16.3136 10.0206 15.5844 13.7918
8.8681 5.3637 13.6336 6.9685 4.9270
>>
A swift comparison led me to believe that there's some link between the two: each integer in R1 is within plus or minus unity from the corresponding element in R2. Nonetheless, I failed to go any further: I checked for ceiling, flooring, fixing and rounding but neither of them seems to work.
randi([2 20]) generates integers between 2 and 20, both included. That is, it can generate 19 different values, not 18.
19 * rand
generates values uniformly distributed within the half-open interval [0,19), flooring it gives you uniformly distributed integers in the range [0,18].
Thus, in general,
x = randi([a,b]]);
y = rand * (b-a+1) + a;
should yield numbers with the same property. From OP’s experiment it looks like they might generate the same sequence, but this cannot be guaranteed, and it likely doesn't.
Why? It is likely that randi is not implemented in terms of rand, but it’s underlying random generator, which produces integers. To go from a random integer x in a large range ([0,N-1]) to one in a small range ([0,n-1]), you would normally use the modulo operator (mod(x,N)) or a floored division like above, but remove a small subset of the values that skew the distribution. This other anser gives a detailed explanation. I like to think of it in terms of examples:
Say random values are in the range [0,2^16-1] (N=2^16) and you want values in the range [0,18] (n=19). mod(19,2^16)=5. That is, the largest 5 values that can be generated by the random number generator are mapped to the lowest 5 values of the output range (assuming the modulo method), leaving those numbers slightly more likely to be generated than the rest of the output range. These lowest 5 values have a chance floor(N/n)+1, whereas the rest has a chance floor(N/n). This is bad. [Using floored division instead of modulo yields a different distribution of the unevenness, but the end result is the same: some numbers are slightly more likely than others.]
To solve this issue, a correct implementation does as follows: if you get one of the values in the random generator that are floor(N/n)*n or higher, you need to throw it away and try again. This is a very small chance, of course, with a typical random number generator that uses N=2^64.
Though we don't know how randi is implemented, we can be fairly certain that it follows the correct implementation described here. So your sequence based on rand might be right for millions of numbers, but then start deviating.
Interestingly enough, Octave's randi is implemented as an M-file, so we can see how they do it. And it turns out it uses the wrong algorithm shown at the top of this answer, based on rand:
ri = imin + floor ( (imax-imin+1)*rand (varargin{:}) );
Thus, Octave's randi is biased!
when I calculate a very small number, matlab gives
1.12345e-15
What is this?
I can interpret it as 1.12345*10^(-15)
or its 1.12345*e^(-15)
I am in very hurry. Sorry for the stupid question.
e represents exponential. Its the scientific notation of writing numbers.
The base is 10. For example:
1e2 =100
1e-2= 0.01
e represents scientific notation as Rahul said but it is base 10, not base e.
Run the following code to confirm.
1e1
It gives you
ans = 10
688^79 mod 3337 = 1570.
When I tried this at wolfram alpha I got:
but When I entered the same thing in Matlab, I get 364 as the answer. I got to be doing something wrong.
Any light on this will be appreciated.
The reason is that Matlab uses double floating-point arithmetic by default. A number as large as 688^79 can't be represented accurately as a double. (The largest integer than can be accurately represented as a double is of the order of 2^53).
To obtain the right result you can use symbolic variables, which ensures you don't lose accuracy:
>> x = sym('688^79');
>> y = sym('3337');
>> mod(x, y)
ans =
1570
My calculator is sending me the same answer than Wolfram, it also calculated the value for 688^79 so I would tend to believe Wolfram is right.
You probably have overrun the capacities of Matlab with such a huge number and it is why it did not send the right answer.
I have a variable, tauMax, that I want to round up to the nearest power of ten(1, 10, 100, 1000...). I am using the below expression to find the closest integer to the max value in the tau array. I am finding the max value because I am trying to calculate the power of ten that should be the x axis cutoff. In this cause, tauMax is equal to 756, so I want to have an expression that outputs either 1000, or 3(for 10^3).
tauMax = round(max(tau));
I'd really appreciate any help!
Since you're talking base 10, you could just use log10 to get the number of digits.
How about:
>> ceil(log10(756))
ans =
3
I don't really do Matlab, but the usual way to do this in any language I do know is: take the logarithm base 10, then round up that number to the nearest integer, then compute 10 to the power of that number. In Python:
from math import ceil, log
def ceil_power_of_10(n):
exp = log(n, 10)
exp = ceil(exp)
return 10**exp
>>> print(ceil_power_of_10(1024)) # prints 10000
You could also look at the source of the built-in Matlab function nextpow2(N) (simply open nextpow2.m) to see how Mathworks engineers implemented this for a power of 2 and create a new function adapting this source to a power of 10.
http://www.mathworks.it/it/help/matlab/ref/nextpow2.html