10:01 a.m.
Hi,
instead of creating an interim list variable I wanted to use the
returned list from a function directly for further operations, but that
failed:
<hansl>
function list checkl(void)
genr time
list out = const time
return out
end function
matrix v = zeros(2,1)
list foo = checkl()
series hey1 = lincomb(foo, v) # works
print hey1
series hey2 = lincomb(checkl(), v) # doesn't work
print hey2
</hansl>
I would think that's a bug.
thanks,
sven
11:58 a.m.
On Fri, 19 Jun 2015, Sven Schreiber wrote:
instead of creating an interim list variable I wanted to use the
returned list from a function directly for further operations, but that
failed:
<hansl>
function list checkl(void)
genr time
list out = const time
return out
end function
matrix v = zeros(2,1)
list foo = checkl()
series hey1 = lincomb(foo, v) # works
print hey1
series hey2 = lincomb(checkl(), v) # doesn't work
print hey2
</hansl>
I would think that's a bug.
I agree. On examining the relevant code (the function eval_ufunc(), in
the source file geneval.c) I found an if-condition with a comment
dated 2015-02-02 which reads:
"collect" the return value [from a user-defined function that
returns a list] only on direct assignment
It's easy enough to remove that condition (which then makes your
example work), but I need to try to remember what prompted me to
insert it in the first place -- I presume it was in response to some
other bug. (Note to self: write more explicit comments!)
Allin
2:17 p.m.
On Fri, 19 Jun 2015, Allin Cottrell wrote:
On Fri, 19 Jun 2015, Sven Schreiber wrote:
> instead of creating an interim list variable I wanted to use the
> returned list from a function directly for further operations, but that
> failed:
>
> <hansl>
> function list checkl(void)
> genr time
> list out = const time
> return out
> end function
>
> matrix v = zeros(2,1)
>
> list foo = checkl()
> series hey1 = lincomb(foo, v) # works
> print hey1
>
> series hey2 = lincomb(checkl(), v) # doesn't work
> print hey2
> </hansl>
>
> I would think that's a bug.
I agree. On examining the relevant code (the function eval_ufunc(), in the
source file geneval.c) I found an if-condition with a comment dated
2015-02-02 which reads:
"collect" the return value [from a user-defined function that returns a list]
only on direct assignment
It's easy enough to remove that condition (which then makes your example
work), but I need to try to remember what prompted me to insert it in the
first place -- I presume it was in response to some other bug. (Note to self:
write more explicit comments!)
OK, I've reconstructed the rationale that I had in mind back in
February. This is a tricky issue. Consider Sven's function once again:
function list checkl (void)
genr time
list out = const time
return out
end function
Now I call checkl() without assigning the return value to anything:
<hansl>
nulldata 10
matrix v = {2,1}
series hey2 = lincomb(checkl(), v)
varlist
</hansl>
Should the "time" variable, which is added to the dataset and included
in the "out" list returned by checkl(), be present in the "main"
dataset after the function call?
I'd be inclined to say No, but that is the consequence of "collecting"
or "accepting" the returned list, even though it's not assigned to
anything. A list is a set of references to series, and it's broken if
those series don't exist. The lincomb() call can work only if "time"
is a member of the caller's dataset -- qua member of an anonymous list
-- but then the two function calls have the potentially problematic
side-effect of adding a series to the caller's dataset without any
explicit authorization.
I don't see any easy way around this, but I'm open to suggestions.
Allin
2:42 p.m.
On Fri, 19 Jun 2015, Allin Cottrell wrote:
I don't see any easy way around this, but I'm open to
suggestions.
I don't have a solution, but I'd like to contribute to the discussion with
a reflection. Everybody loves lists. They're so convenient. However, they
have this feudal privilege (that no other gretl citizen has) of being
somewhat exempt from the principle of strict localisation. This can be
VERY troublesom, at times. Consider this, for example.
<hansl>
function list moo(void)
series you_would_think_this_is_safe = NA
list ret = you_would_think_this_is_safe
return ret
end function
# --- main -----------------------------
nulldata 10
# your precious data
you_would_think_this_is_safe = normal()
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
I don't know about you, but I find this slightly disturbing.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:05 p.m.
Am 19.06.2015 um 20:42 schrieb Riccardo (Jack) Lucchetti:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> I don't see any easy way around this, but I'm open to suggestions.
Well it was a design decision long ago, right? I could come up with
various suggestions (mostly involving namespaces I guess, which
essentially would feel very much like turning the list concept into a
bundle of series, which would be much cleaner), but currently I tend to
think that that's simply the way it is. (The side effect on the outer
scope, I mean.)
I don't have a solution, but I'd like to contribute to the discussion
with a reflection. Everybody loves lists. They're so convenient.
However, they have this feudal privilege (that no other gretl citizen
has) of being somewhat exempt from the principle of strict localisation.
This can be VERY troublesom, at times.
Yes you can come up with disturbing examples, but again, that's nothing
new. It reminds me like Numpy is passing arguments by reference (what we
call pointers basically, instead of copying the data) by default for
performance reasons; if you're not aware of that you get strange effects
on your outer scope, and you simply have to know it. Same here I think.
For a while now I have been quite "ambivalent" about lists. Actually,
the reason I used them now was only that the "mle" block seemed to
insist on defining the likelihoods as a series instead of a matrix (is
that actually correct?).
thanks,
sven
3:41 p.m.
On Fri, 19 Jun 2015, Sven Schreiber wrote:
> I don't have a solution, but I'd like to contribute to
the discussion
> with a reflection. Everybody loves lists. They're so convenient.
> However, they have this feudal privilege (that no other gretl citizen
> has) of being somewhat exempt from the principle of strict localisation.
> This can be VERY troublesom, at times.
Yes you can come up with disturbing examples, but again, that's nothing
new.
I beg to differ. It is quite exceptional, since it violates the idea (that
we try to enforce in hansl as a general principle) that user-written
function must be very predictable in what they modify. This is precisely
why we never allowed global variables. This is precisely why I find the
example disturbing.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:09 p.m.
On Fri, 19 Jun 2015, Riccardo (Jack) Lucchetti wrote:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> I don't see any easy way around this, but I'm open to suggestions.
I don't have a solution, but I'd like to contribute to the discussion with a
reflection. Everybody loves lists. They're so convenient. However, they have
this feudal privilege (that no other gretl citizen has) of being somewhat
exempt from the principle of strict localisation. This can be VERY
troublesom, at times. Consider this, for example.
<hansl>
function list moo(void)
series you_would_think_this_is_safe = NA
list ret = you_would_think_this_is_safe
return ret
end function
# --- main -----------------------------
nulldata 10
# your precious data
you_would_think_this_is_safe = normal()
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
I don't know about you, but I find this slightly disturbing.
But the data are _not_ gone, or not after the change I made in
February of this year. If you don't assign the return value of moo(),
nothing changes in the caller's dataset. Or are you seeing something
different?
There are some built-in gretl functions that return lists. These have
the potential of overwriting data series previously created by the
user, but (I think) they are quite explicit regarding the names of the
series they create and return. Caveat emptor. I wouldn't necessarily
trust a contributed function that returned a list unless I knew the
author well.
IMO that's not a reason to stop using lists. But I think it _is_ a
reason to resist Sven's suggestion that the error resulting from
giving an anonymous, on-the-fly, function-returned list as a function
argument is a gretl bug. I thought it was a bug, at face value, but
now I don't think so; I believe it's a defensible safeguard. However,
the resulting error message should be clearer.
Allin
4:32 p.m.
Am 19.06.2015 um 22:09 schrieb Allin Cottrell:
But the data are _not_ gone, or not after the change I made in February
of this year. If you don't assign the return value of moo(), nothing
changes in the caller's dataset.
I don't really understand why the behavior should so crucially depend on
whether there is an explicit assignment to a new list object or not.
Because it's the list _members_ (or their names) that produce the side
effects, not the new list name itself. So if I do:
list newlist = some_list_returning_function()
and one of the list members is called 'cool' and I happened to have a
series 'cool' already in my dataset, then it is overwritten. How am I
supposed to know what the function uses for the names of returned list
members?
AFAICS this has always been a problem with using lists. Exceptional, as
Jack said, yes; but not new. Or am I too tired and missing something?
So I don't see this February change as a solution.
IMO that's not a reason to stop using lists. But I think it _is_ a
reason to resist Sven's suggestion that the error resulting from giving
an anonymous, on-the-fly, function-returned list as a function argument
is a gretl bug. I thought it was a bug, at face value, but now I don't
think so; I believe it's a defensible safeguard. However, the resulting
error message should be clearer.
Better error message, yes absolutely. But see above, how is the explicit
assignment requirement really a safeguard? I'm puzzled.
thanks,
sven
6:44 p.m.
On Fri, 19 Jun 2015, Sven Schreiber wrote:
Am 19.06.2015 um 22:09 schrieb Allin Cottrell:
>
> But the data are _not_ gone, or not after the change I made in February
> of this year. If you don't assign the return value of moo(), nothing
> changes in the caller's dataset.
I don't really understand why the behavior should so crucially depend on
whether there is an explicit assignment to a new list object or not.
Because it's the list _members_ (or their names) that produce the side
effects, not the new list name itself. So if I do:
list newlist = some_list_returning_function()
and one of the list members is called 'cool' and I happened to have a
series 'cool' already in my dataset, then it is overwritten. How am I
supposed to know what the function uses for the names of returned list
members?
AFAICS this has always been a problem with using lists. Exceptional, as
Jack said, yes; but not new. Or am I too tired and missing something?
So I don't see this February change as a solution.
>
> IMO that's not a reason to stop using lists. But I think it _is_ a
> reason to resist Sven's suggestion that the error resulting from giving
> an anonymous, on-the-fly, function-returned list as a function argument
> is a gretl bug. I thought it was a bug, at face value, but now I don't
> think so; I believe it's a defensible safeguard. However, the resulting
> error message should be clearer.
Better error message, yes absolutely. But see above, how is the explicit
assignment requirement really a safeguard? I'm puzzled.
OK, let me try to explain -- this is not particularly obvious unless
you have pored over the internals of gretl lists at length, as I have.
1) We have some built-in functions that return lists. For example,
log() and dummify(). Hopefully, it is clear that these functions may
add several series to the caller's dataset, and the documentation for
these functions should make clear what names the added series will
bear. If you use one of these functions and are surprised by the
results (e.g. "How come my pre-existing series l_x got overwritten?"
when calling log()), you just haven't bothered to read the doc for the
function you're calling.
2) If and when a contributed function package returns a list, it
should be just as explicit as the built-in functions with regard to
the character and naming of the series members of the returned list.
Again, there should be no surprises for anyone who has read the doc. I
would regard violation of this principle as sufficient reason to
reject a function package.
Now, please note that the function calls I have in mind in relation to
1) and 2) above would typically look like:
list Lx = log(x) # built-in
list Dx = dummify(x) # built-in
list Fx = fooify(x) # notional contributed function
But there are two other possible cases:
(i) A plain, unassigned call to a function, as in
fooify(x)
and (ii), a function call to create an anonymous argument for a
further function, as in
y = somefun(fooify(x))
where we suppose that fooify() returns a list.
Case (i) is (I would say) artificial, but case (ii) is an instance of
the sort of thing you noted in the post that started this thread. In
both cases, what I'm concerned about is the possible side-effect.
Here's the fork: such calls either (a) do nothing, or (b) they
(potentially) add series to the caller's dataset unbidden. If they do
nothing, then case (ii) fails, which is the "bug" you raised. But
otherwise they must add series to the main dataset _even though the
user has not called for any such thing_. That is, the user has neither
assigned the return value from the function, nor has he/she poked in a
"pointer"-type argument which could cause changes in a variable at the
caller level.
In my opinion a hansl function should never produce any changes in the
caller's data other than via assignment of a return value or
modification of an argument given in pointer form ("commands" are a
different matter). It's a somewhat unfortunate (but, I think,
unavoidable) consequence of this that you can't call a function to
create an on-the-fly, anonymous list to serve as an argument to
another function.
Allin
3:50 a.m.
On Fri, 19 Jun 2015, Allin Cottrell wrote:
But the data are _not_ gone, or not after the change I made in
February of
this year. If you don't assign the return value of moo(), nothing changes in
the caller's dataset. Or are you seeing something different?
Well, yes. If you run the code below (slight modification of the
previous version),
<hansl>
function list moo(void)
series you_would_think_this_is_safe = NA
list ret = you_would_think_this_is_safe
return ret
end function
# --- main -----------------------------
nulldata 10
# your precious data
you_would_think_this_is_safe = normal()
# your precious data
print you_would_think_this_is_safe
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
then here's what you get:
<output>
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 10)
2.43453 0.131361 -0.220725 -1.66478 0.692591 0.933474 0.830973
0.407995 -0.102742 -0.500323
# apparently harmless function call
? moo()
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 0)
NA NA NA NA NA NA NA NA
NA NA
# data are gone!
</output>
2) If and when a contributed function package returns a list, it
should be
just as explicit as the built-in functions with regard to the character and
naming of the series members of the returned list. Again, there should be no
surprises for anyone who has read the doc. I would regard violation of this
principle as sufficient reason to reject a function package.
This. This is, IMO, the heart of the matter.
In my opinion a hansl function should never produce any changes in
the
caller's data other than via assignment of a return value or modification of
an argument given in pointer form ("commands" are a different matter). It's
a
somewhat unfortunate (but, I think, unavoidable) consequence of this that you
can't call a function to create an on-the-fly, anonymous list to serve as an
argument to another function.
Or to put my previous argument into different words: this is the price
that list-producing function have to pay for having the special privilege
of being able to modify certain objects without an explicit assignment
operation or the usage of a pointerised argument. Caveat emptor.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:01 a.m.
On Sat, 20 Jun 2015, Riccardo (Jack) Lucchetti wrote:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> But the data are _not_ gone, or not after the change I made in February of
> this year. If you don't assign the return value of moo(), nothing changes
> in the caller's dataset. Or are you seeing something different?
Well, yes. If you run the code below (slight modification of the previous
version),
<hansl>
function list moo(void)
series you_would_think_this_is_safe = NA
list ret = you_would_think_this_is_safe
return ret
end function
# --- main -----------------------------
nulldata 10
# your precious data
you_would_think_this_is_safe = normal()
# your precious data
print you_would_think_this_is_safe
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
then here's what you get:
<output>
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 10)
2.43453 0.131361 -0.220725 -1.66478 0.692591 0.933474 0.830973
0.407995 -0.102742 -0.500323
# apparently harmless function call
? moo()
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 0)
NA NA NA NA NA NA NA NA
NA NA
# data are gone!
</output>
There was a fleeting moment in yesterday's CVS (rev 1.986 of
geneval.c) when that would happen -- when I inadvertently committed an
experimental reversal of my change of February 2015.
But the data will not disappear with current CVS, where my February
change is reinstated (with a better comment). Since the return value
offered by moo() is not assigned to anything, the function-call has no
lasting effect.
Allin
5:13 a.m.
On Sat, 20 Jun 2015, Allin Cottrell wrote:
There was a fleeting moment in yesterday's CVS (rev 1.986 of
geneval.c) when
that would happen -- when I inadvertently committed an experimental reversal
of my change of February 2015.
But the data will not disappear with current CVS, where my February change is
reinstated (with a better comment). Since the return value offered by moo()
is not assigned to anything, the function-call has no lasting effect.
Ah, ok then. Sorry for the noise!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
12:49 p.m.
Am 20.06.2015 um 09:50 schrieb Riccardo (Jack) Lucchetti:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> 2) If and when a contributed function package returns a list, it
> should be just as explicit as the built-in functions with regard to
> the character and naming of the series members of the returned list.
> Again, there should be no surprises for anyone who has read the doc. I
> would regard violation of this principle as sufficient reason to
> reject a function package.
This. This is, IMO, the heart of the matter.
I don't think this is the heart of the current discussion, because there
is no disagreement with respect to "mean" functions that secretly aim to
overwrite your data.
We agree that in principle there should be encapsulation -- but we also
agree/know that gretl's design purposefully doesn't really do this when
it comes to lists.
My main point (and I will formulate it a little bluntly, to get the
point across): Your "safeguard" does not ensure encapsulation, either.
As we know, the assigned name of the returned list has nothing to do
with the names of the member series. So when a user ignores the
function's documentation, dataloss can occur in any case, with explicit
assignment or without. Therefore the "safeguard" argument is not valid
to justify your change. Instead your Feb 2015 change is an ad-hoc
special-casing that makes it harder to program in hansl.
Things would be somewhat different if you had proposed the following
change: Always prepend names of list members that are returned in a
function with the name of the list. Example:
<hansl_imaginary>
function list f1(void)
series a = 0
series b = 1
list outlist = a b
end function
list mylist = f1(void)
# new series in dataset: mylist_a and mylist_b
</hansl_imaginary>
This would not be 100% clean encapsulation, either, because by
coincidence I could have had a series mylist_a already. But under this
new rule it would be really the caller's fault to use "mylist" for the
list assignment when already there are series names starting with that
string in the dataset. The caller even wouldn't have to read the doc of
the function.
Quite obviously this idea is inspired by namespaces, which "are one
honking great idea -- let's do more of those!"
(https://www.python.org/dev/peps/pep-0020/)
Or to put my previous argument into different words: this is the price
that list-producing function have to pay for having the special privilege
of being able to modify certain objects without an explicit assignment
As I said above, I think this "explicit assignment" argument is beside
the point, because the individual series within the list are _never_
explicitly assigned under any circumstance, currently.
I'm not opposed to paying a price, but the current state of affairs pays
a price but doesn't really solve the issue.
thanks,
sven
4:53 a.m.
On Sat, 20 Jun 2015, Sven Schreiber wrote:
Am 20.06.2015 um 09:50 schrieb Riccardo (Jack) Lucchetti:
> On Fri, 19 Jun 2015, Allin Cottrell wrote:
>
>> 2) If and when a contributed function package returns a list, it
>> should be just as explicit as the built-in functions with regard to
>> the character and naming of the series members of the returned list.
>> Again, there should be no surprises for anyone who has read the doc. I
>> would regard violation of this principle as sufficient reason to
>> reject a function package.
>
> This. This is, IMO, the heart of the matter.
I don't think this is the heart of the current discussion, because there
is no disagreement with respect to "mean" functions that secretly aim to
overwrite your data.
We agree that in principle there should be encapsulation -- but we also
agree/know that gretl's design purposefully doesn't really do this when
it comes to lists.
My main point (and I will formulate it a little bluntly, to get the
point across): Your "safeguard" does not ensure encapsulation, either.
As we know, the assigned name of the returned list has nothing to do
with the names of the member series. So when a user ignores the
function's documentation, dataloss can occur in any case, with explicit
assignment or without. Therefore the "safeguard" argument is not valid
to justify your change. Instead your Feb 2015 change is an ad-hoc
special-casing that makes it harder to program in hansl.
Sven, you're misunderstanding how "returning a list" works in hansl.
Qualification: what I have to say here in the first instance relates
to user-defined functions; I'll come back to built-in functions at the
end.
Just to be clear, a function that returns a list doesn't necessarily
create or return any new series. We could imagine a function that
takes a list argument and returns a list holding (say) all and only
those series in the input list that are strictly positive. However,
we're talking here about the (presumably more common) case where a
function returns a list that contains one or more newly created
series.
Now, note that a function can create any series the author likes, but
in general such series will not "make it" back to the caller level.
Rather, they will be destroyed when the function exits. The exceptions
are (a) if the function returns a series or (b) if it returns a list
containing newly defined series and the caller assigns the return
value. If a function offers a list return and it is _not_ assigned by
the caller, then all series defined within the function are discarded
on exit, so there can be no series-name collision.
This is the effect of the change I made in February. Before then, the
series included in a list return were shifted to caller level even if
the list was not assigned to anything. Under the new scheme, the list
(array of integer series IDs) created at function level cannot itself
be passed back to the caller as an anonymous object (when not
assigned) because it will be broken: the series it references will in
general not exist any more since they haven't been "accepted" by the
caller.
At present our built-in data-transformation functions are not subject
to the same constraint. If you do, for example,
<hansl>
list X = <whatever>
log(X)
</hansl>
then despite the non-assignment of the return value of log(), the logs
of the members of X will be added to the dataset. Obviously there's a
case for saying this is inconsistent behavior, but I think it's
defensible. I won't get into that right now; I want to think about it
some more first.
Allin
8:43 a.m.
Am 21.06.2015 um 10:53 schrieb Allin Cottrell:
Sven, you're misunderstanding how "returning a list" works in hansl.
No I don't, everything you explain was actually how I already thought
things worked.
series in the input list that are strictly positive. However,
we're
talking here about the (presumably more common) case where a function
returns a list that contains one or more newly created series.
yes
... and the caller assigns the return value.
Part of my point is that there is no "the" (=one and only) return value
when we talk about lists. There is the name of the list and that is
assigned. Then there are names of the list members, and those *cannot*
be assigned (=renamed) under hansl's design.
I feel like I'm repeating "look at the return value of the names of the
list members" and keep getting the reply "check out the return value of
the list name itself", but those are completely independent under
current hansl design.
function offers a list return and it is _not_ assigned by the
caller,
then all series defined within the function are discarded on exit, so
there can be no series-name collision.
I understand that. But there still *can* be series-name collision if the
caller assigns a new list name.
What you're effectively saying is:
1) If the caller assigns a new list name it's all her fault if something
goes wrong. (I'm actually fine with this, though we can --and have--
talked about design changes that would improve the situation.)
2) But a caller who calls the function anonymously somehow cannot be
expected to act responsibly and thus deserves special care.
I fail to see the logic of the combined assumptions behind 1&2.
At present our built-in data-transformation functions are not subject
to
the same constraint. If you do, for example,
<hansl>
list X = <whatever>
log(X)
</hansl>
then despite the non-assignment of the return value of log(), the logs
of the members of X will be added to the dataset. Obviously there's a
case for saying this is inconsistent behavior, but I think it's
defensible. I won't get into that right now;
I agree, this is certainly not the problematic case. IMO it's the
special treatment of non-assigned contributed functions above.
thanks,
sven
8:29 a.m.
El 21/06/15 a las 14:43, Sven Schreiber escribió:
> ... and the caller assigns the return value.
Part of my point is that there is no "the" (=one and only) return value
when we talk about lists. There is the name of the list and that is
assigned. Then there are names of the list members, and those *cannot*
be assigned (=renamed) under hansl's design.
Umm I don't know whether I am understanding you, and I hate to talk
about my Holt-Winters package again, but I think its is an example of
what are you saying.
It takes a series as a paramenter (reskwh from data9-3.gdt in the
example) and optionally, if you assign a name to the list, it produces
the list with two series reskwh_H and reskwh_W. Obviously they are being
renamed for every series you apply the package on so they can be
rebnamed under hansl's design.
I feel like I'm repeating "look at the return value of the names of the
list members" and keep getting the reply "check out the return value of
the list name itself", but those are completely independent under
current hansl design.
> function offers a list return and it is _not_ assigned by the caller,
> then all series defined within the function are discarded on exit, so
> there can be no series-name collision.
I understand that. But there still *can* be series-name collision if the
caller assigns a new list name.
Of course, if you call the function twice over the same series and
assign a name (may be different) for the generated list, the previous
series are overwritten.
I don't think it is a problem. In some sense I think it is a good
feature, for example if you want to repeat the analysis in different
conditions.
The problem that may occur of overwritting some important previous
series should be resolved by the package programmer who should select
the names for the generated series carefully.
I think in general is good to have a way of generating new series that
in some way may have names derived from an existing one, such as reskwh,
reskwh_H and reskwh_W, I don't think it is a good idea that the series
have prepended the name of the list.
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
9:09 a.m.
Am 22.06.2015 um 14:29 schrieb Ignacio Diaz-Emparanza:
El 21/06/15 a las 14:43, Sven Schreiber escribió:
>> ... and the caller assigns the return value.
> Part of my point is that there is no "the" (=one and only) return value
> when we talk about lists. There is the name of the list and that is
> assigned. Then there are names of the list members, and those *cannot*
> be assigned (=renamed) under hansl's design.
Umm I don't know whether I am understanding you, and I hate to talk
about my Holt-Winters package again, but I think its is an example of
what are you saying.
Yes indeed!
It takes a series as a paramenter (reskwh from data9-3.gdt in the
example) and optionally, if you assign a name to the list, it produces
the list with two series reskwh_H and reskwh_W. Obviously they are being
renamed for every series you apply the package on so they can be
rebnamed under hansl's design.
No, "renaming" in this context would mean that as a caller I could
choose to get the series that you named as "reskwh_H" by the name of
"no_I_like_this_better". That is not possible in hansl AFAIK.
> I understand that. But there still *can* be series-name collision
if the
> caller assigns a new list name.
Of course, if you call the function twice over the same series and
assign a name (may be different) for the generated list, the previous
series are overwritten.
I don't think it is a problem. In some sense I think it is a good
feature, for example if you want to repeat the analysis in different
conditions.
Well apart from the fact that by coincidence you could already have a
totally unrelated series named "reskwh_H" in your dataset, it's not me
who's saying it's a problem! It's Allin who's saying that it becomes a
problem when you call the function without assigning the list return name.
In fact that is the central part of my doubt: if it is seen as a problem
at all (which I'm not saying BTW), then why only in one case (anonymous
call) and not in the other case? This is inconsistent IMO.
The problem that may occur of overwritting some important previous
series should be resolved by the package programmer who should select
the names for the generated series carefully.
Absolutely.
I think in general is good to have a way of generating new series that
in some way may have names derived from an existing one, such as reskwh,
reskwh_H and reskwh_W, I don't think it is a good idea that the series
have prepended the name of the list.
I have no strong preference here. The argument there was about defining
a properly separated namespace. Prepending names is just one possibility
how to achieve this. But note I'm not pushing strongly for this, it was
just a related thought.
thans,
sven
9:31 a.m.
On Mon, 22 Jun 2015, Sven Schreiber wrote:
Well apart from the fact that by coincidence you could already have a
totally
unrelated series named "reskwh_H" in your dataset, it's not me who's
saying
it's a problem! It's Allin who's saying that it becomes a problem when you
call the function without assigning the list return name.
And I agree 100% with Allin!
> The problem that may occur of overwritting some important
previous
> series should be resolved by the package programmer who should select
> the names for the generated series carefully.
Absolutely.
And how, exactly? This would require clairvoyance. How am I, the package
writer, supposed to know that the package will never be used on a dataset
that contains a series by the name well_this_should_be_safe?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:51 a.m.
El 22/06/15 a las 15:31, Riccardo (Jack) Lucchetti escribió:
On Mon, 22 Jun 2015, Sven Schreiber wrote:
> Well apart from the fact that by coincidence you could already have a
> totally unrelated series named "reskwh_H" in your dataset, it's not
> me who's saying it's a problem! It's Allin who's saying that it
> becomes a problem when you call the function without assigning the
> list return name.
And I agree 100% with Allin!
>> The problem that may occur of overwritting some important previous
>> series should be resolved by the package programmer who should select
>> the names for the generated series carefully.
>
> Absolutely.
And how, exactly? This would require clairvoyance. How am I, the
package writer, supposed to know that the package will never be used
on a dataset that contains a series by the name well_this_should_be_safe?
Well Jack, please change "resolved" by "minimized" and better use
wEll_THiSs_shoulD_be_sAFe ;-))
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
9:57 a.m.
On Mon, 22 Jun 2015, Ignacio Diaz-Emparanza wrote:
> And how, exactly? This would require clairvoyance. How am I, the
package
> writer, supposed to know that the package will never be used on a dataset
> that contains a series by the name well_this_should_be_safe?
Well Jack, please change "resolved" by "minimized" and better use
wEll_THiSs_shoulD_be_sAFe ;-))
Ok. How do we establish what is "sAFe"? Would "Safe" be safe? How
about
"SAFe"?
And second: how do we check that a contributed package doesn't contain a
public function returning a list that by construction the series "depvar"
(decidedly _not safe_), or worse, "y"?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:21 a.m.
On Sun, 21 Jun 2015, Sven Schreiber wrote:
Am 21.06.2015 um 10:53 schrieb Allin Cottrell:
>
> Sven, you're misunderstanding how "returning a list" works in hansl.
No I don't, everything you explain was actually how I already thought
things worked.
OK, then maybe I can explain my thinking better by reference to
Ignacio's HoltWinters package discussed elsethread.
What you're effectively saying is:
1) If the caller assigns a new list name it's all her fault if something
goes wrong. (I'm actually fine with this, though we can --and have--
talked about design changes that would improve the situation.)
Yes, more or less, though I'd say it's either the user's fault
(assuming the function in question is properly documented) or the
function author's fault (otherwise).
2) But a caller who calls the function anonymously somehow cannot be
expected to act responsibly and thus deserves special care.
No, that's not my view. Take HoltWinters. This function does some
computations, prints out some statistics, and also offers a list
return that wraps a couple of series. Maybe I'd like to see the
statistics but don't care to accept the generated series, so I don't
assign the return value. Before my code modification of February, I'd
have got the two series added to my dataset regardless. Surprise!
That's not Ignacio's fault, as I see it; it was gretl's fault.
With this sort of function, adding the series to the main dataset
should be conditional on accepting the list return, not because we
think the user is a dummy, but because it's a reasonable expectation
that if you don't want and don't ask for the series, you won't get
them.
Consider by contrast a built-in such as log(), applied to a list. This
function does absolutely nothing apart from creating logs of the input
series, and offering as return a wrapper for the generated series.
Unlike HoltWinters there's never any reason to call such a function
unless you want the series it generates. However, you don't
necessarily need the list wrapper. It therefore seems a legitimate
use-case to call log() without assignment in the expectation that the
series you want will be added; otherwise
log(List)
would just be a no-op.
Q: "Why did the logs get added to my dataset when I didn't assign the
return?" A: "Well, if you didn't want that then why did you call
log()?" The answer here seems to me to have force, but it doesn't have
force for HoltWinters, or other contributed functions that print
things or plot things besides offering a list return.
Allin
1:03 p.m.
Am 22.06.2015 um 16:21 schrieb Allin Cottrell:
On Sun, 21 Jun 2015, Sven Schreiber wrote:
> What you're effectively saying is:
> 1) If the caller assigns a new list name it's all her fault if something
> goes wrong. (I'm actually fine with this, though we can --and have--
> talked about design changes that would improve the situation.)
Yes, more or less, though I'd say it's either the user's fault (assuming
the function in question is properly documented) or the function
author's fault (otherwise).
agreed
> 2) But a caller who calls the function anonymously somehow cannot be
> expected to act responsibly and thus deserves special care.
No, that's not my view. Take HoltWinters. This function does some
computations, prints out some statistics, and also offers a list return
that wraps a couple of series. Maybe I'd like to see the statistics but
don't care to accept the generated series, so I don't assign the return
value. Before my code modification of February, I'd have got the two
series added to my dataset regardless. Surprise! That's not Ignacio's
fault, as I see it; it was gretl's fault.
Ok, now I think we're getting to the bottom of this, and probably it's a
matter of style and taste:
To me (and I presume to many other gretl users, but I may be wrong), the
stuff that a function returns is the central thing, maybe apart from
those kind of C-style functions where the return value is just an
integer error code, but still. Most gretl functions also work this way.
IMO that means that whenever such a function is called the default
assumption should be that the user wants the returned stuff and thus
gets it. AFAICS this is the way all functions work in gretl, with the
list-returning functions as the only exception (since Feb 2015). For all
other object types, returned stuff that is optional is covered by
pointer arguments, and that's good.
Now you're saying that lists are special because they have side effects
that are potentially unintended, and that's of course true. Then it
boils down to the question: how do we give the user (some) control over
the side effects? Let me summarize the suggestions:
1) Allin (&Jack): make the non-assigned call special, which protects the
dataset in place. Downside: no way to get the returned list in a 100%
riskless way; inconsistent etc etc.
2) Sven (old and not 100% serious): in some way introduce namespaces
that the caller manipulates through her choice of the assigned list
name. Downside: pretty hefty change.
3) Sven (new and maybe more serious): give the user another explicit
choice to discard the returned list, different from suggestion number
(1). For example with a "null" keyword:
list null = contributed_function(...)
(but the actual implementation of the choice can of course be different;
what's important is that an "empty" call without explicit assignment
would still return the list)
Downside: Also not 100% riskless whenever the return list is fetched.
But at least not inconsistent IMHO.
4) Sven (alternative idea): give the caller a way to override the names
of the returned series in a list. Example
# 'mystrings' would be an array of strings
list outlist[mystrings] = contributed_function(...)
Downside: can't see any right now, apart from the work to implement it.
Obviously I prefer numbers (2)-(4) over the current behavior (1), but
it's as always a matter of taste.
need the list wrapper. It therefore seems a legitimate use-case to
call
log() without assignment in the expectation that the series you want
will be added; otherwise
log(List)
Well yeah it's legitimate, still it's inconsistent with (1) above and
thus is some complication layer.
thanks,
sven
1:18 p.m.
On Mon, 22 Jun 2015, Sven Schreiber wrote:
1) Allin (&Jack): make the non-assigned call special, which
protects the
dataset in place. Downside: no way to get the returned list in a 100%
riskless way; inconsistent etc etc.
I don't think I understand what you mean. If you want the returned list in
a 100% riskless way, all you have to do is assign it to a temporary
variable. What happens is entirely predictable (and hence, I would say,
safe).
<hansl>
function list moo(void)
series y = -1
list ret = y
return ret
end function
nulldata 6
series y = 1
print y
# with this, your original y is safe
moo()
print y
# with this, y is overwritten
list L = moo()
print y
</hansl>
I'm sorry, but I can't see either the risk nor the inconsistency.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:47 p.m.
Am 22.06.2015 um 19:18 schrieb Riccardo (Jack) Lucchetti:
On Mon, 22 Jun 2015, Sven Schreiber wrote:
> 1) Allin (&Jack): make the non-assigned call special, which protects the
> dataset in place. Downside: no way to get the returned list in a 100%
> riskless way; inconsistent etc etc.
I don't think I understand what you mean. If you want the returned list
in a 100% riskless way, all you have to do is assign it to a temporary
variable. What happens is entirely predictable (and hence, I would say,
safe).
<hansl>
function list moo(void)
series y = -1
list ret = y
return ret
end function
...
# with this, your original y is safe
moo()
Safe yes, but of course at the cost of not getting any benefit at all (=
the return value) from the function. I call this throwing the baby out
with the bathwater. How on earth can this non-retrieval of the return
value be considered a solution to the overwriting problem below, if the
solution defeats the purpose in the first place???
*Plus*, it's inconsistent with the way the built-in functions work.
Allin defended this discrepancy and we can argue about whether it's
defensible, but thereby the inconsistency fact itself is undisputed.
# with this, y is overwritten
list L = moo()
print y
</hansl>
Exactly, when you actually want to get at the returned list, something
might get overwritten. And again: I don't see this as a problem per se,
but you guys did and therefore the Feb 2015 change was introduced to be
able to avoid this "risk".
I'm sorry, but I can't see either the risk nor the inconsistency.
The opposite of "safe" is "risky", so if you call the former
"safe", I
think we can call this "risky"; but I don't care about the wording. And
see above for the inconsistency.
This discussion is getting out of hand; but as my last argument, please
recall how this all started: Allin didn't remember the rationale for all
this stuff you are now defending so ferociously as being more or less
self-evident! Now if this isn't telling you that there's something
conceptually fishy there, I give up.
IMHO currently this is a flawed design, and I'm afraid these type of
things might accumulate, but in isolation it's of course not super
important.
cheers,
sven
10:18 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
El 22/06/15 a las 21:47, Sven Schreiber escribió:
Am 22.06.2015 um 19:18 schrieb Riccardo (Jack) Lucchetti:
...
> # with this, your original y is safe
> moo()
Safe yes, but of course at the cost of not getting any benefit at all (=
the return value) from the function. I call this throwing the baby out
with the bathwater. How on earth can this non-retrieval of the return
value be considered a solution to the overwriting problem below, if the
solution defeats the purpose in the first place???
Yes Sven, but this is the way in which all type of functions work, for
example,
<hansl>
function scalar a()
scalar b=2
return b
end function
nulldata 6
a()
</hansl>
the a() invocation does not save the result, or the same with a series.
<hansl>
function series y()
genr time
series y = time*2
return y
end function
nulldata 6
y()
</hansl>
if you don't assign a value to the new created object this is not saved.
Any function you create can be executed without assignement, then I
think this function is something "similar" to a hansl COMMAND, and can
also be executed by assigning to an object, and in this way it is
working as something similar to a native hansl FUNCTION.
*Plus*, it's inconsistent with the way the built-in functions work.
Allin defended this discrepancy and we can argue about whether it's
defensible, but thereby the inconsistency fact itself is undisputed.
No, I think
your first phrase should be "*Plus*, it's inconsistent with
the way the built-in COMMANDS work".
I think here are some misunderstanding of native commands and native
functions.
The problem may be that we have the same spelling for some commands and
functions. For example if you look at the "Gretl Command Reference" ( I
am looking at the pdf)
you will see 'diff', 'lags' etc in the list of COMMANDS and also in the
list of FUNCTIONS.
Anyway, after thinking a little about the subject, I would say that a
bundle is a much more consistent and safe way of returning different
objects (at least in question of namespaces). You may have a look at
some packages we have in the server that produce bundles. For example,
my Brown package is very simple and produces several series in a bundle.
The package may contain a bundle-print function (as Brown has) which
will produce a nice window with the results. From the bundle icon in
this window you can save the series contained in the bundle. Always,
even if the package does not contain a defined bundle-print function you
may call the function assigning it to a new bundle name:
bundle bbrown=Brown(Ct,0.7)
and then this does not destroy any series of your dataset. The series
are there in the bundle so (although there is not a bundle-print
function), you always can go to the session view and extract series
which are inside the bundle, without any problem with the series in the
current dataset, because gretl asks for the name of the new series to be
created.
Of course, if you execute the bundle without assignement
Brown(Ct,0.7)
everything is thrown away, in the same way as with the other different
objects.
I think an experienced hansl user (as myself ;-)) should always use
bundles to return several objects. Does it mean that we should deprecate
the use of lists as return value of a function? It may be, but not
necessarily. And may be also that we should deprecate all use of lists,
because probably all their functionality can be done via bundles and
strings. Lists were created a long time ago before the existence of
strings and bundles (Do they come from ESL, Allin?) and they were a
solution valid for a such a time. Now we should take into account that
they may be an object more easy to manage than bundles, for new hansl users.
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
10:42 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
Am 23.06.2015 um 16:18 schrieb Ignacio Diaz-Emparanza:
El 22/06/15 a las 21:47, Sven Schreiber escribió:
> Am 22.06.2015 um 19:18 schrieb Riccardo (Jack) Lucchetti:
> ...
>> # with this, your original y is safe
>> moo()
> Safe yes, but of course at the cost of not getting any benefit at all (=
> the return value) from the function. I call this throwing the baby out
> with the bathwater. How on earth can this non-retrieval of the return
> value be considered a solution to the overwriting problem below, if the
> solution defeats the purpose in the first place???
Yes Sven, but this is the way in which all type of functions work, for
example,
<hansl>
function scalar a()
scalar b=2
return b
end function
nulldata 6
a()
</hansl>
the a() invocation does not save the result,
You almost had me there Ignacio, but not quite, because after your
function definition this line:
series look = log(a())
of course will work and use the call a() fruitfully. In fact, this
anonymous retrieval of the return value was exactly how this whole
discussion started, because *only* list-returning functions have been
the exception (since Feb 2015).
I will get back to the rest of your message later, right now I don't
have the time.
cheers,
sven
11:29 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
On Tue, 23 Jun 2015, Sven Schreiber wrote:
Am 23.06.2015 um 16:18 schrieb Ignacio Diaz-Emparanza:
> El 22/06/15 a las 21:47, Sven Schreiber escribió:
>> Am 22.06.2015 um 19:18 schrieb Riccardo (Jack) Lucchetti:
>> ...
>>> # with this, your original y is safe
>>> moo()
>> Safe yes, but of course at the cost of not getting any benefit at all (=
>> the return value) from the function. I call this throwing the baby out
>> with the bathwater. How on earth can this non-retrieval of the return
>> value be considered a solution to the overwriting problem below, if the
>> solution defeats the purpose in the first place???
>
> Yes Sven, but this is the way in which all type of functions work, for
> example,
>
> <hansl>
> function scalar a()
> scalar b=2
> return b
> end function
>
> nulldata 6
> a()
> </hansl>
>
> the a() invocation does not save the result,
You almost had me there Ignacio, but not quite, because after your function
definition this line:
series look = log(a())
of course will work and use the call a() fruitfully. In fact, this anonymous
retrieval of the return value was exactly how this whole discussion started,
because *only* list-returning functions have been the exception (since Feb
2015).
I've been thinking about this some more and my view is getting closer
to Sven's, at least in regard to the use of a call to a list-returning
function in the context of a function-argument slot.
If a call to list-returning function foo() is used in place of a
pre-defined list, in a call to a function that wants a list argument,
I think it's only reasonable to assume that the caller _does_ want the
side-effect of foo (possible addition of series to the dataset), even
if he or she has no non-transient use for the direct return value (as
a named list object).
In CVS I've modified my check: we now bar the side-effect of a
list-returning function only if it is called by itself, without
assignment, as in plain
foo(<args>)
Now, I've mentioned that at present this bar does not apply to
built-in list-returning functions such as log(); they will have their
side-effects regardless. If my feet were held to the fire on the
inconsistency here, I think I'd want to generalize the bar to log()
and co.
Allin
3:59 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
Am 23.06.2015 um 17:29 schrieb Allin Cottrell:
I've been thinking about this some more and my view is getting closer to
Sven's, at least in regard to the use of a call to a list-returning
function in the context of a function-argument slot.
If a call to list-returning function foo() is used in place of a
pre-defined list, in a call to a function that wants a list argument, I
think it's only reasonable to assume that the caller _does_ want the
side-effect of foo (possible addition of series to the dataset), even if
he or she has no non-transient use for the direct return value (as a
named list object).
It's probably redundant to say that I agree :-)
In CVS I've modified my check: we now bar the side-effect of a
list-returning function only if it is called by itself, without
assignment, as in plain
foo(<args>)
Thanks, I think this is a very reasonable compromise.
Now, I've mentioned that at present this bar does not apply to built-in
list-returning functions such as log(); they will have their
side-effects regardless. If my feet were held to the fire on the
inconsistency here, I think I'd want to generalize the bar to log() and co.
Now how do I ignite that fire ;-)
But a serious question (meaning I'm not sure of the answer): Taking the
log example, is there any difference between calling the function by
itself and using the command? I.e., for an existing list "somevars"
what's the difference between the hansl script lines:
logs somevars
and
log(somevars)
?
thanks,
sven
11:57 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
On Tue, 23 Jun 2015, Ignacio Diaz-Emparanza wrote:
[...] I think an experienced hansl user (as myself ;-)) should
always use bundles to return several objects. Does it mean that we
should deprecate the use of lists as return value of a function? It
may be, but not necessarily. And may be also that we should
deprecate all use of lists, because probably all their functionality
can be done via bundles and strings. Lists were created a long time
ago before the existence of strings and bundles (Do they come from
ESL, Allin?) and they were a solution valid for a such a time. Now
we should take into account that they may be an object more easy to
manage than bundles, for new hansl users.
No, lists were not in ESL; they were introduced in gretl 1.4.0, in
2005. As you say, bundles are a better container for some purposes,
but I think lists are very useful and would not want to deprecate them
in general.
Allin
3:54 a.m.
New subject: nesting a function call getting a list doesn't work (once more)
Am 23.06.2015 um 16:18 schrieb Ignacio Diaz-Emparanza:
I think an experienced hansl user (as myself ;-)) should always use
bundles to return several objects. Does it mean that we should deprecate
the use of lists as return value of a function? It may be, but not
necessarily. And may be also that we should deprecate all use of lists,
because probably all their functionality can be done via bundles and
strings. Lists were created a long time ago before the existence of
strings and bundles (Do they come from ESL, Allin?) and they were a
solution valid for a such a time. Now we should take into account that
they may be an object more easy to manage than bundles, for new hansl
users.
Well, I would think that an array of series (which doesn't exist exactly
because it would be too similar to a list type) is a more natural
replacement for lists.
In any case, lists of series are so fundamental for gretl commands (as
opposed to functions) that I agree with Allin that this should be kept,
the project would be too disruptive (and also would take a very long
time to accomplish, for very little net profit).
cheers,
sven
7:53 a.m.
New subject: nesting a function call getting a list doesn't work / Re: getenv(): about environment strings
El 19/06/15 a las 22:09, Allin Cottrell escribió:
There are some built-in gretl functions that return lists. These have
the potential of overwriting data series previously created by the
user, but (I think) they are quite explicit regarding the names of the
series they create and return. Caveat emptor. I wouldn't necessarily
trust a contributed function that returned a list unless I knew the
author well.
IMO that's not a reason to stop using lists. But I think it _is_ a
reason to resist Sven's suggestion that the error resulting from
giving an anonymous, on-the-fly, function-returned list as a function
argument is a gretl bug. I thought it was a bug, at face value, but
now I don't think so; I believe it's a defensible safeguard. However,
the resulting error message should be clearer.
Allin
Sorry, I am reading this thread after the other one. Obvioulsy
HoltWinters.gfn is one of these packages that return a list. This is
because it was made before there were bundles and this was the unique
way of returning more than one series. I will update it soon.
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
3434
days inactive
3439
days old
30 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber