getBars - optionally adjust for corporate actions?

[joel23888]

It seems the getBars function never adjusts for corporate actions like stock splits. Eg. 4661 JT Equity had a 1:4 stock split on 3/27/2015. This means unadjusted prices should have a large gap between 3/26 and 3/27 where prices fall by a factor of 4, while adjusted prices should multiply pre-3/27 prices by 0.25 to remove this gap. I find it always returns unadjusted prices, even though my BBG settings in DPDF are set to adjust and IntradayBarRequest should follow this by default according to BBG.

[eddelbuettel]

If you could, something reproducible would be great.

Also, it is not quite clear which settings do, or do not, come 'down' from the Bbg terminal one connects to.

[joel23888]

Basic reproduction steps:
Step 1. In BBG terminal, enter DPDF GO and uncheck all boxes, be sure to save settings
Step 2. Run:

library(lubridate)
library(xts)
library(Rblpapi)
con <- blpConnect() 
tz <- "Asia/Tokyo"
Sys.setenv(TZ=tz)
t7 <- ymd_hms("2015-03-26 14:00:00", tz = tz)
t8 <- ymd_hms("2015-03-27 10:00:00", tz = tz)
d <- getBars("4661 JT Equity", eventType = "TRADE", barInterval = 60,
               startTime = t7, endTime = t8,
               returnAs = "xts", tz = "Asia/Tokyo")
d

Which returns for me:
open high low close numEvents volume
2015-03-26 14:00:00 36089.7 36129.6 35930 35930 1170 216100
2015-03-27 09:00:00 9137.0 9400.0 9050 9395 9002 2576700

This is expected as DPDF settings dictate no corporate actions adjustments should be made, and given the stock split I referred to before when I raised the issue, the price should divide in 4 from one day to the next (approximately).

Step 3. In BBG terminal, enter DPDF GO and check all boxes, be sure to save settings
Step 4. Rerun getBars in step 2 (under new DPDF setting), which for me returns the same result as in step 2. However, this is unexpected because DPDF dictate corporate actions adjustments should be made. The adjustment should be that price on 3/26 is multiplied by 0.25 and volume by 4, which is what I get when I view the same data on BBG terminal using the GIT function (unrelated to "git").

Let me know if you need more details.

If you see http://www.bloomberglabs.com/api/content/uploads/sites/2/2014/07/blpapi-developers-guide-2.54.pdf around p176 there is an option "adjustmentFollowDPDF", which if passed over to BBG should return adjusted data if DPDF is set to apply adjustments.

[joel23888]

eddelbuettel: Seemed easier to provide a potential solution for this than I had first thought (new to RCpp). Sent you a pull request.

[eddelbuettel]

Thanks, the PR looks fine.

But am wondering why we need the setting if the default (per page 176) is TRUE already?

[joel23888]

It does say that, but on my system it was never adjusting for corporate actions even when my DPDF setting were dictating it should. As soon as I made the change, it worked. If anyone has a different behavior I would be interested to know.

Also, under the heading of corporate actions I should point out my approach is incomplete. It does not support the elements adjustmentNormal, adjustmentAbnormal, and adjustmentSplit. These may be useful for per-request control of corporate action adjustments. Expected behavior would be to override DPDF settings.

[eddelbuettel]

I know. I am wondering whether we should have a list, say, blpOptions(...), as opposed to individual toggles. No strong feelings either way, but a shorter argument list may be better.

Opinions on this, @armstrtw @johnlaing ?

[johnlaing]

Very much in favor of a list or ... instead of a long string of potentially esoteric options.

[eddelbuettel]

👍

I'll deal with it: first taking in the PR, then rearranging sligthly.

[armstrtw]

yeah, list sounds good.

I don't know how to put the fancy thumbs up here, so I'll just do +1.

[eddelbuettel]

:)

If you edit in the browser, start with a single : and you'll see ... (oh and you always look at other people's post by opening them for edits ...)

[joel23888]

Many thanks!

[eddelbuettel]

Attempted to get closed by #48 which was not good and then #105 with was better (though not without issues itself 😃 )