Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
*[ ms = milliseconds ]
Imagine that you have a timeline starting at 162000 ms (00:02:42.000), and ending at 10358500 ms (02:52:28.500). You have a marker placed at 4974123 ms (01:22:44.123).
Now, this timeline can be dragged in any way - as long as the start time is smaller that the end time. For example, this is valid: 580000 ms to 610000 ms. This is not: 610000 ms to 580000 ms.
So, imagine that we drag this timeline to start at 338100 ms (03:00:32.100), and ending at 10842200 ms (03:00:32.200). So: What time is the marker placed on now? And how do I calculate this?
Your assumption is wrong -- this is a very simple mathematical issue. If the initial interval is from 100 to 300 and the marker is at 120, it is located (120 - 100)/(300-100) = 10 % of the span from the starting point.
If you change the interval to 500 to 530, the marker should still (I suppose you mean like that) be 10 % of the span from 500 to 530, that is, at 500 + 0.1 * 30 = 503.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 days ago.
This post was edited and submitted for review 8 days ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
We analyzed a program which was supposedly used for cracking some cryptographic algorithms.
During the investigations we determined that the program input size can be varied in a wide range and for N-bit input the program result is also always N bit long. Additionally, we found that the program working time depends significantly on input length N, especially when N is greater than 10-15. Our test also reveals that the program working time depends only on Input length, not the input itself.
During our tests, we fixed the following working times with an accuracy of one hundredth of a second):
N=2-16.38 seconds
N=5 - 16.38 seconds
N = 10 - 16.44 seconds
N = 15 - 18.39 seconds
N = 20 - 1 minute 4.22 seconds
We also planned to test the program for N = 25 and N = 30, but for both cases the program didn't finish within half an hour and was forced to terminate it. Finally, we decided for N = 30 to not terminate the program, but to wait a little bit longer. The result was 18 hours 16 minutes 14.62 seconds. We repeated the test for N = 30 and it gave us exactly the same result, more than 18 hours. Tasks: a) Find the program working times for the following three cases - N = 25, N = 40 and N = 50. b) Explain your result and solution process.
At first I thought of finding a linear relation between N and time taken, t. Obviously that failed.
Then I realized that the t for N=2 and N=5 are nearly identical (here they are identical because they have been rounded to two digits after the decimal). Which emphasizes that the change in t only becomes more apparent when N>=10.
So, I tried to write t as a function of N, since t only depends on the size of the input.
Seeing the exponential growth my first idea was to write it as f(t)=Ce^N+k; where C and k are constants and e is euler's number.
That approach does not hold up. Afterwards I thought of trying powers of 2 because it's a computer question but I'm kind of lost.
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 1 year ago.
Improve this question
If I started with a sha256 hash such as
3f46fdad8e5d6e04e0612d262b3c03649f4224e04d209295ef7de7dc3ffd78a7
and rehashed it continuously (without salting):
i) What is the shortest time it would take before it started cycling in a loop or back onto the same value if at all?
ii) If it did cycle back on itself, could we assume that it had been cracked?
iii) How long would this take using modern GPU cracking techniques?
iv) If all the intermediary hashes were recorded in some kind of rainbow tables - presumably all the hashes within that cycle would be compromised?
v) What is to stop someone computing these cycles and offering cracks to sha256 hashes - likewise for other hashing protocols...
For Extra marks - What is the probability this question would be asked in this forum 60 billion years ago?
If values generated by sha256 can be assumed to be distributed uniformly and randomly, then there exists with probability 1−1/e (about 63%) a 256-bit sequence whose sha256 hash is equal to itself. If so, the minimum sequence length is one.
On the other hand, based on the pigeonhole principle, we know that the sequence must repeat after no more than 2256 iterations. This doesn't say anything about the brokenness of sha256.
The maximum cycle length is 2256 ≈ 1.16×1077 iterations. If you can evaluate 1012 hashes per second, then working your way through all possible hashes would take you about 1065 seconds (about one quindecillion times the age of the earth). Even if you're fortunate enough find a loop in a tiny fraction of that time, you're still liable to be waiting for trillions of years.
Good luck with that. If every atom in our galaxy was used to store a separate hash value, you would run out of space after storing less than one billionth of the total number of hashes. (Source: number of atoms in milky way galaxy ≈ 1068)
See 3 and 4
A similar question was asked about 9 years ago.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
If A=01, B=02...Z=26 and also every block consists of 2 letters, then how the number 83 will be decrypted?
For example, 0102 (or 102) makes AB.
I suggest that 83 will be 083, where 08 is H, but I don't know how to handle the 3
A=01, B=02...Z=26
lets add 64 to every int
A=64+01, B=64+02...Z=64+26
that will give u the correspending decimal number in the ascii-table http://www.ascii-code.com/
every block consists of 2 letters, wich mean 83 is 0083,
assuming 00 is or (space) < > 83 would be <">
another possibility; if we only use letters, then we r sure that the max int here is 26, so 3 can be used as 30 to mark the END of the message
If 00 had some meaning the number could be 0083, but it looks like your index starts with one so that would not be the case
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
The problem:
An undirected graph is unicyclic if it contains exactly one cycle. Describe an O( |V| + |E| ) algorithm for determining whether or not a given graph, G is unicyclic.
My solution:
int i = 0
Run a modified DFS on G, where we increment i everytime we decide not to visit a vertex because it has already been visited.
After DFS is done, if i==1, graph is unicyclic.
I thought this solution would work but am wondering if there is a counter example that would prove it false. If anyone could clarify that would be great, Thanks.
Does your graph consists of a single connected component?
In this case just count vertices and edges and check |V| - |E| = 0
Otherwise count the number of connected components O(|V| + |E|),
and check |V| - |E| = number of connected components - 1.
Remark: having more than one connected component is a counterexample to your algorithm.
"Increment i everytime we decide not to visit a vertex because
it has already been visited."
I am quite unclear about what you are trying to do here.
Rather then this, how about this:
Perform DFS and count number of back edges.
A back edge is an edge that is from a node to itself (selfloop) or one of its
ancestor in the tree produced by DFS.
If number of back edges ==1 then unicycle else not.
To count number of back edges, follow this algorithm.
To detect a back edge, we can keep track of vertices currently in recursion stack of
function for DFS traversal. If we reach a vertex that is already in the recursion stack,
then there is a cycle in the tree. The edge that connects current vertex to the
vertex in the recursion stack is back edge
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 9 years ago.
Improve this question
I'm asking this question here because I believe this is more of a programmatic issue than anything else.
I'm using a TI-84 Plus Sliver Edition calculator that contains logical operators that can test for less-than, greater-than, and equality. I find that when I input the expression:
2^34 == 2^34 - 1
it gives me a surprising 1 for true. It's worth mentioning that my calculator can't precisely output the result of 2^34. Rather, it uses the exponential notation for it and any other powers greater than 33. Is this a potential factor in the boolean output?
Furthermore, the equality test only returns true if the second expression is subtracting by 1 to 9. When the number is >= 10 it then correctly returns false.
Could it be a rounding error? Why is this expression returning true?
Your calculator cant keep track of numbers that large.
Every calculator has a set level of precision (lets say 10 digits). Every answer the calculator gives is rounded so that the answer has that many digits, then it shifts the decimal place as much as it needs to in order to make the number big or small (in your case very large).
Your number is so large that when you subtract 1, that causes a change after the 10th digit. This then gets rounded back to what you started with, and then compared. So naturally, it thinks they are the same number (to the precision it is capable of).