From G.A.Hughes@ed.ac.uk Thu Jul 17 04:01:34 2008
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Re: gretl functions and lists
Date: Thu, 17 Jul 2008 10:01:10 +0200
Message-ID: <200807170801.m6H81WlG031093@f4n3.wfunet.wfu.edu>
In-Reply-To: 200807142233.m6EMWwLQ028698@f4n29.wfunet.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2637917965244946755=="

--===============2637917965244946755==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

At 00:33 15/07/2008, you wrote:
>I agree the extension you propose would be nice. However, the underlying
>machinery which deals with the dollar accessors doesn't lend itself to
>accommodate it easily. Maybe using pointers is easier. Here's a small
>proof-of-concept script:
>
><script>
>function reverse_ols(series y, list X, matrix *rcoeff, series *rres)
>      ols y X --quiet
>      rcoeff = -$coeff
>      rres = -$uhat
>end function
>
>open data4-1
>list reg = const sqft bedrms baths
>ols price reg
>u = $uhat
>matrix foo
>series bar
>reverse_ols(price, reg, &foo, &bar)
>print u bar -o
></script>
>
>Riccardo (Jack) Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>r.lucchetti(a)univpm.it
>http://www.econ.univpm.it/lucchetti


The difficulty with the use of pointers rather 
than $ accessors is really one of how to provide 
a single package which implements the basic 
procedure for the novice user while giving the 
expert user the ability to recover additional 
results.  By adding the requirement to define 
additional variables and provide the relevant 
pointers the function becomes less easy to use 
for someone who just wants to run a simple 
estimation and has no requirement for anything 
beyond the basic printed output.  Still, it may 
be the case that my goal is not achievable with 
the way in which functions and function packages work.

As an alternative, I am inclined to provide two 
versions of each function package - one for 
novice users with no results being returned, and 
the other for those who want to get access to 
coefficients, etc.  Both would be little more 
than different front-ends to the same basic 
procedures but with alternative sets of options 
and information returned.  It might be helpful if 
there were some default conventions which would 
allow a number of function packages to follow 
broadly the same approach and naming protocols.

At the same time, it would be nice to be able to 
use the $ accessors for compatibility with normal gretl commands.

Gordon Hughes




--===============2637917965244946755==--


From r.lucchetti@univpm.it Thu Jul 17 12:34:09 2008
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Re: gretl functions and lists
Date: Thu, 17 Jul 2008 18:34:05 +0200
Message-ID: <alpine.DEB.1.10.0807171828430.22389@ec-4.econ.univpm.it>
In-Reply-To: 200807170801.m6H81WlG031093@f4n3.wfunet.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6755103555588242612=="

--===============6755103555588242612==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 17 Jul 2008, Gordon Hughes wrote:

> The difficulty with the use of pointers rather than $ accessors is really o=
ne=20
> of how to provide a single package which implements the basic procedure for=
=20
> the novice user while giving the expert user the ability to recover=20
> additional results.  By adding the requirement to define additional variabl=
es=20
> and provide the relevant pointers the function becomes less easy to use for=
=20
> someone who just wants to run a simple estimation and has no requirement fo=
r=20
> anything beyond the basic printed output.

Point taken. I've just committed to CVS a little modification that may=20
help in these cases; Allin, feel free to revert it if there's anything=20
wrong with it, but I tested it a little and there seem to be no ill side=20
effects (famous last words). Basically, the keyword "null" is now a valid=20
value for pointers, and can be specified as a default value.

The following example script, which obviously will only run on a fresh CVS=20
build, should clarify what I mean:

<script>
function foo(series x, matrix *q[null], series *e[null])
     m =3D mean(x)
     if !isnull(q)
         q =3D quantile(x,0.1) | quantile(x,0.9)
     endif
     if !isnull(e)
         e =3D x - m
     endif
     return scalar m
end function

nulldata 20
series x =3D normal()
scalar m0 =3D foo(x)

matrix q
m1 =3D foo(x, &q)

series e
m2 =3D foo(x, null, &e)

print m0
print m1
print m2
print q
summary x e
</script>


Riccardo (Jack) Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============6755103555588242612==--


From cottrell@wfu.edu Fri Jul 18 05:29:07 2008
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Re: gretl functions and lists
Date: Fri, 18 Jul 2008 05:29:06 -0400
Message-ID: <alpine.LRH.1.10.0807180516180.31052@ricardo.ecn.wfu.edu>
In-Reply-To: alpine.DEB.1.10.0807171828430.22389@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4158770179497205164=="

--===============4158770179497205164==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 17 Jul 2008, Riccardo (Jack) Lucchetti wrote:

> On Thu, 17 Jul 2008, Gordon Hughes wrote:
> 
> > By adding the requirement to define additional variables and 
> > provide the relevant pointers the function becomes less easy 
> > to use for someone who just wants to run a simple estimation 
> > and has no requirement for anything beyond the basic printed 
> > output.
> 
> Point taken. I've just committed to CVS a little modification 
> that may help in these cases; Allin, feel free to revert it if 
> there's anything wrong with it, but I tested it a little and 
> there seem to be no ill side effects (famous last words). 
> Basically, the keyword "null" is now a valid value for pointers, 
> and can be specified as a default value.

Nothing wrong with it, but actually this was already supported.  
The (useful) sample script you gave runs fine without the change 
to check_function_args().  The case is handled by the first 
condition:

