市場に関する記録 - ページ 31

新しいコメント
 
Vladislav Andruschenko:

おそらく、会社勤めをしていないからでしょう。そして、OOPよりも手続き型プログラミングの方が使いやすいと感じます。

もちろん、これにはさまざまな議論がありました。

さて、ちょうど先週、私のTSリーグの取引品質推定アルゴリズムの修正を行っていました。そして、すべてが仮想インターフェイスをベースにしていることがとてもうれしいです。

ポイントは、以前は最大ドローダウンをバランスだけで見積もっていたことです。そして、Equityで試算してみたいと思いました。しかし、これを行うには、履歴を分析する際に、各トランザクションについて、時系列を要求し、その時の価格に基づいて、トランザクションの最大ドローダウンが何であったかを確認する必要がある。

私のコードはポータブルであり、同じインターフェースに基づいてMT4とMT5の両方が動作することを意味することを忘れないでください。したがって、各プラットフォームのために - 独自の関数を持つ適切なクラスを呼び出しますが、これは顕著に異なっている。だから、コードを修正しながら、おそらく何十回となく、必要なデータに直接アクセスできない状況に陥ったんです。そして、その都度、自分が正しいこと、インターフェースが制限していることを確認しました。もし、私がこのデータを直接「利用」していたら、プログラムの他の部分のエラーにつながっていたかもしれないのです。必要なデータには別の方法でアクセスし、クエリを追加することで、他の部分に影響がないことを確認することができました。

まとめると、「それぞれの場所で、ユーザーはその時必要な構造物だけにアクセスでき、それ以外はアクセスできない」という原則は、絶対に正しいと改めて確信しました。ユーザーが常にすべてにアクセスできるようにすることはできません。修正ミスが発生する恐れがあります。

しかし、一方で、手続き型に慣れている人は、このような場合、どのデータをどこから変更できて、どのデータを変更できないかを覚えておくだけで、自分を制限することができます。

 
Georgiy Merts:

さて、ちょうど先週、私のリーグTSの取引品質評価アルゴリズムの修正を行っています。そして、すべてが仮想インターフェイスをベースにしていることがとてもうれしいです。

ポイントは、以前は最大ドローダウンをバランスだけで見積もっていたことです。そして、Equityで試算してみたいと思いました。しかし、これを行うには、履歴を分析する際に、各トランザクションについて、時系列を要求し、その時の価格に基づいて、トランザクションの最大ドローダウンが何であったかを確認する必要がある。

私のコードはポータブルであり、同じインターフェースに基づいてMT4とMT5の両方が動作することを意味することを忘れないでください。したがって、各プラットフォームのために - 独自の関数を持つ適切なクラスを呼び出しますが、これは顕著に異なっている。だから、コードを修正しながら、おそらく何十回となく、必要なデータに直接アクセスできない状況に陥ったんです。そして、その都度、自分が正しいこと、インターフェイスが私を制限していること、つまり、もし私がこのデータを直接「利用」していたら、プログラムの他の部分のエラーにつながることを確認したのです。必要なデータには別の方法でアクセスし、クエリを追加することで、他の部分に影響がないことを確認することができました。

まとめると、「それぞれの場所で、ユーザーはその時必要な構造物だけにアクセスでき、それ以外はアクセスできない」という原則は、絶対に正しいと改めて確信しました。ユーザーが必要とするものすべてに常にアクセスできるようにしてはいけません。修正エラーが発生する可能性があります。

しかし、一方で、手続き型に慣れている人は、このような場合、与えられた場所から変更できるデータとできないデータを覚えておくことで、自分を制限することができるのです。

そうですね、mt5とmt4で同じように動作する独自のライブラリも持っています。私は1つのコードを書くだけで、あとはライブラリがやってくれます。
また、すべてをOOPにするほどコードは大きくありません。
ちなみに、株式のドローダウンといえば、まさに私のインジケーターで使っていました。
でも、そこにはいろいろなニュアンスがあります。特に、あるバーのティック履歴を 取得することができない。そのため、データは概算となります。
 
Реter Konow:

まあ、それが競争なんですけどね。しょうがないですね。とにかくあきらめないで、前に進み続けて、勝ってください。そうでなければ、取り残されてしまいます。

PLOのことは忘れてください。もしこの質問が気になるなら、プログラミングでは、なくても困らないものしか使ってはいけないと言えるでしょう。プロシージャルスタイルでできるのであれば、そうしてください。

私の原則は、「課題を解決する上で、何かがなくても済むのであれば、絶対にない方がいい」 です。

犬には5本目の脚が必要なのか？:)

その通りです。

そういう競争が必要なのです。

 
Vladislav Andruschenko:

驚かれるかもしれませんが、私は今でも手続き型プログラミングに悩まされているんです。

14歳でパスカルにハマり、自分を変えられない。そして、ずいぶん前に「授業を習った」のですが、気持ちを切り替えることができない...。

おそらく、会社勤めをしていないからでしょう。そして、OOPよりも手続き型プログラミングの方が使いやすいと感じます。

OOPの原則は手続き型プログラミングとあまり変わりませんが、MQLプログラムではタスクが高度に専門化されており、クラスの 内部構造を 開発する意味がないことが多いのです。Codobaseにあるクラスを使った例の9割以上は、クラスで解決する作業を一度だけ行い、継承やポリモーフィズムを使わない（必要がないから）ため、「クラスを使った」手続き型プログラミングに過ぎない。

この問題はすでに解決されており、フリーアクセスで、使い方や修正方法（継承など）を知るだけでよいのです。

彼らはすでにそれをやっているし、自由に利用できる。ただ、それをどう使うか（MQLのグラフィックス）、どう継承するか（継承の使い方）が問題なのだ。

ZZZY：それは、ALGLIBの観点から使い勝手について言わないことです。確かに、通常のクラスで「包む」べきです！。

 

Igor Makanu:

...

そして、OOPでなければできないシリアスなタスクはグラフィックス...。

非常に賛否両論です))

 
Реter Konow:

非常に賛否両論です))

イゴール・マカヌ

OOPの原則は手続き型プログラミングとあまり変わりませんが、特にMQLプログラムではタスクが高度に専門化されており、クラスの 内部構造を 開発する意味がないことが多いのです。Codobaseにあるクラスを使った例の90%以上は、クラスで解決するタスクは一度しか行わず、継承やポリモーフィズムも（必要性がないため）使われないので、「クラスを使った」手続き型プログラミングに過ぎないのです。

この問題はすでに解決されており、フリーアクセスで、使い方や修正方法（継承など）を知るだけでよいのです。

彼らはすでにそれをやっているし、自由に利用できる。ただ、それをどう使うか（MQLのグラフィックス）、どう継承するか（継承の使い方）が問題なのだ。

ZZZY：それは、ALGLIBの観点から使い勝手を言うつもりはありません。確かに、通常のクラスで「包む」べきです。


何のためかは人それぞれ。

他のユーザーが使いやすいように？

可能性はありますね。

ユーザーが「いたずらしたい」という衝動に駆られ、危害を加えることがないように。


私はグラフィックに5つの描画機能（テキスト、ボタン、チェックボックス、フィールド、背景）を使っています！)

すべてがクリアになりました。他の人は見なくていい。

 
Vladislav Andruschenko:

その通りです。

そういう競争が必要なのです。

このような競争が、私たちのマーケットで育っていくことを夢見ています。マーケットだけをきれいにする必要があります。

完璧なスイミングを実現するためには、まずプールを掃除し、水を入れる必要があります。要するに、適切な条件が必要なのです。

プールが汚かったら、誰も競技をしたがらないでしょう。:)
 
Georgiy Merts:

さて、ちょうど先週、私のリーグTSの取引品質評価アルゴリズムの修正を行っています。そして、すべてが仮想インターフェイスをベースにしていることがとてもうれしいです。

ポイントは、以前は最大ドローダウンをバランスだけで見積もっていたことです。そして、Equityで試算してみたいと思いました。しかし、これを行うには、履歴を分析する際に、各トランザクションについて、時系列を要求し、その時の価格に基づいて、トランザクションの最大ドローダウンが何であったかを確認する必要がある。

私のコードはポータブルであり、同じインターフェースに基づいてMT4とMT5の両方が動作することを意味することを忘れないでください。したがって、各プラットフォームのために - 独自の関数を持つ適切なクラスを呼び出しますが、これは顕著に異なっている。だから、コードを修正しながら、おそらく何十回となく、必要なデータに直接アクセスできない状況に陥ったんです。そして、その都度、自分が正しいこと、インターフェースが制限していることを確認しました。もし、私がこのデータを直接「利用」していたら、プログラムの他の部分のエラーにつながっていたかもしれないのです。必要なデータには別の方法でアクセスし、クエリを追加することで、他の部分に影響がないことを確認することができました。

まとめると、「それぞれの場所で、ユーザーはその時必要な構造物だけにアクセスでき、それ以外はアクセスできない」という原則は、絶対に正しいと改めて確信しました。ユーザーが必要なものすべてに常にアクセスできるようにしてはいけません - 修正エラーの原因になります。

しかし、一方で、手続き型に慣れている人は、このような場合、ある場所からどのデータを変更できて、どのデータを変更できないかを覚えておくだけで、自分を制限することができます。

失礼ながら、あなたの論法は、まるで老人が寄りかかった棒の必要性を説明し、証明するようなものです。これがないと、私は必ず倒れると言われています。それはそうですね。しかし、誰にでもというわけではありません。

 
Реter Konow:

非常に賛否両論です))

でも、私は90年代後半にTurbo Pascalとグラフィックスの初歩をライブラリで見たので、それをどう回してもNorton Commanderになるんです。）

しかし、Delphiの登場（と私の移行）で、よく言われるように、そこから人生が始まったばかり...なのです。アクティブウィンドウやチェックボックスなどをOOPなしでどうやって作るのか、理論的にはそうなのでしょうが、良いものには慣れるという言葉通り、OOPなしでは想像もつきませんね

 
Реter Konow:

失礼ながら、あなたの主張は、まるで老人が自分のもたれている棒の必要性を説明し、証明するようなものです。それがなければ、私は必ず倒れる。それはそうですね。しかし、誰にでもというわけではありません。

あなたは確か、膨大なデータセットの中にあるものをすべて完璧に記憶しているはずです。一方、私は、若い頃もそんなことは覚えていなかった。今、私が老人になったとき、あるブロックを書いたときの意味をすべて覚えていることは、確かにできません。この "棒 "には本当に助けられています。でも、必要なものをすべて記憶にとどめておける人なら、なくても大丈夫というのは、私も同感です。

とはいえ、私はすでに何度かfxsaberのコードを引用していますが、彼自身はその仕組みを正確に説明できないのです。ただ、非常にトリッキーで当たり前でないチェックが入っているので、さすがに覚えるのが大変です。そして、男は覚えていない。このコードは何度もチェックされているから信頼できる」というのがコンセンサスでした。 しかし、一部の作業プロトコルが変更されたらどうなるのでしょう。この場合、変更箇所を修正するのではなく、変更箇所を見つけるまで再調査が必要になります。

そのための "棒 "なのです。今日のソフトウェア製品は非常に複雑であり、その複雑さをすべて把握することは非現実的である。そのため、さまざまな手法が用いられています（OOPはそのひとつに過ぎません）。

1...242526272829303132333435363738...43
新しいコメント