記事"ユニバーサルEA: CUnIndicator と予約オーダーの使用 (その 9)"についてのディスカッション - ページ 2

新しいコメント
 

こんにちは！

UnExpertの勉強を始めたばかりです。今日まですべて順調だったのですが、突然Message、Dictionary、Sessioninfoなどのライブラリファイルでエラーが発生しました。何が起こったのでしょうか？一般的に、このライブラリはサポートされていますか？

 
Titika:

UnExpertの勉強を始めたばかりです。今日まですべて順調だったのですが、突然さまざまなライブラリファイル Message、Dictionary、Sessioninfo などでエラーが発生しました。何が起こったのでしょうか？

言語の変更で自由が利かなくなったのでしょう。修正するのは簡単です。

 
fxsaber:

言葉の変更によって、いくつかの自由が許されなくなったのだ。修正するのは簡単だ。

自分のコードを見て驚いた。いくつかのメソッドには戻り値の型が指定されていなかったのだ。以前はコンパイルできたのに不思議だ。

 
Vasiliy Sokolov:

自分のコードを見て驚いた。いくつかのメソッドには戻り値の型が指定されていなかったのだ。以前はコンパイルできたのに不思議だった。

どういうわけか、最近の記事でもそのようになっていた。

ZIPライブラリでは、記憶が確かであれば、以前は同じケースで、動作していました。

 

今日、私はUniversal Engineをベースにした最初のExpert Advisorを書いた。この場を借りて、作者にお礼を申し上げたい。

主要なクラスと関数を実質的に理解しながら、わずか1日でエキスパート・アドバイザーを書くことができました。CodeBaseへの掲載を申請しましたが、ユニバーサル・エンジンのメイン・ライブラリがないとコンパイル可能かどうかの最終テストに合格しないからです。moderatotramに手紙を書いたので、もしかしたら通してくれるかもしれない。

このプロジェクトはStockSharpプラットフォームのS#.Shellライブラリを思い出させますが、より効率的で最適です。

いくつかの小さな指摘

1.CTrailingMovingクラスもCUnIndicatorを使うように変更すべき。

2.2.CTrailingClassicクラスのModify()メソッドが本当に間違って動作していることは、記事「Universal Trading Expert Advisor: Working with Custom Trailing Stops (Part 6)(リンク)」のディスカッションで気づかれましたが、修正されていませんでした。

適切なメソッド終了には、m_step_modify値を超えるかどうかのチェックを含めるべきです：

   if(m_position.Direction()==POSITION_TYPE_BUY)
      {
         n_sl=extremum-m_diff_extremum;
         if(n_sl-m_position.StopLossValue()>m_step_modify) return m_position.StopLossValue(n_sl);
      }
   else
      {
         n_sl=extremum+m_diff_extremum;
         if(m_position.StopLossValue()-n_sl>m_step_modify) return m_position.StopLossValue(n_sl);
      }

3.ストップロスは、SupportBuy/SupportSellの中ではなく、即座に配置されるべきです。例えば、Expert AdvisorがM15で動作するようにスケジュールされている場合、ポジションはSLなしで15分となり、それは良くありません。

ユニバーサルエンジンの現在のバージョンでは、これは2つの方法で実現できます：

a) CStrategyクラスのRebuildPositionsメソッドをpublicにする、

c) M1 TFを動作するものとし、使用するすべてのインジケータのTFをExpert AdvisorのTFからリンク解除する。

しかし、これらはすべて小さなことです。

グローバルに

特にコミュニティからの要望が多いので、作者にはユニバーサル・エンジンの開発を続けてほしい。

すでに1年間、一度もアップデートがありません。Artyom Trishkinという 人がすでに代替ユニバーサルライブラリのトピックについて記事を書いていますが、今でもユニバーサルエンジンのレベルには達していません - UDの最新バージョンに実装されている機能の1/3もカバーしていない哀れなアナログです（私は、MT4とのライブラリの完全な互換性をプラスとは考えていません - 誰ももう本当に必要としていません）。

 
Sergey Lebedev:
...

この1年間、一度もアップデートがなかった。Artyom Trishkinが 代替ユニバーサルライブラリのトピックについて記事を書いていますが、今でもユニバーサルエンジンのレベルには達していません - UDの最新バージョンに実装されている機能の1/3もカバーしていない哀れなアナログに過ぎません（私は、MT4とのライブラリの完全な互換性をプラスとは全く考えていません - 誰ももう本当に必要としていません）。

この "誰か "は、プログラムを簡単に書くためのツールを皆に提供するという、"今すぐ、すぐに "とはやや異なる課題を持っている。プロジェクトは発展中であり、これはその10分の1に過ぎない。だから、その胎動で物体を判断してはいけない-早すぎる-まだ生まれていないのだ。

 
私は、あなたのプロジェクトが+80記事でユニバーサルエンジンプロジェクトを大幅に追い抜くことを信じることができますが、今週末、両方のプロジェクトを比較したとき、私はUDを支持する選択をしました。
競争力のあるユニバーサル・プラットフォームの存在は、コミュニティによって同時に開発され、作者がプロジェクトに興味を失った後に凍結されない場合には、良いことです。結局のところ、あなたは100以上の記事を作ることも、あなたのプロジェクトをサポートするのをやめるのですか？関心は常に維持できるものではない！そして、あなたの後には、ユニバーサル・ライブラリーの独自のビジョンを持ち、200以上の記事を計画する別のユニバーサル化者が現れるでしょう。
従って、なぜこれらの類似品がエンドユーザーに必要とされているのか、また、あなたが仕事を始めた時点で作成されていたユニバーサル・エンジンを開発し、その新しい改良/クラスを19～20個作成する代わりに、どのような重大な理由ですべてを一から書く必要があったのかを考えることを提案したい。
 
