More strategies? No problem! - page 9

 
voltair >> :

I suggest that those wishing to discuss generators and their strategies "pass" here.

Apologies to the SX author for not using the branch for its intended purpose.

And further success!

Thank you and thank you very much.

 
TheXpert >> :

By Monday I will try to make a version in which I will change the order of optimisation, so that there is no initial downtime.

>> And here it is.

 
TheXpert >> :

There she is.

Sorry, corrected error with hang-up when opening an order. Added balance check for minimum opening. Please everyone who downloaded previous version, update to new version.

Files:
home_1.zip  7 kb
 
TheXpert писал(а) >>

...I'd like to hear some constructive criticism and suggestions (of any kind)...

extern string Condition_9_       = "Close(1) < BBands(BBandsPeriod, BBandsDeviation, 1)";

bool BuyCondition9()
{
   return ( iBands( symbol, 0, BBandsPeriod, BBandsDeviation, 0, PRICE_CLOSE, MODE_LOWER, 1) > Open[0]);
}

bool SellCondition9()
{
   return ( iBands( symbol, 0, BBandsPeriod, BBandsDeviation, 0, PRICE_CLOSE, MODE_UPPER, 1) < Open[0]);
}

I'd like some kind of certainty. :)

 
SergNF >> :

Like, I want certainty. :)

And where do you suggest we change it? I'm in favour of changing the comment.

__________________________

Started up my 4 o'clock.

Progress looks like this:




My computer isn't the most powerful.

So the clock on a normal computer can realistically run even in 24 hours. And if you split it up...


This dwindling of remaining time is due to the fact that the highest concentration of significant strategies is now at the beginning, before that it was in the middle.

 
TheXpert писал(а) >>

I am in favour of changing the comment.

I agree.

The main thing is that everyone's "original" should have a "reference". Otherwise how will you swap sets :).

So the clock on a normal computer can realistically even in a day. And if you parse it...

And if the "opening prices", then ... I've already "fitted" 10 times, and all variants fail at OOS.

(The EURUSD clock fitting is all of 2008. 3 iterations - Condition_X -> Secondary_ -> Condition_X)

Results of models "All ticks" and "by opening prices" coincide

 
SergNF >> :

I agree.

The main thing is that everyone should have a 'reference' set. Otherwise, how will you swap sets :)

Apart from sets, you can swap files and just condition strings. A fix will be in the next version.

 
SergNF >> :

And if "opening prices", then ... I've already "fitted" 10 times and all variants are draining on OOS.

Of course at opening prices ohh. Why torment the computer for nothing?

(EURUSD watchframes fitting - all of 2008. 3 iterations - Condition_X -> Secondary_ -> Condition_X)

I've been testing since '99.

 
TheXpert писал(а) >>

...I'd like to hear some constructive criticism and suggestions (of any kind)...

- IMHO. It is better to take out the block "// Externs" and the block "// here" into a separate "inludnik", so that no one even has a hand to edit the base file.

- And in "coding", IMHO, it is better to move away from numbers "BuyCondition9()" to some "mnemonic", so that no one simultaneously adds completely different "BuyCondition786()". Otherwise the "repository" will have to be kept by the author. Like capitalizing functions on the left and functions on the right - "BB_O" (for Condition9) or adding "author's nickname" to the prefix. But then you'll have to "make up" functions "bool BuyCondition(int index)" and "bool SellCondition(int index)".

In some of my projects, in external parameters (and ini-files I duplicate them) I have long been writing some menonics something like "+EURUSD" - "buy EURUSD". It will be a little step to the interpreter. :)

'

ZS.

extern string ConditionName1 = "BB_O";
extern int ConditionValue1 = 0;

But it is difficult to optimize it. :)

'

ZY.

If only we could find compromise between "optimized extern" (int) and impossibility for end-user to use reserved numbers/functions... This product would surpass all others in flexibility and versatility. Although "for my beloved" it would be an unnecessary complication. :)

A fix will be in next version.

And Comment's orders in extern string!!!!!

'

 
SergNF >> :

- IMHO. It is better to put the block "// Externs" and the block "// here" into a separate "inluder", so that no one even has a hand to edit the base file.

In fact, I was going to do that.

On version 1.0 planned splitting into modules, cleaning, codogeneration (probably), and some mana to write.

To make it look more or less like a product.

- And in "coding", IMHO, it's better to get away from "BuyCondition9()" numbers to some "mnemonic" so that no one adds completely different "BuyCondition786()" at the same time. Otherwise the "repository" will have to be kept by the author. Like capitalizing functions on the left and functions on the right - "BB_O" (for Condition9) or adding "author's nickname" to the prefix. But in this case you'll have to make up "bool BuyCondition(int index)" and "bool SellCondition(int index)" functions.

That's where I'm against. Although adding conditions is facilitated, it's not welcomed. Let's just say that once you change the code, you can't count on support.

If you need to add a condition, tell me, I'll add it.

If only to find compromise between "optimized extern" (int) and impossibility for end-user to use reserved numbers/functions... Flexibility and versatility of this product would surpass all others. Although "for my beloved" it would be an unnecessary complication. :)

Why bother looking for it? It's called Foolproofing, in plain English. Normally, it's data integrity protection at any step of execution.

This is only partially in place for now, and adding it in version 1.0 is not yet foreseen.

If you can't use terminal, you can always check the integrity by hand.

And Comment's orders in extern string!!!!!'

I don't get it here.

Reason: