Before this update, all VL, VL+ and SI Pro data took effect for trading in backtests on the first market date after the Friday of publication, usually the following Monday. Data now takes effect for trading in backtests at the close of the same Friday of publication, or the most recent market date if Friday was a holiday. Likewise, WER data now takes effect for trading at the close of the same Thursday of publication, or the close of the most recent market date if Thursday was a holiday.

Because of this change, it is now advisable to use a lag of one market day for all VL, VL+, SI Pro and WER data fields in backtests in order to avoid crystal ball effects. However, for your convenience, the backtester automatically applies this lag of one market day to all field files that are not explicitly lagged by some other amount. For example, if a backtest references the field file tim.v, the backtester will interpret it as tim.v:1 in backtests. This automatic lag can be overridden by either explicitly specifying a lag other than 1 (including 0), or by using the new option called "Field File Lag" in the user interface, which allows you to change the default lag applied to all field files whose lag is not explicitly specified. In all cases, the backtester will always honor a lag that is specified at the end of a filename using the filename:n notation.

The lags in technical analysis functions like tr, rrs, sma etc are not affected by either the "Field File Lag" setting or the automatic lag--they work exactly as they did before. While the new automatic lag does affect generic field files like pav63p.a, ph253.g, etc derived from daily data, these files have not changed at all, and it is perfectly safe to apply lags of zero market days to these fields if that is what you've been doing before.

The only field functions affected by automatic lagging or the "Field File Lag" setting are the special pricing functions for specific data sources, such as vprc, pprc and sprc, which use field files gtov.v, gtop.p and gtos.s respectively. When no lag arguments are specified for these field functions, the same field file lag is assumed for these arguments (both share_lag and quote_lag) that is applied to field files.

The main reason for making these changes is that they allow me to update the VL, VL+ and SI Pro data over the weekend instead of on Monday nights, which is much more convenient for me.

New Screener Mode

The user interface at backtest.org/gtr1/2011 now has two "Run" buttons: a "Run Backtest" button and a "Run Screener" button. The "Run Screener" button generates a list of all stocks eligible for the screen's final step on the last day of the backtest, sorted by the field used at the final step (if the final step uses an absolute comparison, e.g., tim.v = 1, then the list is unsorted and consists only of stocks passing the final step). The results also show all field values for the stocks listed.

When you click "Run Screener" for the first time, a section is added to the form for entering passwords for the various data sources before showing any results. Once you've entered any required passwords, you will need to click "Run Screener" again to get results. Since your passwords are not added to URLs, you will need to re-enter your passwords each time you run the screener. I recommend using iMacros (described below) to automate your password entry.

The second reason for changing when VL, VL+, and SI Pro takes effect is that it allows you to run the screener on the new data over the weekend instead of having to wait until Monday night. Likewise, screening on new WER data can be done on Thursday night instead of Friday night at the earliest.

The default lag is changed from 1 market day to 0 market days in screening mode. Thus, if you want to get screen picks for a screen you've been backtesting, you don't need to change the lags of field files in the screen definition. You will, however, have to manually change the lags in technical analysis functions if you want your trading to be consistent with the lags used in backtests.

Calculating Passwords for Stock Screening

If you are a subscriber to one of the data services below, you can calculate a stock screening password as follows:

VL+: Export all of the latest Summary and Index data to text file. Select all stocks where [Technical Rank] = 5 and [Alert] = 0 and sort them in ascending order by [Ticker Symbol]. Form the password by stringing together all resulting ticker symbols that begin with the letter 'A'. Strip the ticker symbols of any white space, but include any punctuation (such as '/', '-', '.', etc). Do not separate the ticker symbols by commas or any other characters.

VL: If you are a VL+ subscriber, you do not need a separate VL screening password--simply enter your VL+ password in the "VL" box.

For standard VL subscribers, export all of the latest Summary and Index data to text file. Select all stocks where [Technical Rank] = 5 and [Alert] > 0 and sort them in ascending order by [Ticker Symbol]. Form the password by stringing together all resulting ticker symbols. Strip the ticker symbols of any white space, but include any punctuation (such as '/', '-', '.', etc). Do not separate the ticker symbols by commas or any other characters.

Note that the use of the VL field [Alert] means that the password cannot be constructed from the printed version of the VL Summary and Index.

SI Pro: The screening password is simply the upper-case MD5 hash of the latest Program/Data Installation file available to subscribers at http://www.aaii.com/stock-investor-pro/downloads . The SI Pro screening password for 9/28/2012 would have been:

