I'm asking for a non-programming point of view because i want to see the meaning - why is it that way?
There is a sequence in one book and the formula for it is (2n+3)/(6n-5). And it is said that it is decreasing which can be seen by the obtained formula: -28/((6+1)(6n-5)). I see the formula works for every member but how can i obtain that formula which determines if the sequence is decreasing or increasing?
What you're interested in is the difference between two sequential elements, take for example n and (n+1).
The nth term is (2n+3)/(6n-5)
The (n+1)th term is (2n+5)/(6n+1)
Now, you can find the difference between these two terms:
f(n+1)-f(n) = (2n+5)/(6n+1) - (2n+3)/(6n-5)
Notice that, conceptually, the value is the Difference between one term and the next one.
This simplifies to the expression you wrote. Now, just to be pedantic, there is a small typo in the solution you gave, but it looks like an actual typo, not a misunderstanding or wrong answer. You have "(6+1)" where it should be "(6n+1)"
Now, when this value is positive, the sequence is increasing, and when it is negative the sequence is decreasing. This value, for example, will always be negative for n>5/6. There is a negative number in the numerator, and no way for the denominator to become negative to cancel it out.
Go to : http://www.wolframalpha.com/widgets/view.jsp?id=c44e503833b64e9f27197a484f4257c0
Under "derivative of" input your formula : (2*x+3)/(6*x-5)
Click "submit" button
Click the "Step-by-step solution" link
OPs question: How to get from (2*x+3)/(6*x-5) to -28/(5-6x)^2
Answer: Find the first derivative of (2*x+3)/(6*x-5)
How: Start with quotient rule for finding derivatives http://en.wikipedia.org/wiki/Quotient_rule to simplify that you'll need a few other rules http://en.wikipedia.org/wiki/Category:Differentiation_rules
Related
While doing certain computations involving the Rogers L-function, the following result was generated by Wolfram Alpha:
I wanted to verify this result in Pari/GP by means of the lindep function, so I calculated the integral to 20 digits in WA, yielding:
11.3879638800312828875
Then, I used the following code in Pari/GP:
lindep([zeta(2), zeta(3), 11.3879638800312828875])
As pi^2 = 6*zeta(2), one would expect the output to be a vector along the lines of:
[12,12,-3]
because that's the linear dependency suggested by WA's result. However, I got a very elaborate vector from Pari/GP:
[35237276454, -996904369, -4984618961]
I think the first vector should be the "right" output of the Pari code sample.
Questions:
Why is the lindep function in Pari/GP not yielding the output one would expect in this case?
What can I do to make it give the vector that would be more appropriate in this situation?
It comes down to Pari treating your rounded values as exact. Since you must round your values, lindep's solution doesn't always come to the same solution as the true answer due to error.
You can try changing the accuracy of lindep using the second argument. The manual states that you should choose this to be smaller than the number of correct decimal digits. I believe this should solve the issue.
lindep(v, {flag = 0}) finds a small nontrivial integral linear
combination between components of v. If none can be found return an
empty vector.
If v is a vector with real/complex entries we use a floating point
(variable precision) LLL algorithm. If flag = 0 the accuracy is chosen
internally using a crude heuristic. If flag > 0 the computation is
done with an accuracy of flag decimal digits. To get meaningful
results in the latter case, the parameter flag should be smaller than
the number of correct decimal digits in the input.
Can anybody please look at the image and tell me how the time is calculated for exponential algorithms i.e., 2^n and 3^n.
From the top row, we can see that when n = 10, it takes 10μs to perform the work. That means that each operation takes one microsecond.
The rows with 2n and 3n are computed by listing 2nμs and 3nμs in more convenient units. For example, 210μs = 1024μs is about 0.001s.
(It would have been nice for the table designer to explicitly indicate that each operation is one microsecond, since that would let you interpret the data more clearly or adjust it for cases where, say, each operation took one nanosecond.)
Hope this helps!
Problem
I want to find
The first root
The first local minimum/maximum
of a black-box function in a given range.
The function has following properties:
It's continuous and differentiable.
It's combination of constant and periodic functions. All periods are known.
(It's better if it can be done with weaker assumptions)
What is the fastest way to get the root and the extremum?
Do I need more assumptions or bounds of the function?
What I've tried
I know I can use root-finding algorithm. What I don't know is how to find the first root efficiently.
It needs to be fast enough so that it can run within a few miliseconds with precision of 1.0 and range of 1.0e+8, which is the problem.
Since the range could be quite large and it should be precise enough, I can't brute-force it by checking all the possible subranges.
I considered bisection method, but it's too slow to find the first root if the function has only one big root in the range, as every subrange should be checked.
It's preferable if the solution is in java, but any similar language is fine.
Background
I want to calculate when arbitrary celestial object reaches certain height.
It's a configuration-defined virtual object, so I can't assume anything about the object.
It's not easy to get either analytical solution or simple approximation because various coordinates are involved.
I decided to find a numerical solution for this.
For a general black box function, this can't really be done. Any root finding algorithm on a black box function can't guarantee that it has found all the roots or any particular root, even if the function is continuous and differentiable.
The property of being periodic gives a bit more hope, but you can still have periodic functions with infinitely many roots in a bounded domain. Given that your function relates to celestial objects, this isn't likely to happen. Assuming your periodic functions are sinusoidal, I believe you can get away with checking subranges on the order of one-quarter of the shortest period (out of all the periodic components).
Maybe try Brent's Method on the shortest quarter period subranges?
Another approach would be to apply your root finding algorithm iteratively. If your range is (a, b), then apply your algorithm to that range to find a root at say c < b. Then apply your algorithm to the range (a, c) to find a root in that range. Continue until no more roots are found. The last root you found is a good candidate for your minimum root.
Black box function for any range? You cannot even be sure it has the continuous domain over that range. What kind of solutions are you looking for? Natural numbers, integers, real numbers, complex? These are all the question that greatly impact the answer.
So 1st thing should be determining what kind of number you accept as the result.
Second is having some kind of protection against limes of function that will try to explode your calculations as it goes for plus or minus infinity.
Since we are touching the limes topics you could have your solution edge towards zero and look like a solution but never touch 0 and become a solution. This depends on your margin of error, how close something has to be to be considered ok, it's good enough.
I think for this your SIMPLEST TO IMPLEMENT bet for real number solutions (I assume those) is to take an interval and this divide and conquer algorithm:
Take lower and upper border and middle value (or approx middle value for infinity decimals border/borders)
Try to calculate solution with all 3 and have some kind of protection against infinities
remember all 3 values in an array with results from them (3 pair of values)
remember the current best value (one its closest to solution) in seperate variable (a pair of value and result for that value)
STEP FORWARD - repeat above with 1st -2nd value range and 2nd -3rd value range
have a new pair of value and result to be closest to solution.
clear the old value-result pairs, replace them with new ones gotten from this iteration while remembering the best value solution pair (total)
Repeat above for how precise you wish to get and look at that memory explode with each iteration, keep in mind you are gonna to have exponential growth of values there. It can be further improved if you lets say take one interval and go as deep as you wanna, remember best value-result pair and then delete all other memory and go for next interval and dig deep.
I want to generate some numbers, which should attempt to share as few common bit patterns as possible, such that collisions happen at minimal amount. Until now its "simple" hashing with a given amount of output bits. However, there is another 'constraint'. I want to minimize the risk that, if you take one number and change it by toggling a small amount of bits, you end up with another number you've just generated. Note: I don't want it to be impossible or something, I want to minimize the risk!
How to calculate the probability for a list with n numbers, where each number has m bits? And, of course, what would be a suitable method to generate those numbers? Any good articles about this?
To answer this question precisely, you need to say what exactly you mean by "collision", and what you mean by "generate". If you just want the strings to be far apart from each other in hamming distance, you could hope to make an optimal, deterministic set of such strings. It is true that random strings will have this property with high probability, so you could use random strings instead.
When you say
Note: I don't want it to be impossible or something, I want to minimize the risk!
this sounds like an XY problem. If some outcome is the "bad thing" then why do you want it to be possible, but just low probability? Shouldn't you want it not to happen at all?
In short I think you should look up the term "error correcting code". The codewords of any good error correcting code, with any parameters that you feel like, will have the minimal risk of collision in the presence of random noise, for that number of code words of that length, and they can typically be generated very easily using matrix multiplication.
I am working on designing a new sensor, and so I have a vector of measured values and a vector of truth values. To represent error, it's simply measured - truth. Since there's a lot of variation in the truth, I would like to represent the normalized error. My initial thought would be error./truth to get percent error, but there are many cases where my truth value is zero! Can anyone think of a better way to represent the normalized data while avoiding the divide-by-zero? I'm working in Matlab, though the question is a bit language-agnostic as well.
PS, feel free to push this to another stackexchange if you think it's better suited
Try error = (measured-truth)/norm2(truth) for each vector.
Where norm2() is the forbenious norm.
norm2(x) =SQRT( SUM( x[i]^2, i=1..N ) )
This can only fail is all the values of truth are zero. You can mitigate this by adding a small positive number like 1e-12 to the norm, or to avoid the division when the norm is less than a threshold number.
I'd suggest you to separate results with zero (or smaller than 10e-6 for example) truth vector and non-zero truth vector. You can't treat it by the same means (since you can't normalize truth vector) and you should define what to do in that case.
I can't suggest you something specific because I don't know the problem statement, but you should define it by yourself how to deal with it. Or if you post your problem here I hope we can help you.