-------------------------------------------------- FREQUENTLY ASKED QUESTIONS (Updated Daily) -------------------------------------------------- --EXPORT--SYSOPTIONS--TRADINGDATA--NEXTDAY--HELPFILES --HELPFILES-(WZ)-------------------------------------------------- 08/02/2010 How can I see the ULTRA10 help files if they won't display from the ULTRA menu? When you select one of the HELP menu items, ULTRA's code simply opens your Internet Explorer directed to the help file in your c:\ultra9 folder. It's exactly the same as opening a webpage except the page is on your computer instead of the internet. ULTRA uses the standard path to Internet Explorer which is: c:\progra~1\intern~1\iexplore.exe (changeable via ULTRA's Options/Startup Option menu item) The filenames ULTRA opens are listed in ULTRA's menu. -EG. Help/ULTRA User's Guide/Start Here (easy.htm) (The "Start Here" file is in c:\ultra9\easy.htm.) So to open the "Start Here" help file with your browser: 1) Open your browser exactly like you normally view the internet. 2) In the URL line, which contains internet pages URLs like: http://www.yahoo.com type: c:\ultra9\easy.htm 3) Press the key. This will display the "Start Here" help file exactly as ULTRA would do. ---------------------------------------------------------------- The way ULTRA 10 works is that: --NEXTDAY-(RG)-------------------------------------------------- 08/02/2010 Why do Buy/Sell Signals seem to sometime disappear or move to different dates? ---------------------------------------------------------------- The way ULTRA 10 works is that: "So that signals are generated in time for users to act upon them, all same/next-day issues are ignored for the last date in the database." (A) This means that percent gains are a bit askew when the last date in the database is the date that the signal occured. This is because the Program doesn't yet have the actual prices with which the trade was executed. The complexity is serious for high frequency systems because, Assume this sequence of trades: 08/01/10: SELL (to be traded at close on 08/02/10). 08/02/10: BUY (to be traded at close on 08/03/10). 08/10/10: SELL. 1) With the 08/01/10 data download, a SELL signal will display because of (A) above. 2) With the 08/02/10 data download, because (A) no longer applies to the SELL in (1), the SELL would normally move to the actual trade date of 08/02/10 (with correct gain info). 3) Also with the 08/02/10 data download, a BUY signal is generated which should be acted upon on 08/03/10. 4) Because: a) ULTRA 10 cannot have both a BUY and SELL on the same day, b) BUYs are checked before SELLs, The 08/02/10 BUY cancels out the SELL that was supposed to move to 08/02/10 so a BUY is displayed on 08/02/10. 5) Because the system's state on 07/31/10 was BUY and the 08/02/10 SELL has now canceled out by the new BUY on 08/02/10, the SELL seems to disappear! 6) With the 08/03/10 data download, the BUY moves to the trade date (08/03/10), which allows the 08/02/10 SELL to display on its trade date. 7) All signals are now on their correct trade days with the correct gains computed. The rule of (A) above allows the program to create the correct historical results and also generates the BUY/SELL signals in time for a user to act upon them. The user will follow the system exactly as long as he acts exactly as the Program recommends. -IE. when the system recommends a Position upon a download of data, he needs to be in that position at the next-day close. Fortunately for all of us, this complexity has been totally simplifed (and hopefully eliminated forever) in ULTRA 11, which is hopefully shipping this month! --SYSOPTIONS------------------------------------------------------- How do I make sure systems give the same results on two computers? (3:51 PM 1/25/2010) (11:16 AM 3/2/2010) ------------------------------------------------------------------- ------------------- WHY IT CAN HAPPEN ------------------- The reasons that a system or strategy running on two computers can generate different results (in order of probability) are: 1. The systems are not set up with the exact same options. 2. Different analysis control settings. 3. Different databases between the two computers or versions. 4. A bug in ULTRA. 5. Different processing methods between the floating point processors. Here's all the information we have available for each reason: 1. Systems with different options. This is by far the most common reason. The way ULTRA is designed, when a system is run via any ULTRA menu item, the "Current Variation" of that system is used (unless overruled as described below). this can get very confusing as there's really no way to know what the "Current Variation" of each system is without Selecting ULTRA's Systems + Options for each system that is contained in a Composite Strategy Definition File (CDF). This is one of the biggest problems with ULTRA and is therefore heavily addressed in ULTRA 11. Our goal with ULTRA 11 is totally portability of systems. (Eg. if you want to give a system or combination of systems to another user, all you need to do is send them one file which totally represents the system/strategy.) 2. Different Analysis Control Settings. Every type of Analysis has some control options (like Start/End Date or Same-day/Next-day). If one computer is running Same-day and the other Next-day, the result will be very different. Same-day/Next-day confusions are a very common reason for differing results. In terms of Composite Strategies the most common confusion is with the *ND flag. Whenever the *ND flag is used in a Composite Strategy Definition (CDF), the system/strategy should be run on a Same-Day basis. Running on a Next-Day basis could delay the signals for the systems marked with *ND by two days. 3. Different Databases. The way ULTRA data downloads work is that each time you download data, the entire current year is downloaded. Therefore, the current year will always be the same on all computers in the field unless a file is corrupt. But that corruption would automatically be repaired upon the next data download. However, in ULTRA versions before 10.15, there was no way for ULTRA to know if all the data for years before the prior year was complete. So say you stopped using ULTRA on 12/05/08 and then started again on 03/02/09 by downloading data. The 2009 year would be complete but a gap would existe from 12/05/08 to 12/31/08. In the past these gaps accounted for many confusions. ULTRA versions 10.15 and later will now periodically, review all the data from 01/02/00 to present to make sure no gaps exist. So this particular problem is now resolved for recent years. But if you had a gap in the 1995 data and installed a new version of ULTRA via a patch instead of the full version, this problem could still occur. (Patches only contain file that have changed since the last major version release so the 1995 data files would not be included.) Another possibility is that a user changed say the SPX close on 03/25/08. His database would now differ from all the other ULTRA databases and ULTRA currently has no way to find that error and/or correct it. And yes, while it's unlikely, one data value error can change a system's buy/sell signals which could create a sequence where the following signals are different as well. Due to compounding, the historical results would end up dramatically different. ULTRA 11 will have extensive database checking to ensure that all the data in a user's database is exactly the same as the main ULTRA database that we maintain, unless the user has specifically asked the program to allow the difference to remain in place. 4. An ULTRA Bug. Every piece of software on earth contains bugs. Many of these only occur on certain computers. (We worked one bug on the old IBM Aptiva for three years and finally determined that it was actually a hardware bug in the Aptiva of which the engineers were aware, but hid from their users.) We do not guarantee that ULTRA is bug-free because that would be ridiculous. Having said that, ULTRA has been used by thousands of people for almost two decades. Most of the bugs have been long shaken out of the program. In our experience very few of user bug reports are actually bugs in the ULTRA code. (Excepting the very recent history with ULTRA 10.32 which is our first port to the 32-bit environment and required a substantial rewrite.) We're fully aware that even though ULTRA is a very low-priced piece of code, users are highly dependent upon it. And, bugs in the buy/sell signals can result in financial losses (or gains interestingly enough). Because of this, ULTRA 11 contains the most extensive integrity checking capability that is possible without effecting the ability of the program to operate. We designed this functionality to be invisible to the user in terms of execution speed but it allows us to easily debug even very minor bugs that would probably never effect any user in the field. (For context, if Microsoft used this type integrity checking in their code, it would probably generate thousands of errors per hour of use.) Our goal for ULTRA 11 is to be Military/NASA spec in terms of reliability which as you can imagine is very challenging consider our development budget vs. theirs. 5. Different Floating Point Processors. Computers must emulate floating point computations and they all do it very slightly differently. Pretty much everything ULTRA does is floating point math. So by design (of the computer manufacturers), ULTRA will run very slightly differently on all computers (just like all software that uses floating point mathematics.) While it's extremely rare, we have seen a few cases in the past where one of our machines generated a buy/sell signal while another did not due to the differences in the floating point emulation algorithms. Again, when one buy/sell signal is generated on one computer and not on another, the results over a period of history following that signal difference can be dramatic making the signal appear as garbage while the difference was really only something like 0.000001 in one floating point number. ------------------------------------------ HOW TO TROUBLESHOOT / RESOLVE THIS ISSUE ------------------------------------------ STEP ONE- Make 100% sure all systems are using the same options. ---------------------------------------------------------------- Whenever possible, use a complete representation of each system which eliminates the use of the "Current Variation" of a system by ULTRA. Systems can easily be defined differently on two computers. The best way to ensure that you are running the exact same on both machines is to always represent systems using full definition via the CDF button in ULTRA's SYSTEMS + OPTIONS. For example, If you were to go into SYSTEM + OPTIONS + PRES and click the CDF button, a string is copied into the windows clipboard that completely represents PRES with the options displayed on the screen, such as: PRES,1 *O POSY=0,MIDY=0,PREY=1,ELEY=0,ODE=0 If you pasted that string into a Composite Strategy Definition File (CDF) by creating the file C_PRES.TXT containing: @sys PRES,1 *O POSY=0,MIDY=0,PREY=1,ELEY=0,ODE=0 @all 0,0 1,100 @end Then, running a TIMING + HISTORICAL ANALYSIS(COMP...) on c_pres.txt will give you the exact same results as if you had gone into SYSTEM + OPTIONS + PRES, set up those options, and then run a TIMING + HISTORICAL... Any computer running C_TEST.TXT would create the same historical results and real-time signals (as long as none of cases #2 through #5 above occur). Assume you were using another Composite Strategy defined in C_TEST2.TXT which contained: @SYS SIMA,1 *ND *O MAD=21, INDEX=SIL @ALL 0,0 1,100 @END You can then create a COMPOSITE RUN ALL DEFINITION file, CA_TEST.TXT containing: C_TEST.TXT,1 C_TEST2.TXT,1 Which you can run via: TIMING + HISTORICAL ANALYSIS (Mult...) or TIMING + RUN ALL COMP... Unfortunately, as of 03/02/10, not all systems have the ability to be fully defined by a string of text yet. But that will soon change with ULTRA 11 which simplifies and expands this testing ability significantly. STEP TWO- Make 100% sure you are using the same Next-day / Same-day settings. ----------------------------------------------------------------------------- Again, the *ND flag in Composite Definition Files (CDFs) are very often the culprit. STEP THREE- Identify exactly which system is causing the difference. -------------------------------------------------------------------- As indicated above, while the results may appear dramatically different making you think that there is some severe bug in ULTRA, more likely is that just one system is generating some different buy/sell signals which create a sequence of differences. It's easy to determine which system is causing the difference by just commenting out all the others and comparing the results. For example, if you had a CDF: @SYS SIMA,1 *ND *O MAD=21, INDEX=SIL PRES,1 *O POSY=0,MIDY=0,PREY=1,ELEY=0,ODE=0 @ALL 0,0 1,100 @END The first thing you should notice is that SIMA uses *ND while PRES does not. Because *ND is use, the strategy should be tested using Same-Day trading in the Analysis Control (window where you set Start/End date). Doing otherwise would delay the SIMA signals by two days. Another reason with this particular CDF is that since PRES is based solely on the calendar it can be traded on a Same-day basis. If you wanted to be notified of the PRES buy/sell signals one-day in advance, you could change the defintion line to: PRES,1 *ND *O POSY=0,MIDY=0,PREY=1,ELEY=0,ODE=1 By adding *ND and setting ODE (One-Day-Early) to 1, the signals fire in time to act upon them but the *ND correctly moves the signals to the day on which the trade actually occurs. In order to determine which of the two systems are causing the difference you should "Comment-out" one system. For example: @SYS SIMA,1 *ND *O MAD=21, INDEX=SIL // PRES,1 *O POSY=0,MIDY=0,PREY=1,ELEY=0,ODE=0 @ALL 0,0 1,100 @END By starting the line with // the PRES system is ignored so only the SIMA system is running. LASTLY... ---------- Dealing with this exact issue is largely why we were almost forced to abandon the ULTRA product instead of spending 1400+ programming hours modifying it to run for Windows 7 and Vista 64-bit. As stated above, historically a very tiny percentage of these types of issues end up actually being ULTRA bugs. As you can probably also see, determining the cause of these issues can be very time-consuming. Over the years we've spent thousands of hours figuring out these issues. In the early days of ULTRA we did find some bugs so that time was a good investment for us. But nowadays, almost zero are actually bugs and those hours just paralyze the ULTRA business. Therefore, we cannot provide any additional help for these types of issues other than what is stated in this document. The exception to that policy is under our Paid Support where we'll generally do anything you need. On the other hand, if you narrow down the problem to one system which is generating different results using the same version, same database, and same options on two computers, please report it as a bug report (Via the Contact Us link at ultrafs.com). Fixing real bugs in the generation of system signals is our highest priority. --TRADINGDATA------------------------------------ How can I test against Rydex and Profunds data besides RYNVX that's in ULTRA's Database. (11:00 AM 2/26/2010) ------------------------------------------------- With ULTRA 10 you can test against any datafile that is pure ASCII. An ASCII file is one which contains only displayable characters with a few exceptions line Newline, Tab, etc. An ASCII file is a .txt file while a word document or a web page file is not. In ULTRA 10, data beside RYN (Rydex Nova) has to be downloaded from another source. The process is a bit tedious at first but once you've done it a few times, it's very easy. Instructions are available via the ULTRA menu: "Data + How To Create..." In ULTRA 11 we will eventually have in our database every Rydex and Profunds fund that is: 1. Tradable at end-of-day. 2. Based upon a benchmark. --SYSOPTIONS------------------------------------- What does the W3S system's ODE=1 option mean? (10:49 AM 2/26/2010) ------------------------------------------------- Any system that is based solely on a calendar can be set with ODE=1, which stands for (O)ne (D)ay (E)arly. ODE=1 causes the system to generates the buy/sell signals one day early so that you are notified in time to actually act upon the signal. For historical testing, whenever ODE=1, you should also be using the *ND flag which tells the system to make it's transactions on the Next-Day after the signal generates. So if the buy/sells are generated One-Day-Early and the system trades Next-day, it essentially becomes a "Same-day" system, which is how the system should be traded since it's calendar based. Lastly, because of the way ULTRA 10 is designed, the *ND flag is ignored by ULTRA on the last day in the database. This causes the ODE=1 system's signal to show up in real-time on the day before you should act upon it. But during historical testing, on days that are not the last in the database, the *ND moves the ODE=1 signal back to the actual day that it should have been acted upon. --EXPORT------------------------------------------------------------------------------- I'm having a problem running a Historical Analysis against a .txt file. I know the data is ok. Am I doing something wrong or is there a fix for this? I have tried it on 2 computers. (11:40 AM 2/25/2010) --------------------------------------------------------------------------------------- I just used Data + Export Data to export the SPX into a file named: spxdata.txt . Here's a sample from the file: 01/02/42,8.89 01/03/42,8.97 01/05/42,9.09 01/06/42,9.05 01/07/42,9.00 01/08/42,8.88 01/09/42,8.85 01/10/42,8.79 01/12/42,8.84 01/13/42,9.02 Then I ran the ALLEN System from 01/02/42 to present against the file by typing into Timing + Historical Analysis' "Index or EDF" field: spxdata.txt It ran perfectly. I'm not aware of any bugs in this area of ULTRA and it's very heavily used. It may be that your ULTRA isn't set up to read the file correctly. In order to read a file like this which is of the format: MM/DD/YY , Data ULTRA should be set up via Options / External Data File Options as: Date Field Number: _1_ Date Format: _x_ MM/DD/YY Date Item Field Number: _2_ Field Delimiter: _,_ My suggestion would be to try to replicate what I just did and the exercise will probably give you the clues you need to determine why the Historical Analysis isn't working for your file. --EXPORT-------------------------------------------------------- How do we run historical analysis with the S&P 500 TOTAL return, rather than just the index return? (10.32a at 4:55 PM on 1/25/2010) ---------------------------------------------------------------- 1. DATA + EXPORT DATA with: 'Export File name' = spx_tr.csv 'Field1 = date' 'Field1 = SPX' 'Include Dividends...' = CHECKED. CLICK OK. 2. TIMING + HISTORICAL ANALYSIS with: 'Index or EDF' = spx_tr.csv CLICK OK.