Hi,
I've attached a badly specified mle model which provokes the error. I don't know
whether one can find a well specified model which has these problems, too. The script is
named test_bfgs.inp.
I've attached two more patches. The first one adds a function debugger to gretl. It
adds 4 new commands to gretl: debug and undebug for initiating and stopping debugging of a
user defined function and continue and next (aliases c and n) which allow to step through
a function. After having these problems with my code last Thursday/Friday I thought that a
real debugger would be really helpful. If you have a large programm set debug 2 is not
sufficient anymore. The debugger is not thoroughly tested. There are two things that I
don't like about it. First of all a callback into the client application is needed in
order to talk with the users out of the depths of libgretl. Perhaps I can extend the PRN
structure somehow in order to have a more coherent interface. Another problem here is that
I didn't find a way to transport the callback address to exec_user_func. I extended
libset, but I think libset was meant only to care for user editable properties. I would be
happy to receive comments about this from you. If I have time in the next days I will try
to implement breakpoints and "step into function"-commands. Up to now the
debugging feature is only available to gretlcli users. Below you find a sample debug
session:
script:
set debug 2
function fred(scalar a)
scalar d=a+1
scalar f=1
scalar g=f
return scalar d
end function
debug fred
scalar q=fred(2)
scalar q=fred(2)
session:
? run test.inp
/home/chris/dev/gretl-cvs8/test.inp
? set debug 2
? function fred(scalar a)
#scalar q=fred(2)
#print q
? debug fred
? scalar q=fred(2)
*** executing function fred
? scalar d=a+1
Generated scalar d = 3
Debugging fred, line 0
? d
3
? d=4
Replaced scalar d = 4
? n
? scalar f=1
Generated scalar f = 1
Debugging fred, line 1
? n
? scalar g=f
Generated scalar g = 1
Debugging fred, line 2
? c
Generated scalar q = 4
? scalar q=fred(2)
*** executing function fred
? scalar d=a+1
Generated scalar d = 3
Debugging fred, line 0
? c
? scalar f=1
Generated scalar f = 1
? scalar g=f
Generated scalar g = 1
Replaced scalar q = 3
Done
The second patches is more like a proof of concept. I really liked the integration of R
into gretl via the foreign code block. But up to now it has 2 problems: It is slow and for
all foreign blocks you need gretl glue code which transports parameters and results into
and out of R. The second patch speeds up the execution of R functions by calling directly
into libr. I have extended the makefiles in order to link against libR. The position of
libr is hand coded in order to match the location on my ubuntu system. Another feature of
this patch is the seamless integration of R functions into gretl. After defining a
function in a gretl foreign-block, it can be called from within gretl using standard genr
statements: No more glue needed. But this functionality is still a bit experimental. I
haven't tested this much too. Another problem is that using libr may have some
side-effects. For example R installs its own segfault-handler. This feature, too, is only
avaiable to gretlcli users. Below you find again an example:
script:
nulldata 10
foreign language=RLib
abc<-function(q) {
z=q+1
invisible(z)
}
end foreign
scalar b=abc(2)
session:
? nulldata 10
periodicity: 1, maxobs: 10,
observations range: 1-10
? foreign language=RLib
? abc<-function(q) {
? z=q+1
? invisible(z)
? }
? end foreign
abc<-function(q) {
+ z=q+1
+ invisible(z)
+ }
? scalar b=abc(2)
abc(2)
Generated scalar b = 3
Done
Christoph
________________________________________
Von: gretl-devel-bounces(a)lists.wfu.edu [gretl-devel-bounces(a)lists.wfu.edu] im Auftrag von
Allin Cottrell [cottrell(a)wfu.edu]
Gesendet: Samstag, 4. Juli 2009 21:21
An: Gretl development
Betreff: Re: AW: AW: [Gretl-devel] bfgs: failed to match initial value
On Sat, 4 Jul 2009, Sven Schreiber wrote:
Am 03.07.2009 22:35, Klein, Christoph schrieb:
> I'm sorry for all the trouble. Looking carefully through my code, it seems more
like the problem is within my scripts than in gretl. I will try to find out why this
problem did arise in the next days.
>
> Sorry again and thanks for your helping pointers!
>
> Christoph
Nevertheless, if it was the case that you get an error message "which
should never happen" then it's worthwhile to fix it, no?
Yes, I think it would still be useful to have a testcase which
provokes that error message.
Allin.
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel