8 a.m.
Hi,
finally I installed the latest snapshot (thanks Allan for pointing this out) , so I can
test all the fixes you do for my ;-) bugs...
I imported the attached file. The thousands separator seems to be working fine. However, I
am not sure if the numbers are interpreted as such. The log-file says:
variable 1 (Erster): non-numeric values = 3386 (100.00 percent)
variable 2 (Hoch): non-numeric values = 3386 (100.00 percent)
variable 3 (Tief): non-numeric values = 3386 (100.00 percent)
variable 4 (Schlusskurs): non-numeric values = 6486 (99.98 percent)
A bit odd. All are stock prices and therefore numbers.
A look at the times-series seems perfectly ok, but the graph is nonsense:
Schlusskurs
1990-02-22 9,51723
1990-02-23 9,41995
1990-02-26 9,29997
1990-02-27 9,52696
1990-02-28 9,69558
1990-03-01 9,80907
[cid:image001.png@01D04E7E.2C326390]
Could you please have a look at this?
Snapshot 1.10.0cvs, 64-Bit Windows
Thank you and kind regards,
Thorsten
Prof. Dr. 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
2:59 p.m.
On Sun, 22 Feb 2015, Wingenroth, Thorsten wrote:
finally I installed the latest snapshot (thanks Allan for pointing
this out) , so I can test all the fixes you do for my ;-) bugs...
I imported the attached file. The thousands separator seems to be
working fine. However, I am not sure if the numbers are
interpreted as such. The log-file says:
variable 1 (Erster): non-numeric values = 3386 (100.00 percent)
variable 2 (Hoch): non-numeric values = 3386 (100.00 percent)
variable 3 (Tief): non-numeric values = 3386 (100.00 percent)
variable 4 (Schlusskurs): non-numeric values = 6486 (99.98 percent)
The thousands-separator detection is not working right on this file,
and all variables are being taken as string-valued. There must be a
subtle difference between this file and the one you posted a few
weeks back (DAX) -- I checked, and reading of the DAX file is still
correct. I'll take another look at this.
Allin
3:09 p.m.
Am 22.02.2015 um 15:59 schrieb Allin Cottrell:
On Sun, 22 Feb 2015, Wingenroth, Thorsten wrote:
The thousands-separator detection is not working right on this file,
and
all variables are being taken as string-valued. There must be a subtle
difference between this file and the one you posted a few weeks back
(DAX) -- I checked, and reading of the DAX file is still correct. I'll
take another look at this.
Perhaps because now it's also a millions-separator, i.e. a dot ocurring
twice in the same number? Or was that also the case back then?
-sven
3:47 p.m.
On Sun, 22 Feb 2015, Sven Schreiber wrote:
Am 22.02.2015 um 15:59 schrieb Allin Cottrell:
> On Sun, 22 Feb 2015, Wingenroth, Thorsten wrote:
> The thousands-separator detection is not working right on this file, and
> all variables are being taken as string-valued. There must be a subtle
> difference between this file and the one you posted a few weeks back
> (DAX) -- I checked, and reading of the DAX file is still correct. I'll
> take another look at this.
Perhaps because now it's also a millions-separator, i.e. a dot ocurring
twice in the same number? Or was that also the case back then?
That was also the case with the previous file. I think the difference
is coming from the representation of dates, which was in the canonical
form YYYY-MM-DD in the previous file but is in the form DD.MM.YYYY in
the current one. I guess gretl is getting confused due to the need for
multiple passes through the data: the pass to fix the dates is somehow
interfering with the pass to fix the thousands separators.
A fix shouldn't be too far away. But this time I think I'll put in a
"backstop": if we find ourselves having to construct a "string table"
for data that are composed of nothing but digits, dot and comma, we
should flag an error and give up instead of accepting the data as
string-valued.
Allin
3:50 p.m.
Am 22.02.2015 um 16:47 schrieb Allin Cottrell:
That was also the case with the previous file. I think the difference is
coming from the representation of dates, which was in the canonical form
YYYY-MM-DD in the previous file but is in the form DD.MM.YYYY in the
current one. I guess gretl is getting confused due to the need for
multiple passes through the data: the pass to fix the dates is somehow
interfering with the pass to fix the thousands separators.
Not sure if I'm suggesting things that already exist, but for these
complicated/non-standard files why not give the user a chance to specify
all these peculiarities (various separators, date format...), instead of
trying to teach gretl to figure it all out herself?
cheers,
sven
4:25 p.m.
On Sun, 22 Feb 2015, Sven Schreiber wrote:
Not sure if I'm suggesting things that already exist, but for
these
complicated/non-standard files why not give the user a chance to specify
all these peculiarities (various separators, date format...), instead of
trying to teach gretl to figure it all out herself?
I *think* that stata has a feature like that. I guess we could have a gui
element in which you can choose
(a) decimal separator (default '.')
(b) thousands separator (default none)
(c) field separator (default ',')
(d) quote character default ('"')
(e) NA code
(f) presence/absence of variable names
(g) presence absence of a "date" field
(h) rule to treat multiple separators
when importing from text files. That would probably solve most issues. The
one that gnumeric has is incredibly good, the best one I've ever seen in a
spreadsheet. Perhaps we could rip it off theirs to some extent.
-------------------------------------------------------
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:15 p.m.
On Sun, 22 Feb 2015, Riccardo (Jack) Lucchetti wrote:
The one that gnumeric has is incredibly good, the best one I've
ever
seen in a spreadsheet. Perhaps we could rip it off theirs to some
extent.
Whoa. More easily said than done. I've downloaded the gnumeric source and
the stf importer is a very sophisticated piece of code, spread across
several files. Not sure it's worth the effort.
-------------------------------------------------------
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:26 p.m.
On Sun, 22 Feb 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 22 Feb 2015, Riccardo (Jack) Lucchetti wrote:
> The one that gnumeric has is incredibly good, the best one I've ever seen
> in a spreadsheet. Perhaps we could rip it off theirs to some extent.
Whoa. More easily said than done. I've downloaded the gnumeric source and the
stf importer is a very sophisticated piece of code, spread across several
files. Not sure it's worth the effort.
I agree their importer is very good, but I suspected that borrowing it
might not be easy. Thanks for checking.
Allin
4:19 p.m.
On Sun, 22 Feb 2015, Allin Cottrell wrote:
A fix shouldn't be too far away. But this time I think I'll
put in a
"backstop": if we find ourselves having to construct a "string table"
for
data that are composed of nothing but digits, dot and comma, we should flag
an error and give up instead of accepting the data as string-valued.
Excellent idea.
-------------------------------------------------------
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:10 p.m.
On Sun, 22 Feb 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 22 Feb 2015, Allin Cottrell wrote:
> A fix shouldn't be too far away. But this time I think I'll put in a
> "backstop": if we find ourselves having to construct a "string
table" for
> data that are composed of nothing but digits, dot and comma, we should flag
> an error and give up instead of accepting the data as string-valued.
Excellent idea.
That's now in CVS and snapshots.
The problem with reading Thorsten's new data file was simpler than I
guessed (and nothing to do with dates). There was an oversight in the
code that meant it was not general enough: we got lucky with the first
file Thorsten posted, the second one exposed the flaw. Now fixed.
Allin
3622
days inactive
3622
days old
9 comments
4 participants
participants (4)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Wingenroth, Thorsten