8:26 p.m.
Hi,
hammering the release candidate on some special system cases some more:
Consider this first example:
<hansl>
open denmark
bundle b
list endo = diff(deflist(LRM, IBO))
list rhs1 = deflist(const, LRY)
list rhs2 = deflist(const, IBO(-1))
lists rhses = defarray(rhs1, rhs2)
list b.endo = endo
lists b.rhses = rhses
system
equations endo rhses # works
end system
system
equations b.endo b.rhses # "b.endo not found"
end system
</hansl>
I'm not sure if list(s) inside bundles are supposed to work in this
context or not.
(And BTW while we're at it, "equations" isn't recognized and
syntax-colored.)
--
Secondly, here's something with string substitution and a newline character:
<hansl>
open denmark
system
equation LRM 0 LRM(-1)
equation IBO 0 LRM IBO(-1)
end system
# standard way:
restrict $system
b[1,2] = 0
b[2,1] = 0
end restrict
estimate $system method=ols
# now with string substitution:
string rs = sprintf("b[1,2] = 0 \n b[2,1] = 0")
print rs # looks good, with line break
restrict $system
@rs # error: undefined symbol b
end restrict
</hansl>
Note that this whole thing with string substitution works fine when
there's only a single restriction, no \n character in the string!
This example probably looks a bit artificial, but the use case is to
process stuff like that programmatically inside a function.
thanks
sven
9:18 p.m.
On Fri, 8 Jan 2021, Sven Schreiber wrote:
hammering the release candidate on some special system cases some
more:
Consider this first example:
<hansl>
open denmark
bundle b
list endo = diff(deflist(LRM, IBO))
list rhs1 = deflist(const, LRY)
list rhs2 = deflist(const, IBO(-1))
lists rhses = defarray(rhs1, rhs2)
list b.endo = endo
lists b.rhses = rhses
system
equations endo rhses # works
end system
system
equations b.endo b.rhses # "b.endo not found"
end system
</hansl>
I'm not sure if list(s) inside bundles are supposed to work in this
context or not.
They're not. That could be added but it's not in-spec at present.
(And BTW while we're at it, "equations" isn't
recognized and
syntax-colored.)
OK, registered.
Secondly, here's something with string substitution and a newline
character:
<hansl>
open denmark
system
equation LRM 0 LRM(-1)
equation IBO 0 LRM IBO(-1)
end system
# standard way:
restrict $system
b[1,2] = 0
b[2,1] = 0
end restrict
estimate $system method=ols
# now with string substitution:
string rs = sprintf("b[1,2] = 0 \n b[2,1] = 0")
print rs # looks good, with line break
restrict $system
@rs # error: undefined symbol b
end restrict
</hansl>
hansl input has already been carved into lines by the time string
substitution comes along, so this is not going to work. Try this
instead:
<hansl>
Rmat = {0,1,0,0,0;0,0,1,0,0}
qvec = {0;0}
restrict $system
R = Rmat
q = qvec
end restrict
</hansl>
Allin
2:44 p.m.
Am 08.01.2021 um 22:18 schrieb Allin Cottrell:
On Fri, 8 Jan 2021, Sven Schreiber wrote:
> I'm not sure if list(s) inside bundles are supposed to work
in this
> context or not.
They're not. That could be added but it's not in-spec at present.
OK, noted.
> restrict $system
> @rs # error: undefined symbol b
> end restrict
> </hansl>
hansl input has already been carved into lines by the time string
substitution comes along, so this is not going to work. Try this
instead:
<hansl>
Rmat = {0,1,0,0,0;0,0,1,0,0}
qvec = {0;0}
restrict $system
R = Rmat
q = qvec
end restrict
</hansl>
Yeah, well, I knew that, but was somehow hoping to simply relay the
standard restriction specification syntax.
Perhaps I can come up with a function that translates human-readable
system restrictions into that format...
thanks
sven
3:44 p.m.
On Sat, 9 Jan 2021, Sven Schreiber wrote:
Am 08.01.2021 um 22:18 schrieb Allin Cottrell:
>> restrict $system
>> @rs # error: undefined symbol b
>> end restrict
>> </hansl>
>
> hansl input has already been carved into lines by the time string
> substitution comes along, so this is not going to work. Try this
> instead:
>
> <hansl>
> Rmat = {0,1,0,0,0;0,0,1,0,0}
> qvec = {0;0}
> restrict $system
> R = Rmat
> q = qvec
> end restrict
> </hansl>
Yeah, well, I knew that, but was somehow hoping to simply relay the
standard restriction specification syntax.
Perhaps I can come up with a function that translates human-readable
system restrictions into that format...
That's precisely what "restrict" does. Rather than hacking up a way
to send a multi-line string to restrict via string-substitution, I
suppose we could support an array of strings variant, something
like:
strings R = defarray("b[1,2] = 0", "b[2,1] = 0")
restrict $system
strings R
end restrict
with the keyword "strings" guiding gretl's interpretation.
Allin
9:14 p.m.
Am 09.01.2021 um 16:44 schrieb Allin Cottrell:
On Sat, 9 Jan 2021, Sven Schreiber wrote:
> Yeah, well, I knew that, but was somehow hoping to simply relay
the
> standard restriction specification syntax.
>
> Perhaps I can come up with a function that translates human-readable
> system restrictions into that format...
That's precisely what "restrict" does. Rather than hacking up a way to
send a multi-line string to restrict via string-substitution, I suppose
we could support an array of strings variant, something like:
strings R = defarray("b[1,2] = 0", "b[2,1] = 0")
restrict $system
strings R
end restrict
with the keyword "strings" guiding gretl's interpretation.
Ah, that would be nice of course. I was also thinking if perhaps in some
situations some other character (combination) could signify a separation
of command lines. Obviously the usual character in many languages would
be ";", but in gretl/hansl that would probably be too ambiguous. Perhaps
a double ";;"?
So what I mean in this context would be to write something like:
restrict $system
b[1,2] = 0 ;; b[2,1] = 0
end restrict
cheers
sven
5:09 p.m.
Am 09.01.2021 um 22:14 schrieb Sven Schreiber:
Am 09.01.2021 um 16:44 schrieb Allin Cottrell:
> we could support an array of strings variant, something like:
>
> strings R = defarray("b[1,2] = 0", "b[2,1] = 0")
> restrict $system
> strings R
> end restrict
>
> with the keyword "strings" guiding gretl's interpretation.
[Not the main point of this reply, but: wouldn't it be a problem that
normally "strings" is an alias for "genr", but here it's not? Of
course
the context resolves this, but still.]
Ah, that would be nice of course. I was also thinking ...
Here's another approach to helping a little to construct restrictions in
systems. The idea is that it's fairly difficult for the user to know
what variable position indices to put into the restriction syntax,
because in the system context using the identifiers of the variables is
not supported. So my idea is that you can use the names of the LHS and
the RHS variables (plus a lag number) in a natural way, and you get back
the two position numbers you need if you want to restrict the coefficent.
The relevant helper functions are in the attached file, and below are
some tested examples. Note that the helper function amend_sysbdl needs
to be run before the actually interesting call. (But only once per system.)
cheers
sven
<hansl>
include redsys-helpers.inp
open denmark
## example with var
list endo = diff(LRM LRY IBO)
var 2 endo -q
bundle bv = $system
amend_sysbdl(&bv, endo)
# the relevant interface line:
eval eqnvarindices(bv, "d_LRY", "d_LRM", 2)
## example with system
endo = LRM IBO
lags 3 ; endo
lists RHS = defarray( deflist(const, LRM_2), deflist(const,LRM,IBO_3) )
system method=ols
equations endo RHS
end system -q
bundle bsys = $system
amend_sysbdl(&bsys, endo,RHS)
# again the relevant interface line:
eval eqnvarindices(bsys, "LRM", "LRM", 2)
# and some wrong input yielding an error:
eval eqnvarindices(bsys, "LRM", "LRM", 3)
</hansl>
2:28 p.m.
On Sun, 10 Jan 2021, Sven Schreiber wrote:
Am 09.01.2021 um 22:14 schrieb Sven Schreiber:
> Am 09.01.2021 um 16:44 schrieb Allin Cottrell:
>> we could support an array of strings variant, something like:
>>
>> strings R = defarray("b[1,2] = 0", "b[2,1] = 0")
>> restrict $system
>> strings R
>> end restrict
>>
>> with the keyword "strings" guiding gretl's interpretation.
[Not the main point of this reply, but: wouldn't it be a problem that
normally "strings" is an alias for "genr", but here it's not? Of
course
the context resolves this, but still.]
Yes, "strings" may not be the best keyword for that context. We
already have "Rvec" so we could use "Rstrings". But if we think this
approach might be helpful for programmatic handling of other
block-commands then a more generic keyword would be wanted, maybe
"cmdstrings" or similar.
BTW this facility (with keyword "strings", and for "restrict" only)
is now in git. (I'm confident it's a harmless experiment.)
Here's another approach to helping a little to construct
restrictions in
systems. The idea is that it's fairly difficult for the user to know
what variable position indices to put into the restriction syntax,
because in the system context using the identifiers of the variables is
not supported. So my idea is that you can use the names of the LHS and
the RHS variables (plus a lag number) in a natural way, and you get back
the two position numbers you need if you want to restrict the coefficent.
The relevant helper functions are in the attached file, and below are
some tested examples. [...]
OK, that's worth exploring.
Allin
2:52 p.m.
Am 11.01.2021 um 15:28 schrieb Allin Cottrell:
On Sun, 10 Jan 2021, Sven Schreiber wrote:
> Am 09.01.2021 um 22:14 schrieb Sven Schreiber:
>> Am 09.01.2021 um 16:44 schrieb Allin Cottrell:
>
>>> we could support an array of strings variant, something like:
>>>
>>> strings R = defarray("b[1,2] = 0", "b[2,1] = 0")
>>> restrict $system
>>> strings R
>>> end restrict
>>>
>>> with the keyword "strings" guiding gretl's interpretation.
>
> [Not the main point of this reply, but: wouldn't it be a problem that
> normally "strings" is an alias for "genr", but here it's not?
Of course
> the context resolves this, but still.]
Yes, "strings" may not be the best keyword for that context. We already
have "Rvec" so we could use "Rstrings". But if we think this
approach
might be helpful for programmatic handling of other block-commands then
a more generic keyword would be wanted, maybe "cmdstrings" or similar.
I guess you mean Rmat and qvec, or isn't it actually just R and q?
Anyway, I like "lines" because it's all about passing several lines in a
different format.
BTW this facility (with keyword "strings", and for
"restrict" only) is
now in git. (I'm confident it's a harmless experiment.)
OK, let's try it.
thanks
sven
8:09 p.m.
Am 11.01.2021 um 15:52 schrieb Sven Schreiber:
Am 11.01.2021 um 15:28 schrieb Allin Cottrell:
>
> Yes, "strings" may not be the best keyword for that context. We already
> have "Rvec" so we could use "Rstrings". But if we think this
approach
> might be helpful for programmatic handling of other block-commands then
> a more generic keyword would be wanted, maybe "cmdstrings" or similar.
I guess you mean Rmat and qvec, or isn't it actually just R and q?
Anyway, I like "lines" because it's all about passing several lines in a
different format.
Or maybe simply a new option for the restrict block, like --strings ?
cheers
sven
7:28 p.m.
Am 11.01.2021 um 15:52 schrieb Sven Schreiber:
Am 11.01.2021 um 15:28 schrieb Allin Cottrell:
> On Sun, 10 Jan 2021, Sven Schreiber wrote:
>>>> restrict $system
>>>> strings R
>>>> end restrict
>
> Yes, "strings" may not be the best keyword for that context. We already
> have "Rvec" so we could use "Rstrings". But if we think this
approach
> might be helpful for programmatic handling of other block-commands then
> a more generic keyword would be wanted, maybe "cmdstrings" or similar.
Anyway, I like "lines" because it's all about passing several lines in a
different format.
> BTW this facility (with keyword "strings", and for "restrict"
only) is
> now in git. (I'm confident it's a harmless experiment.)
OK, let's try it.
I have now tested it in an automated context and it appears to be
working nicely. As I'm working on a function package with this feature,
it would be useful if the naming/syntax could be fixed relatively soon.
I agree that choosing something that could be reused in blocks in the
future would be good. (cmdstrings, lines, ...)
thanks
sven
1183
days inactive
1197
days old
9 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber