Switching from "getCurrentBarIndex()" to "getBarState()"

[Doji3333]

Correction...

Correction to the statement below...

"Lets say the stochastics were hovering at about the same value. Up ticks may cause if to report a bullish cross, then down ticks could cause it to negate this cross. With my code, the cross action would be recorded and action could be taken based on this condition."

should read...

Lets say the stochastics were hovering at about the same value. Up ticks may cause if to report a bullish cross, then down ticks could cause it to negate this cross. With my code, the cross action would be recorded and action could be taken based on this condition. if the stochastics (throught tick-by-tick trading) crossed up 5+ times within a bar, then without our timestamp, the system MAY try to enter 5+ times...

The solution to this is really with the StrategyisInTrade variable and the timestamp. In the code examples I have provided, the StrategyisInTrade variable would also prevent the system from trying to enter multiple entry signals. But, if the entry code did not include the test for StrategyisInTrade, the time stamp would provide an alternate solution.

The time stamp solution also prevents a system from entering a trade, getting stopped out (or reaching a profit target), then re-entering on the same bar. This is critical because you may not want your system to be able to do this. The strategyisInTrade variable will not assist you with this type of problem - only time stamps will assist in resolving this issue (as far as I know).

More later..

Brad (a coding fool).

[dloomis]

"I am beginning to see" said the blind man

Now I know why I didnt see the advantage of your method at first. You describe entering mid bar - I only enter after the bar is finished - so the multiple entry problem is not an issue cuz I only have one stop limit order to open a position issued per bar, max.

In fact, that is the first section of my code - check to see if a new bar just started. I trade 5 min bars so ....

if(curtime==curtime-curtime%5)

is a new bar, I set a ItsNew flag.

(I should be able to use getBarStatus==NEWBAR for this but I ain't breaking what ain't broke, been there, done that)

later on I check for fills.

I check for a fill every x seconds, currently set at 5. I am trying to save cpu cycles - doesnt seem to be necessary, btw.

If I get filled, I enter my stops and set my YourFilled flag on the very next line.

This flag prevents another fill till one of my stops is hit (on an OCA) and a new bar is drawn.

All of this confused the heck out of me for quite some time, but it seems I finally understand what the program is doing - and why.

I use DO Host and not the esignal commands, mostly for the nice paper trading system and the OCA feature. And DB is a great resource.

[dloomis]

PS

my if(curtime==curtime-curtime%5) does have a draw back.

if the price doesnt change (up or down) during the 1st minute of a new 5 minute bar, I miss the fact that a new bar is drawn, because the efs program will not run unless the price changes.

You wouldnt think so, but the price doesn't change during that first minute sometimes on the ES and NQ - statisically remote, but it happens. Turn on a 1 minute chart and look for them, I almost had on yesterday - second 58 ticked up and the code caught it.

this is enough reason for me to try getBarState. This will trigger NEWBAR even if the bar doesnt start to draw till the 4th minute of the bar.

I wish there was a way to tell what time it was, independent of the ticks.

Also, the time stamp I see on the Formula Output windo precedes the time stamp on T&S by about 3-4 seconds. I am not sure where this disconect lies, but it seems very strange to me.

[Doji3333]

actual time functions...

dloomis,

there is a way of accessing the system time of your computer within EFS.

you do it like this...

//  Define System Variables...
  var vTime = new Date();
  var vHour;
  var vMin;
  var vSec;
  var vDay;
  var vMonth;

//---------------------------------------------------
//  Get Time Variables 
  vTime = getValue("Time", 0);
  vHour = vTime.getHours();
  vMin = vTime.getMinutes();
  vSec = vTime.getSeconds();
  vDay = vTime.getDate();
  vMonth = vTime.getMonth()+1; 

this will return the system time for you to use..

Brad

[dloomis]

Unless I am mistaken, this code will only execute when there is a change in the price either up or down.

I have found it difficult to tell what time it is, unless a price change occurs.

[dloomis]

this efs file

