It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
It is my intention to reinvent the wheel. I learn many things by example. That's important information you should consider when answering.
This isn't homework, it's purely a side project.
Now, I've heard of modulus math. I'm trying to use it to make an uncrackable (by today's technology standards).
I have more than one question:
How can you make encryption harder to crack (asymmetric)
Random Numbers or Patterns (Like, there's a set standard, not random), why or why not.
Is this formula vulnerable:
a = (unknown prime)
b = (unknown prime)
c = (unknown prime)
d = (a ^ b) mod c
Can you get a, b, and c if d = 9? Don't brute force it but actually make a formula to reverse it. If you can do so, post it.
Is this a good way to make a key, seed, or something of that nature? Why or why not?
By all means, answer what you understand, the best answer gets marked as so, and fairly!
Also, if you can, give me references to cryptology texts (Free).
This is a broad question. As templatetypedef has mentioned, you shouldn't be designing any cryptography-related algorithm you plan to use in the real world, so you may want to forget about "trying to use it to make an uncrackable [cipher]" and leave that to the experts.
Answering your questions:
1- The general understanding is that if you want to make a message harder to "crack", you increase the key size. There's no point in developing a entirely new (and most certainly weak) cipher when there are tried and true algorithms for that.
2- It's difficult to tell what's being asked here, but I'll assume you're referring to the randomness of a given ciphertext. The general understanding is that any kind of pattern (non-randomness) of the ciphertext is a very bad sign. Ciphertext should be indistinguishable from pure random data, and there are several batteries of tests to check that (see ENT, Diehard and many others)
3- The formula you give is close to the one used in RSA, although a,b,c are not the primes directly. Also, it's not clear which one of your variables is the plaintext (hint: a cipher that can only encrypt prime numbers is not particularly useful). AFAICT, as you state, it's also not reversible (which is not a good thing at all, unless you don't plan on decrypting the messages ever...)
As a final note, you're looking for a cryptography reference, not a cryptology one. Many people associate cryptology with classic (and easy to break) ciphers, like Caesar's.
Bruce Schneier's Applied Cryptography is a standard textbook on the subject. It's not free, but you can always try university libraries.
Related
I am currently a freshmen in college doing some self-studying about the different sorting algorithms.
My studying source does provide the codes and I did some practice on it (coding the sorting base on the concept it). At the moment, I can provide selection sort with just a little bit of trouble (coding that is).
Am I required to memorize the codes? I know the difference between the sorts and the concept behind it. Do I need to memorize the Pseudocodes behind it as well? Will interviewers ever ask you to produce the codes on the spot?
There is no need to memorize the exact code syntax , but it would be important to understand the logic behind the sorting algorithms (ie. be able to explain using pseduocode).
I've been asked in interview how to do some basic sorting algorithms like a bubble sort, but nothing very complex. I was not required to write the exact "code" in any particular language, but just prove that i know the logic and can explain how it works.
Hello and welcome on Stack Overflow. I'm answering your post below, even though it will be closed as too broad or primarly opinion-based, because this QA site is oriented towards coding questions. You might want to ask this on another QA site, like programmers stackexchange.
Do I need to memorize the Pseudocodes behind it as well?
not really, as in every decent language you'll have a standard library that offers you state of the art implementations, and what you really need to remember is the complexity and mechanism of each sort algorithm, to choose the best fit for your dataset, when you need it.
And otherwise, when you really need to dig again in the pseudocodes, there are books (like the Art of Computer Programming by Donald Knuth), and wikipedia, and many other resources online.
Will interviewers ever ask you to produce the codes on the spot?
Yes they will. It happened to me at least five times. But most of the time, they'll understand that you might not remember the full pseudocode on the spot, but they expect you to know the mechanism and complexity, and be able to reinvent the algorithm on the spot.
Though, when you do interviews, you're usually compared to other people passing the same interview, and between two candidates that passes, they'll choose the one that did the best on the tests… And then you might loose a job opportunity because someone else remembered better those algorithms.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have to divide 1 by a number X of more than 4000 digits that I have stored in a string and obviously this is going to return a floating point number. I'm looking for algorithms to perform this division efficiently but I could not find anything that convinces me.
As a side note, I would like to implement the algorithm on my own without using a third-party library.
Anyone have any idea?
Thanks!
EDIT:
The reason why I do not want to use a third-party library it's that I want to do this operation using openCL but without losing too much accuracy in the process. Therefore using one of those libraries is actually not possible in this case.
You are describing a special case of division, known as inverting a number. Here's a paper which gives a description of Picarte's Iteration method of inverting a large integer: http://www.dcc.uchile.cl/~cgutierr/ftp/picarte.pdf
You should take a look at the GNU Multiple Precision Arithmetic Library, it has no limits to the size of the numbers handled, and will obviously have insanely well optimized number crunching algorithms.
As for implementing it yourself, if it's not for educational purposes, I'd say don't fall prey to the NIH syndrome! And a Web search on binary arithmetic should provide a wealth of documents to start with…
You should use the System.Numerics.BigInteger structure, it allows you to make a lot of calculations however it's only available in the .NET 4.0
If your number X is an integer you may well not be able to do what you want. float and double are pretty much out; you'll have to use a long double. On some platforms a long double is just a double.
If you don't want to use a third-party bignum package (why?), you will have to implement the division algorithm on your own (and that is pretty much going to require you to develop a good chunk of a bignum package).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
When we start getting into algorithm design and more discrete computer science topics, we end up having to prove things all of the time. Every time I've seen somebody ask how to become really good at proofs, the common (and possibly lazy) answer is "practice".
Practicing is all fine if you have the basics down, but how do you get into the mind set for mathematical proofs? When did induction click? What resources are best for teaching these topics? What foundation topics should be researched prior to indulging in proof-writing?
They aren't being lazy, practice is the only way. Take classes you have to do proofs in and look online for class notes and old tests with answers from other colleges that go over proofs.
I'll start off my answer by admitting that as a CS student, I had a really tough time grasping a formal way of thinking, and it's never easy, unless you have a talent for it.
I'm afraid there is no better answer than practice and study.
A formal mathematical and algorithmic way of thinking and visioning problems is a skill which first demands a very deep understanding of the subjects you are dealing with. Second, it requires you have good knowledge of existing proofs. Try to envision yourself as some of the great scientists who came up with the algorithms you are studying. Understand how you would have tried to tackle that specific problem. Then see how they proved the correctness of their algorithm.
I can only recommend the greatest textbook in this subject which is Intro to Algorithms by CLRS. If you go through it from start to finish, including every exercise, you will enhance your skills.
Practice is really the only way, but it can helped along by reading proofs as well. I won't touch on practice because the other answerers have covered everything that I can think of, so I'll just talk about what I mean by reading.
Textbooks are very fond of writing out the "important" proofs. Its very nice, because they often prove very powerful statements, and are really fancy. But just as you shouldn't learn to be a world-class gymnast from day 1 by emulating an Olympian (as in, you'll probably break your spine), you shouldn't read any really big proofs (at first). What I found was helpful was reading smaller proofs, usually from returned homework (I assume you're a student) or occasionally a textbook that wisens up.
The reason why I think reading proofs is helpful is because there are a small set of "tricks" or "ideas" that constitute huge chunks of schoolwork proofs, and even more advanced ones. Data structure qualities and recurrence relations usually involve thinking related to proof by induction, proofs involving computability with finite state machines sometimes use the pigeonhole principle, and more rarely the idea of diagonalization (very infrequent, don't worry about it). And of course, just about every other proof uses proof by contradiction. I'm sure there are other handy tools that have slipped my mind, but I hope you get the idea.
Figuring out when, how, and why you'd approach a problem with one particular method or another is what takes practice and experience. I suggest reading proofs in addition to practice because it can often show you creative ways of using a proving method you've already encountered.
As a final note, try to remember when you first learned to program. How did you get better? Proving things and programming things are not too dissimilar, in my opinion. :)
You get into the mind set for doing mathematical proofs by becoming a mathematician. I don't mean the last statement in a tautological way, but realize that a mathematical proof, as published in a mathematical journal, is something of a rhetorical artifact; i.e., it is a proof because a body of mathematicians agree that it is a proof. Ideally, the arguments in the proof could all be reduced to symbolic logic, but this is not how it is done in practice. The utter failure of computer-generated proofs to do valuable mathematics provides some evidence for this.
I get into the mind set by doing proofs and having them accepted by other mathematicians. I agree with the others that "practice" is essential. You don't do proofs unless you try, try, and try. Often the light dawns slowly.
The best resources are, of course, other mathematicians, and reading proofs. There are very few, if any, who can do true mathematical proofs without being part of the mathematical community.
I'm afraid that "practice" really is the best answer here.
Its very similar to programming: once you get the hang of it, you find patterns which solve problems particularly well, and you can create a picture of the high-level design of novel systems which you've never implemented before. However, neophyte programmers aren't aware of patterns: they hack away at code until they accidentally stumble on some solution which appears to "work".
When you're given a problem to prove, you can usually identify properties ("Do I have a set of distinct objects?", "Am I generating permutations?", "Am I looking to minimize/maximize some value?", etc). Sooner or later, proofs will clump together into vaguely similar group, where techniques used to solve one problem can easily apply to novel variations.
Recommended reading:
The Algorithm Design Manual by Steven Skiena.
I have no idea. Probably the same way you get good at composing music.
When I try to prove something I'm not following some fixed strategy, I just think about the problem. Then [undefined amount of time] later, my mind returns a result and I jump up to write it down.
But practicing definitely helps. When I started trying to prove extremely simple statements, like DeMorgan's laws, I was completely hopeless. So I sat down and did the fifty or so optional example problems on a worksheet we were given. Now it feels natural to prove something.
Practice and study makes perfect sense, agreed. Some tricks, that I found useful:
Make notes on everything you study (I've tried just to read books -- a lot of material just passes through).
In addition to previous point: do all (or most) proofs by youself, use book/lecture notes as a guide; a lot of proofs contains phrases like "we can see now, that XXX". And XXX is not always trivial conclusion.
Make exercises; for example, in CLRS book there are dozens of exercises. Exercises are good way to get the ideas behind algorithms/correct proofs.
If you want to better understand the internals of algorithm -- consider participating in online programming contests like UVa's.
Are there any broad, overgeneralized and mostly useless rules about how long it will take to understand a program based on the number of LOC (lines of code)?
(I understand any rules will be broad, overgeneralized and mostly useless. That's fine.)
(The language in question is Delphi, but that shouldn't matter because I'm looking for broad, overgeneralized and mostly useless rules.)
It's not the number of LOC that determines how long it takes to understand a program, it's more the complexity.
If my program had 100,000 lines of print statements, I think the program is pretty clear to understand. However if I had a program with for-loops nested ten deep, I think that will take far longer to understand.
Cyclomatic complexity can give a ROUGH indication of how hard the code is to understand, and can signal some other warning flags as well about your code.
Some papers concerning peer code review say that it should be somewhere between 100 and 400 lines of code per hour.
I have the theory that it's O(n2) (because you have to understand each line in conjunction with every other line).
But, as usual when using big-o notation to get an actual numeric value, this answer is broad, overgeneralized and mostly useless.
Code review metrics (which is not the same thing, but nearly comparable) put the number in the range of approximately 50-100 LoC per hour, for an experienced code reviewer.
This of course also depends on what they're looking for in the review, language, complexity, familiarity, etc.... But that might give you a general overgeneralization anyway.
You cannot google this because there will be a different approximate number for each individual person programming in a specific language.
You are trying to write the Drake's Equation for program writing.
This is what I mean.
About program writers.
each person has a different style of writing and commenting code
every programming language has different nuances and readability
algorithms can be implemented in many ways even in the same language
data structures used by different people tend to be quite varied
the decision of how code is distributed over source files also changes with personal taste
Moving to the person reading the code.
the familiarity of the person with the language matters
familiarity to the algorithms and data structure patterns used matters
amount of information context that the person can retain at a time matters
Shifting focus to the environment, things that matter would be.
the amount of distraction (both for the programmer and the person trying to read the program)
nearness to code release time for the programmer
pending activities and motivation on the part of the reader
proximity of popular events (vacations, sports events, movie release dates!)
I'm looking for broad, overgeneralized and mostly useless rules.
Sounds to me like you're just trying to find a way to estimate time it will take to learn a new codebase to management or something. In that case, find a code snippet online, and time how long it takes you to understand it. Divide that by the number of lines in the snippet. Add some padding. Bam! There's your rule.
Look at the COCOMO equations. They contain broad, overgeneralized and mostly useless rules based on Source Lines of Code.
Apart from "how complicated is the program?", other variables include things like "how well do you understand it?" and "how well do you understand other things, such as the program's functional specification?"
When I start to work with a new program, I try to understand as little of it as possible! Specifically I try to:
Understand the functional specification of the change that someone wants me to make (if nobody wanted me to change the program then I wouldn't need to understand it at all)
Find and understand the smallest possible subset of the existing program, which will let me make that change without breaking any other, previous/existing functionality.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What are some simple algorithm or data structure related "white boarding" problems that you find effective during the candidate screening process?
I have some simple ones that I use to validate problem solving skills and that can be simply expressed but have some opportunity for the application of some heuristics.
One of the basics that I use for junior developers is:
Write a C# method that takes a string which contains a set of words (a sentence) and rotates those words X number of places to the right. When a word in the last position of the sentence is rotated it should show up at the front of the resulting string.
When a candidate answers this question I look to see that they available .NET data structures and methods (string.Join, string.Split, List, etc...) to solve the problem. I also look for them to identify special cases for optimization. Like the number of times that the words need to be rotated isn't really X it's X % number of words.
What are some of the white board problems that you use to interview a candidate and what are some of the things you look for in an answer (do not need to post the actual answer).
I enjoy the classic "what's the difference between a LinkedList and an ArrayList (or between a linked list and an array/vector) and why would you choose one or the other?"
The kind of answer I hope for is one that includes discussion of:
insertion performance
iteration performance
memory allocation/reallocation impact
impact of removing elements from the beginning/middle/end
how knowing (or not knowing) the maximum size of the list can affect the decision
Once when I was interviewing for Microsoft in college, the guy asked me how to detect a cycle in a linked list.
Having discussed in class the prior week the optimal solution to the problem, I started to tell him.
He told me, "No, no, everybody gives me that solution. Give me a different one."
I argued that my solution was optimal. He said, "I know it's optimal. Give me a sub-optimal one."
At the same time, it's a pretty good problem.
When interviewing recently, I was often asked to implement a data structure, usually LinkedList or HashMap. Both of these are easy enough to be doable in a short time, and difficult enough to eliminate the clueless.
This doesn't necessarily touch on OOP capabilities but in our last set of interviews we used a selection of buggy code from the Bug of the Month list. Watching the candidates find the bugs shows their analytical capabilities, shows the know how to interpret somebody elses code
Write a method that takes a string, and returns true if that string is a number.(anything with regex as the most effective answer for an interview)
Please write an abstract factory method, that doesn't contain a switch and returns types with the base type of "X". (Looking for patterns, looking for reflection, looking for them to not side step and use an if else if)
Please split the string "every;thing|;|else|;|in|;|he;re" by the token "|;|".(multi character tokens are not allowed at least in .net, so looking for creativity, the best solution is a total hack)
Graphs are tough, because most non-trivial graph problems tend to require a decent amount of actual code to implement, if more than a sketch of an algorithm is required. A lot of it tends to come down to whether or not the candidate knows the shortest path and graph traversal algorithms, is familiar with cycle types and detection, and whether they know the complexity bounds. I think a lot of questions about this stuff comes down to trivia more than on the spot creative thinking ability.
I think problems related to trees tend to cover most of the difficulties of graph questions, but without as much code complexity.
I like the Project Euler problem that asks to find the most expensive path down a tree (16/67); common ancestor is a good warm up, but a lot of people have seen it. Asking somebody to design a tree class, perform traversals, and then figure out from which traversals they could rebuild a tree also gives some insight into data structure and algorithm implementation. The Stern-Brocot programming challenge is also interesting and quick to develop on a board (http://online-judge.uva.es/p/v100/10077.html).
Follow up any question like this with: "How could you improve this code so the developer who maintains it can figure out how it works easily?"
Implement a function that, given a linked list that may be circular, swaps the first two elements, the third with the fourth, etc...
I like to go over a code the person actually wrote and have them explain it to me.
Asking them to write a recursive algorithm for a well known iterative solution (i.e. Fibonacci etc. -- we give them an iterative function, if needed) and then have them compute the run time for it.
Many times the recursive function involves a tree data structure. The number of times the person has failed to recognize that baffles me. It becomes slightly difficult to calculate the run time until you can see that it's a tree structure...
I find that this problem covers many areas. Namely, their code-reading ability (if they are given an iterative function), code-writing ability (since they write a recursive function), algorithm, data-structure (for run-time)...
A trivial one is to ask them to code up a breadth-first search of a tree from scratch. Yeah, if you know what you're doing it is trivial. But a lot of programmers don't know how to tackle it.
One that I find more useful still is as follows. I've given this in a number of languages, here is a Perl version. First I give them the following code sample:
# #a and #b are two arrays which are already populated.
my #int;
OUTER: for my $x (#a) {
for my $y (#b) {
if ($x eq $y) {
push #int, $x;
next OUTER;
}
}
}
Then I ask them the following questions. I ask them slowly, give people time to think, and am willing to give them nudges:
What is in #int when this code is done?
This code is put into production and there is a performance problem that is tracked back to this code. Explain the potential performance problem. (If they are struggling I'll ask how many comparisons it takes if #a and #b each have 100,000 elements. I am not looking for specific terminology, just a back of the envelope estimate.)
Without code, suggest to make this faster. (If they propose a direction that is easy to code, I'll ask them to code it. If they think of a solution that will result in #int being changed in any way (eg commonly order), I'll push to see whether they realize that they shouldn't code the fix before checking whether that matters.)
If they come up with a slightly (or very) wrong solution, the following silly data set will find most mistakes you run across:
#a = qw(
hello
world
hello
goodbye
earthlings
);
#b = qw(
earthlings
say
hello
earthlings
);
I'd guess that about 2/3 of candidates fail this question. I have yet to encounter a competent programmer who had trouble with it. I've found that people with good common sense and very little programming background do better on this than average programmers with a few years of experience.
I would suggest using these questions as filters. Don't hire someone because they can answer these. But if they can't answer these, then don't hire them.