As the title says, I am really really really curious about this.
I've been trying to find the cases where you can't use backtracking to solve them but I can't find them.
Share your knowledge please
If there are too many possibilities to check, backtracking search will be impractical - see e.g. http://en.wikipedia.org/wiki/Lighthill_report. There may also be cases where you cannot state the problem simply and clearly enough to recognize the correct answer when you find it.
Related
I have to apply the SMA* algorithm for the labyrinth problem in Python. I found just this PDF: pdfSMA, but it didn't help me too much.
I tried to resolve it, but I didn't manage. Any implementation for this algorithm in Python would help me.
The original description of SMA* from the original AIMA book is flawed. If you implement it as described it may not work. The issue is that you need to preserve the ordering of children and be sure to explore unexplored children before re-exploring old children.
Felner introduced the idea of collapse and restore macros which can be very helpful in understanding SMA*. I suggest looking at that paper and then using a similar approach to implement the algorithm.
But, also know that the recent A*+IDA* algorithm may be a better approach than SMA*. (Not much help if it is an assignment.)
I was wondering when some one asks you to solve an algorithmic problem, is it a good way to actually start off with Hastable, Hashset or HashMap. Normally i have heard people saying you shouldn't come up with Hashes as your first answer.
So how should we go about in algorithms: In-place should be given importance or make sure time complexity is best
I'm not trying to generalise, but still some suggestions would be helpful.
Thanks
The best you can hope for is a generalized answer for your generalized question.
It depends.
The reason there are many different algorithms is because there is not always 1 algorithm that is the best. And many algorithms aim to solve different problems from each other. Some algorithms it makes no sense to even talk about hash tables.
If someone asks me to solve an algorithmic problem though, I will probably try to use something that is built in to the language I'm using before designing my own algorithm. The reason is because I value my time. If I find later that the code is not efficient enough, then I can look for a better way to do it.
I think it is really situational. If random access is a priority and you need fast access and little constraint on memory utilization and no sequential access, then Hashtable, (et al), is the choice.
Can someone explain me how the text searching algorithm works? I understand its a huge field but am trying to understand it from high level so that I can look up academic papers on it.
For example, Spelling mistakes is one problem that is tough to solve and of course Google solves it. When I search for a term and misspell it on Google, it automatically suggests the correct spelling. How is indexing done for it? Using MapReduce I can see they index various entities. What do they or some one else index and store? May be I am looking for a practical implementation of MapReduce if I am thinking in the right direction at all.
Pav
I'm afraid this question really is too big, which probably explains why it has not seen an answer yet. As far as Google's spell-checker is concerned, Peter Norvig explains how it is done: How to Write a Spelling Corrector
The exact implementation in productive use at Google surely looks quite a bit different and way more complicated, but this might get you started.
In another question, I asked something similar but I ended up just posting my algorithm there and invalidating several answers. I re-ask it here:
If I "invented" an algorithm, what's the best way for me to figure out if it's already been published about/patented?
You would need to do some searching. Starting with Google search, generically, will often be sufficient to reassure you that your algorithm is not novel. If that is not conclusive, then you need to search harder, perhaps looking at searching various patent sites (Google, USPTO, other places too). If you still don't find anything, then maybe your algorithm is novel.
Next questions: is it worth it to you to try and patent it, or get someone else to patent it for you (a company, for example)? Indeed, can you patent it or does your employer already own it? This will depend in part on how likely it is that everyone else will want to use the same algorithm. The chances are, they won't. If you patent it, they will ignore it until the patent expires.
If you do find a way to afford getting the patent filed - and issued (which is not automatic just because you filed) - then you face enforcing your patent. Will you be able to identify and prosecute those who abuse your patent? If not, was it worth chasing it? Maybe, maybe not; but probably not.
Finally, note that you cannot actually patent a pure algorithm. You would have to reduce it to practice. That isn't as hard as it seems, but just be aware that pure mathematical algorithms are inherently non-patentable.
In summary:
You will probably find someone else already thought of it.
If you decide to patent it because it is novel, you need money.
You need money to file for the patent.
You need money to pursue those who abuse your patent.
You would probably be better off just publishing it.
Most often you basically just have to do back ground research in the given area. This is why when academics do research projects they start of by learning about the history (back ground) of the area all the way up to the current methods or theories being used. It also helps to ask someone who knows the area and has worked in it for many years.
Well, if it's in a textbook like your algorithm seems to have been (Dijkstra), then it definitely already exists in the public domain and cannot be patented. How you use the algorithm in your application as a whole might be, but most abstract ideas or implementations thereof (such as "finding the shortest path between two nodes") cannot be patented.
Or, you could waste a bunch of money and submit a patent and see what happens :)
In all seriousness though, you might start by searching for existing patents, or read up on some articles like this one to get a better feel for the patent process.
Tracking down every algorithm for a particular problem would be quite daunting. A better process might be to track down the best solutions known for the problem and compare them with yours.
I would start with Wikipedia. I know people say "don't use wiki for research", but it's pretty good at computer science (all those geeks contributing), and it will tell you pretty quickly what the best widely-known algorithms are. If you've got something strictly better than the algorithms you can find in Wikipedia, then it might be worth looking further. If Wikipedia's got something strictly better than your algorithm, then you've invented a curiosity at best and probably won't get rich or famous from it.
Next, check the references at the bottom; they may lead you to papers (which will have more references that you can follow), or to academics' websites (which might have links). Also go to Citeseer and search for key words.
Unfortunately, there's no real replacement for having some basic knowledge. If you've invented (for instance) a graph-theoretic algorithm, but you don't know the language of graph-theory, then you'll struggle to find it because you won't know where to start looking. You might profitably spend your time reading an algorithms textbook -- that will give you an overview of good algorithms and how to speak about them.
If an algorithm or method can not be found right away (wikipedia/google), i find it rewarding to scan academic/engineering websites (web of science, ieee explore, acm etc.) for 'review' papers. If recent, they can give a solid overview over the field (e.g. graph search) mentioning books, papers and conferences. After that one can focus the search on particular methods.
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 a beginner C++ programmer, and to stretch my mind I've been trying some of the problems on projecteuler.net. Despite an interest in maths at school, I've found myself automatically going for brute force solutions to the problems, rather than looking for something streamlined or elegant.
Does this sound like a bad mindset to have? I feel a bit guilty doing it like this, but maybe quick and dirty is OK some of the time...
I think you should look at what your end goal is and what your constraints are.
Sometimes a bruteforce method can solve a problem in 50ms trying out every combination of solutions and a "clever" solution can solve it in 10ms. At that point, the less clever but easier to understand solution trumps the clever solution.
However, there are some problems where brute forcing will not only be inelegant but simply won't work. There are many problems where if you attempt to naively brute force them it will take a significant amount of time to solve them. So obviously, these types of problems need a more elegant approach.
So ask yourself, why you are attempting these Project Euler problems? Are you doing it to learn? Then maybe trying a clever solution would be in your best interest but only after you have initially tried a brute force solution to help get a grasp of the problem.
When doing the Python Challenge problems I try to do it the most succinct way I can, pushing the limits of my abilities. After I solve it I then review other peoples answers and take mental notes of people who were more clever than myself and what they did. Some people will make special use of a data structure I hadn't thought of that is more suited to the task or they will have little mathematical tricks they use to make their algorithm more efficient. In the end I try to absorb as much of their cleverness as I can and make it show the next time I'm presented with a problem of a similar nature.
As a beginner programmer, you will be spending more of your mental energy figuring out how to actually implement things in C++, rather than spending energy on finding a clever solution to each problem. This is fine, because it gives you the opportunity to explore different areas of C++ while working on a range of various kinds of problems.
When you become proficient in C++ and you don't have to think about how to do every little thing, then you will be able to spend more time inventing non-brute-force solutions.
No, this isn't a bad thing. I've had solutions that were so elegant they were wrong.
The elegant solutions weren't created spontaneously; they were derived from the brute-force solutions when more speed or less memory consumption were required from the current solution.
So no, it's not. It's how the elegant solutions came into being.
Ken Thompson: "When in doubt, use brute force"
I've sort of gone through this evolution:
Get it to compile
Make it work as expected
Figure out one solution that works
Figure out one good solution
Figure out multiple solutions, and find the best
Figure out multiple solutions, and find the best for this situation
?? haven't gotten there yet
I would say that no, it's not a bad sign. In fact you're doing yourself a favor by trending away from premature optimizations, which is definitely a Good Thing.
learning is a brute force process. I wouldn't say its bad. In trying to do something that way you may notice a pattern. I think as long as you are thinking about something and trying to find solutions you will learn. There are few people who just jump to the most elegant or efficient solutions.
It would be hard to convince me that people that are trying to learn could ever be called bad. Except maybe an evil scientist :P
good luck.
Do you fit inside the 1 minute runtime rule for the problems? If yes, then your "brute force" solution fulfils all the requirements, and that's actually a very good sign that you can quickly come up with something that works!
These kinds of problems encourage micro-optimisation and very clever algorithms, but in general a very readable straightforward implementation will be much easier to maintain, and will be favoured in the business world.
If it happens to be a situation where "brute force" => "simple" and "elegant" => "complex", then brute force wins. And this is very often true.
Not at all. Get the problem solved correctly and completely then make it more performant or elegant as necessary.
That's not to say you should ignore obvious performance improvements... Just don't focus on them until you understand the problem better.
To put this in a different context:
When you use a library that you don't know very well (for creating UI, for instance) you can solve a simple problem in a perfectly performant way, though you know there's a "correct way" to do it. If you are curious and worried that your brute-force code makes you look like a moron, you will soon find the "correct way" to do it (e.g., on weekends, or while you sleep). In the meantime, through brute force, you will have something that works.
I actually forget to use brute force sometimes, and start scanning the API for the "right" solution. This is definitely an error in many cases. If the brute force solution is easy to implement, scales as you need it to (really, if it works), then forget about the correct solution. You'll find it soon enough (and many times you already knew it!), but in the meantime, you solved the problem and were able to go on to the next one.
Roadblocks are terrible when coding, and should definitely be avoided more than brute force solutions.
It's definitely not a bad sign to trend to brute force, especially as a beginner because you may not know any better. Especially with Project Euler, it is a bad sign to implement a brute force method and not review the comments to learn a more efficient method.
I often end up in the same boat you're in and that's actually why I started doing P.E. problems -- I was implementing a lot of brute force approaches and wanted to expose myself to more elegant solutions...
You have weigh your option. If the brute force solution will get the job done and perform ok, it is a good solution.