MQL5への願い - ページ 82

 

前に書いたことがあったら、ごめんなさい・・・。

MT5アーキテクチャに導入し、"将来性 "を考慮しても

フォーマット化された情報を配信する仕組みで、理想的には1つのセンターから配信すること。

例えば、ニュース原稿を端末で処理したり、MCLで処理したり...。

イベントによる処理...

非農業部門:前回値、見通し、今回を想定しています。

その結果、A>Bの場合などの必要式に従って、TOを行う。

*

そして、金利などの経済 指標のような些細なこと。

基本的に、これを行う会社は、見積書のアーカイブに等しいデータベースを維持・管理するだけである。

そして、ディーリング/ブローカー会社は、同じニュースのように買った...。つまり、ビジネスはビジネスとして理解される...

 
sol >> :

だって、Javaはかっこいいけど、Ada, APL, Boo, COBOL, Component Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1C - こんなのばっかりですからね。

ええ、それで「Javaがかっこいい」というのはどうなんですか?そのアプリケーションは、馬のようにメモリを食うから?
一般的に、ITにおいて「かっこいいから」という回答は、それ自体がプロにとってはナンセンスなのです。Javaプラットフォームでの開発では、競合技術と比較して、ソフトウェア開発のサイクルタイムを15%、実装時間を12%、計算資源を23%節約できる、というなら理解できるのですがね。それは確かにまっとうな答えだろう。しかし、現実はそんなものはない。これまで紹介した各プラットフォームには、既成のアプリケーションが多数用意されています。

MT4ターミナルには、独自のMQLプラットフォームが組み込まれています。 管理されたプラットフォームについては、Renatはすでに何度もフォーラムで使いにくいと述べており、MetaQuotesはC++以外のターミナルでそれらを使用するようになりました。 私自身はこの意見に賛成ではありませんが、会社全般、特にその製品に責任を持つ経営者の意見として尊重したいと思います。

 
JavaDev >> :

笑ってはいけないMTにSilverのようなグラフィック能力があれば...。

すべてのキャンドルにブリトニー・スピアーズのビデオを入れてもいいくらいです。

 
まあ、ストリーミングビデオはやりすぎですけどね。でも、ベクターグラフィックは見習うべきところです :)
 
sol >> :

ブラブラブラブラ・・・。


ネクタイと口紅をしっかり締める。SilverlightでEAをプログラミングできるようになることを祈っています。

はい...若者よ、あなたのことがわかりました。
1.IT分野では完全にプロではない、バカッターの「かっこつけ」的な表現で。
2.この問題の利点について何も言うことがない場合、つまり頭脳や知識がない場合、コミュニケーションにおいて完全に無礼であり、個人的になってしまいます(私の質問は、他のプラットフォームに比べてターミナルにおけるJavaの利点は何か、ということでした)。
3.ロシア語を全く読めず、特に書かれていることを理解できないのですね。私は、MetaQuotesの管理は、ターミナルでの管理プラットフォームの実装に反対していると指摘し、Silverlightはその一例に過ぎません(Silverlightが何か知っていればの話ですが)。論理的な結論は(脳があれば簡単に理解できる)、ターミナルにSilverlightのコードは存在しないし、今後も存在しない、ということです。SilverlightのExpert Advisorとはどのようなものですか?ロシア語は「かっこいい」と「ボケる」以外、知らないの?

結論:無能で無礼で理解力のない非プロフェッショナルと何を話し合えるのか?他に話すことがないのです。

 

えー


反対尋問

 

このオペレーターを見たいと思います。

double ArrayNormalizeDouble( double array[], int digits)
パラメータ
array[] - 代入先となる数値の配列.
digits - 精度の形式,小数点以下の桁数(0-8).
浮動小数点数の代入時に指定した精度で丸める
この手続きで宣言された配列に代入されたデータは、以下のようになります。
は自動的に正規化されます。

MyArray[3]です。
ArrayNormalizeDouble( MyArray, 2);
MyArray[0]=12.123;
MyArray[1]=13.234;
MyArray[2]=14.432です。
結果」 12.12、13.23、14.43

 
Urain >> :

そんなオペレーターを見たいです。

double ArrayNormalizeDouble( double array[], int digits)
パラメータ
array[] - 代入先となる数値の配列.
digits - 精度の形式,小数点以下の桁数(0-8).
浮動小数点数の代入時に指定した精度で丸める
この手続きで宣言された配列に代入されたデータは、以下のようになります。
は自動的に正規化されます。

MyArray[3]です。
ArrayNormalizeDouble( MyArray, 2);
MyArray[0]=12.123;
MyArray[1]=13.234;
MyArray[2]=14.432です。
結果 " 12.12, 13.23, 14.43 ".

mql4でやるのは難しくない。

void ArrayNormalizeDouble( double& array[], int digits )
  {
  int i;
  if ( digits>8) digits=8;
  if ( digits<0)  digits=0;
  for( i=0; i<ArrayRange( array,0); i++)       array[ i]=NormalizeDouble( array[ i], digits);
  }
関数で,配列のすべてのメンバをサイクル正規化します.

の場合、配列は参照として関数に渡されなければなりません。一次元配列のみ

次元数が異なる配列の場合、このような関数を複数作成する必要があります。


私は1次元配列と2次元配列の両方を使うことが多いのですが、次元の異なる配列の処理を分けるという問題によく直面しました。

そこで、2次元配列にのみハンドラを持たせ、配列はすべて2次元で定義するのがよいという結論に達しました。

例えば、1次元の配列が必要な場合。

double ARR[100][0]; // 2次元目が使われていないだけです。


もう一つの問題は、測定回数に制限があることと、ゼロ以外の次元を変更できないことです。

そこで、必要な計測数を一次元に拡張することで、回避しています。

苦しいけど、うまくいく、みたいな補助的な機能が多いので

int GetIndex(int info[],int d0,int d1,int d2 ......);

ここで int info[] - 擬似多次元配列の次元数とそのサイズに関する情報.

と int d0,d1,d2....はその次元のインデックスである。

このモンスターは、多次元のものが展開された通常の配列のインデックスを返す。

逆関数はさらにひどいもので、通常の配列の1つのインデックスを返します。

の配列で、擬似次元インデックスを持つ。

が、何度でも計測して、すべて変更することが可能です。


MQL5にクラスと関数のオーバーロードがあれば、この手間は間違いなく楽になります。







 
awo >> :

もちろん、「これとこれとこれは実現するけど、これとこれを待ってはいけない」と伝えるだけでなく、テトリスを書いたり投稿したりする方が簡単です。

私はc++に詳しくないので、mqlがcppとどのように似ているか、新しい機能はどのようなものかを理解するためには、おそらくc++を勉強しなければならないでしょう?

直接の質問ですが、将来的にmqlで仕事をするために、今cppを学ばなければならないのでしょうか?

司会者に感謝、cppを学ぶ :)

 

みなさん、こんにちは。

ブローカーが許可する未決済注文の最大数についての情報があると、非常に良いことがあります。

ブローカーが特定のブローカーの注文を開くことができない場合、あなたは常に特定のブローカーの注文を開くことを試みるべきであるが、あなたがブローカーのプロパティの場合、あなたは常に特定のブローカーの注文を開くために試してみてください。

したがって、要望はこうだ。

MQL5では、この注文数を表示する機能(例えば、MarketInfo() 関数の新しいリクエスト識別子によって)を提供するか、ターミナルの下部に鈍重に表示する(下の画像は曲解してすみません)...ということが考えられます。

私の希望がMQL5とMT5のどちらを指しているのか正確には分かりませんが、どちらでも実装可能なのは間違いないでしょう...。