R help - Nov 2016 - Some basic time series questions

On 11/17/2016 06:00 AM, r-help-request at r-project.org
wrote:
> Hi,
>
> As I sit and learn how to work with time series, I've run into a
problem
> that is eluding a quick easy answer (and googling for answers seems to
> really slow the process...)
>
> Question #1--
> In a simple example on R 3.3.1 (sorry my employer hasn't upgraded to
3.3.2
> yet):
>
> x=rnorm(26,0,1)
> x.ts<-ts(x,start=c(2014,9),frequency=12)
>
> inputting x.ts at the prompt gives me a table with the rooms denoted by
> year and columns denoted by months and everything lines up wonderfully.
>
> Now my problem comes when I type at the prompt
>
> plot(x.ts)  or
> plot(x.ts, xlab="") or
> plot.ts(x.ts,xlab="")
>
> I get a plot of the values, but my x-axis labels are 2015.0, 2015.5,
> 2016.0, and 2016.5 .  January 2015 is coming out as 2015.0...
>
> Is there a way of getting a more intelligible x-axis labeling?  Even 2015.1
> for Janaury, etc. would work, or even getting an index (either Septemebr
> 2014 representing 0 or 1 and it incrementally increasing each month).
There are several ways to do this. Having some bias, I would do

   require(tfplot)
   tfplot(x.ts)
>
> Question #2--
> If I have a time series of decadal events, how best should I set the
> frequency.  It is historical data, in the form of say AD 610-619 5 events,
> AD 620-629 7 events, etc.
For anything other than annual, quarterly, and monthly data you probably 
should consider zoo. (There are other options, but I think zoo is the 
most widely used for some time now.) Guessing a bit how you think of 
this data, I would say you want the date index to be the first year of 
the decade. To illustrate, I can generate a hundred decades of random 
data and index it thus:

require(zoo)
x <- zoo(round(10 * runif(100)) , order.by= 10 * 61:160)

Paul
>
> Sorry for such a basic questions.  Any advice would be appreciated.
>
> Thanks in advance, MEH
>
>
>
> Mark E. Hall, PhD
> Assistant Field Manager
> Black Rock Field Office
> Winnemucca District Office
> 775-623-1529.

> require(tfplot)
> tfplot(x.ts)
Would just like to point out that require() should not be treated as
interchangeable with library(). The former returns a logical status indicating
success or failure, while the latter throws an error if it falls.  You should
reserve use of require() for cases when you are implementing an alternative path
of execution for failure, and in nearly all usual cases use the library()
function instead so hapless users of your script don't have to sift through
all the subsequent errors to figure out the problem.
-- 
Sent from my phone. Please excuse my brevity.

On 11/17/2016 04:49 PM, Jeff Newmiller wrote:
>> require(tfplot)
>> tfplot(x.ts)
>
> Would just like to point out that require() should not be treated as
> interchangeable with library(). The former returns a logical status
> indicating success or failure, while the latter throws an error if it
> falls.  You should reserve use of require() for cases when you are
> implementing an alternative path of execution for failure, and in
> nearly all usual cases use the library() function instead so hapless
> users of your script don't have to sift through all the subsequent
> errors to figure out the problem.
>
Mea culpa.  Force of habit from usually writing with an alternative path 
of execution. In this example I should have used library(), especially 
since 'tfplot' may not have been installed on the user's system and
so
the library() error message would be more explicit than the warning from 
require(). But "in nearly all usual cases" seems a bit strong. It 
implies R users don't usually program much and thus do not implement an 
alternative path of execution for failure. (Some of us consider that the 
most usual case.)

Paul

Perhaps more people write end-user-ready applications in R than I am aware of
and my bias is too strong.  For working at the console I prefer not to have my
scripts installing packages on their own (one possible alternative execution
path), and it is too much trouble to implement multiple routes to the end of an
analysis in most cases, so library() is usually best for me.
-- 
Sent from my phone. Please excuse my brevity.

On November 17, 2016 1:49:18 PM PST, Jeff Newmiller <jdnewmil at
dcn.davis.ca.us> wrote:
>> require(tfplot)
>> tfplot(x.ts)
>
>Would just like to point out that require() should not be treated as
>interchangeable with library(). The former returns a logical status
>indicating success or failure, while the latter throws an error if it
>falls.  You should reserve use of require() for cases when you are
>implementing an alternative path of execution for failure, and in
>nearly all usual cases use the library() function instead so hapless
>users of your script don't have to sift through all the subsequent
>errors to figure out the problem.