spurious description string in pointerized series arg
by Sven Schreiber
Hi,
the attached script files demonstrate a bug. Please run the
bugtest_driver.inp script which includes the other script
port_bugtest.inp. The example uses the built-in example dataset abdata.
The point is that the top-level series "e" which is passed as a pointer
arg to the function (factcoint_test) gets a spurious and more or less
arbitrary description string, sometimes including non-printable
characters. Actually sometimes the correct description happens; in that
case please just run the script again. To trigger the bug it seems
necessary to have an enclosing loop.
In itself it's not a big deal, but since apparently chunks of memory end
up where they do not belong, maybe some related unknown bugs exist and
may be fixed by getting this straight.
This is a fairly recent snapshot.
thanks
sven
1 month, 2 weeks
Some diagnostic test results are not added to the model window
by Sven Schreiber
Hi,
after estimating a model (say with OLS), gretl's standard GUI behavior
after the user runs a diagnostic test via the Test menu in the model
window is to print the result in the model window below the estimation
output.
However, there seem to be some exceptions:
- CUSUMSQ
- Nonlinearity/BDS
(and possibly others that only affect panels or so).
Is there a special reason for this, or simply an oversight?
thanks
sven
2 months
unexpected rnameset behavior
by Sven Schreiber
Hi,
is this intended?
<hansl>
s = "a,b" # two
M = seq(1,3)' # three
rnameset(M,s) # no error, "a,b" is taken as a three-char prefix
print M
</hansl>
I can understand the logic -- it doesn't match, and so the comma loses
its special meaning and the entire string is used as a kind of prefix.
When using strings arrays instead as an input to rnameset, there are
warning messages. Again, I can see why, because with arrays it's more
obvious what's intended and what's wrong.
So I'm not saying it's a bug, but still wanted to ask.
thanks
sven
2 months
about "auto" argument setting with numeric meta type
by Sven Schreiber
Hi, looking at the not-too-old (two years?) possibility of indicating an
automatic function argument value, there's a little hiccup in
combination with the also new numeric thing:
<hansl>
function void hey_num(numeric ho[auto]) # error
eval (exists(ho) ? ho : "nope")
end function
</hansl>
Notice the error already appears at the function definition, no need to
call it.
This is of course a very special thing, I'm not even sure I expected it
to work. On the other hand, "numeric" could be a matrix or series, and
for those types it is supported. (For scalars, it's not directly
supported AFAIK, because there's the traditional way of specifying an
automatic default value.)
thanks
sven
2 months, 2 weeks