http://share.esignal.com/download.jsp?groupid=40&folder=&file=time1.efs

shows what I mean.

[Billmini]

I have a question for Brad along this thread . I am looking at using similar strategies to yours but for Tick charts . I want to be able to take a trade at the end of the bar and then monitor for fills and stop placement once the initital order is placed . say every 10 ticks for example .

//Use the following to determine where I am in the bar
var TradeCount = 0;

function main() {
if (getCurrentBarIndex() != 0) {return;}
if (getBarState() == BARSTATE_NEWBAR) {TradeCount = 0;}
TradeCount += 1;

if Tradecount == 120 // For a 120T chart
- call indicator code and check for new trade

if Tradecount == 10 (or multiple of)
- check for fill and place stops using a
switch statement to step through order sequence (as DB does)

I am using DO so have coded a Switch sequence for this based on ideas from DB .

My questions are :
Is there a way to determine the number of Ticks in a chart other than using the above counter and just capturing the highest value is gets to and storing that ... ?

Is there any issue with only calling the indicators used once per bar ?? Reason I ask is I just ran a SAR indicator which will be part of my strategy and when it updates every tick it can jump around ALLOT and triggered trades that it should not have during the bar and also seemed to get confused about it's state from time to time . What I saw was a the SAR plotting on the bottom indicating a long should be considered when in fact the bar in question was yet another down bar . Very strange and makes think really hard about when I should called this .... I set the compute on close flag in EFS preferences then the SAR settled right down and it's plots made perfect sense . I however want to monitor trade actions during the bar as indicated above .

Thanks very much .

[dloomis]

if Tradecount == 120 // For a 120T chart

has a problem.

Every time the efs runs, Tradecount will increment by 1, but this will not capture all of the trades that go off at a price equal to the previous trade, only the trades that go off at a price above or below the previous trade.

EFS studies only run if the price changes up or dowm.

Watch what debugPrintln(Tradecount); shows after hours and you will see what I mean much clearer than during the day.

[Doji3333]

Tick charts...

Billmini,

You code looks ok to me. I believe you are on the right track...

For DO, I use a function declared at the top of my EFS to handle all the trades... like this...

function TradeMarket(TradeType) 
{
  //test for DO connection and IB connection

  if (TradeType == 1) {
  //  do my BUY stuff and loop till filled

  }
  if (TradeType == 2) {
  //  do my SELL stuff and loop till filled

  }
} 

This way, all the looping and trade execution is located in one place. Also, this way developers can standardize on a structure for their DO trade execution. The other benefit is that the code should loop within the defined "if" statement until the order is filled.

Indicators.....

Yup, this is a problem with most indicators (excluding Averages). Most indicators use a "summation" or a "normalized summation" of past values. Thus, when a new bar forms on a RT chart, an older value has been dropped from the indicator and the new bar has been included. This normally skewes the indicator a bit until the new bar establishes a normal range.

Using your Tick chart, you might find that after tick #80 (or so) the SAR should begin to respond properly. So tick #80+ (maybe 90) you should be able to trade effectively.

Ah, the joys of developing RT code and working out all of the problems...

Best regards,

Brad




}

[Doji3333]

dloomis

If you are correct, which I believe you are, then we need to direct this question to Jason or Matt - as I don't know the answer.

I am still considered a "junior developer" compared to these guys.

Hello Jason or Matt, can you answer this question for us???

Brad

[underdog430]

Revisiting my first post on this thread, I just wanted to clarify. If switching from SetComputeOnClose(true) and getCurrentBarIndex(-1) to an approach using BarState, do I need to change the bar references (since I'm no longer checking at the end of bar but now at the beginning of a bar)?

If I'm working on the current bar this isn't a problem but if I'm using a newbar then I need to offset (e.g., close(-1)), right?

Just trying to make sure. I think I'm making progress. My EOD close function went crazy (sent out an order with every cycle) because I didn't have the code right (but I had taken DO offline anyway since my SAR function didn't seem to be working).

thanks.