1:59 p.m.
Sorry for so many questions ;) I still find new ones.
a) Is there a way to access rownames similar to 'colname(matrix M, scalar
column)'? If yes, do rownames default to the index, if not explicitly provided? How
das print matrix access the rownames?
b) I am trying to find a solution to get the observation number of a specific entry
of a series in a subsampling (i.e., the integer with which I could access this entry in
the full sample), in order to synchronise it with a matrix OBSDATE I have in a bundle that
is passed to this function and holds string labels for each element in the full sample.
I can check via $nobs == nrows(OBSDATE) if there is a subsampling (which will not always
work..), but I do not know, how I can then treat with it (in both cases, time-series data
and cross-section data). If I use "obs" to generate a new series, than it does
not relate to the global identifiers but creates a new, small series of consecutive
integers (as is stated within the help). At the same time, the series within the bundle is
not synchronised with the global series'. Is there a way to deal with this? Or is the
only option to print an error message and demand that the bundle is reinitialised
accordingly with a series "obsdate=obs" from outside any function definition?
Isn't there a (hidden) accessor for a series entries' real (i.e. in full sample)
obsnumber/date?
perhaps $sample is an option? (Although I do not know how... ) and basically $t1 and
$t2 work for the first and last element in the current (sub)sample, but the values in
between are not provided?
c) Misc. feedback :
a. obs and obsnum are not highlighted in the editor (but the question mark works
nonetheless)
b. Instead of "varname()" one needs to use "argname()" to get
the name of a series (even when passed by pointer). This could be noted in the gretl help
(q-mark in script editor)
c. neither argname nor varname work on elements contained within a bundle. It does
also not help to make an new series from the series within the bundle (btw., pointer
arithmetic is not allowed at all in this case). It would be nice if this would work. My
Workaround is to have a special function that "adds" series to the bundle and,
at the same time, adds a key-entry for the series name.
d. A recursive "exists" for bundles would be nice. I.e. if I ask
"exists(a.b.x)" it is checked if x exists, but if "b" already is
missing, an error is produced. Perhaps a exists(a.b.x) --recursive option? Alternatively,
if conditions would be checked one at a time, this would also help. For example 'if
exists(a.b) && exists(a.b.x)' does not work if a.b does not exist
(https://en.wikipedia.org/wiki/Short-circuit_evaluation)
d) Misc. questions:
a. When I attach, within a function, a genr element (like series) that was passed by
pointer to the function, to a bundle, it is in fact copied (hansl-primer p.20). Is there a
way to instead add pointers to the bundle? Perhaps by means of using the array type?
Thanks
Frederik
8:11 a.m.
Am 09.01.2018 um 14:59 schrieb Schaff, Frederik:
Sorry for so many questions ;) I still find new ones.
No problem at all.
a)Is there a way to access rownames similar to ‘colname(matrix M,
scalar
column)’? If yes, do rownames default to the index, if not explicitly
provided? How das print matrix access the rownames?
Hm, good question. I don't know why there is no rowname analogue to
colname(). I was going to say "use the transpose", but this doesn't work
for me, either. There was a question on the mailing list by Henrique
Andrade in 2016 about the row names being lost after applying
mreverse(). So applying transp() has the same effect apparently.
b)I am trying to find a solution to get the observation number of a
specific entry of a series in a subsampling (i.e., the integer with
which I could access this entry in the full sample), in order to
synchronise it with a matrix OBSDATE I have in a bundle that is passed
to this function and holds string labels for each element in the full
sample.
I can check via $nobs == nrows(OBSDATE) if there is a subsampling (which
will not always work..), but I do not know, how I can then treat with it
(in both cases, time-series data and cross-section data). If I use “obs”
to generate a new series, than it does not relate to the global
identifiers but creates a new, small series of consecutive integers (as
is stated within the help). At the same time, the series within the
bundle is not synchronised with the global series’. Is there a way to
deal with this? Or is the only option to print an error message and
demand that the bundle is reinitialised accordingly with a series
“obsdate=obs” from outside any function definition? Isn’t there a
(hidden) accessor for a series entries’ real (i.e. in full sample)
obsnumber/date?
I'm not sure I understand the question. The observation numbers/indices
in the dataset do not depend on subsampling. See for example:
<hansl>
open hendry_jae.gdt # annual data from 1873 to 1991
eval obslabel(1) # gives 1873
smpl 1900 1991
eval obslabel(1) # still gives 1873
</hansl>
perhaps $sample is an option? (Although I do not know how… ) and
basically $t1 and $t2 work for the first and last element in the current
(sub)sample, but the values in between are not provided?
Do you want to check for subsampling? You could check whether $t1==1 and
$t2==$tmax.
Caveat: For panel data --especially unbalanced-- it could be more
tricky. Perhaps something like this:
series check = 1
smpl full
checksum = sum(missing(check))
smpl --no-missing check # restore to the initial sample, if different
The if checksum is positive, the initial sample was a subsample. (Some
setobs magic might be needed afterwards to really reimpose the panel
structure.)
c)Misc. feedback :
a.obs and obsnum are not highlighted in the editor (but the question
mark works nonetheless)
True for obs, but obsnum() works here.
BTW I notice that 'obs()' (with parentheses) doesn't work -- I think
this should be mentioned in the function ref.
b.Instead of “varname()” one needs to use “argname()” to get the name
of
a series (even when passed by pointer). This could be noted in the gretl
help
You mean inside a function, and you want a cross-reference from the help
for varname() to the help for argname()?
c.neither argname nor varname work on elements contained within a
bundle. It does also not help to make an new series from the series
within the bundle (btw., pointer arithmetic is not allowed at all in
this case). It would be nice if this would work.
If I understand correctly, this is what I meant earlier when I said "if
you use bundles, you need good documentation for what they contain".
I don't think it's possible to get what you want. For example a bundle
can contain many series. Do you want to retrieve all the names in there?
If yes, what are you going to do about it without having some meta
knowledge about what each of them represents?
d.A recursive “exists” for bundles would be nice. I.e. if I ask
“exists(a.b.x)” it is checked if x exists, but if “b” already is
missing, an error is produced. Perhaps a exists(a.b.x) --recursive
option? Alternatively, if conditions would be checked one at a time,
this would also help. For example ‘if exists(a.b) && exists(a.b.x)’ does
not work if a.b does not exist
Are you talking about nested bundles here? Are you aware of the
inbundle() function? (Which isn't recursive AFAIK, though.)
But indeed it sounds as if it might be useful to turn the not yet
possible 'exists(b["hey"])' into an alias for something like:
if exists(b)
if inbundle(b, "hey")
return <type code for b.hey>
else
return 0
endif
else
return <new code? NA?>
endif
d)Misc. questions:
a.When I attach, within a function, a genr element (like series) that
was passed by pointer to the function, to a bundle, it is in fact copied
(hansl-primer p.20). Is there a way to instead add pointers to the
bundle? Perhaps by means of using the array type?
No I don't think so. What you could do is store your own reference to
the series, so for example save the argname() as a string, and then work
with that. Apart from that a gretl list is basically just a set of
references to existing series, and recently it was made possible to add
a list to a bundle, so perhaps that's your solution.
Or also the integer ID via varnum(), but that may change so I tend to
avoid it. (Strictly speaking the string name may also change, but only
through explicit action AFAIK.)
good luck,
sven
6:17 p.m.
> a)Is there a way to access rownames similar to
'colname(matrix M,
> scalar column)'?
Hm, good question. I don't know why there is no rowname analogue
to
colname(). [...]
> b)I am trying to find a solution to get the observation number
of a
> specific entry of a series in a subsampling (i.e., the integer with
> which I could access this entry in the full sample), [...]
I'm not sure I understand the question. The observation numbers/indices in
the dataset do not depend on subsampling.
I missed a crucial part. I use a bundle structure and attach a series "obsdate =
obs" to the bundle. Now, when I subsample the dataset, the series contained in the
bundle does not work anymore, because it is not sampled alongside (because it is a copy,
not a link). However, the list-idea works great! (see at the end)
> c)Misc. feedback :
[...]
> b.Instead of "varname()" one needs to use
"argname()" to get the name
> of a series (even when passed by pointer). This could be noted in the
> gretl help
You mean inside a function, and you want a cross-reference from the help
for varname() to the help for argname()?
Yes.
> c.neither argname nor varname work on elements contained within
a
> bundle. [...]
If I understand correctly, this is what I meant earlier when I said "if you use
bundles, you need good documentation for what they contain".
I don't think it's possible to get what you want. For example a bundle can
contain many series. Do you want to retrieve all the names in there?
If yes, what are you going to do about it without having some meta
knowledge about what each of them represents?
I would use them for plotting, to provide information for the titles.
> d.A recursive "exists" for bundles would be nice. I.e.
if I ask
> "exists(a.b.x)" it is checked if x exists, but if "b" already
is
> missing, an error is produced.
Are you talking about nested bundles here? Are you aware of the
inbundle() function? (Which isn't recursive AFAIK, though.)
Yes, I am aware of it and used it, but it has the same problem. Btw.: It is not documented
that "strings" and "matrices" have the same type reported as
"array" (6)
But indeed it sounds as if it might be useful to turn the not yet
possible
'exists(b["hey"])' into an alias for something like:
if exists(b)
if inbundle(b, "hey")
return <type code for b.hey>
else
return 0
endif
else
return <new code? NA?>
endif
I even have a bundle inside a bundle, so for checking if "abndl.bbndl.cstring"
exists, I need:
<hansl>
scalar isOK=0 #0==not ok
if exists(abndl)
if inbundle(abndl,bbndl)
isOK = inbundle(abndl.bbndl,cstring)
endif
endif
> d)Misc. questions:
>
> a.When I attach, within a function, a genr element (like series) that
> was passed by pointer to the function, to a bundle, it is in fact
> copied (hansl-primer p.20). Is there a way to instead add pointers to
> the bundle? Perhaps by means of using the array type?
No I don't think so. What you could do is store your own reference to the
series, so for example save the argname() as a string, and then work with
that. Apart from that a gretl list is basically just a set of references to existing
series, and recently it was made possible to add a list to a bundle, so perhaps
that's your solution.
Or also the integer ID via varnum(), but that may change so I tend to avoid it.
(Strictly speaking the string name may also change, but only through explicit
action AFAIK.)
THAT'S IT! thanks! If you assign a series first to a list and then to the bundle, it
is "behind the curtain" a pointer assignment. I can provide a front-end function
where a user only passes a series via pointer now, which is then internally passed to a
list that is stored in the bundle. This way, I can also take care of the problem with
identifying the correct items in case of subsampling (and it is more efficient to not copy
the series). I tested it and it's a perfect solution to my problem.
Some other things I noticed:
A) it would be nice if one could "pipe" return values, i.e. "return
function()" is not a valid statement. This would make things more readable.
B) inbundle(bundle,list) returns "7", but this is not documented.
C) If you have a bundle within a bundle, you cannot save it to inspect it (via gui, icon
view, click on envelop bundle then save.. select the bundle. Nothing happens.) However, if
you assign a new bundle from the bundle directly via the script, it works (inbundle =
bundle.inbundle)
D) If you create an empty bundle like "bundle new" that is fine, but
"bundle new = null" doesn't do anything, but neither report that. Perhaps
just my error, I don't know. But it might be a source for bugs.
E) The error msg for functions with a name that is too long (>31 chars) is not
informative. Names so long CAN happen if working with telling quasi-namespaces... (via
"_" connected), e.g.
F) I have frequent crashes when using the button to move the output window to the front.
7:25 p.m.
On Wed, 10 Jan 2018, Schaff, Frederik wrote:
Some other things I noticed:
A) it would be nice if one could "pipe" return values, i.e. "return
function()" is not a valid statement. This would make things more
readable.
In principle you can. For example the following works OK:
<hansl>
function scalar fun2 (scalar x)
return 2*x
end function
function scalar fun1 (scalar x)
return fun2(3*x)
end function
eval fun1(2)
</hansl>
Can you give us a case where this sort of thing fails?
B) inbundle(bundle,list) returns "7", but this is not
documented.
Storing lists in bundles is a relatively new thing. I've now updated
the help for inbundle().
C) If you have a bundle within a bundle, you cannot save it to
inspect it (via gui, icon view, click on envelop bundle then save..
select the bundle. Nothing happens.)
OK, we'll look into that.
D) If you create an empty bundle like "bundle new" that is
fine, but
"bundle new = null" doesn't do anything, but neither report that.
I can't reproduce that:
<gretl-interactive>
? bundle new = null
? eval new
bundle new: empty
</gretl-interactive>
E) The error msg for functions with a name that is too long (>31
chars) is not informative. Names so long CAN happen if working with
telling quasi-namespaces... (via "_" connected), e.g.
OK, I see what you mean. In git the error message is now better.
F) I have frequent crashes when using the button to move the output
window to the front.
That's serious, but not something that anyone has reported before.
This is on Windows? In English or in German? (Not that that should
make a difference.) 64-bit or 32-bit build? (This may make a
difference.) And you're talking about the little "two windows" button
that pops down a list of gretl windows?
Allin
9:31 p.m.
Am 10.01.2018 um 20:25 schrieb Allin Cottrell:
On Wed, 10 Jan 2018, Schaff, Frederik wrote:
> F) I have frequent crashes when using the button to move the
output
> window to the front.
That's serious, but not something that anyone has reported before. This
is on Windows? In English or in German? (Not that that should make a
difference.) 64-bit or 32-bit build? (This may make a difference.) And
you're talking about the little "two windows" button that pops down a
list of gretl windows?
I remember that Frederik mentioned he often uses different gretl
instances in parallel. Maybe that could have to do with it. (?)
cheers,
sven
9:54 p.m.
On Wed, 10 Jan 2018, Sven Schreiber wrote:
Am 10.01.2018 um 20:25 schrieb Allin Cottrell:
> On Wed, 10 Jan 2018, Schaff, Frederik wrote:
>> F) I have frequent crashes when using the button to move the output window
>> to the front.
>
> That's serious, but not something that anyone has reported before. This is
> on Windows? In English or in German? (Not that that should make a
> difference.) 64-bit or 32-bit build? (This may make a difference.) And
> you're talking about the little "two windows" button that pops down a
list
> of gretl windows?
I remember that Frederik mentioned he often uses different gretl instances in
parallel. Maybe that could have to do with it. (?)
Conceivably, though I don't offhand see how that could mess things
up.
I'm in the process of testing the window-raising business on Windows
10 (64-bit) and I just added a test with two gretl instances active.
So far I'm not able to provoke a crash.
Allin
8:12 a.m.
> A) it would be nice if one could "pipe" return values,
i.e. "return
> function()" is not a valid statement. This would make things more
> readable.
In principle you can. For example the following works OK:
<hansl>
function scalar fun2 (scalar x)
return 2*x
end function
function scalar fun1 (scalar x)
return fun2(3*x)
end function
eval fun1(2)
</hansl>
Can you give us a case where this sort of thing fails?
Hmm, perhaps it is only "void" which cannot be piped. "return null" is
also invalid in this case.
> D) If you create an empty bundle like "bundle new"
that is fine, but
> "bundle new = null" doesn't do anything, but neither report that.
I can't reproduce that:
Hmm, perhaps it was my mistake. I tried different things before and also made the error to
assign first an empty list to a bundle and then a series to the bundle, which changed the
element from a list to a copy of the series... Then I reread the manual and found my
mistake. Might be that I should have put it from the list
> F) I have frequent crashes when using the button to move the
output
> window to the front.
That's serious, but not something that anyone has reported before.
This is on Windows? In English or in German? (Not that that should make a
difference.) 64-bit or 32-bit build? (This may make a
difference.) And you're talking about the little "two windows" button that
pops down a list of gretl windows?
Yes, the little two windows button. gretl version 2017e-git, 64bit english
But I cannot reproduce it at will... I guess it is not something that happens with normal
usage. I changed a lot in many scripts and rerun them and had very long output windows
(using debug 2). Also, as Sven mentioned, I had two instances open. I will keep an eye on
it and try to reproduce it, the next time and report back.
Frederik
1:58 p.m.
On Thu, 11 Jan 2018, Schaff, Frederik wrote:
>> F) I have frequent crashes when using the button to move the
output
>> window to the front.
>
> That's serious, but not something that anyone has reported before.
> This is on Windows? In English or in German? (Not that that should make a
> difference.) 64-bit or 32-bit build? (This may make a
> difference.) And you're talking about the little "two windows" button
that
> pops down a list of gretl windows?
Yes, the little two windows button. gretl version 2017e-git, 64bit english
But I cannot reproduce it at will... I guess it is not something
that happens with normal usage. I changed a lot in many scripts and
rerun them and had very long output windows (using debug 2). Also,
as Sven mentioned, I had two instances open. I will keep an eye on
it and try to reproduce it, the next time and report back.
Thanks. I wonder if you noticed: when this happens, does the crash
occur when you click the windows button, or when you select the
particular window to raise from the popup menu?
Anyway, in git and snapshots I've now modified the code that stands
behind that menu in a way that hopefully should make it safer. I can't
verify that this is an improvement, however, since I couldn't provoke
a crash with the old code.
Allin
11:09 a.m.
Am 10.01.2018 um 19:17 schrieb Schaff, Frederik:
>> b.Instead of "varname()" one needs to use
"argname()" to get the name
>> of a series (even when passed by pointer). This could be noted in the
>> gretl help
>
> You mean inside a function, and you want a cross-reference from the help
> for varname() to the help for argname()?
Yes.
This thread is becoming quite complex. Maybe you could enter a short
ticket (bug or feature request, doesn't matter much) for this on the
sourceforge tracker.
Yes, I am aware of it and used it, but it has the same problem. Btw.:
It is not documented that "strings" and "matrices" have the same type
reported as "array" (6)
An "array" in gretl can be 'bundles', 'strings',
'matrices', so this is
correct. One could debate whether this differentiation should be
conveyed, but of course you could always do typeof(myarray[1]) to get
that. (Provided it's not an empty array...)
I even have a bundle inside a bundle, so for checking if
"abndl.bbndl.cstring" exists, I need:
<hansl>
scalar isOK=0 #0==not ok
if exists(abndl)
if inbundle(abndl,bbndl)
isOK = inbundle(abndl.bbndl,cstring)
endif
endif
In principle I agree that some shortcircuiting possibility in the syntax
would be useful. OTOH I would appeal to you to keep it simple. Yes,
hansl has some limitations and is in terms of flexibility not comparable
to Python or some other languages. But typically if you avoid being "too
clever", there is always a straightforward solution, even if it comes at
the cost of some extra lines of code.
(For example, I love Python's short one-liner
"if thisistrue: justdothat"
but I can tolerate the required "endif" in hansl.)
cheers,
sven
2537
days inactive
2539
days old
8 comments
3 participants
participants (3)
-
Allin Cottrell -
Schaff, Frederik -
Sven Schreiber