I have taken up Prolog course in my university. The coursework requires us to write prolog programs. I am able to write simple programs, however I am finding it little hard to digest the complex programs. Any suggestions how to proceed or how do I study this subject ? what is the approach to tackle this kind of course. Any help appreciated.
Thanks.
I write an answer (which is probably just rant) because I struggle with the same problems. If a question gets closed I think the answer still stays?
what is the approach to tackle this kind of course.
Like all courses, you collect all material that your teacher/instructor/professor gives and find the books they recommend. You do the exercises as the way they expect. Do not be clever with your solutions, be clever with finding what your instructor wants to see! Try to find old exams and study them; esp. if you can find graded exams (if you are lucky and "resourceful"... ask older students for help!)
Any suggestions how to proceed or how do I study this subject ?
It is difficult to learn Prolog. I try to learn it at University and the teacher says one thing. Then I pick up a book ("Sterling and Shapiro") and it says another thing. Then I go online and I find yet another two very different things ("Amzi Amazing Adventure" and "Learn Prolog Now!"). There is also "Expert systems in Prolog" (from the Amzi website) and it is still another thing. I come to StackOverflow and I find yet other answers that are NOWHERE in all the texts I have tried to read.
The best place to learn for me is the SWI-Prolog predicate documentation: this is outrageous, don't you think? At least it is consistent....
And then many of the answers here on Stackoverflow I have tried to learn from are talking about things that make no sense (to me), probably because I don't know Prolog, but how to learn it? And almost all questions are homework, and almost all answers to homework are like little lectures that talk about ISO and logic and pureness but no clear answers.
In conclusion: "Sterling and Shapiro" was at least complete, and not too strange; and SWI-Prolog has good predicate documentation and even code examples.
EDIT: nowhere nowhere in all texts do you read about modules, but how do you write big programs without module system? Even the C++ book by Stroustrup explains how to use headers and source files to maintain a bigger program. Again, you go and read the chapter on modules in the SWI-Prolog documentation.
EDIT2: I study "Computer Science" so I maybe know "programming" and "data structures" and "algorithms" and I understand what is "proof tree" and "backtracking" and such things. Prolog is just another language. So why is it so difficult to teach it and learn it? This is an open question. I don't want to ask it on Stackoverflow because it will be closed.
EDIT3: Because you have tagged "clpfd", there is yet another text:
https://www.metalevel.at/prolog
It shows many solutions with clp(fd) that I did not see in any other of the texts I cited. It is useful and consistent but again it is different from all other texts. Maybe if I read and study everything I can find I can give you a real answer.
But do you want to pass the course or learn Prolog? Do you want a good grade and minimum effort? You need to find answers to such questions first!
This question sounds very vague and needs some explanation:
I learned about Binary Indexed Tree a few weeks ago. This data structure is a brilliant design. It actually took me very long to figure out how it's built thanks to this video (I mean... this is the first time I couldn't understand a written documentation and have to watch someone drawing a BIT step by step..)
Anyway, so (I think) I know how to build a BIT and the basic idea behind the structure design.. And now, I'm excited to practise some problems that can be easily solved with BIT.. In fact, someone has gathered a list of nice problems in this Quora post. I also tried some on HackerRank.
I spent long time trying and only managed to solve two (one by myself, the other taken from other's solution).. For instance, this direct connections problem..
I realise that the problem is never about how to build a BIT. The real challenge is to conceptualise the problem and use BIT to solve it... this is really beyond my imagination.. Is there a technique that I can use to tackle such problems?
And the interesting observation is.. for each problem set, the discussion below contains some comments like:
"BIT... :)"
It's like whoever managed to solve the problem always ended up with a proud smiley face without further explanation :(
Also, are there some classical problems that are solved by BIT?
EDIT
For those who voted to close this question: please give a valid reason. I believe this question is worth a discussion here!
I've been learning Prolog for the past two months. I want to increase my knowledge as soon as possible.
Am asking if someone can point me to where i can get Prolog exercises and practice them. I also welcome examination questions as well from universities.
Thanks for your help.
Unfortunately the previous Question mentioned by aschepler has been removed, with its links to Prolog beginner materials. A well-known tutorial is Dennis Merritt's Amzi! Adventure in Prolog. [Disclosure: I previously volunteered as a moderator on the Amzi! Prolog forums.]
For a systematic challenge you might look at Werner Hett's Prologsite 99 problem set:
This is a remake of the P-99: Ninety-Nine Prolog Problems collection that I assembled over several years of teaching at the University of Applied Sciences (Berner Fachhochschule) at Biel-Bienne, Switzerland. The collection is structured into seven sections. I have renumbered the problems in order to get more freedom to rearrange things within the sections.
It might be the ladder to rapidly increase your knowledge after a couple of months of introductory study.
This really helped me, just follow the examples and run them one by one.
Hope it helps.
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 7 years ago.
Improve this question
When I am stuck with a problem:
I search Google for code snippets.
I look at isolating the problem, so that I can better explain it to others in order to get answers.
What search techniques do you use to find the solution to your problem?
I started asking questions in Stack Overflow.
What other techniques or methods do you follow, to fix the problem more quickly?
Go and do something else. No, really. I've found that putting the problem away in the back of my mind helps. I can't count the number of times I thought of a great solution to something I've been working on when I was working on something else, or watching TV, or eating. It seems your brain is still working on the problem in the background.
If that fails to solve your problem, try talking to someone. You'd be surprised how often others can give solutions to your problem that are so simple you'd facepalm.
Well there's:
Google
Google
Google
Stack Overflow
Google
Google
Maybe a book if I have one.
Seriously, I started (hobby) programming in the 1980s and even into the mid 90s you had to know things and have a technical library. Then Google came along and it's easier to Google something than it is to look up (bookmarked!) API documentation (Google "java stringbuilder" will get me there faster than navigating will) let alone an actual book (electronic or paper).
Most problems you're trying to solve have been solved before. Many times.
The rest of debugging comes down to decomposition, possibly unit testing (which is related to decomposition) and verifying your assumptions.
By "decomposition", I mean that your solution is structured in such a way that small pieces can be individually tested and readily understood. If you have a 7000 line method you're (probably) doing something wrong.
Understanding what assumptions you've made is key too so you can verify them. For example, when I started with PHP I wrote a piece of code like this:
$fields = $_SESSION["fields"]; // $fields is an associative array
$fields["blah"] = "foo";
and I was scratching my head trying to figure out why it didn't work (the array wasn't being updated next time I queried $_SESSION). I came from a Java background where you might do this:
Map fields = (Map)httpSession.get("fields");
fields.put("blah", "foo");
and that would most definitely work. PHP however copies the array. A working solution is to use references:
$fields =& $_SESSION["fields"]; // $fields is an associative array
$fields["blah"] = "foo";
or simply:
$_SESSION["fields"]["blah"] = "foo";
The last thing I'll say about debugging and writing robust code in general is to understand the boundaries of your solution. By this I mean if you're implementing a linked list then the boundary conditions will revolve around when the list is empty.
Explain the problem to a colleague, or write it down to describe it. That will makes you think a different way, from a different perspective. In order to be more accurate, and to describe the context of the problem, you'll step back, get a higher level view of the problem, you may find out think you overlooked something that is actually important.
Sometimes, you even find the explanation before ending your description.
My best friend for many years has been to jump on my bike and go home. Just getting away from the keyboard has solved many problems over the years for me.
If the problem lasts to the end of the day, I try and consciously lock the problem away for solving before I go to sleep.
I realise this sounds a bit out there, but it has been very common in my experience that I'll wake up with at least an alternate approach to the problem, if not the full-on solution. The idea is not to stress about it - but actively decide to solve it over night. That way you can go to sleep without worry.
I think eating well, regular exercise and good sleep are huge contributors to the problem-solving process.
Usually I'll try nut out the problem for a few hours or so, trying different things writing it on paper, making diagrams. If none of that works I'll usually work through the following options.
Put a sticky note on my monitor and keep going with something else
Glance at the note through out the next few hours to keep the problem in the back of my mind
Google for similar problems and the methods used
Consult a co-worker or a friend
Ask on a forum such as stackoverflow
Give up and design the problem away or design a way around the problem so it can be dealt with some other time and stick a TODO note at the site of said workaround
Don't forget Google Code Search
It's often best to clear your head by doing something other than programming for a little while. See this answer for an example - I did it while struggling with a particularly thorny bug, and when I came back to the problem I solved it in about a minute.
Usually I try to solve it until I go to sleep.. Sometimes I write on paper what the code is doing and then I divide it in pieces; I try to know how the variables of the program change when it's running.
Try solving a much smaller version of the problem first and see how you get on with that.
Once you've done that the bigger problem won't look so scary.
Ask yourself: is solving this particular tricky problem really important to what you doing?
For the purposes of your application (or whatever the big picture is) is there a similar but easier problem that you could address to accomplish broadly the same thing.
Normally, I would get pen and paper and try to work out the details of the problem there. If that doesn't help, Google. Failing that, I'd do something else for a while, or ask online. Worked for me so far.
The fact you are stuck might be a 'code-smell'. Suggesting that their is something wrong with the design or approach somewhere else. Try to put your finger on what's causing this and fix this instead.
When you come back to your problem it might no longer exist.
One more time, browse thru what I think might be relevant, then take nap.
There are two other answers which mention sleeping or napping, but this deserves more emphasis. It is now known that there's SERIOUS machinery in there which goes to work when you sleep. Google (( CBS SCIENCE SLEEP )) will get you to a great free video.
If I can't figure out how to solve the real problem, I try to consider a simplified version of the problem. To take a simple example: I recently had the problem of finding a set of shipping routes to get an item from point A to point B, when there is not necessarily a direct route from A to B, but there might be an A to C and then C to B, or A to C, C to D, and then D to B. (I'm sure the airlines and railroads do this all the time.) That was fairly complex, so I tried looking first at the simple case: a direct A to B. That was easy. Then consider how I'd handle it with one stop along the way. Then consider two stops. At that point I was able to see the pattern to a solution.
Solutions to a simplified version of the problem may end up being a part of the bigger solution, with some additional complexity wrapped around them. But even if not, the exercise of solving the easier problem often gives you ideas on how to solve the real problem.
The main techniques I use (should be followed in order so that you can reuse what you have done in previous steps to be more efficient):
Define your issue: Try to clearly define what's the problem, and what's expected. See 2 to help you.
Collect data about the bug: Log everything: your attempts, the expected result, the observed result. This will avoid the need to redo several times the same tests (because your mind cannot memorize it all), and probably help you see the bigger picture.
Reduce your problem. This is true in general for any abstract modelling of natural phenomenons, but it's even more true of programming, because programs are very complex entities. You should try to reduce your code to a minimal program that reproduces your issue. Automated tools exist.
Talk to someone: several anecdotes affirm than about 2/3 of the bugs are resolved just by talking about it. See the Helpful Teddy Bear anecdote. If you have previously reduced your program to a minimal program, and have a clear definition of your issue, both will be useful to your explanation.
Reach for collaborative help: search on Google and on StackOverflow, and post if you can't find anything that answers your problem (but first see 1, you must have a clear definition of your problem).
As you can see, I put the collaborative help as the last step, because you should only ask for help after you have clearly defined your issue and tried to reduce the problem and fix it by yourself. If you reach for collaborative help before having tried the previous steps, you will either end up with a poor help or figure it out by yourself as soon as you have posted.
Also you can be interested in the Coursera Software Debugging course, which also describes several automated debugging methods.
Go to the toilet.
You move, so your brain gets oxygen.
You relax, so you focus on other things.
Peeing for innovation! :)