Related
(This question regards search/6.)
I was wondering if there is a way -rather than manual tracing- to pause the execution of search/6 every time a new solution for a single variable was found?
I would like to accomplish this to further investigate what is happening during search in constrained models.
For example, if you are trying to solve the classic sudoku problem, and you have written a set of constraints and a print method for your board, it can be useful to print the board after setting the constraints, but before searching, in order to evaluate the strongness of your constraints. However, once search is called to solve the sudoku, you don't really have an overview of the single results being built underneath unless you do a trace.
It would be very useful if something was possible in the likes of:
(this is just an abstract example)
% Let's imagine this is a (very poorly) constrained sudoku board
?- problem(Sudoku),constraint(Sudoku),print(Sudoku).
[[1,3,_,2,_,_,7,4,_],
[_,2,5,_,1,_,_,_,_],
[4,8,_,_,6,_,_,5,_],
[_,_,_,7,8,_,2,1,_],
[5,_,_,_,9,_,3,7,_],
[9,_,_,_,3,_,_,_,5],
[_,4,_,_,_,6,8,9,_],
[_,5,3,_,_,1,4,_,_],
[6,_,_,_,_,_,_,_,_]]
Now for the search:
?- problem(Sudoku),constraint(Sudoku),search_pause(Sudoku,BT),print(Sudoku,BT).
[[1,3,6,2,_,_,7,4,_],
[_,2,5,_,1,_,_,_,_],
[4,8,_,_,6,_,_,5,_],
[_,_,_,7,8,_,2,1,_],
[5,_,_,_,9,_,3,7,_],
[9,_,_,_,3,_,_,_,5],
[_,4,_,_,_,6,8,9,_],
[_,5,3,_,_,1,4,_,_],
[6,_,_,_,_,_,_,_,_]]
Board[1,3] = 6
Backtracks = 1
more ;
Using existing Visualization tools
Have a look at the Visualization Tools Manual. You can get the kind of matrix display you want by adding a viewable_create/2 annotation to your code, and launching a Visualisation Client from TkECLiPSe's Tools-menu.
Using your own instrumented search routine
You can replace the indomain_xxx choice methods in search/6 with a user-defined one where you can print information before and/or after propagation.
If that is not enough, you can replace the whole built-in search/6 with your own, which is not too difficult, see e.g. the ECLiPSe Tutorial chapter on tree search or my answer to this question.
Tracing using data-driven facilities
Using ECLiPSe's data-driven control facilities, you can quite easily display information when certain things happen to your variables. In the simplest case you do something on variable instantiation:
?- suspend(printf("X was instantiated to %w%n",[X]), 1, X->inst),
writeln(start), X=3, writeln(end).
start
X was instantiated to 3
end
Based on this idea, you can write code that allows you to follow labeling and propagation steps even when they happen inside a black-box search routine. See the link for details.
I'm using Fortran for my research and sometimes, for debugging purposes, someone will insert in the code something like this:
write(*,*) 'Variable x:', varx
The problem is that sometimes it happens that we forget to remove that statement from the code and it becomes difficult to find where it is being printed. I usually can get a good idea where it is by the name 'Variable x' but it sometimes happens that that information might no be present and I just see random numbers showing up.
One can imagine that doing a grep for write(*,*) is basically useless so I was wondering if there is an efficient way of finding my culprit, like forcing every call of write(*,*) to print a file and line number, or tracking stdout.
Thank you.
Intel's Fortran preprocessor defines a number of macros, such as __file__ and __line__ which will be replaced by, respectively, the file name (as a string) and line number (as an integer) when the pre-processor runs. For more details consult the documentation.
GFortran offers similar facilities, consult the documentation.
Perhaps your compiler offers similar capabilities.
As has been previously implied, there's no Fortran--although there may be a compiler approach---way to change the behaviour of the write statement as you want. However, as your problem is more to do with handling (unintentionally produced) bad code there are options.
If you can't easily find an unwanted write(*,*) in your code that suggests that you have many legitimate such statements. One solution is to reduce the count:
use an explicit format, rather than list-directed output (* as the format);
instead of * as the output unit, use output_unit from the intrinsic module iso_fortran_env.
[Having an explicit format for "proper" output is a good idea, anyway.]
If that fails, use your version control system to compare an old "good" version against the new "bad" version. Perhaps even have your version control system flag/block commits with new write(*,*)s.
And if all that still doesn't help, then the pre-processor macros previously mentioned could be a final resort.
I'm new to funcctional programming and have some questions regarding coding style and debugging.
I'm under the impression that one should avoid storing results from funcction calls in a temp variable and then return that variable
e.g.
let someFunc foo =
let result = match foo with
| x -> ...
| y -> ...
result
And instead do it like this (I might be way off?):
let someFunc foo =
match foo with
| x -> ...
| y -> ...
Which works fine from a functionallity perspective, but it makes it way harder to debug.
I have no way to examine the result if the right hand side of -> does some funky stuff.
So how should I deal with this kind of scenarios?
To inspect the middle of a pipeline, I suggest the following workaround:
Put this code at some place:
[<AutoOpen>]
module AutoOpenModule
#if DEBUG
let (|>) value func =
let result = func value
result
#endif
Enable "Step Into Properties and Operators in Managed Code":
https://msdn.microsoft.com/en-us/library/cc667388(v=vs.100).aspx
Now you should be able to step into the pipeline operator.
Either way is acceptable, as you are simply binding to local immutable variable.
There is a catch though. If you using it as part of a recursive loop using tail calls, the one using the temp variable will eliminate the tail call, and hence you will have an increase in stack space.
Being able to see the return value of a function in VS is a long-standing request. Other intermediate expression values too; in F# for example, you often want to inspect the middle of a pipeline, which is hard to do. In the sense that functional programming means "fewer named variables and locals" and "larger expressions", this does have a negative impact on the current generation of debuggers. (On the other hand, with things like less mutability and higher abstraction, hopefully you spend less time in the debugger.)
There are still many ways the debuggers of the future can be improved...
See also
Do some Functional programming constructs reduce Debuggability?
I wouldn't shoot you if you used the temp, but I also wouldn't cramp my style on the off chance that I needed to watch something under debug.
Besides, debugging this sort of thing is much easier with Visual Studio 2010's visual debugger, as you can use breakpoints inside each possible match expression. There is also quick watch and other great features.
For a list of the latest features in the Visual Studio debugger:
http://msdn.microsoft.com/en-us/library/01xdt7cs.aspx
Peter Norvig in PAIP says:
in modern lisps...eval is used less often (in fact, in Scheme there is
no eval at all). If you find yourself using eval, you are probably
doing the wrong thing
What are some of the ways to circumvent using eval in scheme? Arent there case where eval is absolutely necessary?
There are cases where eval is necessary, but they always involve advanced programs that do things like dynamically loading some code (eg, a servlet in a web server). As for a way to "circumvent" using it -- that depends on the actual problem you're trying to solve, there's no magic solution to avoiding eval except for ... eval.
(BTW, my guess is that PAIP was written a long time ago, before eval was added to the Scheme Report.)
He's wrong. Of course there is eval in Scheme.
You'll need eval in some very rare case. The case that comes into mind first is when you'll build program with a program and then execute it. This happens mainly with genetic algorithm for example. In this case you build a lot a randomized programs that you'll need to execute. Having eval in conjunction with code being data make lisp the easiest programming language to do genetic algorithm.
Having these properties comes at a great cost (in term of speed and size of your program) because you'll remove all possibility to do compile time optimization on the code that will be evaled and you must keep the full interpreter in your resulting binary.
As a result it is considered poor design to use eval when it can be avoided.
The claim that Scheme has no eval is inaccurate at least for the most recent versions of the Scheme standard (R5RS and later). Usually, what you want is a macro instead, which will generate code at compilation time.
It is true that eval should be avoided. For starters, I've never seen a satisfactory definition of how should it behave, for example:
What environment expressions should be evaluated in when no environment is passed?
When you do pass in an environment, how do those work? For example, the standards specify no way you can pre-bind a value in that environment object.
That said, I've worked with a Scheme application that uses eval to generate code dynamically at runtime for cases where the structure of the computation cannot be known at compilation time. The intent has been to get the Scheme system to compile the code at runtime for performance reasons—and the difficulty is that there is no standard way to tell a Scheme system "compile this code."
It should go without saying also that eval can be a huge security risk. You should never eval anything that doesn't have a huge wall of separation from user input. Basically, if you want to use eval safely, you should be doing so in the context of the code-generation phase of a compiler-like system, after you've parsed some input (using a comprehensively defined grammar!).
First, PAIP is written for Common Lisp, not Scheme, so I don't know that he'd say the same thing. CL macros do much the same thing as eval, although at compile time instead of run time, and there's other things you could do. If you'd show me an example of using eval in Common Lisp, I could try to come up with other methods of doing the same thing.
I'm not a Scheme programmer. I can only speak from Norvig's perspective, as a Common Lisp programmer. I don't think he was talking about Scheme, and I don't know if he knew or knows Scheme particularly well.
Second, Norvig says "you are probably doing the wrong thing" rather than "you're doing the wrong thing". This implies that, for all he knows, there's times when eval is the correct thing to use. In a language like C, I'd say the same thing about goto, although they're quite useful in some restricted circumstances, but most goto use is by people who don't know any better.
One use I've seen for 'eval' in scripting environments is to parameterize some code with runtime values. for instance, in psuedo-C:
param = read_integer();
fn = eval("int lambda(int x) {
int param = " + to_string(param) + ";
return param*x; }");
I hope you find that really ugly. String pasting to create code at runtime? Ick. In Scheme and other lexically scoped Lisps, you can make parameterized functions without using eval.
(define make-my-fn
(lambda (param)
(lambda (x) (* param x)))
(let* ([ param (read-integer) ]
[ fn (make-my-fn param ])
;; etc.
)
Like was mentioned, dynamic code loading and such still need eval, but parameterized code and code composition can be produced with first class functions.
You could write a scheme interpreter in scheme. Such is certainly possible, but it is not practical.
Granted, this is a general answer, as I have no used scheme, but it may help you nonetheless. :)
I've been coding on and off my whole life. I've mostly coded Perl, but also some Java, PHP, C, C++. I've even took a stab at Emacs Lisp, and I've done the occasional shell script. However, I've never actually engaged the subject to gain any kind of expertise – other things have had higher priorities for me. I don't consider myself to be really proficient in any language but Perl, and also now Haskell which I'm taking a course in right now.
Lately, I've been thinking about my style of coding. Not the style of the actual code; as a CS student I only do projects for fun or for school, which enables me to write what in my opinion is beautiful code almost always. One question in particular has been troubling me. It's a rather curious thing, but still something I would like to hear other opinions about.
Here's the thing: I find myself taking a fair amount of time to name my functions and variables to the most easily understood names I can possibly think of. Sometimes this task can be very tedious, even when not taking into account the difficulty of finding a variable name that conveys the meaning of a piece of code. For example, right now I'm making a function that looks like this.
This is Haskell code but the meaning should be quite clear. (It's exact meaning isn't that important so if you want to, just skip the code and read on.)
-- return the row with least number of Nothing values
bestRow :: [[Maybe Int]] -> Int -> Maybe (Int,Int)
bestRow [] _ = Nothing
bestRow (row:rows) thisIndex
| nextRow == Nothing && thisFilled > 8 = Nothing
| nextRow == Nothing = Just (thisIndex,thisFilled)
| thisFilled >= nextFilled = Just (thisIndex,thisFilled)
| thisFilled < nextFilled = nextRow
where thisFilled = length $ filter (/= Nothing) row
nextRow = bestRow rows (thisIndex + 1)
(nextIndex,nextFilled) = fromMaybe (-1,-1) nextRow
I couldn't decide on the variable names. The function did it's task well but it wasn't as clear as it could be. Once I settled on a solution, I spent 15 minutes on naming and renaming the variables. Should I go with curIndex, nextIndex || index, nextIndex || ind, indN etc? 15 minutes after I decided I was done, I realized this function wasn't needed after all: I found a much better solution to my problem. BOOM I had lost a lot of time simply cleaning code to no use to anyone, least of all to me. Or at least it felt that way.
This is something which has happened to me more than once, and is quite frustrating, mostly because it makes me feel dumb. What are your thoughts on this subject? Is this something you've experienced, something wrong with my way of doing things or simply something unavoidable?
Are there "perfect" variable names, or is it "ok" if they at least doesn't obfuscate your code?
Thanks,
Stefan Kangas
Read the book Clean Code by Robert C. Martin
One thing he goes into detail on is naming. Variable and function names should be as exact as possible. If you require a comment to describe it, the function is either doing too much, or the name can be clearer.
The goal, is to have code that reads like a story. Changing variable and function names and breaking them down into several functions or variables if necessary to achieve this goal.
Great book, worth every penny
Good names for variables and functions make understandable code. Good names should describe the intent and use of a variable or function. Bad names confuse other coders when it comes time to make changes.
Clarity is good in code.
I think its psychological, I always used to think my variables etc was unreadable to anyone but me even though I always placed comments in my code.
Whenever I had to go through code by someone else I was quite surprised at how I could easily read their code without having to read every single comment, the exact same thing happens when they read my code so clearly I'm doing a good job ;)
I think as long as your comments are meaningful and actually describe what a method does, what a variable is being used for you should be fine.
One tip is to always make sure your comments are up to date. I've seen code too many times where the comments for a method haven't changed, but the method code has.....it can be very confusing!