[R-pkg-devel] environment scoping

[Glenn Schultz]

All,

I would like to have some inputs available to many functions.  For example, I 
have coefficient for a term structure fit which I would like to make a 
available to total return functions.  Thereby eliminating the need to fit the 
same term structure over and over again.  However, I still reading and 
researching scoping.  My understanding is that I could fit the term structure 
and keep the coefficients in the global environment which would then make those 
coefficients available to all functions requiring a term structure object 
input.  Am I correct in my understanding.  What is the downside of environment 
global, if any?

Best Regards,
Glenn
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] environment scoping

[Duncan Murdoch]

On 27/10/2016 10:05 AM, Glenn Schultz wrote:

All,

I would like to have some inputs available to many functions.  For example, I 
have coefficient for a term structure fit which I would like to make a 
available to total return functions.  Thereby eliminating the need to fit the 
same term structure over and over again.  However, I still reading and 
researching scoping.  My understanding is that I could fit the term structure 
and keep the coefficients in the global environment which would then make those 
coefficients available to all functions requiring a term structure object 
input.  Am I correct in my understanding.  What is the downside of environment 
global, if any?


You're writing in R-package-devel, so I'll assume you're thinking of 
doing this in a package that you will release to others.


In that case, the downside is huge.  The global environment doesn't 
belong to you, it belongs to the user.  If you choose to write to it, 
you could clobber something there that the user doesn't want clobbered.  
You'll hopefully get warnings from "R CMD check" about doing this, and 
CRAN will not accept your package.


There are a couple of ways to do what you want.  The simplest is to have 
the function that creates the common data return it in some sort of 
structure, and you pass that structure to other functions that need to 
work with it.  You can use S3 or S4 or other class systems to mark the 
structure for what it is.


Another approach that works sometimes is to have the function that 
creates the common data also create functions to work on it, and return 
them.  Since functions created in another function can see its local 
variables (even after it has returned!), those functions will have 
access to the common data, and nobody else will (without going through 
some contortions).  Some of the newer object systems support this 
approach, but you don't need to use them, you can just return a function 
(or a list of functions) and make calls to it/them.


I hope this helps.

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] environment scoping

[Jenny Bryan]

Hi Glenn,

It sounds like you should create an environment for your package. If you store 
these objects in the global environment, they are exposed to the user and, more 
importantly, user could modify or delete them. If you use an environment 
specific to your package, you can be sure you are the only one messing with 
them.

You create it like so:

.package_env <- new.env(parent = emptyenv())

And read from / write into it like so (very much like a list):

.package_env$foo <- ...
.package_env$foo

or with assign() and get():

assign(foo, bar, envir = .package_env)
get(foo, envir = .package_env)

This blog post by Jeff Allen is a nice write-up of what you're trying to do:

http://trestletech.com/2013/04/package-wide-variablescache-in-r-package/

-- Jenny

> On Oct 27, 2016, at 7:05 AM, Glenn Schultz  wrote:
> 
> All,
> 
> I would like to have some inputs available to many functions.  For example, I 
> have coefficient for a term structure fit which I would like to make a 
> available to total return functions.  Thereby eliminating the need to fit the 
> same term structure over and over again.  However, I still reading and 
> researching scoping.  My understanding is that I could fit the term structure 
> and keep the coefficients in the global environment which would then make 
> those coefficients available to all functions requiring a term structure 
> object input.  Am I correct in my understanding.  What is the downside of 
> environment global, if any?
> 
> Best Regards,
> Glenn
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] environment scoping

[William Dunlap]

If I were writing a package for factoring integers I might store a vector
of known primes in an environment in my package and have my factoring
functions append to the list when they find some more primes.  This works
because there is only one set of of primes (given we stick with ordinary
integers).

However the term structure (of interest rates, I assume) depends on the
date, the county, the type of bond, the method used to estimate it, etc.  I
think it would be better to store it in some sort of object (function,
list, or environment) that the user would be expected to know about.  The
user would be expected to pass that data into each function that need that
information (via the argument list, by using a function made in the
environment containing the term structure, etc.).


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Oct 27, 2016 at 7:55 AM, Jenny Bryan  wrote:

