Announcement

Collapse
No announcement yet.

the implementation of sym()

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • the implementation of sym()

    The implementation of sym() is EFS2 seems flawed. To demonstrate what I am talking about, you may apply the attached testing script and apply it on 1min chart of "6E H8".

    When the secondary symbol is set to "ES H8", the minute info of Bar -1 printed out for both "6E H8" and "ES H8" are the same for all historical bars. Then during the realtime updating period ( getCurrentBarIndex(0 == 0 ), the values of minute(-1) and m may be different. This happens when the new bar of "6E H8" is created eariler than that of "ES H8" ( the first tick of "6E h8" comes earlier than that of "ES h8"), otherwise the printed out values are the same.

    However in my opinion, EFS2 engine should be able to allign all old bars of different symbols using sym(). In the about example, no matter whether ES H8 bar 0 exists or not, when minuteArray.getValue(-1) is called, it should always return the correct value. Otherewise sym() only works to align historical bars, and when doing realtime update, it is no different from using getValue("Minute", -1, 0, "ES H8,1").

    The reason I am pointing out this is when the trading decision is made at the beginning of each new bar based on the inficators values at the end of previous bar, if the secondary symbol's tick comes later then the primary symbol, then the inficator value of the secondary symbol would actually be one bar older than it is intended, while in backtesting or after fact study, everything is aligned perfectly by sym() and such design flaw can not be noticed.
    Attached Files

  • #2
    clearpicks
    Try retrieving the value using the getBarStateSymbol() function instead of when the main symbol creates a new bar at which time the function returns the last known value for the external symbol (while the script is running in real time). FWIW this same topic was discussed also in this thread where Jason already explained to you what happens in this situation.
    Try the enclosed modification of your script (note that this is just a quick modification to illustrate the point so it may need some refining) and run it on the 1 minute chart of 6E H8.
    PHP Code:
    function preMain(){
        
    setPriceStudy(false);
        
    setStudyTitle("TestSetBar");
        
    setDefaultBarFgColor(Color.blue,0);
        
    setDefaultBarThickness(3,0);
        
    setPlotType(PLOTTYPE_HISTOGRAM,0); 
        
    setHistogramBase(00);
    }

    var 
    bInit;
    var 
    volumeArray;
    var 
    minuteArray;
    var 
    secondSymbol "ES H8";

    function 
    main(){
        if ( 
    getBarState() == BARSTATE_ALLBARS ) {
            
    setChartBG(Color.lightgrey);
            
    bInit false;
            var 
    today = new Date();
            
    drawTextPixel(2020secondSymbol ", loaded at " today.getHours()+":"+today.getMinutes(), 
                         
    Color.whiteColor.redText.RELATIVETOBOTTOM Text.BOLD"Arial"20"S" );
            
    setCursorLabelName(today.getHours()+":"+today.getMinutes(), 0); 
        }
        if ( 
    getBarStateSymbol(secondSymbol+"") == BARSTATE_NEWBAR ) {
                
    volumeArray volume(-1,sym(secondSymbol));
                
    minuteArray minute(-1,sym(secondSymbol));
        }
        var 
    volumeArray;
        var 
    minuteArray;
        if ( 
    == ) {
            
    setBar(Bar.Value,-1,0,volumeArray);
            
    0;
        }
        else {
            
    setBar(Bar.Value,-1,0,volumeArray);
            
    0;
        }
        return 
    v;

    In the image enclosed below you can see that both scripts were loaded at 9:55 and have run in real time since. Notice that the cursor is on the bar time stamped 9:59 and that your script is returning a Volume of 1745 [which is the last known value at the time of the execution of the efs] while mine is returning 2141 which is the value shown for the same bar on the ES H8 chart included in the same screenshot for comparison.
    Notice also the difference in the bars that follow (all executed in real time) where the plot from my script (bottom pane) mirrors that of the ES chart while the plot of your script is different
    Hope this helps
    Alex



    Originally posted by clearpicks
    The implementation of sym() is EFS2 seems flawed. To demonstrate what I am talking about, you may apply the attached testing script and apply it on 1min chart of "6E H8".

    When the secondary symbol is set to "ES H8", the minute info of Bar -1 printed out for both "6E H8" and "ES H8" are the same for all historical bars. Then during the realtime updating period ( getCurrentBarIndex(0 == 0 ), the values of minute(-1) and m may be different. This happens when the new bar of "6E H8" is created eariler than that of "ES H8" ( the first tick of "6E h8" comes earlier than that of "ES h8"), otherwise the printed out values are the same.

    However in my opinion, EFS2 engine should be able to allign all old bars of different symbols using sym(). In the about example, no matter whether ES H8 bar 0 exists or not, when minuteArray.getValue(-1) is called, it should always return the correct value. Otherewise sym() only works to align historical bars, and when doing realtime update, it is no different from using getValue("Minute", -1, 0, "ES H8,1").

    The reason I am pointing out this is when the trading decision is made at the beginning of each new bar based on the inficators values at the end of previous bar, if the secondary symbol's tick comes later then the primary symbol, then the inficator value of the secondary symbol would actually be one bar older than it is intended, while in backtesting or after fact study, everything is aligned perfectly by sym() and such design flaw can not be noticed.

    Comment


    • #3
      Alex,

      Thank you for your reply.

      The reason I started this thread is to point out that at the beginning of a new bar of primary symbol, to make decision based on multiple other symbols, simply using sym() is not enough. In my own real working scripts, I compare the time stamp of the primary symbol bar and rawtimeArray(sym(secondSymbol)).getValue(xxx) so that to process these misalignment problem. However I think in the implementation of sym(), it would be a better solution to shift the series of the secondary symbol and add a null object at bar 0 position whenever a new bar of the primary symbol is created first or temparily withhold the bar 0 data of the secondary symbol if it is built before the new bar of the primary symbol is created. If so, secondSymbolSeries.getValue(-n) would be exactly corresponding to the position of the bar -n on the primary symbol chart.

      Do you know in your code whether a new volume series is totally rebuilt each time volume(-1,sym(secondSymbol)) is called at the beginning of each new bar and got released when exiting main()?

      - Clearpicks

      Comment


      • #4
        Wouldn't another approach to this "Bar closes when 1st tick in next candle arrives" issue be to add a true time-based bar close?

        A call to, say "CloseBarsByTime(true);", to be permitted in main() as well as preMain(), would then result in a main() call with getBarState() == CLOSEBAR "as soon as the clock strikes 12" so to speak.

        Advantages:
        * logic based on candles closing would fire at a known time
        * All nCandle == -1 for sym()s would synchronise (and be valid with current code).

        Disadvantages
        * The programmer would have to be aware that there is not yet a valid open (or any other) price for nCandle = 0.
        * Logic that fired based on the close of the last candle of the day (which currently doesn't fire until the first tick of the new day) might need reworking - but who has the same logic for the last/first candle as any other candle anyway? Maybe there could be a CLOSEBARLAST (close of last candle) and a CLOSEBARLASTNEWDAY (open of first candle) state added to cope more easily.

        Comment


        • #5
          I've posted about what I do to handle RT auto-trading code with EFS. I wait for new bars to form (first tick), then go back and do my analysis on -1, -2, -3, etc. as needed. I've been doing this for years.

          Now, when it comes to pulling data from other charts/intervals, I find it is easier to write files (with date/time stamps) for historical loading and pass the same file structure to a GLOBAL VALUE when running in RT. Then all I have to do is PARSE the GLOBAL VALUE to retrieve the current data from another chart.

          I can scan/study multiple indicators/analysis this way and it does not bogg down my auto-trading efs (much).

          The current set of files I'm working on like this is over 9000 lines of EFS code.

          Yes, that call to VOLUME would be reinstantiated (and the data re-filled) with each call to it.


          Originally posted by clearpicks
          Alex,

          Thank you for your reply.

          The reason I started this thread is to point out that at the beginning of a new bar of primary symbol, to make decision based on multiple other symbols, simply using sym() is not enough. In my own real working scripts, I compare the time stamp of the primary symbol bar and rawtimeArray(sym(secondSymbol)).getValue(xxx) so that to process these misalignment problem. However I think in the implementation of sym(), it would be a better solution to shift the series of the secondary symbol and add a null object at bar 0 position whenever a new bar of the primary symbol is created first or temparily withhold the bar 0 data of the secondary symbol if it is built before the new bar of the primary symbol is created. If so, secondSymbolSeries.getValue(-n) would be exactly corresponding to the position of the bar -n on the primary symbol chart.

          Do you know in your code whether a new volume series is totally rebuilt each time volume(-1,sym(secondSymbol)) is called at the beginning of each new bar and got released when exiting main()?
          My question regarding to this has not been answered yet in this thread .

          - Clearpicks
          Last edited by Doji3333; 02-28-2008, 10:17 AM.
          Brad Matheny
          eSignal Solution Provider since 2000

          Comment

          Working...
          X