Constructor/extractor.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Constructor/extractor.

Rolf Turner

Preamble:
=========

In spatial point pattern analysis an important component of a point
pattern object is the *observation window*.  In the spatstat package we
have the function owin() to *construct* such a window.  It creates an
object of class "owin" which can happily exist separately from any point
pattern object (object of class "ppp").

However we have at the moment no convenient function to *extract* the
observation component of a ppp object, nor have we a really convenient
means of (re-) assigning the window component of such an object.  We can
extract the component via X$window or more suavely via as.owin(X) ---
but the latter is rather counter-intuitive and lacks parallelism with
other usage.  Re-assignment of the observation window component of X can
be done either via X$window <- W or X <- X[W].  These are not quite the
same.  The former may leaves points which are outside of W hanging
around. The latter does not suffer from this defect, and is more suave,
but is not as intuitive as it might be.

I suggested that we could make the owin() function generic, make the
current owin() creator function into owin.default(), and build an
extractor function owin.ppp() (and an assignment function owin<-.ppp ()
to assign an observation window to a ppp object).

It was pointed out to me that this would make for an unorthodox syntax
It is at the very least *unusual* if not unheard of for a function to be
used both for *creation* of objects and for *extraction* of components
from other objects.

Questions:
==========

My questions to R-devel are:

(1) Are there any other functions in R that serve this dual role of
constructor and extractor?

(2) Even if there are no such functions, is there anything intrinsically
*wrong* with having a function possessing this somewhat schizophrenic
nature?  Is it likely to cause confusion, induce syntactical mistakes,
create errors, or produce wrong results?

Any thoughts, comments, insights or suggestions gratefully received.

cheers,

Rolf Turner

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Constructor/extractor.

barry rowlingson
On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner <[hidden email]> wrote:

>
>
> Questions:
> ==========
>
>
> (2) Even if there are no such functions, is there anything intrinsically
> *wrong* with having a function possessing this somewhat schizophrenic
> nature?  Is it likely to cause confusion, induce syntactical mistakes,
> create errors, or produce wrong results?
>
> Any thoughts, comments, insights or suggestions gratefully received.
>


 I don't see why you can't conceptually think of w = owin(some_ppp_object)
as an owin "Constructor" rather than an "Accessor". Its "constructing" (and
returning) an owin from an object, it just happens to be as simple as
getting a component from that object.

 The raster package has the 'extent' function - you can create an extent
with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or
set the extent of a raster with extent(r1) <- extent(r2), so I don't see
any problem with:

w1 = owin(poly=...) # construct polygon owin

ppp1 = ppp(x,y,window=w1)
ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object

owin(ppp1) = owin(ppp2)  # give ppp1 the owin of ppp2

That all reads pretty nicely. As long as owin(...) returns an observation
window and owin<-(...) assigns an observation window to an object that can
validly have one, I don't think you can go wrong. I've probably already
tried to do "owin(ppp1)=..." a few times...

Barry

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Constructor/extractor.

Hervé Pagès
Hi Rolf, Barry,

On 03/04/2014 08:08 AM, Barry Rowlingson wrote:

> On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner <[hidden email]> wrote:
>
>>
>>
>> Questions:
>> ==========
>>
>>
>> (2) Even if there are no such functions, is there anything intrinsically
>> *wrong* with having a function possessing this somewhat schizophrenic
>> nature?  Is it likely to cause confusion, induce syntactical mistakes,
>> create errors, or produce wrong results?
>>
>> Any thoughts, comments, insights or suggestions gratefully received.
>>
>
>
>   I don't see why you can't conceptually think of w = owin(some_ppp_object)
> as an owin "Constructor" rather than an "Accessor". Its "constructing" (and
> returning) an owin from an object, it just happens to be as simple as
> getting a component from that object.
>
>   The raster package has the 'extent' function - you can create an extent
> with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or
> set the extent of a raster with extent(r1) <- extent(r2), so I don't see
> any problem with:
>
> w1 = owin(poly=...) # construct polygon owin
>
> ppp1 = ppp(x,y,window=w1)
> ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object
>
> owin(ppp1) = owin(ppp2)  # give ppp1 the owin of ppp2
>
> That all reads pretty nicely. As long as owin(...) returns an observation
> window and owin<-(...) assigns an observation window to an object that can
> validly have one, I don't think you can go wrong. I've probably already
> tried to do "owin(ppp1)=..." a few times...

I agree with Barry. Once you realize there is no clear line between
constructor and extractor (conceptually every function can actually
be thought of as a constructor), then re-using the same function name
(via methods of a generic function) doesn't sound too bad. An example
of this design is the strand() generic in Bioconductor: can be used
to get or set the strand factor of an object containing such a
component (e.g. a GRanges object), and also for constructing a
strand factor from different kinds of input (character, logical,
integer vector, etc...)

Cheers,
H.

>
> Barry
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel