I wish to create one of a number of stops for a short term system (for use with stocks) and am having difficulty with the code. The stop value in this case is anything below the low of the entry bar.

Most of the stops I have seen wait for signals to happen in “bar” and then exit at “bar + 1”. However, it seems reasonable to me to exit on stop at anything after the entry bar.

Specifically, I do not wish to exit until (bar + 1) because it is impossible to know when within the bar the price fell below a particular threshold and it is useless (unless I bought at market open - which is perhaps another topic worth looking at e.g. where the threshold is defined by the low of the previous bar).

However, with my current system, it seems reasonable to have a stop “at bar” at any bar after the entry bar.

I see two scenarios for bars after the entry bar.

The first is where the price opens below the low of the first bar (the threshold). In this case the exit should be “at market”.

The second is where a subsequent bar opens above the threshold and then falls below it. In this case I see the exit as being at the threshold value itself.

I am fairly new to coding and would appreciate some help.

Clarification for above.

By "Specifically, I do not wish to exit until (bar + 1)" I actually meant that I did not want to exit until "(entry bar +1)"

By design, the default Single-Position Strategy Code Template doesn't allow same bar exits. So what's the problem? Can we see the code you're having difficulty with?

What I have written here as a DataSeries for "lowstop" is not what I intended, but I have written it to give the code something to work on. What I would like as a stop is the low which happens at the time of the entry bar to be an initial stop, and to define other stops and targets separately. Please let me know if what I have written makes sense as I am quite new to coding. I am also not saying that this is necessarily a great stop method, just that I would like to be able to do this at least as an exercise.

CODE:
Please log in to see this code.

Please tell me if this is closer or if my understanding wasn't correct. I also got rid of the peeking condition:

CODE:
Please log in to see this code.

Thank you for the code. I can see from looking at individual stocks (and adding the target back) that your code does what I want it to.

However, I am struggling as to why you have set “Open[bar] > threshold” for the condition “SellAtTrailingStop(bar + 1, p, threshold, "#2")”. I have gone through all the entries for peeking in the forum but still find this hard to understand. I can see that what you have coded works. I just don’t understand why the open > threshold condition has to be a bar before the exit at threshold and not in the same bar as the exit (so long as it is after the entrybar).

For the sake of the exercise I have also looked at coding a stop as the lower of the (1) low of the entrybar and (2) low of the bar before the entrybar. I think that my code works, but it is rather messy. Any suggestions as to how to clean it up?

CODE:
Please log in to see this code.

QUOTE:
However, I am struggling as to why you have set “Open[bar] > threshold” for the condition “SellAtTrailingStop(bar + 1, p, threshold, "#2")”. I have gone through all the entries for peeking in the forum but still find this hard to understand. I can see that what you have coded works.

Open[bar] was there probably because I overlooked the requirement to look at Open[bar+1]. Sorry for that. Here's a fixed version, accessing the current trading session's opening price:

CODE:
Please log in to see this code.

The advantage is that now you can run this code shortly after the market open.

Thanks very much for that Eugene. I very much appreciate your input.

Please note that not all data providers support GetSessionOpen (the key to this trick). It depends entirely on data provider implementation and data feed's ability to deliver the opening price.

Of those I know for sure the following support the method: Fidelity (WLP), BBFree, Database, Finam, Google, Morningstar, QuoteMedia, Yahoo (as of v2014.02).

Yahoo! currently doesn't which is compensated by having a partial bar feature. Support for GetSessionOpen will appear in next build.

I know that I am asking a lot, but I am learning so much about coding by this exercise. As mentioned above I programmed the lower of the (1) low of the entry bar and (2) low of the bar before the entry bar but suspected there were better ways of writing this.

I tried to represent the parts of the two conditional lines after the "(mode2)" parts as bools also i.e. the underlined parts below.
"if((mode2) & (Low>>1)[bar] > Low[bar])" and "if((mode2) & (Low>>1)[bar] <= Low[bar])"
However, I found that I had to declare "bar" and that I was already in the bar loop where "bar" was being used differently - so I stuck to the full length code.

Any ideas about how I could I clean this up?

bar is the current bar being processed, not necessarily the entry bar.

CODE:
Please log in to see this code.

Thanks Cone. That helps a lot.
I am relatively new to this forum and have been scouting over entries for the last month or so. You make some great contributions. Keep it up!

As a followup to my reply #9 from 1/15/2014 8:49 AM:

Starting from v2014.02, our Yahoo! data provider supports the GetSessionOpen method of WealthScript.

Sorry for my ignorance for your role in Wealth-Lab, Cone!

For the sake of completeness, I have tidied up my code for the stop between the lower of the low of the entry bar and entry bar minus 1 using a modification of your suggestion.

Clearly, the stop does not work for this particular system.

CODE:
Please log in to see this code.

First, make sure that you select "1" for the slider parameter that controls mode1.

Exit #1 works fine. SellAtStop(bar+1, p, threshold1, "#1") will sell at market if the Open is below the threshold1, or it will sell at the stop price if the open is above threshold1 and then crosses below it.

Exit #2 uses a SellAtTrailingStop signal. The purpose of SellAtTrailingStop is to ensure always a "higher" stop as stop values are varied in the signal. You're not varying the stop price, it's constant. That's fine too, but since the trigger price is not changing from threshold1 (which is fixed for each trade) the way it's programmed, Exit #1 will always occur before the condition for Exit #2.

Is the purpose of exit #2 to raise the stop price to successively higher opening prices? If it is, that was very ambiguous in your initial requirements. I have a feeling that's the case, since you later said the low of "ebar" and "ebar-1" should be the initial stop, and then you left out the other controlling code that Eugene provided. Please explain in detail what exit #2 should do. Use an example.

Thanks Cone.

What I meant by the stop not working for this particular system is that it does not help the equity returns of the CumDown/CumUp system (not that the stop is not working at all). To me that the stop does not help the returns is understandable as, on average, the price is likely to go lower in a reversion system such as this before going up, and this kind of tight stop is perhaps best for something that is already expected to be going up from the start.

You are right about exit #2 which was redundant for the intentions I specified.

I did not understand the "controlling code" that Eugene provided but do now do (I think!) in that GetSessionOpen is for the last bar (when the system is used for live trading) so that the Open of the last bar can be used to signal an alert which would otherwise not happen. Is that correct?

I have re-written the code again….

CODE:
Please log in to see this code.

QUOTE:
I did not understand the "controlling code" that Eugene provided but do now do (I think!) in that GetSessionOpen is for the last bar (when the system is used for live trading) so that the Open of the last bar can be used to signal an alert which would otherwise not happen. Is that correct?

Yes, the system would either take Open[bar+1] in historic backtesting and on the last bar it would switch to today's Open price (which doesn't exist in the OHLC data yet at this point).