10:11 a.m.
Dear all,
I'm aware that backward-incompatibilty should in principle be avoided.
However, it occurred to me that we introduced string arrays only
after (more or less) clever workarounds to their absence. Typical cases
are:
* the modprint command
* the varname() function (yes I know about varnames(), but it's a hack)
* the jsonget() function
* the labels command
* the colnames() and rownames() function
etc etc.
Clearly, a redesign of all these would be optimal, but it would involve a
major revision of hundreds of scripts out there; however, like always, the
sooner this is done, the better.
Opinions?
-------------------------------------------------------
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
-------------------------------------------------------
9:04 a.m.
Am 07.12.2015 um 11:11 schrieb Riccardo (Jack) Lucchetti:
Dear all,
I'm aware that backward-incompatibilty should in principle be avoided.
However, it occurred to me that we introduced string arrays only after
(more or less) clever workarounds to their absence. Typical cases are:
* the modprint command
* the varname() function (yes I know about varnames(), but it's a hack)
* the jsonget() function
* the labels command
* the colnames() and rownames() function
With some of these functions/commands it's not clear to me right now how
string arrays would enter the picture, simply because I'm not too
familiar with some of these.
etc etc.
Clearly, a redesign of all these would be optimal, but it would involve
a major revision of hundreds of scripts out there; however, like always,
the sooner this is done, the better.
I'll not talk about the general issue of (breaking) backwards
compatibility right now in this context, which is always difficult, but
in principle I still think there's always the danger of developers'
tendency to play around and tinker with their project, instead of
providing something stable to the users. And to paraphrase Allin, the
number of bugs may be finite at each point in time, but dynamically it
can become infinity.
But in this case I'm really skeptical about "sooner is better". In my
view the array support in gretl is still not mature enough. For example,
just recently (and still undocumented?) the possibility to assign array
elements directly in one go was introduced. (See Allin's message about
mkarray() from last month.)
And especially for string arrays, I think most of the string search and
manipulation functions would need to work with arrays or have the
respective analogues.
thanks,
sven
9:02 a.m.
On Tue, 8 Dec 2015, Sven Schreiber wrote:
Am 07.12.2015 um 11:11 schrieb Riccardo (Jack) Lucchetti:
> Dear all,
>
> I'm aware that backward-incompatibilty should in principle be avoided.
> However, it occurred to me that we introduced string arrays only after
> (more or less) clever workarounds to their absence. Typical cases are:
>
> * the modprint command
> * the varname() function (yes I know about varnames(), but it's a hack)
> * the jsonget() function
> * the labels command
> * the colnames() and rownames() function
With some of these functions/commands it's not clear to me right now how
string arrays would enter the picture, simply because I'm not too
familiar with some of these.
Mainly as a reminder to myself: it just occurred to me that it'd be very
beneficial to use matrix arrays to represent complex matrices in all the
cases where we resort to some degree of contortionism to that effect.
For example, eigengen(): I would favour a new function (say, eigengen2()),
in which we return a 3-elements matrix array (eigenvalues, left and right
eigenvectors) if the result is purely real and a 6-elements array if it's
complex, with elements 4, 5, and 6 holding the imaginary parts. Just
sayin'.
-------------------------------------------------------
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
-------------------------------------------------------
2:37 p.m.
On Mon, 7 Dec 2015, Riccardo (Jack) Lucchetti wrote:
Dear all,
I'm aware that backward-incompatibilty should in principle be
avoided. However, it occurred to me that we introduced string
arrays only after (more or less) clever workarounds to their
absence. Typical cases are:
* the modprint command
* the varname() function (yes I know about varnames(), but it's a hack)
* the jsonget() function
* the labels command
* the colnames() and rownames() function
etc etc.
Clearly, a redesign of all these would be optimal, but it would
involve a major revision of hundreds of scripts out there;
however, like always, the sooner this is done, the better.
Opinions?
Sven's response included this: "In my view the array support in
gretl is still not mature enough. For example, just recently (and
still undocumented?) the possibility to assign array elements
directly in one go was introduced."
I take Sven's point: Jack's question should be addressed but first
we need to put arrays on a more regular, better documented footing.
In that context let me pose a question.
As a reminder, the undocumented mkarray() function allows you to
define an array by listing its members as arguments, as in
strings S = mkarray("foo", "bar", "baz")
which is equivalent to
strings S = array(3)
S[1] = "foo"
S[2] = "bar"
S[3] = "baz"
Before I document this let me float an idea. We could rename
mkarray() as just array(), but preserve the existing functionality
of array() -- that is, to create an array of specified size with
each member initialized to an appropriate "empty" value -- in this
way: if the function is given a single, scalar argument it acts as
array() currently acts, otherwise it acts as mkarray(). [Note that
we don't accept scalars as arguments to mkarray(); you can't have an
array of scalars as such.]
Question(s): is this too tricksy? And if it is too tricksy and we
want two separate functions, is the name "mkarray" alright for the
new one or can anyone think of a better name?
Once this is resolved let's come back to Jack's question.
Allin
3:21 p.m.
On Sun, 13 Dec 2015, Allin Cottrell wrote:
Before I document this let me float an idea. We could rename
mkarray() as
just array(), but preserve the existing functionality of array() -- that is,
to create an array of specified size with each member initialized to an
appropriate "empty" value -- in this way: if the function is given a single,
scalar argument it acts as array() currently acts, otherwise it acts as
mkarray(). [Note that we don't accept scalars as arguments to mkarray(); you
can't have an array of scalars as such.]
Question(s): is this too tricksy? And if it is too tricksy and we want two
separate functions, is the name "mkarray" alright for the new one or can
anyone think of a better name?
No, it isn't. In fact, I find it brilliant. array("3") would be
different from array({3}) which would be, in turn, different from
array(3) (where the last expression would need an explicit type
declaration, eg, "matrices"). I'm all for it.
The only problems (of clarity, mainly) would arise in certain contexts,
due to the subtleties of implicit type conversion. For example:
<hansl>
foo = array(3 + I(1))
list X = a b c
loop foreach i X
zoo_$i = array($i)
endloop
</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
-------------------------------------------------------
3:35 p.m.
New subject: string arrays: slightly aside ask
Dear Allin, You have just mentioned about undocumented mkarray() function/ Can you place a
list of undocumented functions and accessors in one message? Oleh
4:17 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
Dear Allin, You have just mentioned about undocumented mkarray()
function/ Can you place a list of undocumented functions and accessors
in one message? Oleh
https://pbs.twimg.com/media/BgbRcz7CcAA22bX.jpg
They're undocumented for a reason, you know ;)
-------------------------------------------------------
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
-------------------------------------------------------
7:57 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
Dear Allin, You have just mentioned about undocumented mkarray()
function/ Can you place a list of undocumented functions and
accessors in one message?
Actually, I think that's a reasonable request. I, too, would like to
have easy access to a list of undocumented stuff. Trouble is, once
something undocumented has been lying around for a while it's hard
for anyone (for example, me!) to remember. Should it be documented,
should it be removed, or what? That will never get answered if
everyone has forgotten about it.
So... actually I'm not going to give you a fish, but rather teach
you how to fish ;-) In fact, we have functionality to check this in
the gretl source tree, but I see it has been subject to bit-rot.
I've now renovated it in git -- so you'll need current git to do
this right:
Navigate to the doc/commands directory in the gretl source tree --
or your build tree if you're building outside of the source (which
is recommended, BTW) -- and do "make check". You'll probably want to
redirect output to a file. What you get is a detailed comparison of
what's in the actual source and what's documented. It's not perfect
-- there will be a few "false positives" -- but it gives a pretty
good picture of the current state of play.
Allin
8:14 p.m.
New subject: string arrays: slightly aside ask
Thank you, I'll try it later Oleh
P.S. there are also some items in books (User's guide, etc), but not in the list, e.g.
funcerr $dotdir $gretldir
13 грудня 2015, 21:57:10, від "Allin Cottrell" < cottrell(a)wfu.edu >:
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
Dear Allin, You have just mentioned about undocumented mkarray()
function/ Can you place a list of undocumented functions and
accessors in one message?
Actually, I think that's a reasonable request. I, too, would like to
have easy access to a list of undocumented stuff. Trouble is, once
something undocumented has been lying around for a while it's hard
for anyone (for example, me!) to remember. Should it be documented,
should it be removed, or what? That will never get answered if
everyone has forgotten about it.
So... actually I'm not going to give you a fish, but rather teach
you how to fish ;-) In fact, we have functionality to check this in
the gretl source tree, but I see it has been subject to bit-rot.
I've now renovated it in git -- so you'll need current git to do
this right:
Navigate to the doc/commands directory in the gretl source tree --
or your build tree if you're building outside of the source (which
is recommended, BTW) -- and do "make check". You'll probably want to
redirect output to a file. What you get is a detailed comparison of
what's in the actual source and what's documented. It's not perfect
-- there will be a few "false positives" -- but it gives a pretty
good picture of the current state of play.
Allin
8:28 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
Thank you, I'll try it later Oleh
P.S. there are also some items in books (User's guide, etc), but not in
the list, e.g. funcerr $dotdir $gretldir
Allin's solution will cover the commands. For the functions, your bes bet
is taking a look at the file lib/src/genlex.c. The juicy stuff starts at
line 48.
-------------------------------------------------------
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
-------------------------------------------------------
8:40 p.m.
New subject: string arrays: slightly aside ask: thanks
Thank you, Riccardo Oleh
13 грудня 2015, 22:28:24, від "Riccardo (Jack) Lucchetti" <
r.lucchetti(a)univpm.it >:
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
Thank you, I'll try it later Oleh
P.S. there are also some items in books (User's guide, etc), but not in
the list, e.g. funcerr $dotdir $gretldir
Allin's solution will cover the commands. For the functions, your bes bet
is taking a look at the file lib/src/genlex.c. The juicy stuff starts at
line 48.
-------------------------------------------------------
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-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:01 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
> Thank you, I'll try it later Oleh
>
> P.S. there are also some items in books (User's guide, etc), but not in the
> list, e.g. funcerr $dotdir $gretldir
Allin's solution will cover the commands. For the functions, your bes bet is
taking a look at the file lib/src/genlex.c. The juicy stuff starts at line
48.
Actually my solution will cover functions/accessors too, except that
I forgot to "push" my last few commits -- still getting used to git!
Done now.
Allin
9:13 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, Allin Cottrell wrote:
On Sun, 13 Dec 2015, Riccardo (Jack) Lucchetti wrote:
> On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
>
>> Thank you, I'll try it later Oleh
>>
>> P.S. there are also some items in books (User's guide, etc), but not in
>> the list, e.g. funcerr $dotdir $gretldir
>
> Allin's solution will cover the commands. For the functions, your bes bet
> is taking a look at the file lib/src/genlex.c. The juicy stuff starts at
> line 48.
Actually my solution will cover functions/accessors too, except that I forgot
to "push" my last few commits -- still getting used to git!
Done now.
Aaaaaahhh, cool, thanks.
There's stuff I'd totally forgotten about!
-------------------------------------------------------
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:09 p.m.
New subject: string arrays: slightly aside ask
On Sun, 13 Dec 2015, Riccardo (Jack) Lucchetti wrote:
On Sun, 13 Dec 2015, Allin Cottrell wrote:
> On Sun, 13 Dec 2015, Riccardo (Jack) Lucchetti wrote:
>
>> On Sun, 13 Dec 2015, oleg_komashko(a)ukr.net wrote:
>>
>>> Thank you, I'll try it later Oleh
>>>
>>> P.S. there are also some items in books (User's guide, etc), but not in
>>> the list, e.g. funcerr $dotdir $gretldir
>>
>> Allin's solution will cover the commands. For the functions, your bes bet
>> is taking a look at the file lib/src/genlex.c. The juicy stuff starts at
>> line 48.
>
> Actually my solution will cover functions/accessors too, except that I
> forgot to "push" my last few commits -- still getting used to git!
> Done now.
Aaaaaahhh, cool, thanks.
There's stuff I'd totally forgotten about!
Yeah, me too! One stand-out is that it's high time we moved the MPI
documentation, currently sitting on its own at
http://ricardo.ecn.wfu.edu/~cottrell/gretl/gretl-mpi.pdf
into the packaged docs (after suitable modification from its present
Q and A format). So far as I'm concerned this is "stable" stuff,
though if anyone has information to the contrary, please let us
know.
Allin
3335
days inactive
3342
days old
13 comments
4 participants
participants (4)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber