I tried to recover a password. When thinking of this I recognized that the problem "password recovery" is a very nice example of a NP problem. If you know the password it's very easy to verify it in polynomial time. BUT if you don't know the password you have to search the whole space of possible solutions which can be shown to take exponential time.
Now my question is: Doesn't this demonstrate that P != NP since "password recovery" is an element of NP that can be shown to require more than polynomial time to run?
If you show that any algorithm that solves "password recovery" requires more than polynomial time, then it does demonstrate that P ≠ NP.
Otherwise, if you only show that one particular solution requires more than polynomial time, it demonstrates nothing. I can write a sort to require exponential time (shuffle array until it's sorted), but that doesn't mean there's no polynomial solution.
NP does not mean "nonpolynomial", if that's what you were thinking (and my apologies in advance if you were not!). It means "nondeterministic polynomial". A nondeterministic algorithm is one that's equivalent to an unbounded number of parallel instances of an algorithm. As an example, finding the correct password by brute force is nondeterministic polynomial: if you imagine that checking the password, if your guess happens to be correct, takes linear (i.e. polynomial) time on the length of the password, but that you need to check an arbitrary number of possible passwords (k^n) in parallel, then the cost of finding the solution using this method is nondeterministic polynomial.
A nondeterministic algorithm can also be thought of one whose state branches at some steps. A simple example of this is a nondeterministic finite automaton (NFA) -- sometimes you don't know what edge to take between states, so you take them both. It's easy to show that every NFA is equivalent to a deterministic FA, and so it is tantalising to think the same could be proved for other interesting classes of algorithm. Unfortunately it's hard to do so for the general case of polynomial algorithm, and the general suspicion is that they are not equivalent, i.e. that P != NP.
The reasoning that the problem is in NP is correct: if it can be verified in polynomial time, it's in NP. Even very simple problems are in NP. Basically, all of P is included in NP. (*)
Now, here is one way you could go about turning this into a proof that P != NP:
1) Show that "password recovery" is NP-complete. That is, any problem in NP can be reduced to "password recovery" in polynomial time. (i.e. there is an efficient algorithm to convert any other NP problem to "password recovery".)
2) Once you have that then, as Pavel Shved mentions, it is not enough to show that the intuitive algorithm is non-polynomial. You have to show that there does not exist a polynomial algorithm to solve "password recovery". A very difficult task.
(*) Edmund is also right: NP means polynomial on a non-deterministic machine. A polynomial verification is essentially the path chosen by the non-deterministic machine.
As stated, "password recovery" is not a decision problem.
You have not proved that "password recovery" does not have a polynomial-time algorithm, you have merely argued on intuitive grounds that it does not. Just because a solution space is gigantic does not mean there are not fast algorithms to find the solution; for example, there are n! permutations of a set of n distinct integers but only one is sorted ascending yet we can find it in n log n time. For a more fun example, see Project Euler #67.
Even if you did rephrase "password recovery" as a decision problem and were able to show that there is not a polynomial-time algorithm for solving it, you now have to prove that "password recovery" is NP-complete.
For details on P/NP/etc. see this previous question.
The problem is not showing that password recovery is non-polynomial, since clearly it is -- you have to search an exponential space of answers.
Actually, "password-recovery" isn't really a description of a standard computational problem. It seems that, formally, password breaking algorithms take some sort of "oracle" that can answer whether a given string is the correct password. However, P and NP are defined in terms of Turing machines, which take strings as input.
The formal statement of this problem would be one that accepts as input the hashed value (and salt) and attempts to find a password that will generate that hash: your basic known cyphertext collision finding problem.
Depending on the quality of the hash, this might not require exponential time. Indeed, many cryptographic hashed in widespread use have identified attacks that run faster than keyspace searches.
Which is to say: you (ans some of the other responders) have assumed that the password munging routine has all the properties the designers wanted them to have. This would have to be proved.
Writing this answer because I had this idea at some point, and the answers here were not satisfactory.
You have proved that P =/= NP under the presence of an 'Oracle' (this is the thing that tells if the password is right or not).
It has been shown you can actually not prove the original P vs NP by using Oracles (this technique is called relativisation).
In order to prove the original problem you have to define the Oracle in terms of a turing machine. In other words, you have to describe what the password verifier does with the input, and then prove that there is no algorithm that can guess the password given the password verifier code.
Note that you have to do this for any possible fast password verifier. The only requirement of the password verifier algorithm is that it runs in polinomial time with regards to the password length.
So given any possible algorithm that checks if the password is right or not in polinomial time, you have to write an algorithm that reads the verifier algorithm and tries to guess the password is in polinomial time. If you can prove or disprove that such algorithm exists then you have solved the problem.
Related
I'm running a glmer model with a three-way interaction, which causes me to receive the following warning:
Warning:
In optwrap(optimizer, devfun, start, rho$lower, control = control, :
convergence code 1 from nlminbwrap
The warning is not there when the 3-way interaction is omitted, so I suspect it has to do with model complexity.
Unfortunately, there is no further information about the nature of the convergence issue in the warning (and also not in the model summary), which makes it hard to resolve. [I've tried different optimizers and increasing the nr of function evaluations already].
Is there any way of finding out what precisely convergence code 1 means? Also, I'm wondering whether it is as serious as when it says Model failed to converge? I've been looking for an answer in the R help pages and in the GLMM FAQs, but can't seem to find any. Any help is much appreciated!
Okay, so I've done some reading here with the hope of being able to help out a fellow linguist. Let's start with the model you specified in the comments:
model=glmer(Correct_or_incorrect~ (condition|CASE) + condition + sound + syll + condition:sound + condition:syll + syll:sound + condition:sound:syll, dataMelt, control=glmerControl(optimizer="nlminbwrap"), family = binomial)
The warning message code didn't say anything useful, but convergence code 1 from bobyqa at the very least used to be about exceeding the maximum number of function evaluations. How high did you try and go with the iterations? All you're going to lose is a few hours, so I would try and set it really high and see if the warning message goes away. All you'd be losing is computer time, and I personally think that's a small price to pay for a model that doesn't throw warnings.
You also mentioned that the warning was not there when the 3-way interaction is omitted, and I would be inclined to think that you are right concerning model complexity. If you don't have any specific hypotheses about that interaction I would leave it out and be done, but if you do, I think there are a few options that you haven't mentioned that you have tried yet.
There is a function called allFit() that will fit the model with all available optimizers. This would be a quick and easy way to see if your estimates are roughly the same among all the different optimizers. You run it on an already fitted model, like this:
allFit(model)
There is a good walkthough of using allFit() and it's different arguments here:https://joshua-nugent.github.io/allFit/ This page also has a lot of other potential solutions to your problem.
If you can, I would take advantage of a machine with multiple cores and run allFit with as many iterations as you can swing, and see if any of the optimizers don't give this warning, which is presumably about not minimizing the loss function before the iterations run out.
Is there a way to ensure that:
if a==b then devfun(a)==devfun(b);
where devfun() is a device function involves some floating point maths ops (e.g. polynomials) and returns floating point results, a and b are floating point variables.
I don't care about cross-implentation consistence (e.g. different compiler/different OS/different driver versions or different compiler options), I only care about, within the same building/program, at runtime, can it ensure that during each function call, the result returned by devfun() are consistent in a way such that as long as a==b, devfun(a)==devfun(b)?
I am talking about SM2.0+ hardware and CUDA 5.0+, just in case being relevant.
Let's assume that your numbers a and b represent properly normalized IEEE-754 representation floating point numbers and that niether a nor b is a NaN value. Let's also assume a and b are both 32-bit, or else a and b are both 64-bit (IEEE-754 floating point representations).
In that case, I believe the (ISO C/C++, or CUDA C/C++) floating point test for equality (==) will return TRUE when the two numbers a and b are bitwise identical (and FALSE otherwise).
Under the TRUE case, with one exception, I believe it is safe to assume that devfun(a) == devfun(b) without any additional conditions except the obvious ones: there is no difference in the behavior of devfun on either side of the == operation, that is, it's the same code, compiled in the same way, executed under the same conditions (e.g. other variables that may be taking part in devfun, same GPU type, etc.), just as you've indicated in your question: "same building/program".
The one exception is if the result of devfun(a) is NaN, since (IEEE-754) NaN != NaN.
It would be interesting (to me) if you think you have a piece of code that disproves this assertion.
Perhaps floating point ninjas will come along and correct me.
Perhaps also I would be remiss if I did not say something about the hazards of floating point comparisons. If you're not familiar with this (most folks would never recommend performing a test a==b on two floating point numbers) you can find many questions about it on SO.
For the same reasons that floating point equality comparison (==) in general is unwise, I think relying on the above assertion, even if it's true, is unwise. Let me give you one example.
Suppose you compile code for architecture sm_20. Now you run the code on an sm_21 device. This one simple variation could result in a JIT-compile at runtime. Now you are no longer running the same code, and all bets are off.
So, again, even if the above is true, I think it's unwise for you to rely on such a statement:
if a==b, then devfun(a) == devfun(b)
Is it possible to construct a turing-complete language in which every string is a correct program?
Any examples? Even better, any real-world examples?
Precisions: by "correct" I mean "compiles", although "runs without error" and "runs without error, and finishes in finite time" would be interesting questions too :)
By string I mean any sequence of bytes, although a restriction to a set of characters will do.
Yes (assuming by correct you mean compiles, not does something useful). Take brainfuck and map multiple letters to the eight commands.
Edit... oh and redefine an unmatched [ or ] to print "meh. nitpickers" to the screen.
One PhD please ;)
This is a compiler for a C-like language expressed in BNF as
<program> ::= <character> | <character> <program>
#!/bin/bash
# full_language.sh
gcc "$1"
if [ $? != 0 ]
then
echo -e "#!/bin/bash\necho 'hi'" > a.out
chmod +x a.out
fi
We can build this up out of any turing-complete language. Take C, for example. If input is a correct C program, than do what it intended to. Otherwise, print "Hello, world!". Or just do nothing.
That makes a turing-complete language where every string is a correct program.
Existence proof: perl.
No, because your definition of 'correct' would leave no room for 'incorrect' since 'correct' would include all computable numbers and non-halting programs. To answer in the affirmative would make the question meaningless as 'correct' loses it's definition.
Combinatory logic is very near to the requirement You pose. Every string (over the {K, S, #} alphabet) can be extended to a program. Thus, althogh Your requirement is not entirely fulfilled, but its straighforward weakening to prefix property is satisfied by combinatory logic.
Although these programs are syntactically correct, but they do not necessarily halt. That is not necessarily a problem: combinatory logic has originally been developed for investigating theoretical questions, not for a practical programming language (although can be used as such). Are non-halting combinatory logic "programs# interesting? Do they have at least a theoretical relevance? Of course some of them do! For example, Omega is a non-halting combinatory logic term, but it is subject of articles, book chapters, it has theroetical interestingness, thus we can say, it is meaningful.
Summary: if we regard combinatory logic over alphabet {K, S, #}, the we can say, every possible strings over this alphabet can be extended (as a prefix) to a syntactically correct combinatory logic program. Some of these won't halt, but even those who don't halt can be theoretically interesting, thus "meaningful" (e.g. Omega).
The answer TokenMacGuy provided is better than mine, becasue it approaches the poblem from a broader view, and also because Jot is inspired combinatory logic, thus TokenMacGuy's answer supercedes mine.
If by "correct" you mean syntactically, then certainly, yes.
http://en.wikipedia.org/wiki/One_instruction_set_computer
http://en.wikipedia.org/wiki/Whitespace_(programming_language)
etc
Turing-complete and "finishes in finite time" are not possible.
Excerpt from wikipedia: http://en.wikipedia.org/wiki/Turing_completeness
"One important result from computability theory is that it is impossible in general to determine whether a program written in a Turing-complete language will continue executing forever or will stop within a finite period of time (see halting problem)."
What you are describing is essentially similar to a mapping from Godel number to original program. Briefly, the idea is that every program should be reducible to a unique integer, and you could use that to draw conclusions about the program, such as with some sort of oracle. One such mapping is the Jot language, which has only two operators, 1 and 0, and the first operator must be a 1.
Is there an upper limit to the number of bugs contained in a given program? If the number of instructions are known, could one say the program cannot contain more than 'n' bugs? For example, how many bugs could the following function contain?
double calcInterest(double amount) {
return -O.07 / amount;
}
A parser would count four terms in the function, and I could count these errors:
wrong number syntax
wrong interest rate (business requirements error)
wrong calculation (should be multiply)
Potential divide by zero
Clearly the number of bugs is not infinite given a finite number of instructions. Alternatively, one could say the function accepts 2^64 inputs, and of those, how many produce the correct output. However, is there any way to formally prove an upper limit?
If bug is "a requirement not met by the program", then there is no limit on the number of bugs (per line or otherwise), since there is no limit on the number of requirements.
print "hello world"
Might contain a million bugs. It doesn't create a pink elephant. I leave it to the reader to come up with 999999 other requirements not satisfied by this program.
Number of instructions have nothing to do with whether the program does what the user wants it to do. I mean, look at how poorly GCC does balancing my check book. Buggy as all get out, down right useless!
This would all depend on how you define a 'bug'.
If you define a program as a function from some input to some output, and a specification as a definition of that function, and a bug as any difference in output from the specification on a given input, then yes, you can conceivably have countably infinite bugs - however this is a somewhat useless definition of a bug.
The upper limit is the number of states your program can be in. Since this number is finite on real machines you could number the states from 1 to n. For each state you could label if this state is a bug or not. So yes, but even a small program having 16 bytes of memory has 2^128 states and the problem of analyzing all the different states is intractable.
There is a theoretical upper limit for bugs, but for all but the most trivial programs it is very nearly impossible to calculate, although engines such as Pex do give it the old college try.
Law of programming:
"If You will find all compile-time bugs, then n logical ones are still hidden, waiting to surprise You at run-time."
Depends on how you count bugs, which leads me to say "nope, no limit." I don't know about you, but I can easily write several bugs in the same line of code. For instance, how many bugs are in this Java code? :-P
public int addTwoNumbers(int x, String y)
{{
z == x + y;
return y;
}
As little as one if the bug is significant enough.
It goes without saying that using hard-coded, hex literal pointers is a disaster:
int *i = 0xDEADBEEF;
// god knows if that location is available
However, what exactly is the danger in using hex literals as variable values?
int i = 0xDEADBEEF;
// what can go wrong?
If these values are indeed "dangerous" due to their use in various debugging scenarios, then this means that even if I do not use these literals, any program that during runtime happens to stumble upon one of these values might crash.
Anyone care to explain the real dangers of using hex literals?
Edit: just to clarify, I am not referring to the general use of constants in source code. I am specifically talking about debug-scenario issues that might come up to the use of hex values, with the specific example of 0xDEADBEEF.
There's no more danger in using a hex literal than any other kind of literal.
If your debugging session ends up executing data as code without you intending it to, you're in a world of pain anyway.
Of course, there's the normal "magic value" vs "well-named constant" code smell/cleanliness issue, but that's not really the sort of danger I think you're talking about.
With few exceptions, nothing is "constant".
We prefer to call them "slow variables" -- their value changes so slowly that we don't mind recompiling to change them.
However, we don't want to have many instances of 0x07 all through an application or a test script, where each instance has a different meaning.
We want to put a label on each constant that makes it totally unambiguous what it means.
if( x == 7 )
What does "7" mean in the above statement? Is it the same thing as
d = y / 7;
Is that the same meaning of "7"?
Test Cases are a slightly different problem. We don't need extensive, careful management of each instance of a numeric literal. Instead, we need documentation.
We can -- to an extent -- explain where "7" comes from by including a tiny bit of a hint in the code.
assertEquals( 7, someFunction(3,4), "Expected 7, see paragraph 7 of use case 7" );
A "constant" should be stated -- and named -- exactly once.
A "result" in a unit test isn't the same thing as a constant, and requires a little care in explaining where it came from.
A hex literal is no different than a decimal literal like 1. Any special significance of a value is due to the context of a particular program.
I believe the concern raised in the IP address formatting question earlier today was not related to the use of hex literals in general, but the specific use of 0xDEADBEEF. At least, that's the way I read it.
There is a concern with using 0xDEADBEEF in particular, though in my opinion it is a small one. The problem is that many debuggers and runtime systems have already co-opted this particular value as a marker value to indicate unallocated heap, bad pointers on the stack, etc.
I don't recall off the top of my head just which debugging and runtime systems use this particular value, but I have seen it used this way several times over the years. If you are debugging in one of these environments, the existence of the 0xDEADBEEF constant in your code will be indistinguishable from the values in unallocated RAM or whatever, so at best you will not have as useful RAM dumps, and at worst you will get warnings from the debugger.
Anyhow, that's what I think the original commenter meant when he told you it was bad for "use in various debugging scenarios."
There's no reason why you shouldn't assign 0xdeadbeef to a variable.
But woe betide the programmer who tries to assign decimal 3735928559, or octal 33653337357, or worst of all: binary 11011110101011011011111011101111.
Big Endian or Little Endian?
One danger is when constants are assigned to an array or structure with different sized members; the endian-ness of the compiler or machine (including JVM vs CLR) will affect the ordering of the bytes.
This issue is true of non-constant values, too, of course.
Here's an, admittedly contrived, example. What is the value of buffer[0] after the last line?
const int TEST[] = { 0x01BADA55, 0xDEADBEEF };
char buffer[BUFSZ];
memcpy( buffer, (void*)TEST, sizeof(TEST));
I don't see any problem with using it as a value. Its just a number after all.
There's no danger in using a hard-coded hex value for a pointer (like your first example) in the right context. In particular, when doing very low-level hardware development, this is the way you access memory-mapped registers. (Though it's best to give them names with a #define, for example.) But at the application level you shouldn't ever need to do an assignment like that.
I use CAFEBABE
I haven't seen it used by any debuggers before.
int *i = 0xDEADBEEF;
// god knows if that location is available
int i = 0xDEADBEEF;
// what can go wrong?
The danger that I see is the same in both cases: you've created a flag value that has no immediate context. There's nothing about i in either case that will let me know 100, 1000 or 10000 lines that there is a potentially critical flag value associated with it. What you've planted is a landmine bug that, if I don't remember to check for it in every possible use, I could be faced with a terrible debugging problem. Every use of i will now have to look like this:
if (i != 0xDEADBEEF) { // Curse the original designer to oblivion
// Actual useful work goes here
}
Repeat the above for all of the 7000 instances where you need to use i in your code.
Now, why is the above worse than this?
if (isIProperlyInitialized()) { // Which could just be a boolean
// Actual useful work goes here
}
At a minimum, I can spot several critical issues:
Spelling: I'm a terrible typist. How easily will you spot 0xDAEDBEEF in a code review? Or 0xDEADBEFF? On the other hand, I know that my compile will barf immediately on isIProperlyInitialised() (insert the obligatory s vs. z debate here).
Exposure of meaning. Rather than trying to hide your flags in the code, you've intentionally created a method that the rest of the code can see.
Opportunities for coupling. It's entirely possible that a pointer or reference is connected to a loosely defined cache. An initialization check could be overloaded to check first if the value is in cache, then to try to bring it back into cache and, if all that fails, return false.
In short, it's just as easy to write the code you really need as it is to create a mysterious magic value. The code-maintainer of the future (who quite likely will be you) will thank you.