Excel 2003 xls format
by Riccardo (Jack) Lucchetti
I've had a report from a user who wasn't able to open via gretl an xls
file created by Excel 2003. Since I don't have access to the software, I'm
not able mayself to do any type of check.
Could someone please try this and report the results?
If MS changed the xls format so gretl's unable to read the newer files,
there are a few things we may do: in the short run, we should advise Excel
users to save their files using an older format. When we have time
(presumably, after 1.6.6), we should IMO provide support for it. From a
quick web search, it looks like the xls 2003 format isn't officially
documented anywhere, but apparently it has been reverse-engineered by the
Openoffice.org people. I _think_ gnumeric should handle it too: if it
does, that's great, because the way gnumeric is written is much more
similar to gretl than openoffice, and it should be much easier to rip
code from them.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
18 years, 10 months
de.po update
by Sven Schreiber
I just committed the final(?) update to the German translation for
1.6.6. As always, it would be nice if another snapshot could be provided
before release, to see if I broke anything.
On a completely unrelated issue, it looks as if I will soon have a
MacOSX system to play with. Some time ago it was indicated that you
could need help with building on Mac, and starting in December or
January I will hopefully be in the position to do that.
cheers,
sven
18 years, 10 months
Bug tracking
by Sven Schreiber
Ok, about establishing bug tracking on Sourceforge:
There is some export mechanism if we need it later on (the following
copied from the sf support pages):
<sf help>
XML Export
The XML Data Export facility provides Tracker data, DocManager data and
Project News releases in an XML format. Due to the limited visibility of
data in disabled or project member-only Trackers (which will appear in
this export), the XML Data Export may only be accessed by Project
Administrators.
The XML Data Export facility may be accessed by Project Administrators
from the "Backup" section of the Project Admin pages for the project.
The XML Data Export facility will provide a complete set of Tracker
data, less file attachments, from all Trackers for a project. This data
may then be parsed from its XML format for inclusion in spreadsheets or
for further analysis by the project.
</sf help>
So I would suggest to start the bug tracking! There are some needed
setup tasks (I think Allin as the project admin has to do this):
1) disable SF patches tracker (to avoid confusion and only keep the
trackers that are really used)
2) disable SF support requests tracker (dito, support is on the mailing
list)
(2b: unrelated: maybe also disable SF mailing lists, referring to the
existing lists)
3) make me the "Tracker Admin" for the remaining two trackers, namely
"bug reports" and "feature requests/RFE" (Tracker -> Admin -> choose
which tracker -> "Add/Update Users & Permissions"...)
After (3) I think I should be able to do (if not I'll get back to you):
4) allow unauthenticated issue submissions, because we don't want to
scare off users by having to register, right? (Tracker -> Admin ->
choose which tracker -> update preferences -> allow non-logged-in
postings -> submit)
5) maybe set other options, such as public tracker display, automated
emails to the team, ...
I'm not sure if the priority attribute is necessary, but given the scale
of 1-9 I suggest the following meanings for the bug tracker (note that
feature requests have their own tracker, and do not appear here):
9: crashes the entire computer, sets the house on fire, or x-rays the
backup disk in the closet
8: dataloss without gretl crashing (higher priority than a crash-loss
because it could go unnoticed)
7: gretl crashes (assuming such a thing always implies possible dataloss)
6: leads to wrong results/numbers (higher priority than giving no result
at all)
5: default priority for new issues
4: a feature doesn't work, although it should
3: documentation is missing
2: cosmetic issues like bad formatting
1: reserved for spam-type issues
About the "categories" and "groups", let's see later if/how we can use them.
-sven
18 years, 10 months
Regarding long variable names
by andreas.rosenblad＠ltv.se
Would it be terribly difficult to let gretl allow longer variable lengths?
For example, function names are allowed to have 31 characters. Couldn't
variable names also be allowed to have 31 characters?
Andreas
cottrell(a)wfu.edu @ INTERNET skrev 2007-10-27 21:29:41 :
> On Sat, 27 Oct 2007, Sven Schreiber wrote:
>
> > the snapshot from Oct 21 crashed for me repeatedly, and it looks >
> like it has to do with long (more than 16 chars) variable names >
> that were entered via "define new variable".
>
> Thanks for the report. The maximum length of variable names was not
> being properly enforced. Fixed in CVS.
>
> Allin.
18 years, 10 months
Ang. Re: [Gretl-devel] Regarding long variable names
by andreas.rosenblad＠ltv.se
OK. How about matrix and scalar names, are the output-formatting constr
aints applicable for these too?
I don't think the variable length is the most important question for gretl,
there are other much more important questions, but if it was not too hard
to implement it would make it easier to write functions if longer names
were allowed, especially for matrices and scalars.
Andreas
cottrell(a)wfu.edu @ INTERNET skrev 2007-10-29 14:45:58 :
> On Mon, 29 Oct 2007, andreas.rosenblad(a)ltv.se wrote:
>
> > Would it be terribly difficult to let gretl allow longer > variable
lengths?
>
> Yes. Basically, it would require that all output-formatting
> routines be re-written from scratch. With 15-character variable
> names we're at the limit of what we can support using the current
> formats, and given a sensible maximum line length of around 80
characters.
>
> Allin.
>
18 years, 10 months
Making the programming of user defined functions easier
by andreas.rosenblad＠ltv.se
To make the programming of user defined functions easier, I would like to
have access to the following new commands in gretl:
1. sampleranks() or tiedranks() or rankorder(): A function taking as input
one or two data series or matrix vectors and returning a series or matrix
vector with the sample ranks of the values in these, from smallest to
largest, with ties, i.e., equal values, resulting in ranks being averaged.
For example sampleranks(x) would rank the observations from variable x
only, while sampleranks(x,y) would rank the observations from both
variables jointly.
2. floor(): Round down to nearest integer. A complement to the current
commands ceil(), that round up to nearest integer. As int() gives just the
integer part, it gives the same value as floor() for positive values but
the values for ceil() for negative values, thus floor() is needed for
obtaining a round down to nearest integer for negative values. And floor()
is a standrad matematical function that shouldn't be absent from gretl.
3. factorial(): Taking a nonnegative integer as input, with factorial(n) =
n! Of course one can use gammafunc(n+1) instead, but factorial(n) would be
more intuitive.
4. permutation(): Taking two nonnegative integers as input, with
permutation(n,x) = n!/(n-x)!, i.e., the number of possible arrangements
when x objects are to be selected from a total of n and arranged in order.
Of course one can use gammafunc(n+1)/gammafunc(n-x+1) instead, but
permutation(n,x) is easier and more intuitive.
4. combination(): Taking two nonnegative integers as input, with
combination(n,x) = n!/x!(n-x)!, i.e., the number of possible selections
when x objects are to be selected from a total of n and order is not of
importance. Of course one can use
gammafunc(n+1)/gammafunc(x+1)*gammafunc(n-x+1) instead, but
combination(n,x) is easier and more intuitive.
Best regards
Andreas
18 years, 10 months
reading CSV files
by Allin Cottrell
There are a couple of modifications in CVS and the Windows
snapshot, based on recent discussions.
1) Non-numeric data. Up till now we've treated a given data
column as string-coded only if the first observation is
non-numeric. Now we're more generous, and treat any column that
contains non-numeric values as a coding, subject to the following
qualification (designed to catch genuine data errors):
* If there's only one non-numeric value in a given column, or if
the non-numeric values amount to less than 1 percent of the total
non-missing values, we give up on the coding and flag an error.
The user can override this qualification for specific named
columns using "set codevars <list of names>" or can override it
globally by adding the "--coded" flag to the "open" command.
Also, as suggested by Jack, we automatically flag variables
treated in this way as discrete.
2) BLS-type data files with "five quarters" or "13 months": gretl
will now read at least some such files correctly, disregarding the
extra lines. However, my feeling is that the BLS is playing silly
buggers with this sort of file and that somebody should file a bug
report with them.
If a file of this type is not recognized, then besides the nice
and easy "grep -v" method suggested by Jack, it's also easy to
clean up such files using gretl's data manipulation tools. For
example, for a "five-quarter" data file where the data start in
1950Q1:
open nonsense.csv
genr index
smpl (index % 5 > 0) --restrict
setobs 4 1950:1
store sensible.gdt
Allin
18 years, 10 months
crash with long variable names
by Sven Schreiber
Hi,
the snapshot from Oct 21 crashed for me repeatedly, and it looks like it
has to do with long (more than 16 chars) variable names that were
entered via "define new variable". It doesn't crash on creating the new
variable, but later on when right-clicking that variable or doing other
stuff with it. When gretl doesn't crash, it sometimes truncates the
names (maybe always, not sure). Sometimes, after creating that variable
and doing something which does not lead to a crash straight away, the
computer beeps. On the next action after a beep, gretl always seems to
crash.
Obviously, this is quite serious as it leads to dataloss.
Thanks,
Sven
18 years, 10 months
some new gretl issues
by Sven Schreiber
Hi,
before getting to the issues list I put together during my last
semi-serious gretl session, I want to support the idea of a more formal
bug collection & management approach that came up recently. Among other
reasons, I think one gets a nice feeling of job satisfaction when
looking at resolved bugs...
If you want I could do the maintenance of the bug list/database at least
initially. I mean not on my computer at home or by setting up a server,
but just by verifying, classifying, and hopefully closing bug reports
that are stored in some sourceforge/bugzilla/trac/whatever instance.
Somebody said the sourceforge tool is not good, but I'd say we can
always switch to something better later. (Provided that at least the sf
tool has some usable export feature?)
What do you think?
--
Ok, here's the list (on gretl windows snapshot from 9/19, so not the
most recent I'm afraid):
1) the VAR model window doesn't have a close box (apart from the window
manager thing) -- actually I guess all windows that have a menu bar
instead of a toolbar... I know I'm partly responsible because I
requested removing redundant close buttons at the bottom, and this thing
actually isn't a problem, but it caught my attention.
2) with T = 235 and 2 equ with about 20 coeffs each, gretl says it
doesn't have enough dofs for autocorrelation test of order 4 (or
even 1!) -- sometimes it even does that just for estimation! (maybe
triggered by repeatedly checking/un-checking the robust cov option,
which I did?)
3) a big wishlist item or question: how to modify an existing model
instead of starting always from scratch???
4) bug recipe (not 100% sure which part is the bug though):
a) create new dataset
b) save dataset as "test1.gdt"
c) save as session "my1session.gretl"
d) close dataset
e) open above session file, and get the data named "data.gdt" (
instead of "test1.gdt")
5) also observed that saving a subset of variables to a new datafile
doesn't update the variable list/view, but does change the datafile
name above the variable listing. Not sure which part of this
behavior is intended and which is a bug.
Oh BTW, I'm sorry but I won't have time to take another look at de.po
before next week. But if needed for release I can promise Tuesday.
thanks,
sven
18 years, 10 months