MetaTrader 4とMQL4の新機能 - 大きな変更が予定されています。 - ページ 35 1...282930313233343536373839404142...66 新しいコメント Renat Fatkhullin 2013.08.02 14:47 #341 kazakov.v: つまり、タイムゾーンの問題を自ら作り出し、世界の他の地域とは異なる、自分だけの時間の「基準」を持つ閉じた空間を作り出しているのです。 このフォーラムで何度も言われているように、「トレーダーは自分自身の履歴をアップロードする」のです。 データを取り込んで、自分好みにイン ポートするだけ。しかし、その代わりに、「方法はどうでもいいから、歴史を教えてくれ、そうすればわざわざ考える必要はない」という、全く同じ予想通りの主張が見られる。つまり、ここでもMetaQuotesが非難されるのです。 トレーダーの心を救うために、プラットフォームを使うだけで、どこから詳細なデータが来ているのか考えることもない、十数年かけてM1に正確なMetaTrader5を作りました。 Mykola Demko 2013.08.02 15:31 #342 kazakov.v: つまり、タイムゾーンの問題を自ら作り出し、世界の他の地域とは異なる、自分だけの時間の「基準」を持つという閉じた空間を作り出しているのです。 何が問題なのか、どのような密閉空間なのか、詳しく教えてください。 Рустам 2013.08.02 15:33 #343 それとは別の問題で、ユーザーの頭の中にあると思うのですが...。 とか、その意図とか。 Vladimir Kazakov 2013.08.02 16:46 #344 Urain: 何が問題なのか、どのようなクローズアップなのか、詳しく教えてください。 。 誰もが知っているように、datetime変数には1970年1月1日00:00からの秒数が格納されています。明らかに、これはunixの時間フォーマットの原型である。しかし、原典には非常に重要な説明があります。00:00はUTC時間です。そして、どのタイムゾーンのどのコンピューターも、同じ瞬間に同じtime_tの値を生成する。つまり、time_t はある時点を一意に特定する。タイムゾーンや夏時間のルールなど、エンドユーザーの要望に応じて、time_t を様々な方法でシンボル形式に変換することができます。つまり、2値表現が一義的なのです。しかし、MQは取引サーバーの時間（シンボル）をベースにする方が簡単だと判断した。例えば、現在time_t == 100000で、UTC+1のトレードサーバーは新しいバー103600にサインし、別のUTC+2のトレードサーバーは新しいバー107200にサインしている場合です。同じ期間を表示するバーが、datetameフィールドに異なる値を持つことを意味します。一見すると、見覚えがありますね。しかし、アメリカのサーバーの統計データをヨーロッパのサーバーに適用しようとすると、サマータイムが発生する日が異なるため、固定時間に移動しただけでは、年に2回、異なるデータが取得されることになるのです。例えば、NETからEETに時刻を変更したサーバーもありましたが、今ではボトルがなくても、何がシフトしたのか区別がつくほどです。 Mykola Demko 2013.08.02 17:06 #345 kazakov.v: 誰もが知っているように、datetime変数には1970年1月1日00:00からの秒数が格納されています。明らかに、これはunixの時間フォーマットのプロトタイプである。しかし、原典には非常に重要な説明があります。00:00はUTC時間です。そして、どのタイムゾーンのどのコンピューターも、同じ瞬間に同じtime_tの値を生成する。つまり、time_t はある時点を一意に特定する。タイムゾーンや夏時間のルールなど、エンドユーザーの要望に応じて、time_t を様々な方法でシンボル形式に変換することができます。つまり、2値表現が一義的なのです。しかし、MQは取引サーバーの時間（シンボル）をベースにする方が簡単だと判断した。例えば、現在time_t == 100000で、UTC+1のトレードサーバーは新しいバー103600にサインし、別のUTC+2のトレードサーバーは新しいバー107200にサインしている場合です。同じ期間を表示するバーが、datetameフィールドに異なる値を持つことを意味します。一見すると、見覚えがありますね。しかし、アメリカのサーバーの統計データをヨーロッパのサーバーに適用しようとすると、サマータイムが発生する日が異なるため、固定時間に移動しただけでは、年に2回、異なるデータが取得されることになるのです。例えば、NETからEETに時刻を変更したサーバーもありましたが、今ではボトルがなくても、何がシフトしたのか区別がつくほどです。 ええ、そういうことですね。ここでの質問は簡単です、CPU時間の多くを保存したこのMQのおかげで、アマゾンの森林の面で実質的にそれをすべて繰り返し植えた。 dillingのdatafeedはdillingにあり、死ぬという前提で、あるdillingから別のdillingへの見積もりの移行はないだろうということです。原理的には正しいのですが、なぜ販売店から販売店へ見積書が移行するのでしょうか。 もし、MQがやったようなこと（取引時間へのバインド）をしなければ、データコールのたびに、ローカルタイムに 正しく表示されるように変換する（GMTシフトをする）必要があるのです。また、データは頻繁に読み込まれるため、ディリングコールのたびにコンバーターを設置する必要があります。 ローカルなサマータイムを行うか、全世界を一つのユニバーサルタイムにするか、哲学的な問題があります。そして、MQはプロメテウスになることを望まず、ただ市場に従った。市場は、アメリカ人はターミナルで起きてほしいし、ヨーロッパ人は8時台を見てほしいと思っています。 ですから、ディーリングに縛られるのは、ある意味理にかなっています。また、MQL5にはGMT変換の機能がありますので、この機能もmql4+で実装されることを期待します。 Dmitry Rannev 2013.08.02 18:01 #346 Renat: しかし、あなたがおっしゃるカップや独立は、本当にサンクコストで、開発にブレーキをかけてきただけです。そして、MT5を無視したのは、意味が分からず、すでにMT4で既成のソリューションを持っていたためです。MT5を使えば、より速く、より美しいソリューションを手に入れることができたはずです。 当社のECNをタンブラーと呼ぶのであれば、大多数の企業が必要とする修正ではなく、自分が必要とする修正を迅速に行えるようにしたい。他のほとんどの会社と利害が正反対であることは、よくわかります。ランタイムカウンティングの 導入などのアナウンスは心強いですが。 タンブラーそのものをタンブラーと呼ぶなら、そこそこ2週間くらいの出来栄えです。 MT5が良いという主張ではなく、私自身本当にそう思っているのですが、もし私がMT5を「見て」始めていたら、今の私の顧客はもっと少なかっただろうとずっと思っています。 それに、アルパリで他人の開発で何度も失敗した経験から、私はとても慎重で、懐疑的とさえ言えますし、自分のビジネスを託したくありません。開発者であるあなたなら、きっと理解してくれるはずです。 Renat Fatkhullin 2013.08.02 18:29 #347 Rann: 当社のECNをタンブラーと呼ぶのであれば、大多数の企業が必要とする修正ではなく、自分が必要とする修正を素早く行えるようにしたいです。他のほとんどの会社と利害が正反対であることは、よくわかります。実行時間カウントの実装などのアナウンスは心強いですが。 タンブラーそのものをタンブラーと呼ぶのであれば、2週間ほどの作業でした。 MT5が良いという議論ではなく、私自身本当にそう思っているのですが、もし私がMT5を「理解して」始めていたら、今の私の顧客はずっと少なかっただろうとずっと思っています。 それに、アルパリで他人の開発で何度も失敗した経験から、私はとても慎重で、懐疑的とさえ言えますし、自分のビジネスを託したくありません。開発者であるあなたなら、きっと理解してくれるはずです。 つまり、仲介の本当の目的は、開発への痒いところに手が届くということに置き換わります。私も全く同じ痒いところに手が届くのですが、私の痒いところはビジネスの焦点と完全に一致しているのです。 MT5でのベッティングは、すべてのゲートウェイ、プロセス、エキスパートなど、システム全体と完全に統合されています。また、どのMT5ブローカーもゲートウェイの問題は全くありません。もし必要なら、内部で仕掛けられたMetaTrader 5 Gateway APIを使ってゲートウェイを書く方がずっと簡単です。だから、プログラミングの痒いところに手が届くような無駄な時間を過ごさなくていい。 しかし、MT4を批判し続け、すべてが根本から修正されたMT5には見向きもしない人もいます。そして、いくつかのブローカーはすでに目をつぶり、ECNを書きに行き、何かを疑い始めているのです。 Dmitry Rannev 2013.08.02 18:50 #348 Renat: つまり、仲介の本当の目的は、開発への痒いところに手が届くということに置き換わります。私も全く同じ痒いところに手が届くのですが、ビジネスの方向性と完全に一致させています。 MT5でのベッティングは、すべてのゲートウェイ、プロセス、エキスパートなど、システム全体と完全に統合されています。また、どのMT5ブローカーもゲートウェイの問題は全くありません。もし必要なら、内部で仕掛けられたMetaTrader 5 Gateway APIを使ってゲートウェイを書く方がずっと簡単です。だから、プログラミングの痒いところに手が届くような無駄な時間を過ごさなくていい。 しかし、MT4を批判し続け、すべてが根本から修正されたMT5には見向きもしない人がいます。そして、いくつかのブローカーはすでに見て見ぬふりをして、ECNを書きに行き、何かを疑い始めているのです。 MT5は顧客同士を対立させているのでしょうか？ Renat Fatkhullin 2013.08.02 19:08 #349 Rann: MT5では、クライアント同士をペアリングするのですか？私たちは、無意味にマスマーケット・サービスに注力しているわけではありません。MetaTrader 5 Exchange Serverを覗いてみましょう。 この秋のリリース後は、すべてのブローカーがデフォルトで、MT5プロバイダーを含む大量のゲートウェイ流動性プロバイダーと完全かつ容易に統合できる自社ECNを取得するため、すべてのカスタムECNを捨てる必要があります。完全なルールベースのマッチングを含む。 Dmitry Rannev 2013.08.02 19:17 #350 Renat: 私たちは、無意味にマスマーケット・サービスに注力しているわけではありません。MetaTrader 5 Exchange Serverを覗いてみましょう。 この秋のリリース後は、すべてのブローカーがデフォルトで、MT5プロバイダーを含む大量のゲートウェイ流動性プロバイダーと完全かつ容易に統合できる自社ECNを取得するため、すべてのカスタムECNを捨てる必要があります。完全なルールベースのマッチングを含む。 I.e.クライアント同士がマッチングするようになるのですか？このようなサービスを選択する企業は少ないのではないかと思います。マッチングした顧客からの収益が一般人の4倍程度と低すぎるのです。そして、顧客数が多いほど、乗り換えの割合が高くなります。 1...282930313233343536373839404142...66 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
つまり、タイムゾーンの問題を自ら作り出し、世界の他の地域とは異なる、自分だけの時間の「基準」を持つ閉じた空間を作り出しているのです。
このフォーラムで何度も言われているように、「トレーダーは自分自身の履歴をアップロードする」のです。
データを取り込んで、自分好みにイン ポートするだけ。しかし、その代わりに、「方法はどうでもいいから、歴史を教えてくれ、そうすればわざわざ考える必要はない」という、全く同じ予想通りの主張が見られる。つまり、ここでもMetaQuotesが非難されるのです。
トレーダーの心を救うために、プラットフォームを使うだけで、どこから詳細なデータが来ているのか考えることもない、十数年かけてM1に正確なMetaTrader5を作りました。
つまり、タイムゾーンの問題を自ら作り出し、世界の他の地域とは異なる、自分だけの時間の「基準」を持つという閉じた空間を作り出しているのです。
何が問題なのか、どのようなクローズアップなのか、詳しく教えてください。 。
誰もが知っているように、datetime変数には1970年1月1日00:00からの秒数が格納されています。明らかに、これはunixの時間フォーマットのプロトタイプである。しかし、原典には非常に重要な説明があります。00:00はUTC時間です。そして、どのタイムゾーンのどのコンピューターも、同じ瞬間に同じtime_tの値を生成する。つまり、time_t はある時点を一意に特定する。タイムゾーンや夏時間のルールなど、エンドユーザーの要望に応じて、time_t を様々な方法でシンボル形式に変換することができます。つまり、2値表現が一義的なのです。しかし、MQは取引サーバーの時間（シンボル）をベースにする方が簡単だと判断した。例えば、現在time_t == 100000で、UTC+1のトレードサーバーは新しいバー103600にサインし、別のUTC+2のトレードサーバーは新しいバー107200にサインしている場合です。同じ期間を表示するバーが、datetameフィールドに異なる値を持つことを意味します。一見すると、見覚えがありますね。しかし、アメリカのサーバーの統計データをヨーロッパのサーバーに適用しようとすると、サマータイムが発生する日が異なるため、固定時間に移動しただけでは、年に2回、異なるデータが取得されることになるのです。例えば、NETからEETに時刻を変更したサーバーもありましたが、今ではボトルがなくても、何がシフトしたのか区別がつくほどです。
ええ、そういうことですね。ここでの質問は簡単です、CPU時間の多くを保存したこのMQのおかげで、アマゾンの森林の面で実質的にそれをすべて繰り返し植えた。
dillingのdatafeedはdillingにあり、死ぬという前提で、あるdillingから別のdillingへの見積もりの移行はないだろうということです。原理的には正しいのですが、なぜ販売店から販売店へ見積書が移行するのでしょうか。
もし、MQがやったようなこと（取引時間へのバインド）をしなければ、データコールのたびに、ローカルタイムに 正しく表示されるように変換する（GMTシフトをする）必要があるのです。また、データは頻繁に読み込まれるため、ディリングコールのたびにコンバーターを設置する必要があります。
ローカルなサマータイムを行うか、全世界を一つのユニバーサルタイムにするか、哲学的な問題があります。そして、MQはプロメテウスになることを望まず、ただ市場に従った。市場は、アメリカ人はターミナルで起きてほしいし、ヨーロッパ人は8時台を見てほしいと思っています。
ですから、ディーリングに縛られるのは、ある意味理にかなっています。また、MQL5にはGMT変換の機能がありますので、この機能もmql4+で実装されることを期待します。
Renat:
しかし、あなたがおっしゃるカップや独立は、本当にサンクコストで、開発にブレーキをかけてきただけです。そして、MT5を無視したのは、意味が分からず、すでにMT4で既成のソリューションを持っていたためです。MT5を使えば、より速く、より美しいソリューションを手に入れることができたはずです。
当社のECNをタンブラーと呼ぶのであれば、大多数の企業が必要とする修正ではなく、自分が必要とする修正を迅速に行えるようにしたい。他のほとんどの会社と利害が正反対であることは、よくわかります。ランタイムカウンティングの 導入などのアナウンスは心強いですが。
タンブラーそのものをタンブラーと呼ぶなら、そこそこ2週間くらいの出来栄えです。
MT5が良いという主張ではなく、私自身本当にそう思っているのですが、もし私がMT5を「見て」始めていたら、今の私の顧客はもっと少なかっただろうとずっと思っています。
それに、アルパリで他人の開発で何度も失敗した経験から、私はとても慎重で、懐疑的とさえ言えますし、自分のビジネスを託したくありません。開発者であるあなたなら、きっと理解してくれるはずです。
当社のECNをタンブラーと呼ぶのであれば、大多数の企業が必要とする修正ではなく、自分が必要とする修正を素早く行えるようにしたいです。他のほとんどの会社と利害が正反対であることは、よくわかります。実行時間カウントの実装などのアナウンスは心強いですが。
タンブラーそのものをタンブラーと呼ぶのであれば、2週間ほどの作業でした。
MT5が良いという議論ではなく、私自身本当にそう思っているのですが、もし私がMT5を「理解して」始めていたら、今の私の顧客はずっと少なかっただろうとずっと思っています。
それに、アルパリで他人の開発で何度も失敗した経験から、私はとても慎重で、懐疑的とさえ言えますし、自分のビジネスを託したくありません。開発者であるあなたなら、きっと理解してくれるはずです。
つまり、仲介の本当の目的は、開発への痒いところに手が届くということに置き換わります。私も全く同じ痒いところに手が届くのですが、私の痒いところはビジネスの焦点と完全に一致しているのです。
MT5でのベッティングは、すべてのゲートウェイ、プロセス、エキスパートなど、システム全体と完全に統合されています。また、どのMT5ブローカーもゲートウェイの問題は全くありません。もし必要なら、内部で仕掛けられたMetaTrader 5 Gateway APIを使ってゲートウェイを書く方がずっと簡単です。だから、プログラミングの痒いところに手が届くような無駄な時間を過ごさなくていい。
しかし、MT4を批判し続け、すべてが根本から修正されたMT5には見向きもしない人もいます。そして、いくつかのブローカーはすでに目をつぶり、ECNを書きに行き、何かを疑い始めているのです。
つまり、仲介の本当の目的は、開発への痒いところに手が届くということに置き換わります。私も全く同じ痒いところに手が届くのですが、ビジネスの方向性と完全に一致させています。
MT5でのベッティングは、すべてのゲートウェイ、プロセス、エキスパートなど、システム全体と完全に統合されています。また、どのMT5ブローカーもゲートウェイの問題は全くありません。もし必要なら、内部で仕掛けられたMetaTrader 5 Gateway APIを使ってゲートウェイを書く方がずっと簡単です。だから、プログラミングの痒いところに手が届くような無駄な時間を過ごさなくていい。
しかし、MT4を批判し続け、すべてが根本から修正されたMT5には見向きもしない人がいます。そして、いくつかのブローカーはすでに見て見ぬふりをして、ECNを書きに行き、何かを疑い始めているのです。
MT5は顧客同士を対立させているのでしょうか？
MT5では、クライアント同士をペアリングするのですか？
私たちは、無意味にマスマーケット・サービスに注力しているわけではありません。MetaTrader 5 Exchange Serverを覗いてみましょう。
この秋のリリース後は、すべてのブローカーがデフォルトで、MT5プロバイダーを含む大量のゲートウェイ流動性プロバイダーと完全かつ容易に統合できる自社ECNを取得するため、すべてのカスタムECNを捨てる必要があります。完全なルールベースのマッチングを含む。
私たちは、無意味にマスマーケット・サービスに注力しているわけではありません。MetaTrader 5 Exchange Serverを覗いてみましょう。
この秋のリリース後は、すべてのブローカーがデフォルトで、MT5プロバイダーを含む大量のゲートウェイ流動性プロバイダーと完全かつ容易に統合できる自社ECNを取得するため、すべてのカスタムECNを捨てる必要があります。完全なルールベースのマッチングを含む。
I.e.クライアント同士がマッチングするようになるのですか？このようなサービスを選択する企業は少ないのではないかと思います。マッチングした顧客からの収益が一般人の4倍程度と低すぎるのです。そして、顧客数が多いほど、乗り換えの割合が高くなります。