> Hi Glenn,
>
> It sounds like you should create an environment for your package. If you
> store these objects in the global environment, they are exposed to the user
> and, more importantly, user could modify or delete them. If you use an
> environment specific to your package, you can be sure you are the only one
> messing with them.
>
> You create it like so:
>
> .package_env <- new.env(parent = emptyenv())
>
> And read from / write into it like so (very much like a list):
>
> .package_env$foo <- ...
> .package_env$foo
>
> or with assign() and get():
>
> assign(foo, bar, envir = .package_env)
> get(foo, envir = .package_env)
>
> This blog post by Jeff Allen is a nice write-up of what you're trying to
> do:
>
> http://trestletech.com/2013/04/package-wide-variablescache-in-r-package/
>
> -- Jenny
>
> > On Oct 27, 2016, at 7:05 AM, Glenn Schultz  wrote:
> >
> > All,
> >
> > I would like to have some inputs available to many functions.  For
> example, I have coefficient for a term structure fit which I would like to
> make a available to total return functions.  Thereby eliminating the need
> to fit the same term structure over and over again.  However, I still
> reading and researching scoping.  My understanding is that I could fit the
> term structure and keep the coefficients in the global environment which
> would then make those coefficients available to all functions requiring a
> term structure object input.  Am I correct in my understanding.  What is
> the downside of environment global, if any?
> >
> > Best Regards,
> > Glenn
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] environment scoping

[Glenn Schultz]

All,

Thank you, I have built the package such that it passes an object TermStrutrure 
to those functions which require it as an input.  The package is here

https://github.com/glennmschultz/BondLab 


The question is largely motivated by the source MortgageScenario.R and 
MortgageOAS.R.  I have decided to default to Diebold Lee model in termstuc.

 In the case of MortgageScenario.R:

Currently shift in the curve is driven by shift in the coupon curve and the 
term structure model is refit.  Naturally one could use the coefficients from 
the original fit to shift the curve making theanalysis much 
faster and more intuitive than the current paradigm of shifting the coupon 
curve.  However, some portfolio prefer to be able to use either or.  So, I need 
to make either/or available.

In the case of MortgageOAS.R

This is currently a single factor CIR OAS model.  It will remain for teaching 
purposes as a single factor model is the gateway to multi-factor models.  
Nevertheless, one may choose to batch job OAS across say 500 MBS.  In which 
case it makes little sense to replicate the paths 500 times.  Simulate the 
paths and pass them to the function.  Obviously, I am looking at parallel 
processing of a portfolio mortgage and asset backed securities.  Thank-you for 
the time that you have taken to consider and reply to my question.  This has 
been very helpful.

Best,
Glenn

 




> On Oct 27, 2016, at 11:29 AM, William Dunlap  wrote:
> 
> If I were writing a package for factoring integers I might store a vector of 
> known primes in an environment in my package and have my factoring functions 
> append to the list when they find some more primes.  This works because there 
> is only one set of of primes (given we stick with ordinary integers).
> 
> However the term structure (of interest rates, I assume) depends on the date, 
> the county, the type of bond, the method used to estimate it, etc.  I think 
> it would be better to store it in some sort of object (function, list, or 
> environment) that the user would be expected to know about.  The user would 
> be expected to pass that data into each function that need that information 
> (via the argument list, by using a function made in the environment 
> containing the term structure, etc.).
> 
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com 
> On Thu, Oct 27, 2016 at 7:55 AM, Jenny Bryan  > wrote:
> Hi Glenn,
> 
> It sounds like you should create an environment for your package. If you 
> store these objects in the global environment, they are exposed to the user 
> and, more importantly, user could modify or delete them. If you use an 
> environment specific to your package, you can be sure you are the only one 
> messing with them.
> 
> You create it like so:
> 
> .package_env <- new.env(parent = emptyenv())
> 
> And read from / write into it like so (very much like a list):
> 
> .package_env$foo <- ...
> .package_env$foo
> 
> or with assign() and get():
> 
> assign(foo, bar, envir = .package_env)
> get(foo, envir = .package_env)
> 
> This blog post by Jeff Allen is a nice write-up of what you're trying to do:
> 
> http://trestletech.com/2013/04/package-wide-variablescache-in-r-package/ 
> 
> 
> -- Jenny
> 
> > On Oct 27, 2016, at 7:05 AM, Glenn Schultz  > > wrote:
> >
> > All,
> >
> > I would like to have some inputs available to many functions.  For example, 
> > I have coefficient for a term structure fit which I would like to make a 
> > available to total return functions.  Thereby eliminating the need to fit 
> > the same term structure over and over again.  However, I still reading and 
> > researching scoping.  My understanding is that I could fit the term 
> > structure and keep the coefficients in the global environment which would 
> > then make those coefficients available to all functions requiring a term 
> > structure object input.  Am I correct in my understanding.  What is the 
> > downside of environment global, if any?
> >
> > Best Regards,
> > Glenn
> > __
> > R-package-devel@r-project.org  
> > mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel 
> > 
> 
> __
> R-package-devel@r-project.org  mailing 
> list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel 
> 
> 


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel