4:51 p.m.
In August I raised the possibility of extending the dummify function
to accommodate syntax such as
list dlist = dummify(x, n)
where n <= 0 means that no category is dropped, while n > 0 means
that the n-th category is dropped. For this to work, it would be
necessary to require that x is a series, whereas in its current
version dummify(X) will work with a list X.
After some discussion I think that this was put on the list of
backwards incompatible changes, but it does not appear in the current
version of the gretl wiki which discusses such changes. Is there a
consensus that the extension is desirable or are there reasons for
not implementing it?
As with other things my proposal is driven by the difficulty of
programming functions. The command "dummify x" will create a
complete set of dummy variables. The difficulty is that in a
function it is quite difficult to turn these dummy variables into a
list when you don't know how many values x may take, whether they are
consecutive, etc. On the other hand, the command "list
dlist=dummify(x)" will always drop the first category. There is a
clumsy way of generating the missing dummy variable by using matrices
but it is inefficient and will fail in some circumstances. Hence,
the more flexible syntax is much cleaner.
Gordon
4:58 p.m.
On Wed, 24 Sep 2008, Gordon Hughes wrote:
In August I raised the possibility of extending the dummify
function to accommodate syntax such as
list dlist = dummify(x, n)
where n <= 0 means that no category is dropped, while n > 0
means that the n-th category is dropped. For this to work, it
would be necessary to require that x is a series, whereas in its
current version dummify(X) will work with a list X...
I'm playing with this at present. If I remember right, there
seemed to a consensus last time round that we don't really lose by
confining the dummify() function to a single series argument (not
a list), since it's likely to be confusing to run dummify on a
list anyway (and if you really want to do that you can use a
"foreach" loop).
Suggestion: allow the syntax
list L = dummify(x)
for series x, in which case all the dummies are generated; and
also support
list L = dummify(x, val)
which treats 'val' as the omitted category. (That is, the second
argument to dummify() is optional).
That leaves a question: is it easier/more intuitive to read 'val'
as denoting the val'th category when the distinct values of x are
ordered, or as the condition x == val? I tend to think the latter
is better. Example: in relation to the variable Y in greene22_2,
we have
? matrix v = values(Y)
Generated matrix v
? v
v (6 x 1)
0
1
2
3
7
12
To generate dummies for all values of Y other than 7, do we do
list DL = dummify(Y, 5) # or 0-based, (Y, 4)??
or
list DL = dummify(Y, 7) # what I tend to favor
On the latter approach, you could do
DL = dummify(x, min(x))
DL = dummify(x, max(x))
to skip the first or last categories without counting them.
Allin.
9:48 p.m.
New subject: Russian localization in process
Hello!
Recently I've reported bad symbols in Russian titles in gnuplot. When I
checked this on WinXP - everything was fine. So, there was GNU/Linux
specific problem.
Bad cyrillic text was 'rectangles', that usually means lack of symbols
in font. When I add 'FreeSans.ttf' from my distribution to 'share/fonts'
and
{ "FreeSans", "Free Sans" },
to gpt_dialog.c:558, make, make install - everything went correct. Are
really fonts, bundled with gretl, go without cyrillic symbols? Perhaps
it should be replaced?
Also, I've found some strings, that are not marked for translation:
printout.c:529
discrete.c:1265
fnsave.c:412,421,1193,1330,... - lots of them in this file
Alexander Gedranovich
gedranovich(a)gmail.com
11:02 p.m.
New subject: Russian localization in process
On Mon, 29 Sep 2008, Alexander B. Gedranovich wrote:
Recently I've reported bad symbols in Russian titles in gnuplot.
When I checked this on WinXP - everything was fine. So, there
was GNU/Linux specific problem.
Bad cyrillic text was 'rectangles', that usually means lack of
symbols in font. When I add 'FreeSans.ttf' from my distribution
to 'share/fonts' and
{ "FreeSans", "Free Sans" },
to gpt_dialog.c:558, make, make install - everything went
correct. Are really fonts, bundled with gretl, go without
cyrillic symbols? Perhaps it should be replaced?
I've now added FreeSans to the gretl fonts directory, but I'm
puzzled, because I can see correct cyrillic characters using the
fonts supplied before (luxi and Vera).
Also, I've found some strings, that are not marked for
translation:
printout.c:529
discrete.c:1265
fnsave.c:412,421,1193,1330,... - lots of them in this file
Thanks. Some of these strings are "experimental" and subject to
change, and hence have not been marked for translation. But some
of them probably should be so marked now.
Allin.
5687
days inactive
5691
days old
3 comments
3 participants
participants (3)
-
Alexander B. Gedranovich -
Allin Cottrell -
Gordon Hughes