さらなる戦略？問題なし! - ページ 9

新しいコメント
 
voltair >> :

ジェネレーターとその戦略について議論したい人は、"パス "することをお勧めします。 これ.

SXの作者には、枝を本来の用途に使わなかったことをお詫びします。

そしてさらなる活躍を!

ありがとうございます、そしてありがとうございました。

 
TheXpert >> :

月曜日までに、最適化の順番を変えて、最初のダウンタイムがないようなバージョンを作ってみるつもりです。

>> そして、これです。

 
TheXpert >> :

そこに彼女はいる。

申し訳ありません、注文を開くときにハングアップする誤りを訂正しました。最小開封時のバランスチェックを追加しました。旧バージョンをダウンロードされた方は、新バージョンへのアップデートをお願いします。

ファイル:
home_1.zip  7 kb
 
TheXpert писал(а)>>

...建設的な批判や提案（どんなものでも）を聞きたいのですが......。

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]);
}

何らかの確信が欲しい。:)

 
SergNF >> :

確信が欲しいというか。:)

また、どこをどう変えればいいのでしょうか？コメント変更に賛成です。

__________________________

4時台を立ち上げた。

進捗はこんな感じです。




私のパソコンは一番高性能なものではありません。

だから、普通のコンピュータの時計は、現実的には24時間でも動く。そして、それを分割すると...


このように残り時間が少なくなっているのは、重要な戦略が最も集中しているのが、以前は中盤だったのが、現在は冒頭になっているためである。

 
TheXpert писал(а)>>

コメント変更に賛成です。

私もそう思います。

要は、誰の「オリジナル」にも「リファレンス」があるはずなんです。そうでなければ、どうやってセットを交換するんだ :) 。

だから、普通のコンピュータの時計は、現実的には1日でもいいんです。そして、解析すると...

そして、もし「初値」がついたら・・・。すでに10回ほど「装着」していますが、すべてのバリエーションがOOSで失敗しています。

(EURUSDのクロックフィッティングは2008年の全てです。3回繰り返し -条件_X→ 二次_→ 条件_X)

全ティック」と「始値別」のモデルが一致した結果

 
SergNF >> :

私もそう思います。

要は、誰もが「基準」となるセットを持っていればいいのです。そうでなければ、どうやってセットを交換するのでしょうか :)

セットの他に、ファイルを交換したり、文字列だけを条件とすることも可能です。次のバージョンで修正する予定です。

 
SergNF >> :

そして、「オープニング価格」であれば、．すでに10回ほど「調整」していますが、すべてのバリアントがOOSで消耗しています。

もちろんオープニング価格でohh。なぜ無意味にコンピュータを苦しめるのか？

(EURUSD watchframes fitting - all of 2008.3回繰り返し - 条件_X→二次_→条件_X)

99年からテストしています。

 
TheXpert писал(а)>>

...建設的な批判や提案（どんなものでも）を聞きたいのですが......。

- IMHOExterns」ブロックと「// here」ブロックを別の「inludnik」に取り込んで、誰もベースファイルを編集する手も持たないようにするのがよいでしょう。

- また、「コーディング」においては、「BuyCondition9()」という数字から、何らかの「ニモニック」に移行した方が、同時に全く別の「BuyCondition786()」を追加する人がいなくなると思います。そうでなければ、「リポジトリ」は著者が保持しなければならない。左の機能を大文字に、右の機能を小文字にするように。「BB_O」（Condition9の 場合）とか、接頭語に「著者のニックネーム」をつけるとか。しかし、その場合、「bool BuyCondition(int index)」と「bool SellCondition(int index)」という関数を「作る」必要があります。

私のプロジェクトでは、外部パラメータ（とそれを複製したiniファイル）で、私は長い間、 "+EURUSD" - "EURUSDを買う "のようないくつかのmenonicsを書いてきました。通訳にはちょっとしたステップになります。:)

'

ZSです。

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

しかし、それを最適化 するのは難しい。:)

'

ZYです。

最適化されたextern(int)と、エンドユーザーが予約番号や関数を使えないことの妥協点が見つかればいいのですが......。この製品は、柔軟性と汎用性において、他のすべての製品を凌駕していることでしょう。愛する人のために」というと、余計にややこしくなるけれど。:)

次のバージョンで修正する予定です。

そして、extern文字列でのCommentの命令!!!!!!!

'

 
SergNF >> :

- IMHOExterns" と "// here" のブロックは別の "inluder" に置き、誰もベースファイルを編集する手さえ持たないようにするのがよいでしょう。

実は、そうしようと思っていたんです。

バージョン1.0では、モジュールへの分割、クリーニング、コドジェネレーション（多分）、そして執筆のための若干のマナを計画していました。

多少なりとも製品らしさを出すために。

- また、「コーディング」においては、「BuyCondition9()」という数字から、何らかの「ニモニック」にして、全く別の「BuyCondition786()」を同時に追加する人が出ないようにした方が良いと思います。そうでなければ、「リポジトリ」は著者が保持しなければならない。左の機能を大文字に、右の機能を小文字にするように。「BB_O」（Condition9の 場合）とか、接頭語に「著者のニックネーム」をつけるとか。しかし、この場合、「bool BuyCondition(int index)」と「bool SellCondition(int index)」という関数を「作る」必要があるのです。

そこで反対なんです。条件を追加することは促進されるが、歓迎されない。一度コードを変えたら、サポートはあてにならないと言っておきましょう。

条件を追加する必要がある場合は、言ってください。

最適化された外部関数（int）と、エンドユーザーが予約番号や関数を使用できないことの妥協点を見つけることができれば......。柔軟性、汎用性では他の追随を許さないだろう。愛する人のために」というと、余計にややこしくなるけれど。:)

なぜわざわざ探すのか？それは、わかりやすく言えば「Foolproofing」です。通常は、実行のどの段階でもデータの整合性を保護するものです。

これは今のところ部分的にしかなく、バージョン1.0で追加することはまだ予見されていません。

ターミナルを使用できない場合は、常に手で整合性を確認することができます。

そして、extern文字列でのCommentの命令！！！！』。

ここではわからない。

123456789101112
新しいコメント