Announcement

Collapse
No announcement yet.

entry on close, exit regardless of time?

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

  • entry on close, exit regardless of time?

    hey guys, im writing a script that needs to be able to do something im not entirely sure how to write easily (i try to keep my code succinct, i tend to shy away from writing anything too verbose since i get lost and have to start over every time i try)

    anyways, i have esignal set to calculate my efs only on the close of a candle, it makes coding much simpler that way, but heres the problem, ive just come up with something that looks promising, but what it needs to do is open a trade only on the close of a candle, but exit and send an audio alert regardless of time.. i figure the easiest way to do it is by somehow limiting the entry so it can only cycle every so often.. but i cant seem to figure out a nice way to do that.. could anyone help me out with this, or give me a tip or two?

    thanks in advance

  • #2
    kalzenith,

    I do something similar to this. What I do is protect my entry code with checks for BARSTATE == NEWBAR.

    nBarState = getBarState();
    .
    .
    .
    if (getBarState() == BARSTATE_NEWBAR) {

    <Entry code, and other code I only want to run at the start of a new bar>

    } else {

    <Exit code and code I want to run on every tick>

    }

    As the above implies, the code block inside the NEWBAR conditional will execute on the first tick of a NEWBAR. For most even semi-actively traded securities/contracts this will be virtually the same thing as running at the last tick prior to bar close.

    Some warnings on this...

    1) Don't forget that in realtime (RT) your tick by tick checks for close() will be true at some point in time for the high and low of the historcal bar. This means to get the same historical results as you will see in RT, you have to code your exists correctly. This is doable with a little thought.

    2) Also don't forget that if you are calculating your indicators based on the results of the current bar, that in RT you indicator will move and not stay the same as the end result of a historical bar. For example, an MA will move up in RT as the bar reaches its high for that bar, down as it reaches the low for that bar, and finially rest at wherever the close for that bar is. There is no easy way to calculate what this swing was for your historical bars (it's possible, just not easy) so your results in RT will differ again from your historical results. One way of fixing this is to not use the current close in your calculations, but only the close of one bar back.

    Not sure if all of that is clear...if it isn't please feel free to ask questions.
    Garth

    Comment


    • #3
      thanks, i'll remember that trick for next time.. as it turns out, there were occasions that the efs would exit trades on the same bar it entered them on (considering the fact that it enters on a close, thats not possible) when i fixed the bug, the whole theory had to go down the drain, but thanks for the help, i never thought of that

      Comment


      • #4
        kalzenith,

        Your most welcome.

        One thing to think about...if you are saying it exits on the same bar you enter on when using the NEWBAR method...with NEWBAR you are actually entering on the first tick on the new bar, rather than the last tick of the bar when the condition was true. So it is very possible to enter and exit on the same bar when you enter NEWBAR but exit at any time.
        Garth

        Comment


        • #5
          no no, it enters on a close and exits any time, not the other way around. somehow though it was still picking a price somewhere on the entry bar as its exit price even though that would defy a couple of laws of physics to do

          for example, if the bar closed and it used that as its entry price, it would somehow use the high of that bar as its exit price even though the next bar went nowhere near that price, dont ask me how it managed that one.. but once i used the getBarState() method you suggested, it corrected that problem and the strategy nolonger looked so appealing
          Last edited by kalzenith; 07-05-2008, 04:16 PM.

          Comment


          • #6
            kalzenith,

            If you post up the new code, I'll take a look at it.
            Garth

            Comment


            • #7
              ive already scrapped the file, it was fundamentally flawed, hooray for logic errors.. but thatnks for the help anyway, the getBarState() function should really help in the future

              Comment

              Working...
              X