Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xout not working with na.locf #215

Closed
MortenGrum opened this issue Nov 12, 2017 · 1 comment
Closed

xout not working with na.locf #215

MortenGrum opened this issue Nov 12, 2017 · 1 comment
Assignees
Labels

Comments

@MortenGrum
Copy link

Description

It seems xout is not working with na.locf()

Expected behavior

That xout defines the timestamps of the output (as with na.approx() )

Minimal, reproducible example

I have two xts time series data sets. One with my data and another with time stamps that I would like to use.

xts_with_data <- as.xts(read.zoo(text='
2016-07-01 00:00:10,   1.0
2016-07-01 00:00:14,   2.0
2016-07-01 00:00:20,   3.0
2016-07-01 00:00:29,   4.0
2016-07-01 00:00:34,   5.0
2016-07-01 00:00:39,   6.0
', sep=',', index=1, tz='', format="%Y-%m-%d %H:%M:%S"))
names(xts_with_data) <- c('x')

xts_with_timestamps <- as.xts(read.zoo(text='
2016-07-01 00:00:15,   0.0
2016-07-01 00:00:20,   0.0
2016-07-01 00:00:30,   0.0
2016-07-01 00:00:35,   0.0
2016-07-01 00:00:38,   0.0
', sep=',', index=1, tz='', format="%Y-%m-%d %H:%M:%S"))

na.locf(xts_with_data, xout = index(xts_with_timestamps))

I would expect output like this

                    [,1]
2016-07-01 00:00:15    2
2016-07-01 00:00:20    3
2016-07-01 00:00:30    4
2016-07-01 00:00:35    5
2016-07-01 00:00:38    5

but what I get is my original xts_with_data.
(it works as expected with na.approx() )

AkselA suggested (on stackoverflow) that ... "It seems like the source of your troubles is a missing feature in xts:::na.locf.xts. It might be worth letting Joshua (the developer) know, if he doesn't already."

AkselA also pointed me to a couple of workaround:

xts_all <- merge(xts_with_data, xts_with_timestamps)[,-2]
na.locf(xts_all)[index(xts_with_timestamps)]
# or
na.locf.default(xts_with_data, xout=index(xts_with_timestamps))
# or
na.locf(zoo(xts_with_data), xout=index(xts_with_timestamps))

(stackoverflow: https://stackoverflow.com/questions/47219803/last-observation-carried-forward-locf-on-xts-in-r-not-like-na-approx)

@joshuaulrich
Copy link
Owner

Thanks for the report! I agree this is a bug.

@joshuaulrich joshuaulrich self-assigned this Nov 15, 2017
@joshuaulrich joshuaulrich added the feature request New features label Mar 11, 2018
joshuaulrich added a commit that referenced this issue Mar 14, 2018
We were converting all xts objects to a common type when merging, and
we included the types of zero-width xts objects in our check. This is
a problem because zero-width objects created via the xts constructor
are numeric by default. So calling merge.xts() on any non-numeric xts
objects and a zero-width xts object returned a numeric result.

This manifested in the na.locf() test where xout is specified, because
na.approx.zoo() is called at one point. And that method does a merge
of the original object with an zero-width zoo object created via
zoo(,idx).

See #215.
@joshuaulrich joshuaulrich added this to the Release 0.10-2 milestone Mar 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants