Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I know this is not a mathematical forum but given the bright minds that participate here, i am sure that this question is of interest nevertheless. How would you develop and explain the following statement:
"we can convert the product of a set
of primes into a sum of the logarithms
of the primes by applying logarithms
to both parts of this conjecture"
log(a * b) = log(a) + log(b)
thanks for that OrangeDog and John!
re benefit of introducing logs, OrangeDog is right indeed. It is specific to an exercise from an MIT OpenCourse class. Here's the full details:
There is a cute result from number
theory that states that for
sufficiently large n the product of
the primes less than n is less than or
equal to e^n and that as n grows,
this becomes a tight bound (that is,
the ratio of the product of the primes
to e^n gets close to 1 as n grows).
Computing a product of a large number
of prime numbers can result in a very
large number, which can potentially
cause problems with our computation.
[note: this is what John was referring
to] So we can convert the product of a
set of primes into a sum of the
logarithms of the primes by applying
logarithms to both parts of this
conjecture. In this case, the
conjecture above reduces to the claim
that the sum of the logarithms of all
the primes less than n is less than n,
and that as n grows, the ratio of this
sum to n gets close to 1.
EDIT
given these statements i am, however, unsure about how to apply them i.e.
how do we go from here:
2 x 3 x 5 <= e^7
to
"applying
logarithms to both parts of this
conjecture."
EDIT 2
got it...
2 x 3 x 5 <= e^7
knowing that logarithms are the opposite of powers we can say:
log(2x3x5) <= 7
which is also the same as:
log(2)+log(3)+log(5) <= 7
this only starts to show its "value" when n (in this case 7) gets larger i.e. the 1000th prime or higher
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Say I want to calculate the expected number of rolls of a die before a particular value is rolled, let's say a 5. I know this involves geometric distribution. Is there an R function that can calculate this?
I think what you're looking for is a sum of an infinite series. We basically need to model every scenario - that is we need to sum the expected value of getting a 5 on the 1st, 2nd, 3rd, 4th, etc rolls. To do this we can use a simple sum (not infinite, but a large number to basically get "close" to infinite behavior). The code to do that in R is:
x<-100
rolls<-0
for (i in 1:x){
rolls<-rolls + (5/6)^(i-1)*(1/6)*i
}
Putting this code into plain english we have:
Sum the first 100 rolls
For each roll, n, the probability of a 5 on that roll = (probability of not getting a 5 on all rolls leading up to roll n) * (probability of 5 on roll n)
The probability of not getting a 5 on all rolls leading up to roll n = (prob of not 5^(n-1)) = (5/6^(n-1))
Probability of a 5 on any given roll is 1/6
Finally now that we have the probability of a 5 on any given roll, n (which is just (5/6^n-1 * 1/6), then we can multiply this probability by the roll number to get the expected value of each roll. This gives us the equation seen in the code.
Looking at the result we see that is converges to 6:
rolls
[1] 5.999999
You can probably solve this without doing any programming, but its been a while since I did that type of math.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
This may be quite simple, but I'm wondering if there is a technical way to describe a relative value that grows exponentially based on the percentage.
e.g. If these numbers grow by 13.5% every month:
100 * 13.5% = 13.5
113.5 * 13.5% = 15.3225
115.3225 * 13.5% = 15.5685375
... etc
I am trying to understand the technical or correct way to describe these changes in mathematics. Is there also an equation that would describe this? Thank you to all the math nerds in advance!
It is called a geometric series/sequence.
The generic form is S = a(1 + r^n)
where:
S is the sum of the first n elements of the series.
a is the first element
r is the multiplication factor
n is the number of terms.
in your example:
a = 100
r = 0.135
n = is the number you want to compute for.
if you want the 10th element then n = 10 if you want the 100th element then n = 100.
When you do compound interest calculations you need to be careful as well that the interest you are given is for the year, but the interest is calculated every month so you must adjust your values accordingly.
here is a link to wikipedia that examplains it. At the base it is the same formula but it accounts for all that other stuff I mentioned.
https://en.wikipedia.org/wiki/Compound_interest
Compounded Annual Growth Rate would be the investment term where what you want is a slightly different formula as there is a 1.135 factor that is being multiplied with itself to compound the return.
Consider a 10% growth rate and different interest calculations over a few years:
Simple interest for 3 years on $100 would be $10 each for a total of $30.
Compound interest for 3 years on $100 would be $10 for the first year, $11 for the second year and $12.10 for the 3rd year for a total of $33.10 in this case.
Are you sure your calculations are correct?
I think what you're looking for is:
100 * 13,5 % = 13,5 %
(100 + 13,5) * 13,5 % = 15,3225
(100 + 13,5 + 15,3225) * 13,5 % = 17,3910375
or in short:
100 * 1,135^t
for t=3
100 * 1,135^3 = 146,2135375
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
16 (which has a prime decomposition of 2^4) and 27 (which has a prime decomposition of 3^3) have no common prime factors. Then why is the result of gcd(16, 27) == 1?
I've checked with Python:
>>> from fractions import gcd
>>> gcd(16, 27)
1
What you are probably confusing with is that the numbers 16 and 27 don't have any common divisors except 1. GCD is defined as the greatest common divisor/factor which divides both the numbers.
You are probably thinking about co-primes! But, neither 16 or 27 is prime to be checked for co-prime, as only prime numbers are compared for co-prime condition!
As you can see, the factors (divisors) of 16 are 1,2,4,8,16. Similarly, the factors (divisors) of 27 are 1,3,9,27.
16---> 1,2,4,8,16
27---> 1,3,9,27.
So, checking the highest/greatest common factor(h/gcf) OR greatest common divisor(gcd) of both the numbers, we find the gcd to be 1.
Hence, your python script is giving you the correct result as really the gcd of 16 and 27 does come out to be 1 as I explained above!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
int length = (int) floor( log10 (float) number ) + 1;
My question is essentially a math question: WHY does taking the log10() of a number, flooring that number, adding 1, and then casting it into an int correctly calculate the length of number?
I really want to know the deep mathematical explanation please!
For an integer number that has n digits, it's value is between 10^(n - 1)(included) and 10^n, and so log10(number) is between n - 1(included) and n. Then the function floor cuts down the fractional part, leaves the result as n - 1. Finally, adding 1 to it gives the number of digits.
Consider that a four-digit number x is somewhere between 1000 <= x < 10000. Taking the log base 10 of all three components gives 3.000 <= log(x, 10) < 4.000. Taking the floor (or int) of each component and adding one gives 4 <= int(log(x, 10))+1 <= 4.
Ignoring round-off error, this gives you the number of digits in x.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
random a 512-bit integer N that is not a multiple of 2, 3, or 5
I have a question
for a random 512-bit integer n that isn't a multiple of 2,3, or 5 what is the chance that n is prime? what about that n is composite but fools the fermat primality test? what about that it is composite but doesn't fool the fermat primality test?
Since this is definitely a homework problem, I'll point you at the Prime Number Theorem, which should give you the probability that any large number is prime.
From there, modify the probability with your new information about composite numbers that have been eliminated (Hint: Think about how the problem space shrinks).
Best of luck!