problem with pointerized bundle member
by Sven Schreiber
Hi,
I run into problems (=error) when I try to pass a bundle element as a
function argument in pointerized form. Minimal script:
<hansl>
function void hey(matrix *hu)
print "hey"
end function
bundle bbb
bbb.in = ones(2,2)
hey(&bbb.in)
</hansl>
I also tried "&(bbb.in)" (with parentheses), with no luck. I can
actually understand why pointing to something inside a bundle would be
problematic, but OTOH since we want to do lots of stuff with bundles and
still avoid copying large chunks of data, I'm wondering what the
recommended solution would be.
thanks,
sven
7 years, 8 months
two scripting bugs fixed
by Allin Cottrell
I haven't seen the following bugs reported in the wild, but I came
across them in the course of my own scripting efforts lately. They
are fixed in git and snapshots.
1) Under certain conditions the loop counter variable in a function
could become confused with a loop counter variable of the same name
in the caller. Trivial example:
<hansl>
function series foo (scalar x)
series s
loop i=1..$nobs -q
s[i] = x + i
endloop
return s
end function
nulldata 10
loop i=1..3 -q
series s1 = foo(1)
series s2 = foo(2)
printf "i=%d\n", i
endloop
</hansl>
If the bug is triggered, then on the second and subsequent
iterations of the loop in the caller one sees "i=10" instead of the
expected "i=2". It is triggered only if (a) the loop counter has the
same name in caller and function, (b) the function is called more
than once per iteration of the loop in the caller, and (c) there is
no look-up of variable names (other than series) in the caller
between the calls to the function. (For example, inserting another
instance of 'printf "i=%d\n", i' between the calls to foo() would
prevent the bug from triggering.)
2) Putting a "return" statement inside a loop in a function would
cause a curious failure: the return would be executed prematurely,
at the point when gretl was supposed to be just "compiling" the
loop, not actually executing the code. Trivial example:
<hansl>
function scalar foo (scalar x)
loop i=1..2 -q
if 0
return 1
endif
endloop
return 0
end function
eval foo(1)
</hansl>
Before the fix, "eval foo(1)" would give 1, unconditionally.
I might add that both fixes were basically one-liners --
representing points that had been overlooked rather than major
structural flaws.
Allin
7 years, 9 months
fdjac precision question
by oleg_komashko＠ukr.net
Dear all, First, a couple of numbers to introduce the question
cos(0.1)~ 0.99500416 5278 025766095561987803870294838576225415084035959352...
### NOTE all results are on 32-bit Ubuntu 15.10 To compare a helper:
function string as_string (scalar x) sprintf s "%.15g",x return s end function
1) x={0.1} eval as_string(fdjac(x,sin(x))) 0.99500416 7780 28
2)
set fdjac_quality 1 eval as_string(fdjac(x,sin(x))) 0.99500416 5451 974
3)
set fdjac_quality 2 eval as_string(fdjac(x,sin(x))) 0.99500416 3123 667
A home-backed thing inspired by fdjac help :
A helper: function scalar feval (string fun, scalar x) return @fun end function
The main:
function scalar sdj2 (string f, scalar x) if abs(x)>10^3 h = 10^3*sqrt(x/1000*$macheps) else h=10^(3)*sqrt($macheps) endif z = (8*(feval(f,x+h)-feval(f,x-h)) - (feval(f,x+2*h)-feval(f,x-2*h)))/(12*h) sz = as_string(z) return z end function
We have
eval as_string(sdj2("sin(x)",0.1)) 0.99500416 5277 274 recall: 0.99500416 5278 025766
In theory, fdjac should be better, since it uses the same formula as sdj2() and it should optimize the step h, but... Oleh
7 years, 9 months
Wish/Suggestion: Dark Background for the script window
by Artur Tarassow
Dear Allin and Jack,
this is just a suggestion which may raise gretl's already high-level usability even further a bit.
Personally, I like a dark background and bright letters very much as it nicely suits my eyes. Of course one could use any editor which supports differently coloured backgrounds but then one has to abstain from some other features the default GUI script window offers, as you know.
I've no idea how difficult it is to implement and if this would be helpful for others as well. Don't take this as urgent!
Best wishes,
Artur
7 years, 9 months
a hsk question
by oleg_komashko＠ukr.net
Dear all, hsk command while performing step (b) regression, as described in the Command reference, does not include constant when there is no constant in the original regression. Why it doesn't? The constant in step (b) regression
is a proxy for log(sigma^2) from the original regression. Oleh
7 years, 9 months
default values for matrices?
by oleg_komashko＠ukr.net
Dear all, Is there a possibility to set defaults values for matrix input vars for hansl user-written functions? If no, Is there a chance for it to go into the wishlist? Oleh
7 years, 9 months
Forecast based on ordered probit
by Artur Tarassow
Dear all,
I just trying to run some forecasts based on an ordered probit
regression model and detected some (maybe?) slight inconsistency -- if any.
Using the fcast command returns for the BINARY PROBIT the estimated
probabilties, but for the ORDERED PROBIT a series of the predicted
response at each observation (the response for which the estimated
probability is highest).
However, I would like to estimate using the ORDER PROBIT the forecasted
probabilties using Jack's "oprobit_predict" function for which I would
need forecast of the z-hat values.
Here is an example:
<hansl>
clear
set messages off
set echo off
open ukppp.gdt -q
series B = (diff(e12)>0) # binary
series C = 0 # ordered (3 classes)
C = (diff(e12)>=-0.02 && diff(e12)<0.07) + 2*(diff(e12)>=0.07)
# Set tranining sample
smpl ; 1986:1
# Binary Probit
probit B 0 doilp0 --quiet
fcast --out-of-sample
# Ordered Probit
probit C 0 doilp0 --quiet
fcast --out-of-sample
</hansl>
Best,
Artur
7 years, 9 months
Trouble in configuring MPI in Linux (documentation bug ; )
by Hélio Guilherme
Hi gretl Masters (Allin and Jack),
I think this message is targeted to Jack.
I discovered that to enable MPI we must set the environment var MPICC.
In the guide gretl-mpi.pdf (page 9), you must change ".. can also..." :
(original)
Once MPI is installed it should probably be found automatically by gretl’s
configure script. If need
be you can give the process some help. For instance, if Open MPI is
installed under /opt/openmpi
you might do
--with-mpi-lib=/opt/openmpi/lib
--with-mpi-include=/opt/openmpi/include
(see ./configure --help). You can also set the path to the MPI
compiler-wrapper, mpicc, via the
environment variable MPICC, as in
MPICC=/opt/openmpi/bin/mpicc ./configure ...
(proposed corrected)
Once MPI is installed it should probably be found automatically by gretl’s
configure script. If need
be you can give the process some help. For instance, if Open MPI is
installed under /opt/openmpi
you might do
--with-mpi-lib=/opt/openmpi/lib
--with-mpi-include=/opt/openmpi/include
(see ./configure --help). You must also set the path to the MPI
compiler-wrapper, mpicc, via the
environment variable MPICC, as in
MPICC=/opt/openmpi/bin/mpicc ./configure ...
It's a MUST and not an optional thing!
This is my successful build command:
MPICC=/usr/lib64/openmpi/bin/mpicc ./configure --enable-build-doc
--with-gsf --with-mpi --with-mpi-lib=/usr/lib64/openmpi
--with-mpi-include=/usr/include/openmpi-x86_64 --with-odbc --with-libR
--enable-quiet-build --enable-build-addons
----
I am again without working project (==job), I am wiling to relocate if
there is some project where I can contribute with my IT knowledge. Please
contact me for more details. Thanks.
7 years, 9 months
string arrays
by Riccardo (Jack) Lucchetti
Dear all,
I'm aware that backward-incompatibilty should in principle be avoided.
However, it occurred to me that we introduced string arrays only
after (more or less) clever workarounds to their absence. Typical cases
are:
* the modprint command
* the varname() function (yes I know about varnames(), but it's a hack)
* the jsonget() function
* the labels command
* the colnames() and rownames() function
etc etc.
Clearly, a redesign of all these would be optimal, but it would involve a
major revision of hundreds of scripts out there; however, like always, the
sooner this is done, the better.
Opinions?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
7 years, 9 months