1A025CA920BB2B3E9175DDE6612E9423

For getting MD5 hashes in Windows, I would recommend the freeware HashTab, which allows you to get various hashes by right-clicking on files in Windows Explorer. I haven't used it before (I use the md5 command in Cygwin), but the reviews look good.

WER: The screening password consists of all ticker symbols found in the latest WER, in the order they appear, separated by commas. If you are using Windows, which does not come with a decent text editor, I recommend TextPad for forming the password. If you have the list of WER ticker symbols sorted in ascending order by RIL "rank in list", copy and paste the list into TextPad. Then select "Search", "Replace", and choose "Regular expression". Enter \n for "Find what" and a single comma for "Replace with" and then click "Replace All". The list of ticker symbols should now be all on the first line, separated by commas. If there is a comma at the end, delete it.

DO NOT SHARE SCREENING PASSWORDS. If I suspect that anyone is sharing passwords, then I will remove this feature. If you want the feature to remain permanent, then please consider volunteering to help come up with and program a better system for validating subscribers to these services.

Using iMacros for Firefox to Automate Password Entry

I recommend the Firefox add-on iMacros for automating the entry of passwords. To record a macro that enters the above (expired) VL screening password, go to backtest.org/gtr1/2011 in a new Firefox window and click "Run Screener". When the the password entry form appears, start recording the macro (after you've installed the Add-on, there should be an iOpus icon next to your forward/back buttons). Paste the password into the box next to "VL:" and then stop recording (or you may also want to click "Run Screener" again before you stop recording to save yourself that click as well). Since by default, a macro is recorded to refresh whatever page you were at when you started recording, you'll needed to edit the macro. Right click the new macro (which is called #Current.iim until you give it a new name) in the iOpus pane and choose "Edit Macro". Delete all lines before the line

and then click "Save & Close." When you replay this macro, it will add the password to the form and, if you chose to, click "Run Screener" for you. This same process can be used to automate the entry of "Miscellaneous Options" that are not encoded in URLs, such as risk=gdstub, etc.

"The default lag is changed from 1 market day to 0 market days in screening mode. Thus, if you want to get screen picks for a screen you've been backtesting, you don't need to change the lags of field files in the screen definition. You will, however, have to manually change the lags in technical analysis functions if you want your trading to be consistent with the lags used in backtests."

Could you provide an example of the last sentence? If you want current picks on a Sunday for use on a Monday of a backtested screen using, say, ratio(aprc, sma(0,5) < 1,when would you need to change the lag to match the backtest? Let's say you want to make sure you are getting the (0,5) of the previous Monday to Friday period when you look on Sunday.

Could you provide an example of the last sentence? If you want current picks on a Sunday for use on a Monday of a backtested screen using, say, ratio(aprc, sma(0,5)) < 1 ...

I can't answer your question, but as a slight interjection that expression would be a bug.You can't compare actual ("a") price fields directly with linearized ("g") price fields.aprc is an actual price, sma is based on gprc which is in linearized units.The two have nothing to do with one another in terms of absolute size.I believe gprc is set to 1.0 for all stocks some fixed number of days of extrapolation prior to the first day that pricing opened for that security.It could be thought of as "total return since time immemorial".

GTR1 is like physics equations: if the units don't match, it's the wrong answer.The main units to watch out for are"a" (actual)"s" (SIpro)"v" (Value Line)"g" (linearized, including gprc and sma)rrs fields (their own thing: change in level of trend line of log prices per trading day, I believe, so 10%/year would give you about .000378)

musselmant:Could you provide an example of the last sentence? If you want current picks on a Sunday for use on a Monday of a backtested screen using, say, ratio(aprc, sma(0,5) < 1,when would you need to change the lag to match the backtest? Let's say you want to make sure you are getting the (0,5) of the previous Monday to Friday period when you look on Sunday.

Note that I have used a lag of 1 market day in both gprc(1) and sma(1,5), because if you're going to use the GTR1 screener to produce your stocks picks on Friday night and and will be trading on Monday, there's no point in backtesting a log of 0 in the technical analysis functions, since by Monday the lag is somewhere between 0 and 1 already, probably closer to 1.

Since I did not specify a lag for timely.v (which is recommended), the backtester applied a lag of 1 market day, since Timeliness rankings were not tradable on Fridays for most of the history. Neither this automatic lag nor the "Field File Lag" have any effect on field functions sma and gprc.

Now suppose you want to get this screen's picks over the weekend. If you click "Run Screener", the feedback from the backtester changes to:

As you can see, the lag for timely.v changed from 1 to 0. When you trade on Monday, you want Friday's Timely stocks, not Thursday's. However, since the automatic lagging does not affect field functions like sma and gprc, their lags of 1 market day remain, meaning they are calculated through Thursday's close, not Friday's. If you traded on these rankings at the next close, you'd be using a lag of 2, not 1. In order to match what is backtested and have a lag of 1 in these measurements when you trade on Monday, you need to manually change the lags to 0 when you run the screener:

PS In composing this post, I noticed that when the backtester warns you about having applied automatic lag, it shows you the original command argument as entered, not the modified argument. I should probably change that. Or maybe I should say, "field0=timely.v becomes field0=timely.v:1".

I've been trying to get the picks out of the screener in GTR1. This is the first time I've been using it, so I am quite sure I'm not doing this right.

I have an SIPro subscription.TO get the latest md5, I look at the latest program and data update installer. As of current date, it is the stockinvestorinstall.exe as of 05/10/2013. I calculate an md5 and convert it to upper case thusly: % md5sum stockinvestorinstall.exe | perl -ne 'print uc($_)'

I use this as the password on the screener page on GTR1.And it doesnt work - with a message that password is wrong."SI screening password failed.You do not have permission for SI screening."

Am I missing any step ?

Appreciate any pointers,best,bgpl

PS: awesome functionality - I've just discovered the power of GTR1 and am blown away !

I have a SIPro subscription and have only used the password a couple of times. However I just went to the AAII site downloaded the file, got a hash code and entered it and just likeyou my password failed. In the past AAII has updated their download after the first versionwas posted over the weekend which results in a new hash code that doesn't work. In otherwords I don't think the problem is with you but for that reason I sometimes use GTR1 for backtests but not for screening.

bgpl:I've been trying to get the picks out of the screener in GTR1. This is the first time I've been using it, so I am quite sure I'm not doing this right.

No, you're doing everything right. The problem is this: AAII does not have a single update file they publish each week. Instead, they post an update file on Saturday morning at http://www.aaii.com/stock-investor-pro/downloads , and throughout the next few days, they make changes to the data without notifying members in any way, all the while using the same filename and "data as of" date. I've detected changes to their data as late as Monday night (after market close), and have been meaning to check whether they make any data changes even later than that. (Does anyone else want to volunteer to keep an eye on these changes?) This is a pain in the ass for a few reasons:

1. As you've found, these changes foil my attempts at creating a weekly SI Pro screening password. I've tried basing the SI Pro password on the data itself instead of an MD5 hash of the installation file (which will almost certainly change if just one byte changes), but in all my attempts at doing so, my algorithm has always produced more than one password for the same week depending on which update I used. If I reduce the password's sensitivity to the data so that this is less likely, then I get the same password for a few weeks at a time.

2. More importantly, it means that there is a little bit of arbitrariness to the screen rankings that get posted on this message board. The changes to the data that appear after the initial publication of a weekly update file are often non-trivial.

3. If you generate your own rankings, then it's best to download and reinstall SI Pro right before trading to guarantee that you have the latest data. I usually wait until mid-Monday to download the file, which is what the GTR1 backtester's SI Pro password is based on.

I just downloaded the SI Pro file, computed its MD5 digest and added it to the list of SI Pro screening passwords for this week (meaning more than one password will work). If you ever have trouble with an SI Pro password again, just send me a private email with the password you're using, and if it's a valid one, I'll manually add it to the list for the week.

Another question:- is VL data also having the same problem ?- what VL subscription do I need to make the screening from VL work ?

As far as I know, Value Line does not alter their weekly update files once they are published, except possibly in rare circumstances where they acknowledge errors in their data and fix them (it has probably snowed where I live in Australia more times than this has happened).

You can use the GTR1 screener to generate rankings for either the standard or expanded editions of the Value Line Investment Survey, depending on which version you have. Apparently there is now an online-only version of the standard subscription that doesn't allow you to install the Investment Analyzer software needed to export the "Alert" field that is part of my password algorithm. It also looks like the expanded edition is now advertised as "The Value Line Research Center" on their website.

I realize that manually generating the VL and VL+ passwords is tedious, but the reason I've chosen to base on the password on data instead of MD5 hashes of the installation files (like I do for SI Pro) is that it means I don't have to download both the standard and expanded edition updates--I only need the expanded, from which I can deduce the standard edition data. The cumulative time that I'd spend separately downloading the standard edition installation files each week is probably less than the time it would take someone to write an Excel macro that calculates the passwords and share it with the MI board.