-
-
Notifications
You must be signed in to change notification settings - Fork 225
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
OHLC returns wrong/duplicate columns #305
Comments
In the source the "Low" column is found by Possible solution(s) can be to first attempt more strict matches, alternative to always return the first result |
This is similar to #24. Have you thought through the discussion there? |
Hi, sorry I only checked against the open issues. |
No worries! I only wanted you to be aware of the history, so you could take it into account while thinking about the issue. It would be great if you could write some tests, especially if you can think of any other edge cases that aren't mentioned in the other issue. You can write them in the testthat style and/or use testthat locally. But I would use tinytest instead, so don't spend time getting the package to build/check with testthat. |
In preparing test cases I do not get a positive result from
|
Based upon the test cases analysed from #24 and #305, the following solution should work.
And below solution for the related function (avoiding code duplication).
If you think this makes sense I can prepare a pull request tomorrow with the changes for OHLC functions and including tinytest cases. |
Created pull request #306 to improve the column matching (with test cases). |
I'm sorry I didn't respond earlier. I started working on the comments below on Saturday morning (which was still later than I should have). I'm going to leave these comments here, and I'll add the relevant comments to the PR. Please keep in mind that I had most of the points below in mind before you created your PR. They're based on the code in your comments in this issue, so some points might not apply to your PR.
I would appreciate a PR! Please take a look at the contributing guide before you get started. Some notes to keep in mind:
|
Thanks for your feedback. I will add the response to the PR #306. |
I have run into this bug too.... Have you considered using a REGEX for your pattern matching in
In the pattern I can think of one instance when this solution would fail: a ticker containing "LOW" followed by another letter. For instance, if there were a ticker "FLOWR", the bug would re-emerge. The only other way I can see to solve this would be to match only columns that end in "low," which seems like a reasonable permanent solution. To do that, use "low$" as your grep pattern:
Perhaps implement the first solution now and warn users that in a future version, the column names will need to end with the key search words. |
Thanks for your feedback. The proposed solution in the pull request is to catch exact matches first and secondly perform a regex with 'grep('Low$', colnames(x), ignore.case = TRUE)'. Similar to your second option. The first option fails for example on the symbol of this ETF. The proposed solution works with how the columns are added in other quantmod functions, and by being more strict reduces the risk of interference with other packages/code. The downside is a risk to break code that people may have implemented based on the current matching. |
tickers found in the wild: |
Description
The issue occurs when multiple columns in the data set match the OHLC-names. The OHLC function returns each matching column. In the test case the data set contains a column from Stochastic oscillator (TTR function) with the name "slowD". As a result OHLC returns; "AAPL.Open", "AAPL.High", "AAPL.Low", "slowD", "AAPL.Close" (from a data set with 20 columns).
Expected behavior
Expect the OHLC function to return the
Open
,High
,Low
andClose
data, nothing else.Minimal, reproducible example
The text was updated successfully, but these errors were encountered: