Could the main symbol be triggering fixup=1 after Monday, which would explain the close values?
http://www.amibroker.com/guide/afl/afl_view.php?id=54 *FOREIGN *- access foreign security data *Referencing other symbol data *(AFL 1.5) *SYNTAX* * foreign( TICKER, DATAFIELD, fixup = 1) * *RETURNS* ARRAY * * *FUNCTION* Allows referencing other (than current) tickers in the AFL formulas. TICKER is a string that holds the symbol of the stock. DATAFIELD defines which array is referenced. Allowable data fields: "O" (open), "H" (high), "L" (low), "C" (close), "V" (volume), "I" (open Interest), and for v5.29 and above: "1" (aux1), "2" (aux2) The last parameter - fixup - accepts following values - 0 - the holes are not fixed - 1 - *default value* - missing data bar OHLC fields are all filled using previous bar Close and volume is set to zero. Note: you can use Foreign/RelStrength without specifying last parameter: Foreign( "ticker", "field" ), RelStrength( "ticker" ) - then the holes will be fixed. - 2 - (old pre-4.90 behaviour) - causes filling the holes in the data with previous O, H, L, C, V values Unless you know what you are doing you should use DEFAULT value of fixup parameter (Fixup=1). If you do not use fixup=1, data holes will have the value of Null that you would need to handle by yourself. * * *EXAMPLE* // EXAMPLE 1: // Plotting spread between currently selected symbol and another one *Graph0* = *Close* - Foreign( "MSFT", "Close" ) ; // EXAMPLE 2: // Built-in relative performance chart _N( TickerList = ParamStr("Tickers", "^DJI,MSFT,GE") ); NumBars = 20; fvb = Status("firstvisiblebar"); Plot( 100 * ( *C* - *C*[ fvb ] ) / *C*[ fvb ], Name(), *colorBlue* ); *for*( i = 0; ( symbol = StrExtract( TickerList, i ) ) != ""; i++ ) { fc = Foreign( symbol, "C" ); * if*( ! IsNull( fc[ 0 ] ) ) { Plot( 100 * ( fc - fc[ fvb ] )/ fc[ fvb ], symbol, * colorLightOrange* + ( (2*i) % 15 ), *styleLine* ); } } PlotGrid( 0, *colorYellow* ); _N( *Title* = "{{NAME}} - Relative Performance [%]: {{VALUES}}" ); *SEE ALSO* PLOTFOREIGN() <http://www.amibroker.com/guide/afl/afl_view.php?id=115>function , SetForeign() <http://www.amibroker.com/guide/afl/afl_view.php?id=247>function Comments: *Tomasz Janeczko* tj --at-- amibroker.com 2003-08-07 20:28:41Foreign function synchronizes the data file you are referencing with the currently selected symbol. Synchronization makes sure that EACH bar of FOREIGN data matches exactly with each bar of currently selected symbol. So if DateNum() function returns 990503 for given bar then Close array represents the CLOSE of currently selected symbol at May 3, 1999 and Foreign("SYMBOL", "C") represents close of foreign symbol at May 3, 1999 TOO. This is absolutely necessary because otherwise you won't be able to do ANY meaningful operations involving both selected symbol and foreign symbol. This also needed for the display so when you mark the quote with vertical line it will always match the date displayed regardless if you use Foreign or not. Please note that if you have data holes in currently selected symbol then in order to synchronize bars Foreign function will remove bars that exist in Foreign symbol but do not exist in currently selected symbol. Warm regards, David On Sun, Jun 6, 2010 at 8:23 PM, jooleanlogic <[email protected]> wrote: > > > I have two symbols AP and APS for the Aussie Spi futures. > APS is basically a 24 hour instrument and AP is the day only version of it > from 9:50-16:30. They're identical during the day session. > > I want to view the AP symbol (just high to low bar) overlaid on the > APS(24h) symbol in the daily timeframe only. When I do the following though: > > fh = Foreign("AP M0-SFE", "high"); > fl = Foreign("AP M0-SFE", "low"); > Plot(fh, "FH", colorRed); > Plot(fl, "FL", colorGreen); > > only Mondays seem to work. For all other days, fh and fl just seem to get > assigned the close price of AP. > > Both symbols are part of the same group which is time-shifted 2 hours. It's > a 1 minute mixed intraday/eod database and no filtering is applied. > Both symbols are realtime using eSignal but have had historical ascii data > imported. > > Any ideas? > Thanks, > Jules. > > >
