6:59 p.m.
Hi,
this is a feature request which I grabbed from an old thread:
"to make one-liners like "r = filter(p | zeros(rows(q)-1, 1), q)" more
economical -and other code as well-
wouldn't it be good if the column number argument of zeros() became
optional with a default of 1, such that zeros(rows(q)-1) would be
equivalent to zeros(rows(q)-1, 1)?
(And the same for: ones(), mnormal(), muniform(), and possibly also
mrandgen().)
That would often be very convenient I think.
Actually if there are no objections about the request maybe that's
something that might be relatively easy to implement, so I might try it
myself.
cheers,
sven
10:57 p.m.
On Thu, 4 Jul 2019, Sven Schreiber wrote:
Hi,
this is a feature request which I grabbed from an old thread:
"to make one-liners like "r = filter(p | zeros(rows(q)-1, 1), q)" more
economical -and other code as well-
wouldn't it be good if the column number argument of zeros() became
optional with a default of 1, such that zeros(rows(q)-1) would be
equivalent to zeros(rows(q)-1, 1)?
(And the same for: ones(), mnormal(), muniform(), and possibly also
mrandgen().)
That would often be very convenient I think.
It would save two keystrokes (or three, if you're in the habit of
separating function arguments with spaces).
Actually if there are no objections about the request maybe
that's
something that might be relatively easy to implement, so I might try it
myself.
I have no objection, though it seems to me of low priority.
Allin
6:37 a.m.
Am 05.07.2019 um 00:57 schrieb Allin Cottrell:
On Thu, 4 Jul 2019, Sven Schreiber wrote:
>
> That would often be very convenient I think.
It would save two keystrokes (or three, if you're in the habit of
separating function arguments with spaces).
I agree it's a matter of taste. But ones(3,1) vs. ones(3) is more than
20% savings ;-)
But honestly, it's more the clear looks than the keystrokes that matter
to me.
> Actually if there are no objections about the request maybe
that's
> something that might be relatively easy to implement, so I might try it
> myself.
I have no objection, though it seems to me of low priority.
OK.
thanks
sven
10:27 p.m.
Am 05.07.2019 um 08:37 schrieb Sven Schreiber:
Am 05.07.2019 um 00:57 schrieb Allin Cottrell:
> On Thu, 4 Jul 2019, Sven Schreiber wrote:
>> Actually if there are no objections about the request maybe
that's
>> something that might be relatively easy to implement, so I might try it
>> myself.
>
> I have no objection, though it seems to me of low priority.
OK, I'm attaching a diff with which I seem to be able to do things like
"zeros(3)". The only affected file was lib/src/geneval.c.
The most difficult thing was actually to understand that in the eval
function (static NODE *eval...) the existing check r == NULL did not
work and had to be replaced with null_or_empty(r). I still don't really
understand why r isn't NULL there, like it is in the contex of F_IMAT.
thanks
sven
3:25 p.m.
On Sun, 7 Jul 2019, Sven Schreiber wrote:
Am 05.07.2019 um 08:37 schrieb Sven Schreiber:
> Am 05.07.2019 um 00:57 schrieb Allin Cottrell:
>> On Thu, 4 Jul 2019, Sven Schreiber wrote:
>>> Actually if there are no objections about the request maybe that's
>>> something that might be relatively easy to implement, so I might try it
>>> myself.
>>
>> I have no objection, though it seems to me of low priority.
OK, I'm attaching a diff with which I seem to be able to do things like
"zeros(3)". The only affected file was lib/src/geneval.c.
The most difficult thing was actually to understand that in the eval
function (static NODE *eval...) the existing check r == NULL did not
work and had to be replaced with null_or_empty(r). I still don't really
understand why r isn't NULL there, like it is in the contex of F_IMAT.
Thanks, Sven. I've now committed your changes. They remain to be
documented.
I've also rejigged some of the macros we use a lot in geneval.c with
the aim of clarifying things a little.
In the eval() switch we should never actually encounter a NULL node
-- a skipped argument should show up as a node with EMPTY type. But
the check against NULL is there for extra safety. I've renamed
"null_or_empty" to "null_node" for brevity.
#define null_node(n) (n == NULL || n->t == EMPTY)
I'm also now using these
#define scalar_node(n) (n->t == NUM || scalar_matrix_node(n))
#define null_or_scalar(n) (null_node(n) || scalar_node(n))
#define null_or_string(n) (null_node(n) || n->t == STR)
to check optional scalar or string arguments, respectively.
Allin
4:37 p.m.
Am 07.07.2019 um 17:25 schrieb Allin Cottrell:
On Sun, 7 Jul 2019, Sven Schreiber wrote:
> OK, I'm attaching a diff with which I seem to be able to do
things like
> "zeros(3)". The only affected file was lib/src/geneval.c.
Thanks, Sven. I've now committed your changes. They remain to be
documented.
Sure, I will also do the documentation soon, it's only fair ;-)
In the eval() switch we should never actually encounter a NULL node
-- a
skipped argument should show up as a node with EMPTY type. But the check
against NULL is there for extra safety. I've renamed "null_or_empty" to
"null_node" for brevity.
Well except for F_IMAT where the second arg isn't skipped but is
actually NULL, right?
thanks,
sven
6:41 p.m.
On Sun, 7 Jul 2019, Sven Schreiber wrote:
Well except for F_IMAT where the second arg isn't skipped but is
actually NULL, right?
Actually, you got me thinking about the possibility of having a second
argiment to I() (aka F_IMAT); in many cases, you want to construct a
matrix that is an identity matrix "plus some zeros"; without loss of
backward compatibility, we may introduce an optional 2nd argument to I()
such that I(r,c) returns
* I(r) ~ zeros(r, c-r) if c > r,
* I(c) | zeros(r-c, c) if r < c
and obviously I(r) if r == c; in this way, building (say) a companion
matrix would be really easy; for example,
comp = A | I(cols(A) - rows(A), cols(A))
Besides, I believe this is what Matlab does, so this would also be nice to
have when porting scripts from the Octave/Matlab galaxy.
Do you guys like the 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
-------------------------------------------------------
9:35 p.m.
Am 07.07.2019 um 20:41 schrieb Riccardo (Jack) Lucchetti:
On Sun, 7 Jul 2019, Sven Schreiber wrote:
Actually, you got me thinking about the possibility of having a
second
argiment to I() (aka F_IMAT); in many cases, you want to construct a
matrix that is an identity matrix "plus some zeros"; without loss of
backward compatibility, we may introduce an optional 2nd argument to I()
such that I(r,c) returns
* I(r) ~ zeros(r, c-r) if c > r,
* I(c) | zeros(r-c, c) if r < c
You mean r > c, but apart from that, why not.
Besides, I believe this is what Matlab does, so this would also be
nice
to have when porting scripts from the Octave/Matlab galaxy.
Yes it seems they do that. Of course, if you want to appeal to those
people, you could also make "eye" an alias for "I", but perhaps that
would rather be something for Peter's matlab_utilities package.
cheers
sven
10:31 p.m.
I like both ideas, and I’ll update matlab_ utilities accordingly.
PS
Sent from my iPad
> On Jul 7, 2019, at 5:36 PM, Sven Schreiber <svetosch(a)gmx.net> wrote:
>
>> Am 07.07.2019 um 20:41 schrieb Riccardo (Jack) Lucchetti:
>>> On Sun, 7 Jul 2019, Sven Schreiber wrote:
>>
>> Actually, you got me thinking about the possibility of having a second
>> argiment to I() (aka F_IMAT); in many cases, you want to construct a
>> matrix that is an identity matrix "plus some zeros"; without loss of
>> backward compatibility, we may introduce an optional 2nd argument to I()
>> such that I(r,c) returns
>>
>> * I(r) ~ zeros(r, c-r) if c > r,
>> * I(c) | zeros(r-c, c) if r < c
>
> You mean r > c, but apart from that, why not.
>
>
>> Besides, I believe this is what Matlab does, so this would also be nice
>> to have when porting scripts from the Octave/Matlab galaxy.
>
> Yes it seems they do that. Of course, if you want to appeal to those
> people, you could also make "eye" an alias for "I", but perhaps
that
> would rather be something for Peter's matlab_utilities package.
>
> cheers
> sven
> _______________________________________________
> Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it
> To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
> Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
10:46 p.m.
On Sun, 7 Jul 2019, Sven Schreiber wrote:
Am 07.07.2019 um 17:25 schrieb Allin Cottrell:
> On Sun, 7 Jul 2019, Sven Schreiber wrote:
>> OK, I'm attaching a diff with which I seem to be able to do things like
>> "zeros(3)". The only affected file was lib/src/geneval.c.
> Thanks, Sven. I've now committed your changes. They remain to be
> documented.
Sure, I will also do the documentation soon, it's only fair ;-)
OK, thanks!
> In the eval() switch we should never actually encounter a NULL
node -- a
> skipped argument should show up as a node with EMPTY type. But the check
> against NULL is there for extra safety. I've renamed "null_or_empty"
to
> "null_node" for brevity.
Well except for F_IMAT where the second arg isn't skipped but is
actually NULL, right?
True. That's a rare case, maybe even unique among the "switch"
clauses in eval().
Allin
11:12 p.m.
On Sun, 7 Jul 2019, Riccardo (Jack) Lucchetti wrote:
On Sun, 7 Jul 2019, Sven Schreiber wrote:
> Well except for F_IMAT where the second arg isn't skipped but is
> actually NULL, right?
Actually, you got me thinking about the possibility of having a second
argiment to I() (aka F_IMAT); in many cases, you want to construct a matrix
that is an identity matrix "plus some zeros"; without loss of backward
compatibility, we may introduce an optional 2nd argument to I() such that
I(r,c) returns
* I(r) ~ zeros(r, c-r) if c > r,
* I(c) | zeros(r-c, c) if r < c
and obviously I(r) if r == c; in this way, building (say) a companion matrix
would be really easy; for example,
comp = A | I(cols(A) - rows(A), cols(A))
Besides, I believe this is what Matlab does, so this would also be nice to
have when porting scripts from the Octave/Matlab galaxy.
Do you guys like the idea?
Yes. It's now in git.
Allin
6:12 a.m.
On Sun, 7 Jul 2019, Allin Cottrell wrote:
> Do you guys like the idea?
Yes. It's now in git.
Thanks; besides, we could extend Sven's idea to mshape() and make the
third argument optional (defaulting to 1, of course). Is this a good 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
-------------------------------------------------------
6:25 a.m.
Am 08.07.2019 um 08:12 schrieb Riccardo (Jack) Lucchetti:
On Sun, 7 Jul 2019, Allin Cottrell wrote:
>> Do you guys like the idea?
>
> Yes. It's now in git.
Thanks; besides, we could extend Sven's idea to mshape() and make the
third argument optional (defaulting to 1, of course). Is this a good idea?
Not sure I like the default 1. If X has exactly r elements,
mshape(X,r,1) can be easily achieved by vec(X), right? And it seems to
me it is not a very standard case to use mshape(X,r,1) for r != nelem(X).
What might be nice is to make mshape more clever, to automatically
determine the necessary number of columns c. Example:
matrix X = ones(3,2)
m1 = mshape(X,2,3) # old explicit syntax
m2 = mshape(X,2) # proposed
That is, if the 3rd arg is omitted, mshape would try to calculate c =
nelem(X) / r. (It would throw an error if the result is not an integer.)
cheers
sven
7 a.m.
On Mon, 8 Jul 2019, Sven Schreiber wrote:
Am 08.07.2019 um 08:12 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 7 Jul 2019, Allin Cottrell wrote:
>
>>> Do you guys like the idea?
>>
>> Yes. It's now in git.
>
> Thanks; besides, we could extend Sven's idea to mshape() and make the
> third argument optional (defaulting to 1, of course). Is this a good idea?
Not sure I like the default 1. If X has exactly r elements,
mshape(X,r,1) can be easily achieved by vec(X), right? And it seems to
me it is not a very standard case to use mshape(X,r,1) for r != nelem(X).
In fact, what I had in mind is the idiom "mshape(NA, r, c)", taht I use a
lot for initialising matrices.
What might be nice is to make mshape more clever, to automatically
determine the necessary number of columns c. Example:
matrix X = ones(3,2)
m1 = mshape(X,2,3) # old explicit syntax
m2 = mshape(X,2) # proposed
That is, if the 3rd arg is omitted, mshape would try to calculate c =
nelem(X) / r. (It would throw an error if the result is not an integer.)
I quite like this; actually, in case r*c is not an exact multiple of
nelem(X), we could allow for "wrapping", that is
mshape(seq(1,4), 3)
could return
1 4
2 1
3 2
-------------------------------------------------------
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
-------------------------------------------------------
1:58 p.m.
On Mon, 8 Jul 2019, Sven Schreiber wrote:
Am 08.07.2019 um 08:12 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 7 Jul 2019, Allin Cottrell wrote:
>
> > > Do you guys like the idea?
> >
> > Yes. It's now in git.
>
> Thanks; besides, we could extend Sven's idea to mshape() and make the
> third argument optional (defaulting to 1, of course). Is this a good idea?
Not sure I like the default 1.
I'm also a bit skeptical. Given the "shape" in mshape() I think it's
OK to make the user actually specify a shape.
What might be nice is to make mshape more clever, to automatically
determine the necessary number of columns c.
I'm not too keen on that either. The way mshape() works currently
there isn't a "necessary number of columns":
<quote>
If X contains fewer than k = rc elements, the elements are repeated
cyclically; otherwise, if X has more elements, only the first k are
used.
</quote>
Allin
2:11 p.m.
On Mon, 8 Jul 2019, Allin Cottrell wrote:
The way mshape() works currently there isn't a "necessary
number of
columns" [...]
But if you want to ensure that no elements are repeated or discarded
via mshape, you can do
Xs = mshape(X, r, nelem(X)/r)
That will give an error if nelem(X)/r is not an integer.
Allin
4:32 p.m.
Am 08.07.2019 um 09:00 schrieb Riccardo (Jack) Lucchetti:
On Mon, 8 Jul 2019, Sven Schreiber wrote:
> Am 08.07.2019 um 08:12 schrieb Riccardo (Jack) Lucchetti:
>> Thanks; besides, we could extend Sven's idea to mshape()
and make the
>> third argument optional (defaulting to 1, of course). Is this a good
>> idea?
>
> Not sure I like the default 1. If X has exactly r elements,
> mshape(X,r,1) can be easily achieved by vec(X), right? And it seems to
> me it is not a very standard case to use mshape(X,r,1) for r != nelem(X).
In fact, what I had in mind is the idiom "mshape(NA, r, c)", taht I use
a lot for initialising matrices.
Coming back to this use case: So apparently you often need to start with
a vector that does not hold zeros or ones. I wonder whether we could use
a dedicated function for that, like the 'empty' function in Numpy which
does just that. But maybe it's overkill.
BTW, I checked the expression "zeros(100,1) * NA" which still has all
zeros. Now I remember some dispute about the desired result for 0*NA,
but in any case the variant "zeros(100,1) .* NA" gives all 'nan', so
I'm
sure one of the two must be a bug.
cheers
sve
12:10 p.m.
On Mon, 8 Jul 2019, Sven Schreiber wrote:
BTW, I checked the expression "zeros(100,1) * NA" which
still has all
zeros. Now I remember some dispute about the desired result for 0*NA,
but in any case the variant "zeros(100,1) .* NA" gives all 'nan', so
I'm
sure one of the two must be a bug.
Yep, that's inconsistent. For the present I've made 0 * NA equal 0 in
both contexts, which is "traditional" gretl behavior. But we may want
to revise this, given that our NA is now NaN. Thoughts, anyone?
Allin
1:18 p.m.
Am 10.07.2019 um 14:10 schrieb Allin Cottrell:
On Mon, 8 Jul 2019, Sven Schreiber wrote:
> BTW, I checked the expression "zeros(100,1) * NA" which still has all
> zeros. Now I remember some dispute about the desired result for 0*NA,
> but in any case the variant "zeros(100,1) .* NA" gives all 'nan',
so I'm
> sure one of the two must be a bug.
Yep, that's inconsistent. For the present I've made 0 * NA equal 0 in
both contexts, which is "traditional" gretl behavior. But we may want
to revise this, given that our NA is now NaN. Thoughts, anyone?
Not sure why that internal change would affect the way users want to or
should interact with gretl?
thanks
sven
6:22 p.m.
-----Original Message-----
From: Sven Schreiber <svetosch(a)gmx.net>
Sent: Sunday, July 7, 2019 5:36 PM
> Actually, you got me thinking about the possibility of having a
second
> argiment to I() (aka F_IMAT); in many cases, you want to construct a
> matrix that is an identity matrix "plus some zeros"; without loss of
> backward compatibility, we may introduce an optional 2nd argument to
> I() such that I(r,c) returns
>
> * I(r) ~ zeros(r, c-r) if c > r,
> * I(c) | zeros(r-c, c) if r < c
> Besides, I believe this is what Matlab does, so this would also
be
> nice to have when porting scripts from the Octave/Matlab galaxy.
Yes it seems they do that. Of course, if you want to appeal to those people,
you could also make "eye" an alias for "I", but perhaps that would
rather be
something for Peter's matlab_utilities package.
As promised, version 0.3 of matlab_utilites now includes eye(n,m) with this behavior (and
m = 0 the default case). If the user's version is at least 2019d, it's just a
wrapper for I(n,m); otherwise it builds the matrices explicitly. I've just uploaded
the new version to the package server; if you let me know when it's been accepted I
can send a message to the users' list if you like.
Cheers,
PS
8:30 p.m.
Am 08.07.2019 um 00:46 schrieb Allin Cottrell:
On Sun, 7 Jul 2019, Sven Schreiber wrote:
> Am 07.07.2019 um 17:25 schrieb Allin Cottrell:
>> Thanks, Sven. I've now committed your changes. They
remain to be
>> documented.
>
> Sure, I will also do the documentation soon, it's only fair ;-)
OK, thanks!
Pushed to git. I have only edited doc/commands/gretl_functions_en.xml, I
hope the changes then propagate (through translation or whatever) to the
other xml files.
thanks
sven
9:07 p.m.
On Thu, 11 Jul 2019, Sven Schreiber wrote:
Am 08.07.2019 um 00:46 schrieb Allin Cottrell:
> On Sun, 7 Jul 2019, Sven Schreiber wrote:
>
>> Am 07.07.2019 um 17:25 schrieb Allin Cottrell:
>>> Thanks, Sven. I've now committed your changes. They remain to be
>>> documented.
>>
>> Sure, I will also do the documentation soon, it's only fair ;-)
>
> OK, thanks!
Pushed to git. I have only edited doc/commands/gretl_functions_en.xml, I
hope the changes then propagate (through translation or whatever) to the
other xml files.
Thanks. Translation rather than "whatever" will be the vector for
propagation!
Allin
9:11 p.m.
On Wed, 10 Jul 2019, Sven Schreiber wrote:
Am 10.07.2019 um 14:10 schrieb Allin Cottrell:
> On Mon, 8 Jul 2019, Sven Schreiber wrote:
>
>> BTW, I checked the expression "zeros(100,1) * NA" which still has all
>> zeros. Now I remember some dispute about the desired result for 0*NA,
>> but in any case the variant "zeros(100,1) .* NA" gives all
'nan', so I'm
>> sure one of the two must be a bug.
> Yep, that's inconsistent. For the present I've made 0 * NA equal 0 in
> both contexts, which is "traditional" gretl behavior. But we may want
> to revise this, given that our NA is now NaN. Thoughts, anyone?
Not sure why that internal change would affect the way users want to or
should interact with gretl?
This is kind of a long story but I'll try to be brief. Executive
summary: it's actually not just an internal thing.
At one time we attempted to distinguish between NA (= missing value,
a stand-in for an unknown value that in principle could have been
observed, but was not observed, coded as the maximum
double-precision floating point value) and NaN (not-a-number, for
instance the result of an invalid arithmetical operation such as
taking the log of a negative number).
If one could maintain this distinction consistently, then it would
be reasonable to maintain that NA * 0 = 0, even though NaN * 0 ought
to be NaN (as it is, per IEEE rules).
But the distinction is very difficult to maintain and we never
actually succeeded. (For example, in the series context, log(-1)
gave a result of NA.) Moreover (a) two-way traffic between series
and matrices has become a integral part of the modern hansl idiom
and (b) we have farmed out much of our matrix computation to
openblas, which has no notion of our "NA" definition and would
happily treat it as a valid numerical value. We were therefore
obliged to police the series/matrix interface at quite heavy cost:
NAs in series had to be converted into NaNs in matrices (on pain of
producing numerical nonsense), and (debatably) vice versa.
So in 2018 we cut through this mess: we redefined gretl's "NA" as
NaN. No more policing required; NaNs propagate through calculation
as per IEEE rules (any arithmetical operation with NaN as an operand
produces NaN as result). Except... we kept the NA*0 = 0 rules for
series, and (semi-consistently, as you noted) for multiplication of
matrices by scalars.
So my question is: should we now accept that we have no good reason
for blocking the application of the IEEE rules for NaNs?
Allin
8 a.m.
Am 11.07.2019 um 23:11 schrieb Allin Cottrell:
On Wed, 10 Jul 2019, Sven Schreiber wrote:
So in 2018 we cut through this mess: we redefined gretl's
"NA" as NaN.
No more policing required; NaNs propagate through calculation as per
IEEE rules (any arithmetical operation with NaN as an operand produces
NaN as result). Except... we kept the NA*0 = 0 rules for series, and
(semi-consistently, as you noted) for multiplication of matrices by
scalars.
It seems that even if an exception were made for series, that would not
imply making it for matrix/scalar operations. So irrespective of the
former decision, I think that 'matrix times NA (scalar)' should yield
NA/nan.
So my question is: should we now accept that we have no good reason
for
blocking the application of the IEEE rules for NaNs?
Probably. I haven't heard the argument for the series context, though.
thanks
sven
1750
days inactive
1758
days old
23 comments
4 participants
participants (4)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Summers, Peter -
Sven Schreiber