On Sun, 17 Dec 2017, Summers, Peter wrote:
Hi all,
I was revisiting some code I wrote a few years ago, and came
across what is at least changed (and unexpected) behavior. I have
a script that loops over various numbers of possible structural
breaks, and does some MCMC sampling for each value. I want to
write the mcmc draws to separate data sets labeled by the number
of breaks.
Here's what I originally had:
<hansl>
loop ii=1..breaks --quiet
Nbreaks = ii-1
# do a bunch of stuff
loop draws = 1..ndraws -quiet -progressive
# Do MCMC stuff
rhohat = (draw from posterior)
# now save the draws
sprintf fname "rho_%d.gdt", nbreaks
store "@fname" rhohat
endloop
endloop
</hansl>
This worked fine for me when I wrote it. However currently with
the latest Windows snapshot, after the first time through the
loop, gretl stores successive data sets under the name
"(a)fname.gdt". The string is being updated properly, but not parsed
by the store command. If I insert the line
blah = "@fname"
between the sprintf and store commands, everything works fine.
I tried constructing the following test case (on the assumption that
the undefined identifier "nbreaks" was supposed to be the same as
the defined "Nbreaks":
<hansl>
set verbose off
nulldata 8
scalar breaks = 2
scalar ndraws = 3
loop ii=1..breaks --quiet
Nbreaks = ii-1
# do a bunch of stuff
loop draws = 1..ndraws --quiet --progressive
# Do MCMC stuff
scalar rhohat = draws
# now save the draws
sprintf fname "rho_%d.gdt", Nbreaks
store @fname rhohat
endloop
endloop
</hansl>
and I see what (I think) you mean!
If you use the function-form of sprintf; that is
fname = sprintf("rho_%d.gdt", Nbreaks)
in place of
sprintf fname "rho_%d.gdt", Nbreaks
It works OK; otherwise I see the error that you describe.
So, yes, this is a bug (associated with an old usage of "sprintf",
but a usage that supposedly still ought to work). I'll see what can
be done, but also I guess we should officially deprecate the
command-form of "sprintf" -- if we don't already do so.
Allin