4:32 p.m.
Dear all, The example to explain the situation with comments and a question attached Oleh
6:59 p.m.
Am 04.01.2016 um 17:32 schrieb oleg_komashko(a)ukr.net:
Dear all,
The example to explain the situation
with comments and a question attached
Oleh
!
I don't quite understand; are you suggesting that the square() function
should eliminate some of its output based on your given example usage?
If that's the point, I'm against it. If you don't want the cross product
with a constant, then why don't you remove the constant from the input list?
-s
7:41 p.m.
Dear Sven,
Gretl supplies 2 possibilities to
get cross products (besides doing it by hand)
square() and list1^list2
suppose we have something like this
wage = beta_0+......+beta_i*age*(D_gender=0) +beta_j*age*(D_gender=1)
i.e. we want to understand whether wage depends on age differently
for different gender
While it is easy to create all one needs in the example above,,
in case of many levels square() will give nothing,
and list1^list2 will give too much.
Additionally, for, example stata have option
for, say x,c*d.i where d.i can have 3 or more values
Objections, in my opinion, should include
evidence why stata is wrong here
Oleh
10 січня 2016, 21:00:06, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 04.01.2016 um 17:32 schrieb oleg_komashko(a)ukr.net:
> Dear all,
> The example to explain the situation
> with comments and a question attached
> Oleh
> !
>
I don't quite understand; are you suggesting that the square() function
should eliminate some of its output based on your given example usage?
If that's the point, I'm against it. If you don't want the cross product
with a constant, then why don't you remove the constant from the input list?
-s
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
11:13 p.m.
On Sun, 10 Jan 2016, oleg_komashko(a)ukr.net wrote:
Dear Sven,
Gretl supplies 2 possibilities to
get cross products (besides doing it by hand)
square() and list1^list2
suppose we have something like this
wage = beta_0+......+beta_i*age*(D_gender=0) +beta_j*age*(D_gender=1)
i.e. we want to understand whether wage depends on age differently
for different gender
While it is easy to create all one needs in the example above,,
in case of many levels square() will give nothing,
and list1^list2 will give too much.
Additionally, for, example stata have option
for, say x,c*d.i where d.i can have 3 or more values
Objections, in my opinion, should include
evidence why stata is wrong here
Dear Oleh,
the "xi:" construct in stata has its pros and cons.
What we do is work with lists, which makes everything different. For
example, we have the += and -= operators, which they don't have.
They are not wrong, nor are we. It's just a different mindset. If you like
stata better, please please please use stata.
-------------------------------------------------------
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
-------------------------------------------------------
midnight
On Mon, 11 Jan 2016, Riccardo (Jack) Lucchetti wrote:
On Sun, 10 Jan 2016, oleg_komashko(a)ukr.net wrote:
> Dear Sven,
> Gretl supplies 2 possibilities to
> get cross products (besides doing it by hand)
> square() and list1^list2
> suppose we have something like this
> wage = beta_0+......+beta_i*age*(D_gender=0) +beta_j*age*(D_gender=1)
> i.e. we want to understand whether wage depends on age differently
> for different gender
> While it is easy to create all one needs in the example above,,
> in case of many levels square() will give nothing,
> and list1^list2 will give too much.
> Additionally, for, example stata have option
> for, say x,c*d.i where d.i can have 3 or more values
> Objections, in my opinion, should include
> evidence why stata is wrong here
Dear Oleh,
the "xi:" construct in stata has its pros and cons.
What we do is work with lists, which makes everything different. For example,
we have the += and -= operators, which they don't have.
They are not wrong, nor are we. It's just a different mindset. If you like
stata better, please please please use stata.
And besides: could you please enlighten me on what is
hard/counterintuitive/odd/quirky/inefficient in the example below?
<hansl>
open data6-4.gdt
join data7-1 D
setinfo D --description="Male"
list X = const EXPER D
list Y = EDUC AGE
list Z = D ^ Y
ols WAGE X Y Z
</hansl>
-------------------------------------------------------
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:03 a.m.
Dear Riccardo,
I didn't intended to say stata is better,
I did only mean I did not proposed
some freak self-backed oddities.
For example, list1^list construction
is useful in constructing Chow-type tests.
What I like to have is additional possibilities
to create quickly interactions of continuous
variables with group dummies.
Unfortunately, I do not know currently
how to do it in Hansl quickly since
setinfo --discrete does not work inside functions.
In most cases I try to write myself what I
wish to have in Gretl as packages.
Does your words about stata mean
I am an unwanted person by some reasons?
11 січня 2016, 01:14:13, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 10 Jan 2016, oleg_komashko(a)ukr.net wrote:
> Dear Sven,
> Gretl supplies 2 possibilities to
> get cross products (besides doing it by hand)
> square() and list1^list2
> suppose we have something like this
> wage = beta_0+......+beta_i*age*(D_gender=0) +beta_j*age*(D_gender=1)
> i.e. we want to understand whether wage depends on age differently
> for different gender
> While it is easy to create all one needs in the example above,,
> in case of many levels square() will give nothing,
> and list1^list2 will give too much.
> Additionally, for, example stata have option
> for, say x,c*d.i where d.i can have 3 or more values
> Objections, in my opinion, should include
> evidence why stata is wrong here
Dear Oleh,
the "xi:" construct in stata has its pros and cons.
What we do is work with lists, which makes everything different. For
example, we have the += and -= operators, which they don't have.
They are not wrong, nor are we. It's just a different mindset. If you like
stata better, please please please use stata.
-------------------------------------------------------
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
-------------------------------------------------------
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
12:36 a.m.
On Mon, 11 Jan 2016, oleg_komashko(a)ukr.net wrote:
Dear Riccardo,
I didn't intended to say stata is better,
I did only mean I did not proposed
some freak self-backed oddities.
For example, list1^list construction
is useful in constructing Chow-type tests.
What I like to have is additional possibilities
to create quickly interactions of continuous
variables with group dummies.
Unfortunately, I do not know currently
how to do it in Hansl quickly since
setinfo --discrete does not work inside functions.
In most cases I try to write myself what I
wish to have in Gretl as packages.
Does your words about stata mean
I am an unwanted person by some reasons?
Of course not, don't be silly. What I wanted to say is: if you think that
stata is closer to your taste, use stata. I won't feel offended. Use stata
for the things you like stata for, use R for the things you prefer R for,
use gretl for the things you like gretl better for.
As for interactions, I find that using lists is infinitely superior and
more elegant than the "xi" mechanism. But perhaps it's just me.
Like Sven said, you can't expect others to find it reasonable to bend a
language (Hansl) to the point of contiortionism because YOU can't be
bothered to do things in more than one line of code. If "setinfo
--discrete" doesn't work inside functions (which makes sense IMO),
then set the bloody variable as discrete OUTSIDE THE BLOODY FUNCTION,
for chrissake.
-------------------------------------------------------
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
-------------------------------------------------------
3279
days inactive
3286
days old
6 comments
3 participants
participants (3)
-
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber