2:10 p.m.
Hi,
as Jack suggested, I started learning Hansl.
I tried to implement a download from the website ariva.de which offers data on all sorts
of securities (stocks, funds, etc.) traded in Germany. While the download is fine, getting
the files into Gretl proved hard. The hansl file "elimThousSep.inp" contains the
following line near the end:
append @strFile
This makes Gretl crash. It has something to do with the prior "open" command
(second last line of code) because without, there is no crash.
I attach the file together with an additional small include (arivaTickers.inp) and the csv
file. Gretl version is 1.9.92 on a Windows PC.
Thanks for your help!
Thorsten
Thorsten Wingenroth
Professor für Lehraufgaben BWL-Bank
Fakultät Wirtschaft | Studienzentrum Finanzwirtschaft (Center of Finance)
Duale Hochschule Baden-Württemberg Stuttgart
Baden-Wuerttemberg Cooperative State University Stuttgart
Herdweg 18 | 70174 Stuttgart
Fon +49 711 1849-766
thorsten.wingenroth@dhbw-stuttgart.de<mailto:thorsten.wingenroth@dhbw-stuttgart.de>
| http://www.dhbw-stuttgart.de/bank
Master in Business Management - Banking & Finance
http://www.dhbw.de/master-finance
5:08 p.m.
You found another bug ;).
(my comments should be validated by Allin or Jack)
h1 - The append command used from within the function causes the crash
(there are some restrictions to access the dataset). The crash should not
occur but some error message should be displayed.
h2 - There is a data frequency mismatch caused by the setobs command. The
append command is aborted when called from main script producing a proper
error message, but crashed when called from within the function.
Attached is the modified script file. Using CVS build 1.10 in Linux. I
changed the filename to match capitalized names.
This is the Linux shell output:
[helio@localhost gretl]$ gretl -e elimThousSep.inp &
[1] 11101
[helio@localhost gretl]$ S[0] = '2015-01-29', ed1 = 735640
guessed daily pd = 5
check_daily_dates: data are reversed?
check_daily_dates: daily pd = 5, reversed = 1, err = 0
+++ outfile --close: ignoring redundant filename
S[0] = '2015-01-30', ed1 = 735641
guessed daily pd = 5
check_daily_dates: data are reversed?
check_daily_dates: daily pd = 5, reversed = 1, err = 0
merge_data: opt=0
special: merging daily data
addobs (1) = 0
addobs (2) = 0
---
This is the script output:
gretl version 1.10.0cvs
Current session: 2015-02-01 16:51
# messages off
first row label "2015-01-29", last label "2000-01-31"
trying to parse row labels as dates...
Trying date order YYYYMMDD
Could be 2015-01-29 - 2000-01-31
Observations: 3826; days in sample: 3914
Missing daily rows: 88
Listing 6 variables:
0) const 1) Erster 2) Hoch 3) Tief
4) Schlusskurs 5) Volumen
bundle exchange:
XETRA = 6
INDEX = 12
bundle ticker:
DAI = 297
DAX = 290
URL:
http://www.ariva.de/quote/historic/historic.csv?secu=290&boerse_id=12...
first row label "2015-01-30", last label "2014-01-31"
trying to parse row labels as dates...
Trying date order YYYYMMDD
Could be 2015-01-30 - 2014-01-31
Observations: 252; days in sample: 261
Missing daily rows: 9
Listing 6 variables:
0) const 1) Erster 2) Hoch 3) Tief
4) Schlusskurs 5) Volumen
----
Best Regards.
Hélio
On Sun, Feb 1, 2015 at 2:10 PM, Wingenroth, Thorsten <
Thorsten.Wingenroth(a)dhbw-stuttgart.de> wrote:
Hi,
as Jack suggested, I started learning Hansl.
I tried to implement a download from the website ariva.de which offers
data on all sorts of securities (stocks, funds, etc.) traded in Germany.
While the download is fine, getting the files into Gretl proved hard. The
hansl file “elimThousSep.inp” contains the following line near the end:
append @strFile
This makes Gretl crash. It has something to do with the prior “open”
command (second last line of code) because without, there is no crash.
I attach the file together with an additional small include
(arivaTickers.inp) and the csv file. Gretl version is 1.9.92 on a Windows
PC.
Thanks for your help!
Thorsten
*Thorsten Wingenroth*
Professor für Lehraufgaben BWL-Bank
Fakultät Wirtschaft | Studienzentrum Finanzwirtschaft (Center of Finance)
*Duale Hochschule Baden-Württemberg Stuttgart*
Baden-Wuerttemberg Cooperative State University Stuttgart
Herdweg 18 | 70174 Stuttgart
Fon +49 711 1849-766
thorsten.wingenroth(a)dhbw-stuttgart.de | http://www.dhbw-stuttgart.de/bank
*Master in Business Management – Banking & Finance*
http://www.dhbw.de/master-finance
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
5:45 p.m.
On Sun, 1 Feb 2015, Hélio Guilherme wrote:
You found another bug ;).
(my comments should be validated by Allin or Jack)
h1 - The append command used from within the function causes the crash
(there are some restrictions to access the dataset). The crash should not
occur but some error message should be displayed.
Quite right. As things stand, the "append" command should not be
allowed within a function. This is because for append to work
correctly the full dataset must be "in scope", but inside a function
it's not: only such variables as have been passed as function
arguments are "visible".
h2 - There is a data frequency mismatch caused by the setobs command.
The
append command is aborted when called from main script producing a proper
error message, but crashed when called from within the function.
[...]
Hmm, I see what you mean, but in Thorsten's script elimThousSep.inp,
as it stands, the "setobs" command is harmless since it's overruled by
"open DAX_clean.csv" which establishes the correct data frequency.
Allin
On Sun, Feb 1, 2015 at 2:10 PM, Wingenroth, Thorsten <
Thorsten.Wingenroth(a)dhbw-stuttgart.de> wrote:
> Hi,
>
> as Jack suggested, I started learning Hansl.
>
> I tried to implement a download from the website ariva.de which offers
> data on all sorts of securities (stocks, funds, etc.) traded in Germany.
> While the download is fine, getting the files into Gretl proved hard. The
> hansl file “elimThousSep.inp” contains the following line near the end:
>
> append @strFile
>
> This makes Gretl crash. It has something to do with the prior “open”
> command (second last line of code) because without, there is no crash.
>
> I attach the file together with an additional small include
> (arivaTickers.inp) and the csv file. Gretl version is 1.9.92 on a Windows
> PC.
>
> Thanks for your help!
>
> Thorsten
6:51 p.m.
On Sun, 1 Feb 2015, Allin Cottrell wrote:
On Sun, 1 Feb 2015, Hélio Guilherme wrote:
> You found another bug ;).
>
> (my comments should be validated by Allin or Jack)
>
> h1 - The append command used from within the function causes the crash
> (there are some restrictions to access the dataset). The crash should not
> occur but some error message should be displayed.
Quite right. As things stand, the "append" command should not be allowed
within a function. This is because for append to work correctly the full
dataset must be "in scope", but inside a function it's not: only such
variables as have been passed as function arguments are "visible".
This is possibly the most confusing aspect of Hansl for people coming from
different backgrounds.
Allin and myself have a very strongly "C-oriented" mindset: what happens
inside the function stays inside the function, full stop. I stand very
strongly by this design choice, because anything else leads to
countless headaches in terms of code (a) re-usability (b) clarity (c)
maintainability. So no, dear Gauss users, we don't have global variables;
yes, dear FORTRAN addicts, we pass parameters by value; and, most
importantly, everybody: no matter what you do inside the function, you
CAN'T ALTER THE ORIGINAL DATASET. (Of course, you can use pointers for
performing smart tricks, but that's sort of beside the point.)
This said, I believe that this principle should be very very clearly
stated anytime we can in the documentation and that, of course, no
attempt to do anything should lead to a crash, no matter how fishy it
looks from the viewpoint of the above principle.
-------------------------------------------------------
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:22 p.m.
On Sun, 1 Feb 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 1 Feb 2015, Allin Cottrell wrote:
> [...] As things stand, the "append" command should not be allowed
> within a function. This is because for append to work correctly
> the full dataset must be "in scope", but inside a function it's
> not: only such variables as have been passed as function
> arguments are "visible".
This is possibly the most confusing aspect of Hansl for people coming from
different backgrounds. [...]
Yes, sorry about that. But as Jack goes on to say, it's a deliberate
design decision that's not going to be changed.
However, there are idiomatic ways of adding series to a dataset via
a function. One way is to use the "join" command in the function.
This adds a series as a local variable within the function; it can
then be passed to the caller as a return value. Take a look at
Jack's yahoo_get function package for some ideas.
As for the crash Thorsten got, that's now fixed in CVS and
snapshots: attempting to use "append" within a function will provoke
an error (as does "open", which has always generated an error -- but
when we banned "open" originally we overlooked the need to ban
"append").
Allin
1:15 a.m.
On Sun, 1 Feb 2015, I wrote:
As for the crash Thorsten got, that's now fixed in CVS and
snapshots: attempting to use "append" within a function will
provoke an error (as does "open", which has always generated an
error -- but when we banned "open" originally we overlooked the
need to ban "append").
Nostra culpa -- or "our bad", if you prefer. I had a feeling there
might be an example in the Gretl User's Guide where "append" is used
inside a function and now I've found it, in the "Gretl and R"
section under "Technical details".
In that case we just got lucky and there was no crash. I need to
think a bit more about whether there's a way to support "append" in
functions without breaking the "encapsulation" we require of
functions (basically meaning, no unintended side-effects).
Allin
10:21 a.m.
Am 02.02.2015 um 02:15 schrieb Allin Cottrell:
On Sun, 1 Feb 2015, I wrote:
> As for the crash Thorsten got, that's now fixed in CVS and snapshots:
> attempting to use "append" within a function will provoke an error (as
> does "open", which has always generated an error -- but when we banned
> "open" originally we overlooked the need to ban "append").
Nostra culpa -- or "our bad", if you prefer. I had a feeling there might
be an example in the Gretl User's Guide where "append" is used inside a
function and now I've found it, in the "Gretl and R" section under
"Technical details".
In that case we just got lucky and there was no crash. I need to think a
bit more about whether there's a way to support "append" in functions
without breaking the "encapsulation" we require of functions (basically
meaning, no unintended side-effects).
I strongly agree that the separation of inner and outer scope of
functions is a good thing. The problem with returning more than a single
series from a function is the issue of moving back and forth the names
(identifiers) -- a general-purpose function cannot know which names in
the dataset are already taken.
Currently you can do this with pointer arguments:
<hansl>
series s1
series s2
series s3
call_to_function(<some-input>, &s1, &s2, &s3)
</hansl>
The problem is that it takes many lines of code if you have several
series you want to get this way. Somehow it would be nice if one could
define a "placeholder" list to be passed to a function just as a
container with pre-defined names. Something like:
<hansl-proposed>
list out --varnames="s1 s2 s3"
list out = call_to_function(<some-input>)
</hansl-proposed>
Or a different way: whenever a function returns a list it could be
encouraged (required in the future?) to also accept a string array
argument that contains the names of the list elements.
(I wanted to include an example, but I haven't worked with string arrays
before and cannot find the documentation right now.)
thanks,
sven
7:19 p.m.
On Mon, 2 Feb 2015, Sven Schreiber wrote:
Am 02.02.2015 um 02:15 schrieb Allin Cottrell:
> On Sun, 1 Feb 2015, I wrote:
>
>> As for the crash Thorsten got, that's now fixed in CVS and snapshots:
>> attempting to use "append" within a function will provoke an error (as
>> does "open", which has always generated an error -- but when we banned
>> "open" originally we overlooked the need to ban "append").
>
> Nostra culpa -- or "our bad", if you prefer. I had a feeling there might
> be an example in the Gretl User's Guide where "append" is used inside
a
> function and now I've found it, in the "Gretl and R" section under
> "Technical details".
>
> In that case we just got lucky and there was no crash. I need to think a
> bit more about whether there's a way to support "append" in functions
> without breaking the "encapsulation" we require of functions (basically
> meaning, no unintended side-effects).
I strongly agree that the separation of inner and outer scope of
functions is a good thing. [...]
Ah, it turns out we can maintain that while allowing "append" within
functions (under certain constraints).
The crash that Thorsten got was specific to the case where "append"
inside a function tries to add a series with the same name as a
pre-existing series in the main dataset, not currently visible within
the function. This was actually due to a fairly simple bug, now fixed.
In general "append" can add data either "sideways" (new series) of
"length-wise" (new observations). Within a function we can allow the
former but not the latter. The newly added series will be local to the
function and will disappear when the function exits unless passed back
to the caller via the function's return value.
However, this still leaves the point you go on to raise:
The problem with returning more than a single series from a function
is the issue of moving back and forth the names (identifiers) -- a
general-purpose function cannot know which names in the dataset are
already taken.
Yes, this is awkward; returning a single series is fine but returning
a list can produce name-space collisions.
Somehow it would be nice if one could define a
"placeholder" list to
be passed to a function just as a container with pre-defined names.
Something like:
<hansl-proposed>
list out --varnames="s1 s2 s3"
list out = call_to_function(<some-input>)
</hansl-proposed>
Or a different way: whenever a function returns a list it could be
encouraged (required in the future?) to also accept a string array
argument that contains the names of the list elements.
That's worth thinking about, yes.
Allin
3611
days inactive
3612
days old
7 comments
5 participants
participants (5)
-
Allin Cottrell -
Hélio Guilherme -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Wingenroth, Thorsten