2:58 p.m.
Hi all,
sorry to bring this up again, but there are a few things I don't understand:
1) If I set diffuse=2 and dejong=0, I expect the default method to be
sequential=1. Instead, into the filter bundle, I find:
/Kalman scalars:
t: 0
diffuse: 1 (not 2?)
exact: 0 (not 1?)
cross: 0
dkvar: 0
sequential: 0 (not 1?)/
If I set diffuse=2 and dejong=1, I find:
/Kalman scalars
t: 0
diffuse: 1 (not 2?)
exact: 0 (not 1?)
cross: 0
dkvar: 0
sequential: 0/
Moreover, if disturbances are not correlated (/cross=0/), settings
(diffuse=1, dejong=1) and (diffuse=2, dejong=1) produce same results as
well as (diffuse=1, dejong=0) and (diffuse=2, dejong=0) produce same
results.
On the other hand, if disturbances are correlated (/cross=1/),
(diffuse=2, dejong=1) provides better results (in terms of AIC, BIC,...)
than (diffuse=1, dejong=1).
However, in no case is diffuse=2 reported in the filter bundle!
Paolo
4:30 p.m.
Am 22.10.2025 um 16:58 schrieb Paolo Chirico:
Hi all,
sorry to bring this up again, but there are a few things I don't
understand:
1) If I set diffuse=2 and dejong=0, I expect the default method to be
sequential=1. Instead, into the filter bundle, I find:
I'm working under the
assumption that what you mean is that in your code
these settings are done after the ksetup() call, before any other call,
and that what you're showing us is the bundle content at the very end.
If this is not what you mean, you'd need to show us some of your actual
code.
/Kalman scalars:
t: 0
diffuse: 1 (not 2?)
/
confirmed
/ exact: 0 (not 1?)
/
cannot confirm, I see 1
/ cross: 0
dkvar: 0
sequential: 0 (not 1?)/
cannot confirm, I see 1
...
However, in no case is diffuse=2 reported in the filter bundle!
I'm not seeing a "dejong" bundle member in the end either, although it
was added at the beginning. (Where I took the script 36.4 from the user
guide as my playground.) It is not impossible that this might be some
bug, but I rather expect it to be a certain internal coding of the
initial choices. Someone else would have to comment on that. If that's
true, then the ex-post Kalman bundle does not appear to directly hold
the input choices.
cheers
sven
4:44 p.m.
On Wed, Oct 22, 2025 at 10:58 AM Paolo Chirico <paolo.chirico(a)uniupo.it>
wrote:
Hi all,
sorry to bring this up again, but there are a few things I don't
understand:
1) If I set diffuse=2 and dejong=0, I expect the default method to be
sequential=1. Instead, into the filter bundle, I find:
[something apparently different]
Thanks for the report, Paolo.
There's definitely something confusing here, which needs to be fixed.
However, in general things are done right. Here's the source of confusion:
the initial user input allows setting diffuse (to 0, 1 or 2) and either
sequential (to 0 or 1) or dejong (to 0 or 1). but internally such settings
get translated to three booleans: diffuse, exact and sequential. I'm
attaching a little script which illustrates how this goes.
I think the mismatch between user settings and the internals stemmed from a
desire to maintain backward compatibility, from before we had
implementations of the sequential and de Jong methods for handling diffuse
initialization exactly. But clearly we should come up with a less confusing
interface. I'll report back once that's in place.
(BTW, running the attached script shows little difference between the
diffuse variants, other than the first estimate of the predicted error
variance, pevar. That's not unexpected, although there could well be more
differences in a more complex state-space model, where it takes more
observations to resolve the initial "diffuseness".)
Allin Cottrell
8:29 a.m.
Allin, Sven,
thanks for your reply.
Perhaps the problem, in my case, is that the filter bundle (SVM) is
contained in a function bundle (Mod).
I did a test, i.e., I added some print commands:
SVM.diffuse=2
SVM.dejong=1
print SVM.diffuse
print SVM.exact
print SVM.sequential
The print result was correct:
1
1
0
Indeed, (exact=1 & sequential =0) => (dejong =1). So, I'm fairly
confident that the filter works according to the given settings.
However, after producing Mod, if I run:
Mod.print SVM.diffuse
Mod.print SVM.exact
Mod.print SVM.sequential
I get:
1
0
0
If other functions point to Mod and use the objects of SVM (my case),
this difference can be a problem!
Paolo
Il 22/10/2025 18:44, Cottrell, Allin ha scritto:
On Wed, Oct 22, 2025 at 10:58 AM Paolo Chirico
<paolo.chirico(a)uniupo.it> wrote:
>
> Hi all,
> sorry to bring this up again, but there are a few things I don't
understand:
> 1) If I set diffuse=2 and dejong=0, I expect the default method to
be sequential=1. Instead, into the filter bundle, I find:
[something apparently different]
Thanks for the report, Paolo.
There's definitely something confusing here, which needs to be fixed.
However, in general things are done right. Here's the source of
confusion: the initial user input allows setting diffuse (to 0, 1 or
2) and either sequential (to 0 or 1) or dejong (to 0 or 1). but
internally such settings get translated to three booleans: diffuse,
exact and sequential. I'm attaching a little script which illustrates
how this goes.
I think the mismatch between user settings and the internals stemmed
from a desire to maintain backward compatibility, from before we had
implementations of the sequential and de Jong methods for handling
diffuse initialization exactly. But clearly we should come up with a
less confusing interface. I'll report back once that's in place.
(BTW, running the attached script shows little difference between the
diffuse variants, other than the first estimate of the predicted error
variance, pevar. That's not unexpected, although there could well be
more differences in a more complex state-space model, where it takes
more observations to resolve the initial "diffuseness".)
Allin Cottrell
--
Paolo Chirico
RU e Prof.Agg. di Statistica Economica
Università del Piemonte Orientale
Dip. di Giurisprudenza e Scienze Politiche,
Economiche e Sociali (DIGSPES)
Alessandria, Italia
10:10 a.m.
New subject: Some strange result with the dejong setting. Problem finded!
I finally figured out where the problem was.
The original filter bundle (let's call it A) contains the correct
settings, but if this bundle is copied (for example, B=A), B fails to
copy everything because the "exact" member is not copyable and the
default value, 0, remains in B!
Greetings
Paolo
Il 22/10/2025 18:44, Cottrell, Allin ha scritto:
On Wed, Oct 22, 2025 at 10:58 AM Paolo Chirico
<paolo.chirico(a)uniupo.it> wrote:
>
> Hi all,
> sorry to bring this up again, but there are a few things I don't
understand:
> 1) If I set diffuse=2 and dejong=0, I expect the default method to
be sequential=1. Instead, into the filter bundle, I find:
[something apparently different]
Thanks for the report, Paolo.
There's definitely something confusing here, which needs to be fixed.
However, in general things are done right. Here's the source of
confusion: the initial user input allows setting diffuse (to 0, 1 or
2) and either sequential (to 0 or 1) or dejong (to 0 or 1). but
internally such settings get translated to three booleans: diffuse,
exact and sequential. I'm attaching a little script which illustrates
how this goes.
I think the mismatch between user settings and the internals stemmed
from a desire to maintain backward compatibility, from before we had
implementations of the sequential and de Jong methods for handling
diffuse initialization exactly. But clearly we should come up with a
less confusing interface. I'll report back once that's in place.
(BTW, running the attached script shows little difference between the
diffuse variants, other than the first estimate of the predicted error
variance, pevar. That's not unexpected, although there could well be
more differences in a more complex state-space model, where it takes
more observations to resolve the initial "diffuseness".)
Allin Cottrell
--
Paolo Chirico
RU e Prof.Agg. di Statistica Economica
Università del Piemonte Orientale
Dip. di Giurisprudenza e Scienze Politiche,
Economiche e Sociali (DIGSPES)
Alessandria, Italia
11:40 a.m.
New subject: Some strange result with the dejong setting. Problem finded!
On Thu, 23 Oct 2025, Paolo Chirico wrote:
I finally figured out where the problem was.
The original filter bundle (let's call it A) contains the correct settings,
but if this bundle is copied (for example, B=A), B fails to copy everything
because the "exact" member is not copyable and the default value, 0, remains
in B!
OK, so we need to ensure that our kalman functions do not mess with
the specifications initially passed in by the user via the diffuse,
sequential and dejong bundle members. We can "translate" them for
internal run-time use but should not modify them.
Allin
5:04 p.m.
New subject: Some strange result with the dejong setting. Problem finded!
On Thu, Oct 23, 2025 at 7:40 AM Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Thu, 23 Oct 2025, Paolo Chirico wrote:
> I finally figured out where the problem was.
> The original filter bundle (let's call it A) contains the correct
settings,
> but if this bundle is copied (for example, B=A), B fails to copy
everything
> because the "exact" member is not copyable and the default value, 0,
remains
> in B!
OK, so we need to ensure that our kalman functions do not mess with
the specifications initially passed in by the user via the diffuse,
sequential and dejong bundle members. We can "translate" them for
internal run-time use but should not modify them.
That's now fixed, I believe, in the current gretl snapshots. Specifically,
explicit settings by the user of "diffuse", "sequential" and/or
"dejong" in
a state-space model bundle should not be changed by execution of the
kfilter() function.
Allin
8
days inactive
10
days old
6 comments
4 participants
participants (4)
-
Allin Cottrell -
Cottrell, Allin
-
Paolo Chirico -
Sven Schreiber