Sergey Lebedev:
私は、あなたのプロジェクトが+80記事でユニバーサルエンジンプロジェクトを大幅に追い抜くことを信じることができますが、今週末、両方のプロジェクトを比較したとき、私はUDを支持する選択をしました。
競争力のあるユニバーサル・プラットフォームの存在は、コミュニティによって同時に開発され、作者がプロジェクトに興味を失った後に凍結されない場合には、良いことです。結局のところ、あなたは100以上の記事を作ることも、あなたのプロジェクトをサポートするのをやめるのですか？関心は常に維持できるものではない！そして、あなたの後に、ユニバーサル・ライブラリーの彼自身のユニークなビジョンを持ち、200以上の記事の計画を持つ、別のユニバーサライザーがいるでしょう？
従って、なぜこれらの類似品がエンドユーザーに必要とされているのか、また、あなたが仕事を始めた時点で作成されていたユニバーサル・エンジンを開発し、その新しい改良/クラスを19～20個作成するのではなく、どのような重大な理由ですべてを一から書く必要があったのか、考えてみることをお勧めします。

あなたは、誰もが1つのブランドの車に乗り、1つのブランドの飛行機で1つの航空会社を利用することに賛成ですか？?

そして、そう、私は「追いつけ追い越せ」で、すべてをトウモロコシで植えようとしているわけではない......。私は私自身のプロジェクトをやって いるんだ。

もちろん、当然のことながら、ヴァシリーの作品が選ばれても不思議ではない。あなたは私の記事の意味と本質を少し誤解しているようだ。彼らはライブラリを作成するプロセスを説明しているのであって、すでに完成したものを使用するプロセスを説明しているのではない。開発に飛び込み、原理を理解したい人たち-彼らはそれを実行し、質問し、明確にし、学ぶ。そこに書かれていることをすぐに理解し、開発についていく人もいる。しかし、ここはそれを議論する場所ではない。ここはヴァシリーの仕事について議論する場所なのだ。

巨大な仕事を始めた私が、一夜にしてそれを放棄するとでも？もちろん、そんなことはない。発展の可能性はたくさんある。

 
Sergey Lebedev:

...

グローバルに

作者には、ユニバーサル・エンジンの開発、特にコミュニティからの要望の継続を祈りたい。

すでに1年間、一度もアップデートがありません。Artyom Trishkinという 人がすでに代替ユニバーサルライブラリのトピックについて記事を書いていますが、今でもユニバーサルエンジンのレベルには達していません - UDの最新バージョンに実装されている機能の1/3もカバーできていない哀れな類似品です（MT4とのライブラリの完全な互換性はまったくプラスとは考えていません - 誰ももう本当に必要としていません）。

こんにちは。ご意見ありがとうございます。UTEコードを公開バージョン管理システム（GitまたはMTのもの）に置くのが最適のようです。この場合、ユーザーは私のコードレビュー後にエラーを修正し、コードに追加変更/改善を加えることができます。このようなプロジェクト開発システムは、オープンソースにとって最適だと思います。

UTE自体については、主な機能は形成されていると思います。最も一般的な取引機能のほとんどをカバーしています。したがって、同じ方向でUTEを開発しても、根本的に新しいものは生まれない。しかし、データを扱うための機能的なフレームワークは、UTEの開発にグローバルな推進力を与えることができる。そのアイデアとは、オブジェクトスタイルでシステム構造を操作し、関数スタイルでコレクション（システムのものも含む）を操作することである。この場合、システムデータ型とユーザーデータ型の明確な区別はなくなり、その処理のためのクエリーはユーザー自身が「その場で」作成することになる（C#のLINQのようなもの）。残念ながら、言語の制約上、このフレームワークをワンツー・ベースで書くことはできないので、これはまだアイデアに過ぎない。

 

今日、アップデートを見るために立ち寄って、まず最初にお礼を言いたい。2年前、私はいくつかの不正確な点を修正しましたが、この間、私はバインディングについて考えることなく、ずっと同じEA構造を使ってきました。これはあなたの開発であり、MTの標準ではないことを時々忘れてしまいます。

もし、ライブラリを開発し、配置することができるのであれば、私は自分の手足をすべて使ってFORに一票を投じます（私は自分のニーズにねじ込んできましたが、しばしば最適ではありませんでしたし、他の作者のソリューションにもねじ込んできました）。開発のためのプラットフォームとして、あるいは開発における正しいメッセージとして。あなたが決定した場合、どうか、この議論にサイトのアドレスを書いてください。

ありがとうございました。

1234
新しいコメント