Are the generic broker functions available using Bar Replay

[demarcog]

I have a strategy I'm testing that when run using tick replay generates trade signals that get "executed" via the eSignal Paper Broker.

When I run the same strategy using Bar Replay the orders that get sent using the generic broker function are stacked in the Open Orders eSignal Paper Trading and never get executed.

I'm also not seeing the drawtext objects that are visable using tick replay?

Are these facilities avaiable in Bar Replay as until this evening I've never used this component before?

[eSignal_JasonK]

Hello demarcog,

The Generic Broker functions are real time functions. They should be prevented from executing on historical bars.

For bar replay mode, logically I would think that should work. Post a code example that produces this scenario and I'll look into it further.

drawText objects should work fine in tick replay. Post your code and I'll take a look. Also, let me know what intervals and symbols your running these on.

[demarcog]

Jason,

I appreciate very much your offer to look at the code. I was running it on 5 minute data on GOOG and GBP A0-FX.

Any and all help is greatly appreciated, I have multiple problems with the code.

You may want to use a simple returen (see code) as depending on whether stop and profittartgets are coded in I haven't been able to get the graphics correct.

Be warned I'm a trader not a programmer and struggling through EFS ....

thanks again
glen

[eSignal_JasonK]

Hello demarcog,

I've tested your code as is in Bar Replay mode on GOOG 5-min chart and the trades that were generated were properly executed. Nothing stacked up in the Open orders tab on my end. One thing you might want to try is reloading the formula after you've selected the starting bar for the replay and before you begin the replay.

Regarding your text and graphic objects, they are coded properly and I do see them being drawn on the chart with the initial entry trade.



The others simply are not being executed because the conditional statements that encapsulate them are not evaluating to true. To begin working out the kinks in the trading logic you need to debug each condition to find out why it is not evaluating to true. To do this, add a debugPrintln() statement in front (or above) the condition and print out the current bar index and one or more of the variables used by the condition. Then compare this debug information to the corresponding bar in reference to the price bar data and the indicator values for that bar. This will help point out what may be restricting the condition from evaluating to true. One other very important item for the development process is to plot the indicators on the chart if the formula contains conditions based on indicators. This is critical to the development process to have a visual confirmation that your conditions are coded properly. Without visual references you are basically developing a strategy in the dark. Since your current conditions are based on oscillators, make your formula a non-price study and plot those indicators. Another helpful hint for this formula is that you should not plot the values for nDisplayProfit, nDisplayStop, nTradeEntryPrice, nTradePnl as these values are not to the same scale as the oscillator studies. If you want to just see their values in the cursor window and not plot them on the chart, set them to string values by adding .toFixed(2) to the variables in the return statement. Strings won't plot on the chart, but they will still be available in the cursor window.

return new Array( nDisplayProfit.toFixed(2), nDisplayStop.toFixed(2), nTradeEntryPrice.toFixed(2), nTradePnl.toFixed(2));

Once you have the trading logic worked out to your expectations you could then convert this back to a price study. Then you could plot your stop and target values as those scale to the price data. Any other indicator or value such as nTradePnl should be converted to a string value if they are to remain in the return statement.

Another tip that will help you in the development process is to properly align your code so that you can easily see what the logical order of process is. For example, code that is aligned like below is hard to read, which only complicates things for you. This example is pretty ugly, but it is one of the main problems I see with new programmers.

// VARS
            var bInit = false;
var x1 = null;
        var x2 = null;
        var x3 = null;
    var x4 = null;

            function main() {
        if (bInit == false) {
        x1 = sma(5);
        x2 = sma(10);
        x3 = sma(15);
bInit = true;
}
                // some comments
    if (/* some condition */) {
// some comments
if (/* some nested condition */) {
setBarBgColor(Color.red);
        } else {
                        setBarBgColor(Color.green);
                    }
        } else {
return;
}        
return;
} 

This is the same code properly aligned, which you can see is much easier to read and follow the order of process when reading through code line by line.

// VARS
var bInit = false;
var x1 = null;
var x2 = null;
var x3 = null;
var x4 = null;

function main() {
    if (bInit == false) {
        x1 = sma(5);
        x2 = sma(10);
        x3 = sma(15);
        bInit = true;
    }
    // some comments
    if (/* some condition */) {
        // some comments
        if (/* some nested condition */) {
            setBarBgColor(Color.red);
        } else {
            setBarBgColor(Color.green);
        }
    } else {
        return;
    }        
    return;
} 

It will make your programming life much less stressful if you help yourself out by being more organized with your code alignment. Programming is an extremely detail-oriented endeavor. Properly aligned code will help you tremendously, especially as the amount of code in any particular formula grows.