if ((fp->flags & ARG_OPTIONAL) && 
     arg->type == GRETL_TYPE_NONE) {

Allin.

--===============4158770179497205164==--


From r.lucchetti@univpm.it Fri Jul 18 06:08:32 2008
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Re: gretl functions and lists
Date: Fri, 18 Jul 2008 12:08:28 +0200
Message-ID: <alpine.DEB.1.10.0807181205260.29560@ec-4.econ.univpm.it>
In-Reply-To: alpine.LRH.1.10.0807180516180.31052@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1386738255289685490=="

--===============1386738255289685490==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 18 Jul 2008, Allin Cottrell wrote:

> On Thu, 17 Jul 2008, Riccardo (Jack) Lucchetti wrote:
>
>> On Thu, 17 Jul 2008, Gordon Hughes wrote:
>>
>>> By adding the requirement to define additional variables and
>>> provide the relevant pointers the function becomes less easy
>>> to use for someone who just wants to run a simple estimation
>>> and has no requirement for anything beyond the basic printed
>>> output.
>>
>> Point taken. I've just committed to CVS a little modification
>> that may help in these cases; Allin, feel free to revert it if
>> there's anything wrong with it, but I tested it a little and
>> there seem to be no ill side effects (famous last words).
>> Basically, the keyword "null" is now a valid value for pointers,
>> and can be specified as a default value.
>
> Nothing wrong with it, but actually this was already supported.
> The (useful) sample script you gave runs fine without the change
> to check_function_args().  The case is handled by the first
> condition:
>
> if ((fp->flags & ARG_OPTIONAL) &&
>     arg->type == GRETL_TYPE_NONE) {
>

Sorry, I wasn't clear. My idea was to make "null" a valid value for 
pointers even when they're not optional. The following script, for 
example, would return an error without my little addition:

<script>
function foo(matrix *a)
 	if isnull(a)
 		scalar ret = -1
 	else
 		scalar ret = rows(a)
 	endif
 	return scalar ret
end function

nulldata 8
eval foo(null)
</script>

This is maybe redundant, but probably harmless, isn't it?

Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============1386738255289685490==--


From cottrell@wfu.edu Fri Jul 18 06:30:19 2008
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Re: gretl functions and lists
Date: Fri, 18 Jul 2008 06:30:11 -0400
Message-ID: <alpine.LRH.1.10.0807180614420.31052@ricardo.ecn.wfu.edu>
In-Reply-To: alpine.DEB.1.10.0807181205260.29560@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3536467967075369375=="

--===============3536467967075369375==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, 18 Jul 2008, Riccardo (Jack) Lucchetti wrote:

> Sorry, I wasn't clear. My idea was to make "null" a valid value 
> for pointers even when they're not optional. 

Ah, I see.

I think the question is then whether this makes life easier or 
more difficult for function writers.  At first glance: isn't it 
perhaps better for function writers to indicate when an argument 
is optional, by adding a "[null]" default?  Then they can rely 
on gretl's function-call mechanism to weed out invalid calls, and 
don't have to test for null-ness if a pointer argument is 
in fact mandatory.

(In context we're talking about pointers that are used to 
represent optional auxiliary info, but of course pointers can also 
be used with mandatory arguments as a way of speeding things up by 
avoiding the need to copy data).

Allin.


--===============3536467967075369375==--


From cottrell@wfu.edu Thu Jul 24 12:21:20 2008
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] optional arguments (was Re: gretl functions and lists)
Date: Thu, 24 Jul 2008 12:20:56 -0400
Message-ID: <alpine.LRH.1.10.0807241155080.6956@ricardo.ecn.wfu.edu>
In-Reply-To: 200807170801.m6H81WlG031093@f4n3.wfunet.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0946211822770424268=="

--===============0946211822770424268==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sorry, didn't manage to respond to this earlier, but here goes.

On Thu, 17 Jul 2008, Gordon Hughes wrote:

> The difficulty with the use of pointers rather than $ accessors 
> is really one of how to provide a single package which 
> implements the basic procedure for the novice user while giving 
> the expert user the ability to recover additional results. 
> adding the requirement to define additional variables and 
> provide the relevant pointers the function becomes less easy to 
> use for someone who just wants to run a simple estimation and 
> has no requirement for anything beyond the basic printed 
> output...

There's something that's present in the manual but maybe not 
obvious.  If you're writing a function that provides some "basic" 
output but also offers optional info that's likely to be of 
interest only to experts, the trick is to (a) make the extra info 
available via pointer arguments, (b) give those pointers a default 
value of "null", and (c) make sure they come at the end of the 
list of parameters.  Then the user does not have to mess with them 
at all.

For example, a function with this signature

  function myfun (list L, matrix M, 
                  matrix *A[null], matrix *B[null])

might simply be called as, say,

  myfun(xlist, Xmat)

since trailing arguments that have default values can be omitted 
altogether.  So, if I'm understanding your point right, you really 
shouldn't need two versions of the function.

In the gretl GUI, the call dialog for such a function (assuming it 
has been packaged) will show the pointer arguments, with the 
"null" default in place. One possible refinement of the GUI would 
be to separate optional pointer arguments in such a way that 
things don't look "too complicated" to the average user.  For 
instance, the function call dialog could have a "notebook" 
structure, with such arguments placed under a second tab.

If that sounds useful, I'll have a go at implementing it.

Allin.








--===============0946211822770424268==--