Who wants a strategy? Lots and for free) - page 63

New comment
 

Yes the mail is correct.

I sent you a Private Message a minute ago.

 

Oh, I'd forgotten all about the private line :))))))

It's already piled up there :). Guys - sorry if I didn't answer in time, I just usually turn off Personal Messages on forums and didn't even pay attention here out of habit :)...


Miroslav - then now I will prepare a message (answer) and send by mail ...

 

**Remember, the Bar Opening and Bar Closing - Point of the Position problem is not limited to, the values of common indicators may well be used there. And so a position can be opened "in the middle" of a bar (easy!). (so to speak, about calculation of indicator values ONLY at intersection of bars... as I said - this condition is "not always" feasible ;))**


If understand correctly, you think that we have to recalculate an Indicator on every tick if the Entry point is in the middle of the bar (Let say at a MA). I'll afford to not agree with you.


For a reliable back test (using MT, FSB or other tester), all the indicators including Entry / Exit points have to be fixed. That doesn't limit an EA to use market entry during the bar.

Examples:


1. Entry at Moving Average (21, close):

In this case we cannot use the current MA since it is moving up / down until bar closing price is fixed. So we have to use MA from the previous bar. Doing this it's not necessary to recalculate it on every tick.


2 Entry at Moving Average (21, open):

Here we can use the current MA. It is fixed because the MA base price - Bar Opening is already fixed. We also don't need to recalculate it on every tick.


--------

Edit:

Of course this is my personal opinion.

I don't intend to force you backtesting in that way.

Regards!


Edit2:

In case I'm missing something, please show me an example of a strategy prepared with FSB when you have to recalculate an indicator on every tick.

 

Mmm, Miroslav, I get the idea (a long time ago, moreover)!

I was just confused by the constructions in indicator code, which I gave above:

                    case "The position opens above the MA value":
                        component[0]. PosPriceDependence = PositionPriceDependence. BuyHigherSellLower;
                        component[0]. UsePreviousBar     = iPrvs;
                        component[1]. DataType           = IndComponentType. Other;
                        component[1]. ShowInDynInfo      = false;
                        component[2]. DataType           = IndComponentType. Other;
                        component[2]. ShowInDynInfo      = false;
                        break;

namely: component[0].PosPriceDependence = PositionPriceDependence.BuyHigherSellLower;

That's just not the case, is it? It's important to understand that I'm not talking about the calculation of the indicator, as such. The value of which, yes, is stationary within a bar. But about the fact that in this case (which I cited above) we have to compare the last price value with it? In order to make a decision to open a position. At FSB, this is done by internal procedures (if I understand it correctly). But because they "are not known to us" (and, actually, what for?) - I suggested to recalculate the indicator on every tick, in such cases, to receive an unambiguous YES/NO on the logical condition. In other words, let the indicator itself make this conclusion, not the code that is external to it. I meant it!

I mean, um, once again - I agree with the thesis that the indicator should be calculated once on "crossing" bars. But in cases where the indicator gives signals about position opening, in application to the work of future EA(s) in MT - we should rely only on these values (YES/NO), and not on comparing current prices with indicator prices (which are static). Let the indicator itself compare this for us. And we will only take into account its YES/NO. That's it... :)


Or am I missing something somewhere? :D? ("got a little bit of a mammy...")

 

Hence the implication that I need to make one more revision of such calculations (I'm thinking now) to compare Close[iBar] with current or previous indicator's value (which of them is static) correctly (iPrvs should be considered). But in the idea I think I'm not wrong...?!



(what are we even discussing :))?! Indicators will still account for work with IndicatorCounted() ANYWHERE!!! I just won't do it any other way :). They can be used not only by EA writers, but also by users who will need visual part (and real-time values). The original code doesn't change a bit! Usually, you just add a bit at the beginning, which initializes the "original" values of the self referenced variables. No more than that... Sometimes this is given "little blood". Sometimes not so much (as in Hourly High Low example). But in any case, minimal bodily effort (yet?) :))


Or is it a global aspect? Then there's nothing to discuss - iPrvs is awesome!:) Full stop! But no one argues with it :)!


(I sent an email... I'll try to answer it here in person)

  
case "The position opens above the MA value":
 component[0].PosPriceDependence = PositionPriceDependence.BuyHigherSellLower;


 This logic cannot be managed from the indicator itself since the signals depend on the Entry Point indicator.

 This logic doesn't give buy / sell (1 , 0) signals like the others. 

 FSB proceeds as follows:

 1. It initially ignores this indicator when taking decision for trading;
 2. If all the other logic rules are satisfied and FSB knows the entry point, it checks this indicator to allow or forbid the entry just before the actual execution.

 This is included in the backtester.

 There are three options for application in an EA:

 1. To calculate the entry points first (in an array). After that to send this array to the indicator to calculate the Buy / Sell signals.

 2. to have a base method EntryPrice(int iBar) that returns the position's opening price. 
 The position opens above the MA value:
 for(int iBar ... )
{
 SignalLong[iBar] = EntryPrice(iBar) > MA[iBar] ? 1 : 0;
 SignalShort[iBar] = EntryPrice(iBar) < MA[iBar] ? 1 : 0;
}

 3. Calling this indicator before the actual entry:
 double EntryPrice = ....;
 If(EntryPrice > fsb_MA(...))
 OrderSend(...);


----

 There are several indicators that don't set 1:0 signals:
- All indicators with the logic "Position opens above / below ..."
- "Time" indicators: Entry Time, Entry Hour, Day of Week;
- Account Percent Stop
- ATR Stop
- Stop Limit
- Stop Loss
- Take Profit
- Trailing Stop
- Trailing Stop Limit
- Lot Limiter

 These "Indicators" give Entry / Exit permission at the moment of trading;










 

Miroslav - 'got it'! Not in the sense of finally understanding something :) (the idea of manipulating FSB with indicator logic,

I have understood it a long time ago (I don't take into account Stop Limit and other stuff, I haven't looked them yet).

I'm finally remembering something, let's just say :)


