Avoid thoughtless posting - imagine a post that you would find inspiring from others, then aim for that standard yourself. In this way the board will blossom.
- Manlobbi
Halls of Shrewd'm / US Policy❤
No. of Recommendations: 9
For those who actually use VL data this is my method for checking the quality of the data. I compare the prices in the VL file with an accurate database I store daily. I do this for AAPL and IBM. When they are a match I consider the file to be OK, and when not, GARBAGE. I do not consider the Total Return values, but only the CLOSE price for each weekend file. This is what the conclusion is for 2025.
File Close
Date Date Verdict
12/27/2024
1/3/2025 12/27/2024 OK
1/10/2025 1/3/2025 OK
1/17/2025 1/10/2025 OK
1/24/2025 1/17/2025 OK
1/31/2025 1/24/2025 OK
2/7/2025 1/31/2025 OK
2/14/2025 2/7/2025 OK
2/21/2025 2/14/2025 OK
2/28/2025 2/21/2025 OK
3/7/2025 2/28/2025 OK
3/14/2025 3/7/2025 OK
3/21/2025 3/14/2025 OK
3/28/2025 3/21/2025 OK
4/4/2025 3/28/2025 OK
4/11/2025 4/4/2025 OK
4/18/2025 4/11/2025 OK
4/25/2025 4/17/2025 OK
5/2/2025 4/25/2025 OK
5/9/2025 NONE GARBAGE
5/16/2025 4/25/2018 GARBAGE
5/23/2025 4/25/2018 GARBAGE
5/30/2025 5/23/2025 OK
6/6/2025 4/25/2018 GARBAGE
6/13/2025 6/6/2025 OK
6/20/2025 6/13/2025 OK
6/27/2025 6/20/2025 OK
7/4/2025 4/25/2018 GARBAGE
When it says NONE that means there are no prices for the full history of IBM and AAPL that are a match to the prices they've stored in their file. You'll note that when it is GARBAGE the date of the CLOSE prices are consistently 4/25/2018. This means that when they fail they tend to just keep using that same file again and again.
No. of Recommendations: 2
For those who actually use VL data this is my method for checking the quality of the data. I compare the prices in the VL file with an accurate database I store daily.
Similiar Experience with a different Database makes me suspucious that the recent addition of a new holiday(6/19) is at least part of the problem. But probably not that simple.
GD_
No. of Recommendations: 4
... the recent addition of a new holiday(6/19) ...
I noticed recently that this holiday affects the common assumption that there are 252 (or 252 plus a little) trading days per 12-month period. So maybe annualizing backtest results should use 251 (or 251 plus a little) trading days per 12-month period for recent periods. Calendar 2022 is the first year affected. Calendar 2022, 2023 and 2024 show 251, 250 and 252 trading days. (2024 was a leap year.) No big deal for long-term backtests, especially since early years (back to the 1930s) often had weird numbers of trading days anyway.
No. of Recommendations: 4
makes me suspucious that the recent addition of a new holiday(6/19) is at least part of the problem.
Juneteenth has been a federal holiday for five years by now.
Elan
No. of Recommendations: 2
Addition of a new holiday(6/19) results with the database provided by Microsoft.
Note the odd differences of calandar days with a constant 251 mktday.
As stated before have a lot of respect for others that create database for backtesting.
W/ MktDays @ 251 /Y INX:Days INX:MktDays SPY:Days SPY:MktDays IJH:Days IJH:MktDays IJR:Days IJR:MktDays
LookBack (adj) 9 3 1 2 1
LookBack(6Yr) 2199 2202 2200 2201 2200
Count(5y:262) MktDays 1255 1255 1255 1255
Diff(MD-BM) MktDays 0 0 0 0
MAX(5y) EndDate 03-Jul-25 03-Jul-25 03-Jul-25 03-Jul-25
DAYS(5y) Days 1828 1823 1827 1823
MIN(5y:261) StartDate() 01-Jul-20 06-Jul-20 02-Jul-20 06-Jul-20
Diff(Days-BM) Days 3 (2) 2 (2)
GD_
No. of Recommendations: 3
This one adjusted for StartDay
W/ MktDays @ 251 /Y INX:Days INX:MktDays SPY:Days SPY:MktDays IJH:Days IJH:MktDays IJR:Days IJR:MktDays
LookBack (adj) 9 1 1 1 1
LookBack(6Yr) 2199 2200 2200 2200 2200
Count(5y:262) MktDays 1253 1255 1254 1255
Diff(MD-BM) MktDays 2 0 1 0
MAX(5y) EndDate 03-Jul-25 03-Jul-25 03-Jul-25 03-Jul-25
DAYS(5y) Days 1823 1823 1823 1823
MIN(5y:261) StartDate 06-Jul-20 06-Jul-20 06-Jul-20 06-Jul-20
Diff(Days-BM) Days (2) (2) (2) (2)
GD_
No. of Recommendations: 5
Mapg: As stated before have a lot of respect for others that create database for backtesting.
Creating one with the capabilities of GTR1 like Robbie did for me is more like absolutely awesome admiration.
I still keep my personal one which once a week downloads the SIP data, converts the fields into a MySQL database but I haven’t been using it for investing for several years now.
Until last year the easiest way to roll your own was to get a SIP subscription, write a script to download all the historical data off the AAII website and then download RunRadis which has a built in backtester that works directly with the SIP data stored on a disk or SSD. Sadly, AAII no longer has the older data on their website.
No. of Recommendations: 8
I wrote: You'll note that when it is GARBAGE the date of the CLOSE prices are consistently 4/25/2018.
This last week's file was also CLOSE prices of 4/25/2018. It is crazy that they do this so consistently! While at the same time charging us for quality data!
No. of Recommendations: 6
I wrote: You'll note that when it is GARBAGE the date of the CLOSE prices are consistently 4/25/2018.
This last week's file was also CLOSE prices of 4/25/2018. It is crazy that they do this so consistently! While at the same time charging us for quality data!
I'm guessing that they manually run a multi-step process and it depends who runs it. There's someone who skips some of the steps out of ignorance or sloppiness. And they have absolutely no quality control steps to verify the results of the process.
I've sent them email messages in the past to alert them when the data is bad, but they never respond so I gave up.
Elan
No. of Recommendations: 5
In case anyone is watching, this is my list of bad releases since September 2024.
The date shown is the name on the update file which is a Friday, the release date of that file is generally the Monday four days before that.
2024-11-22 bad prices
2024-12-13 bad prices
2025-01-10 no TR
2025-01-17 no TR
2025-01-24 no TR
2025-01-31 no TR
2025-02-07 bad TR
2025-02-14 bad TR
2025-02-21 bad TR
2025-02-28 bad TR
2025-03-07 bad TR
2025-03-14 bad TR
2025-05-16 bad prices
2025-05-23 bad prices
2025-06-06 bad prices
2025-07-04 bad prices
2025-07-11 bad TR
2025-08-22 bad prices
July 11 was easy to miss, all I spotted was that each stock had identical figures for R26 and total return YTD.
Jim
No. of Recommendations: 2
That's about a 38% failure rate. You guys still pay for that crap?
There's got to be a better way - Pinnacle? Zacks? Finviz?
No. of Recommendations: 1
That's about a 38% failure rate. You guys still pay for that crap?
There's got to be a better way - Pinnacle? Zacks? Finviz?
The data in the VL screener seems to be ok. At least, the prices are ok. Don't know about the other data, but it's not all the same number for all the stocks.
I also grab data from finviz & barcharts. The free versions.
No. of Recommendations: 0
And they have absolutely no quality control steps to verify the results of the process.
I've sent them email messages in the past to alert them when the data is bad, but they never respond so I gave up.
They have quality control. You! :)
No. of Recommendations: 2
I've sent them email messages in the past to alert them when the data is bad, but they never respond so I gave up.
They have quality control. You! :)
Sadly, they don't listen to him. Thus, they have quality input, but no control.
Eric Hines