[demarcog]

Jason,

Can't thank you enough or tell you how amazingly helpful I found all the suggestions you made.

The alignment of code suggestion in particuliar is something that I was somewhat familiar but it's always, "when I get more time I'll do it right". I can't believe how profoundly important it really is, and appreciate very much you taking the time to illustrate that.


I spent most of the day rewriting this and wanted to incorporate the newtrade/signal flag logic to the btDonchian*.efs format and not sure if they are compatable?

I'm also unfamiliar with the syntax of javascript compound IF ELSE, IF ELSE IF, etc and couldn't find very much in the core guide.
Sometimes in the btDonchian*.efs programs you are using a opening bracket after an ELSE statement and sometimes you don't?

Are they any tricks/techniques to determine how to make sure all the conditionals are at least syntatically correct?

Also are there any guidelines for levels of nesting?

I was trying to make it easier by using the EFS editors vertical lines, starting with the main function, having it line up with the last closing bracket, and the next if (getCurrentBarState()) etc, but I think it caused an uncomfortable level of nesting?

I reposted although I haven't gone beyond the syntax check and welcome any comments.

As always I greatly appreciate all the tremendous help you have provided me and cannot thank you enough.

Glen

[eSignal_JasonK]

Hello demarcog,

Originally posted by demarcog
Jason,

Can't thank you enough or tell you how amazingly helpful I found all the suggestions you made.

The alignment of code suggestion in particuliar is something that I was somewhat familiar but it's always, "when I get more time I'll do it right". I can't believe how profoundly important it really is, and appreciate very much you taking the time to illustrate that.

You're most welcome as always. If you need more examples to study how code should be aligned, take a look at any of the formulas in our EFS Library. My advice would be to pay attention to alignment as you go rather than something extra to perform after the fact. That's just my style.

I spent most of the day rewriting this and wanted to incorporate the newtrade/signal flag logic to the btDonchian*.efs format and not sure if they are compatable?

The two sets of logic are slightly different, but accomplish basically the same thing. I would suggest picking one or the other. Trying to mix the two together is unnecessary.

I'm also unfamiliar with the syntax of javascript compound IF ELSE, IF ELSE IF, etc and couldn't find very much in the core guide.
Sometimes in the btDonchian*.efs programs you are using a opening bracket after an ELSE statement and sometimes you don't?

See Ch 5 Statements from the Core JavaScript 1.5 Guide.

You can think of the "else if" as one statement. In those btDonchian formula examples you'll see the open brace at the end of the "else if" condition, or after the close paranth. It's associated close brace will be at the end of the code that you want to execute if the condition is true.

if ( /*condition*/ ) {
    // code executes if above condition is true, otherwise goes to the else.
} else if ( /*condition*/ ) {
    // code executes if above condition is true, otherwise goes to else
} else {
    // code executes if both of the above conditions are false
} 

The open and close braces are used to encapsulate a block of code to be executed when a correspond conditional statement evaluates to true.

Inside of an else statement or else if statement you can have additional if() statements. There's no limit to the number of nested conditions you need to create.

Are they any tricks/techniques to determine how to make sure all the conditionals are at least syntatically correct?

Yes, click on the Syntax Checker in the EFS Editor. If there are any syntax errors, you can see the error info in the formula output window.

Also are there any guidelines for levels of nesting?

There are no specific guidelines, other than the fact that is is allowed to nest conditional statements inside other conditional statements. The specific combination of nested conditions would be specific to the code logic the programmer needs create.

I was trying to make it easier by using the EFS editors vertical lines, starting with the main function, having it line up with the last closing bracket, and the next if (getCurrentBarState()) etc, but I think it caused an uncomfortable level of nesting?

I reposted although I haven't gone beyond the syntax check and welcome any comments.

As always I greatly appreciate all the tremendous help you have provided me and cannot thank you enough.

Glen

Based on your updated code, it appears you have a good handle on code alignment. As far as your level of comfort with your nested conditions, there isn't anything I can do to help you with that. It's the nature of a programming environment. In order to accomplish a complex set of logic, it will most likely required some complex set of nested conditions.

Try not to confuse syntax with logic. The syntax checker can only tell you if your missing a close brace or have an invalid number of parameters for a specific function and that sort of thing. The syntax checker has no way of knowing what logic a programmer is trying to create or what task the programmer is trying to accomplish. Logic refers to what the entire set of code performs as a whole. A formula can be thought of as a collection of smaller pieces of logic that fit together to perform a logical process. The development process refers to the testing, debugging, tweaking of these smaller pieces of code logic to get a the complete set of logic to perform what the programmer is expecting it to.