WE're just talking in the same context about different applications (meaning both the applications themselves (FSB and MT) and "in application to").

The key point is the calculation of FSBindicators once, before the back-testing procedure itself.

FSB simply cannot calculate unambiguously 1/0 for such conditions ("Position opens above / below ...") before the test itself!

Therefore, it uses exactly the right logic:

1. it initially ignores this indicator when taking decision for trading;
 2. If all the other logic rules are satisfied and FSB knows the entry point, it checks this indicator to allow or forbid the entry just before the actual execution.
But for our (RealTime) case THIS IS NOT OBLIGATORY. Or rather - calculating indicators "constantly and on the fly" - we will have at any given moment
at any particular moment we will have a definite answer 1/0 for this logical condition.
We still "cannot" will not be able to open a position at the last available price (Close[0]). So, why not compare the indicator to it?
And why not output a logical 1/0 as in other cases (sorry, formatting is "off", I do not want to look into HTML (there is no point in "freaking out"):
 case MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar];
}
break;

// Which is apparently more correct to rewrite with iPrvs in mind (it just "dawned on me" today how to get around this problem in general)

case MA_POS_OPENS_ABOVE:
For (iBar = iFirstBar; iBar >= 0; iBar--) {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
break;

// Considering that values on all the bars except [0] (real-time) will be "not quite right" (or rather, fixed for Close[iBar]), we can change the code like this

case MA_POS_OPENS_ABOVE:
for (iBar = iFirstBar + 1; iBar >= 0; iBar--) {
if (iBar > 0) {
 LPIndBuffer[iBar] = 0.0;
 SPIndBuffer[iBar] = 0.0;
} else {
 LPIndBuffer[iBar] = Close[iBar] > adMA[iBar + iPrvs];
 SPIndBuffer[iBar] = Close[iBar] < adMA[iBar + iPrvs];
}
}
break;

// T.I.e. for all bars, except [0], the indicator will show that this condition is not fulfilled (was not fulfilled) - a matter of aesthetics, so to speak... nothing more.

 

(off: I'm trying to insert the code again, as a separate comment - "the stone flower doesn't come out" :), then an empty comment, then it just goes to the first page... Maybe there are some elements in the text - "not digestible"... in general - so read (as above) :))

 

Gentlemen, Miroslav updated FSB to version 2.8.3.6 Beta yesterday:

http://forexsb.com/forum/post/2446/#p2446


The signal logic has been unified. The changes affected the vast majority of indicators. The code of the indicators calculation was not changed!

The logic signals became a little less susceptible to "noise". In the config file we have added two parameters:

  <SIGMA_MODE_MAIN_CHART> 1</SIGMA_MODE_MAIN_CHART>
  <SIGMA_MODE_SEPARATED_CHART> 5</SIGMA_MODE_SEPARATED_CHART>

Parameters set the "threshold" of signals triggering from the price change level (for indicators on the window with the chart and for indicators with their own windows).

Correspondence of MODE values are given here:

http://forexsb.com/library/source/Sigma.html


We believe that the "default" values are EXACTLY adequate (in most cases). But... feel free to experiment :).


I purposely waited for this release, so as not to do double work. I am putting my own works too. I have 20 indicators at the moment (I would not consider 2 of them as "useful" (Bar Closing / Bar Opening) - they will be useful in the future ;)):

-FSB- Accelerator Oscillator.ex4
-FSB- Accumulation Distribution.ex4
-FSB- ADX.ex4
-FSB- Bar Closing.ex4
-FSB- Bar Opening.ex4
-FSB- Bar Range.ex4
-FSB- Bollinger Bands.ex4
-FSB- Donchian Channel.ex4
-FSB- Envelopes.ex4
-FSB- Force Index.ex4
-FSB- Heiken Ashi.ex4
-FSB- Hourly High Low.ex4
-FSB- Ichimoku Kinko Hyo.ex4
-FSB- Keltner Channel.ex4
-FSB- Moving Average.ex4
-FSB- Price Oscillator.ex4
-FSB- RSI MA Oscillator.ex4
-FSB- RSI.ex4
-FSB- Starc Bands.ex4
-FSB- Steady Bands.ex4

Calculation algorithms and signal logic are fully FSB compliant (well... should :D)...

INCLUDING INDICATOR VALUES!!! (FSB (application) = -FSB- (conversion) = MT (internal) ) (up to any sign).

The exception is "-FSB- Accumulation Distribution.ex4" - Miroslav has a tricky code there, haven't got around to it yet (doesn't match MT exactly, haven't checked with FSB).


I'm continuing in alphabetical order (well almost). If anyone needs something higher priority, write... (person with Hourly High Low disappeared somewhere, I haven't understood - did it help or not :D?!)


At the same time we begin to develop EA, which will be able to operate with these versions of indicators. At the end there should be a kind of a sheaf:

FSB -> Exported strategy file -> EA, based on converted indicators and internal trading logic, compatible with FSB...


Good luck! And happy holidays to all!!!

I'll show up closer to the start of the work week... stay tuned...

Files:
fsb2mql_20090430.rar  270 kb
 
Stellarator >> :

Gentlemen, Miroslav updated FSB to version 2.8.3.6 Beta yesterday:

http://forexsb.com/forum/post/2446/#p2446


I'm downloading something and the archive is broken... :
1...5657585960616263646566
New comment
Reason: