6:29 p.m.
It is currently not possible to evaluate if an array of matrices is equal to null or not.
Here is an example code snippet. For the list this works fine, for the matrices it
doesn't.
<hansl>
matrices ttt = null
list lll = null
/*
if ttt==null
print "bla"
else
print "blub"
endif
*/
if lll==null
print "blalll"
else
print "blublll"
endif
</hansl>
I came upon this when trying to set up a function with the following head (data can be
passed as series' or 2d-matrices (x,y) ):
<hansl>
function bundle series_to_bundle(list ls[null], series obskey[null], matrices ms[null])
#transform series in bundle of two matrices, the key and the data
...
</hansl>
7:10 p.m.
On Tue, 19 Dec 2017, Schaff, Frederik wrote:
It is currently not possible to evaluate if an array of matrices
is equal to null or not.
I think you want either
exists(foo)
to check whether or not there's any object named "foo", or, if
you're sure that foo exists but want to check if it actually
contains any members/elements:
nelem(foo) != 0
The latter check will work for objects of type matrix, list, array
and bundle (that is, all gretl types that can exist yet be empty).
The formulation "foo == null" is not supported in hansl.
Allin
2:05 a.m.
> It is currently not possible to evaluate if an array of matrices
is
> equal to null or not.
I think you want either
exists(foo)
to check whether or not there's any object named "foo", or, if you're
sure
that foo exists but want to check if it actually contains any
members/elements:
nelem(foo) != 0
The latter check will work for objects of type matrix, list, array and bundle
(that is, all gretl types that can exist yet be empty).
The formulation "foo == null" is not supported in hansl.
Allin
Ah, I had exactly this '!=' formulation before. Now, you point out that it does
not work for matrices, which explains why I had trouble in the first place. However,
'matrices x = null' is valid, so it might be good to have it? (btw
"a==b" did work the same as "!a!=b" for me).
There is an issue with 'exists' and the scope (function vs. script/global). It
seems to be the case that exists checks, at least for lists, on the global scope. Run the
following short test script, to see what I mean. At any rate, this script is also a
workaround for me, now.
Perhaps some specific function for 'function' scope, to test whether a parameter
is passed or not, would be nice? something like 'passed(par)' which evaluates to
1/true if a parameter was passed and to 0/false if not (i.e. 'null' was passed),
valid for all kind of possible data that hansl supports.
<hansl>
function void test(matrices MS[null], list ls[null])
if !exists(MS)
print "MS is not defined"
else
print "MS defined"
endif
if !exists(ls) #problem: if ls exists on higher level...
print "List not defined"
else
print "List defined"
if !(ls!=null)
print "but its empty (on this scope)"
endif
if ls==null
print "also '==' check ok"
endif
endif
end function
#test
open denmark.gdt -q
matrix m1 = {LRM}
matrix m2 = {IBO}
list ls = LRM IBO
matrices MS = null
MS += m1
MS += m2
print "Test with both, matrices and list"
test(MS,ls)
print "Test with neither list nor matrices"
test()
print "Test with only matrices"
test(MS)
print "Test with only list"
test(null,ls)
</hansl>
Best,
Frederik
3:12 a.m.
Am 20.12.2017 um 08:05 schrieb Schaff, Frederik:
Allin:
> if you're sure
> that foo exists but want to check if it actually contains any
> members/elements:
>
> nelem(foo) != 0
>
> The latter check will work for objects of type matrix, list, array
Ah, I had exactly this '!=' formulation before. Now, you
point out that it does not > > work for matrices,
No, I think you missed Allin's proviso above "if you're sure it exists".
A 'matrices' object is just a special array, so is supported for nelem,
but only if it exists.
There is an issue with 'exists' and the scope (function vs.
script/global). It seems > to be the case that exists checks, at least for lists, on
the global scope. Run the > > following short test script, to see what I mean.
I see what you mean, and I understand your confusion. However, the
background is different and there is no scoping issue here. (To verify,
you could rename the list in the outer scope, and I think the results
should stay the same.)
The thing is that lists are special, and therefore you shouldn't use
exists() on them *when checking for a function argument*, only nelem().
This is an exception, and as you saw before nelem() on another function
argument type which is 'null' wouldn't work. There was a thread about
these things about a year ago.
So, the bottom line for checking 'null' default values for function
arguments:
- almost always use exists() first
- but for lists use (only) nelem() directly
- [for lists that are not function args you should be able to use
exists() as well]
Again, I completely understand the confusion, this is the result of some
path dependency in the past.
But I just checked the built-in doc for exists(), and it doesn't mention
the limitation with respect to list function arguments. I think it would
be good to mention the problem there -- in general I cannot really find
an explanation of the list situation in the docs.
And another related doc issue: In ch.13 of the guide I think the
following is incomplete nowadays:
"For optional arguments in pointer form, and additionally for string or
list arguments in standard form (see section 13.4), the special default
value null."
Whereas 'null' is allowed for almost all types now, I think.
cheers,
sven
9:09 a.m.
On Wed, 20 Dec 2017, Sven Schreiber wrote:
The thing is that lists are special, and therefore you shouldn't
use exists()
on them *when checking for a function argument*, only nelem(). This is an
exception, and as you saw before nelem() on another function argument type
which is 'null' wouldn't work. There was a thread about these things about a
year ago.
So, the bottom line for checking 'null' default values for function
arguments:
- almost always use exists() first
- but for lists use (only) nelem() directly
- [for lists that are not function args you should be able to use exists() as
well]
Again, I completely understand the confusion, this is the result of
some path dependency in the past.
Yes indeed. The "list" type has been around for a long time and when
the business of a "null" default for function arguments first came up
we decided that if the caller did not provide an argument, the
function would nonetheless get an empty list under the name of the
parameter. Hence the behavior of exists() in this case.
Subsequently we changed our mind about the most desirable treatment of
the "null" default, and for matrix, bundle, array and series there's
no special construction of an empty object as pseudo-argument. But for
reasons of backward compatibility we didn't go back and change the
behavior for list arguments.
Maybe it's time to reconsider: how disruptive would it be to change
the behavior with list arguments to match that with other objects?
Whichever way we decide to go, I agree with Sven that we should
update/clarify the documentation.
Allin
9:43 a.m.
Am 20.12.2017 um 15:09 schrieb Allin Cottrell:
Maybe it's time to reconsider: how disruptive would it be to
change the
behavior with list arguments to match that with other objects?
very much so, I'm afraid. Jack called it "wreaking havoc" a year ago.
Of course in principle I'd like some clever internal gretl workaround
that would allow a meaningful exists() on lists in functions while
preserving compatibility with direct use of nelem() as well as the old
sometimes paradoxical isnull().
However, we were just reminded that a lot remains to be done in the
documentation department. So I think for now cleaning up and updating
the various documentation parts is fine and might pre-empt the majority
of problems.
cheers,
sven
11:26 a.m.
Dear Sven and Allin,
many thanks for the detailed information and help! A nice feature would be a real help for
data types within gretl. I.e., if I use the contextual help (?->list, e.g.) I only get
general information on genr. If instead I would get some information on list (e.g. meaning
of operators, accessors, etc. - perhaps similar to the cpp help) that would be nice.
In general, a reference structured similar to http://www.cplusplus.com/reference/ would
(or so I hope) decrease the amount of questions I am bothering you all with from time to
time ;).
Best
Frederik
-----Ursprüngliche Nachricht-----
Von: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel-
bounces(a)lists.wfu.edu] Im Auftrag von Sven Schreiber
Gesendet: Mittwoch, 20. Dezember 2017 15:44
An: gretl-devel(a)lists.wfu.edu
Betreff: Re: [Gretl-devel] "if matrices == null" bug?
Am 20.12.2017 um 15:09 schrieb Allin Cottrell:
> Maybe it's time to reconsider: how disruptive would it be to change
> the behavior with list arguments to match that with other objects?
very much so, I'm afraid. Jack called it "wreaking havoc" a year ago.
Of course in principle I'd like some clever internal gretl workaround that
would allow a meaningful exists() on lists in functions while preserving
compatibility with direct use of nelem() as well as the old sometimes
paradoxical isnull().
However, we were just reminded that a lot remains to be done in the
documentation department. So I think for now cleaning up and updating the
various documentation parts is fine and might pre-empt the majority of
problems.
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2479
days inactive
2480
days old
6 comments
3 participants
participants (3)
-
Allin Cottrell -
Schaff, Frederik -
Sven Schreiber