サービスデスク：怠慢、自閉、間違いを認めたくない？ノンネイティブキャンドルでチャートを補完。 - ページ 8 123456789101112131415...22 新しいコメント 削除済み 2012.11.26 01:24 #71 Renat:分ではなく、別のものがあるかもしれない」という考えで、わざとヒステリーを起こしている人がいるのだと受け止めています。事実はこうだ。1999年より古い 分単位データのみの 日数は、深い歴史を埋めるために意図的に、わざわざ 入れたものです。1999年からの分単位のデータではなく、他の時間軸のデータはありません。つまり、分履歴の中に ミックスがないことです。日足を古い分足にインポートする際の技術的なミスはありません。日中OHLCで「素直な」分量があります。1980年の日記 分が私の分数分析を台無しにする」というのは、本気ではありません。この話題で炎上する必要はありませんし、正論 的な怒りもありません。市場に投入される製品は、妥協の積み重ねであることを心に留めておいてください。一つの理論の純粋性を守るための最大公約数は、必然的に他の十数個の立場と対立することになるのだ。そして、最終的に勝つのは、それぞれが少しずつ何かを犠牲にしていくような、妥協の積み重ねであることがほとんどです。意図的に、意図的に、機能を作るためにseries_bars_count現時点での1シンボル期間あたりのバー 数長シリーズ名現時点での期間記号ごとの最短日時分本当の分なのか、それとも意図的に、現在のタイムフレームよりも高い位置に設定されたバーなのかを判断する識別子は、発明できないのではないでしょうか？他のDTについて、心配する必要はありません。series_bars_count現時点でのシンボル期間別バー量長シリーズ名現在のシンボル期間の最初の日付時分は、過去の開始日が時間軸によって異なる可能性があることを意味します。もし、すべてが分単位で保存されているならば、最初のバーの日付で開始日を得ることはできないが、識別子を使用してもよいだろうか」という疑問が生じないわけがない。ところで、デベロッパーのサーバーではすべてが時計のように動くべきで、サードパーティの仲介会社にはバグがあるはずだと思うのは私でしょうか。なぜ、「ここは最悪だから、うまくやらせてあげよう」みたいな言い方をするのか？いずれにせよ、機能と説明文が一致していないのは事実ですが...。 Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Информация об исторических данных по инструменту www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Информация об исторических данных по инструменту - Документация по MQL5 михаил потапыч 2012.11.26 07:31 #72 komposter: 自爆しちゃうよ。私も参加します。MKの傲慢さと攻撃性の理由は明らかではありません。その結果、会社は少なからず経費を節約することができた。そして、それはそのフォーラムの人々があまり考慮しないことについてではない、それは本当です、私はこの週末マイナス2という事実について話している。コンポを無知につけ、専門家を軽く批評した。近年、この2人のフォロワーの貢献度は計り知れないものがあります。でも、ゴポタは気持ちいいので、安心して公開司会者に重ねることができます。 もちろん、「文句を言う」ボタンを押してもいいのですが、今は機能していないか、パーティの進行によって変化します。しかし、gopotaは、一般的に別のものから1期間のキャンドルのチャート上にすることができますどのように質問しないでください。また、情報量を増やすために、他の商品のローソク足を放送することも可能です。 Renat Fatkhullin 2012.11.26 07:41 #73 Mischek:参加させていただきます。MKの傲慢さと攻撃性の理由は明らかではありません。素晴らしいフィードバックがあり、ちなみに、会社はかなりのコスト削減ができた。私から見れば、取るに足らない問題がエスカレートして、仲良く罵り合いになっているようにしか見えません。 私たちの決断は、情報に基づくものでした。私は説明をしたのですが、「最後まで理屈をこねる」のが本当に好きな人がいるんですね。フォーラム参加者がいろいろと配慮してくれないという話ではなく、確かにそうなのですが、この週末はマイナス2だったという話です。コンポスターは誤解され、エキスパートには優しくなじられた。近年、この2人のフォロワーの貢献度は計り知れないものがあります。まず、私が言ってもいないことを私のせいにしていますね。第二に、情報が少なく、片方だけに集中していることです。 また、トピックの文言や、私たちに浴びせられる蔑称にも注目してください。 --- 2012.11.26 07:57 #74 FiftyStars: 明確になっていないのでしょうか？オプション1）履歴ファイルに追加パラメータBasef - バーが実際の分単位であれば0、分単位はないが時間単位がある場合、例えば、パラメータ=60、日単位であれば、パラメータ=1440です。 Anton、バーは全て 分足です。 履歴は全て分足としてのみサーバーに保存されます。 他のTFはターミナルに読み込まれる際に分足をベースに構築されます。99年までの分足に日足のバーが見えるということは、このバー「日足」が分足に含まれているということである。あるのです。ほらね？a) チャート読み込み時にチェックし、それぞれ、日付までの非ネイティブバー等の表示を禁止する。b) 一度チェックし、すべてのステッチポイントを別々に記録する（履歴はどこにも残らない）変形2) ステッチポイントの情報のみを保存 (スペースを節約するため。最近は変形1がハードディスクを占有することはないと思いますが)どこに保存するのか、どうやって手動でコントロールするのか、どうやって履歴ファイルを埋めるのか。 Mykola Demko 2012.11.26 11:03 #75 Renat:私から見れば、取るに足らない問題がエスカレートして、人々が仲良く掛け声に参加したものです。 私たちの決断は、意識的なものでした。説明もされていますが、本当に「最後まで理論で勝負する」のが好きな人がいるんですね。まず第一に、あなたは私が言ってもいないことを私に帰しています。第二に、確かに情報が少なく、片方だけに集中している。 また、トピックの文言や、私たちに浴びせられる蔑称にも注目してください。問題があることを認めたのだから、取るに足らない問題を一つ、また一つ、そして三つと解決していけば、端末は良くなるはずだ。多くの人々によって表されるコミュニティは、最初に開発のための概念的なアイデアを与えた（無償で、すなわち）、あなたは概念に取得しないことを述べている、我々は野心的な計画を持って、あなたはそれらを知らないというように。では、具体的にどこが嫌なのか、どこを改善すればいいのかの洗い出しに移りました。今、具体的な話は必要ないとおっしゃいますが、実際にはどこにも行かず、端末をそのまま使い、MQ脳に迷惑をかけないようにしましょう。まあ、シーザーにはシーザーを。そろそろ失礼します、ここはつまらないので。 Andrew Petras 2012.11.26 11:07 #76 01.01以外の分単位の昼間のバーに出会った方はいらっしゃいますか？履歴ファイルの大き さでわかります Mykola Demko 2012.11.26 11:13 #77 Silent:01.01以外の分単位の昼間のバーに出会った方はいらっしゃいますか？履歴ファイルのサイズを確認することができますMQL5では 履歴ファイルのサイズにアクセスできないため、間接的な推定となります。日でなければ、M5が追加されます。結局、加算は低い方から高い方へと異なる時間枠で行われる。MQL5による接着の日付が必要なのです。プロジェクターは、どのTFまでなら接着が重要でないかを自ら判断します。 Renat Fatkhullin 2012.11.26 11:18 #78 Urain:問題があることを認めたのだから、取るに足らない問題を一つ、また一つ、そして三つと解決していけば、端末は良くなっていくだろう。 問題を認めているのではなく、逆に問題がないことを一点 一点説明しているのです。 --- 2012.11.26 11:18 #79 Urain:MQL5による接着の日付が必要であることは明らかです。プロジェクターは、TFの接着が重要でない日付までを選択します。どこに保存するか、どのように記録するか、どのように制御／変更するか？ なぜ、すべてが古いものから順に進んでいくと思うのですか？ が難しいです。 私のアドバイスは、MCサーバーの履歴とターミナルを使わないで、その愚かな接着剤のないブローカーを見つけることです。 Mykola Demko 2012.11.26 11:25 #80 sergeev:どこに保存するのか、どのように書き込むのか、どのように制御・変更するのか？ スタックはいくつあってもいい。 なぜ、すべてがジュニアからシニアになるのだろう？ は難しいですね。 私のアドバイスは、MCサーバーの履歴とターミナルを使わないで、この愚かな接着剤のないブローカーを見つけることです。ディリングが元ネタを提供し、それを修正するのがディリングです。MQは他のフォーマットからそういうストーリーを作る仕組みを作ればいいだけで、そこに仕組みの欠陥があるんです。歴史は後輩から先輩へと縫い合わされるものだと勝手に思い込んでいたが、論理的である（間違っていたら訂正してください）。このファイルが接着剤ポイントを持っている履歴ファイルの追加情報の導入は、それだけで余分な機能は、すべてが古いによってusurpedされますが、それでも目的の場所progeruとそれを識別するための簡単な方法が表示されます。正直なところ、MQがなぜこのような問題を抱えているのか理解できません。SZYは、保存する場所を伝えることができ、ファイル内の楽器の暗号化された名前がある領域であり、この情報を暗号化します。 123456789101112131415...22 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
分ではなく、別のものがあるかもしれない」という考えで、わざとヒステリーを起こしている人がいるのだと受け止めています。
事実はこうだ。
市場に投入される製品は、妥協の積み重ねであることを心に留めておいてください。
一つの理論の純粋性を守るための最大公約数は、必然的に他の十数個の立場と対立することになるのだ。そして、最終的に勝つのは、それぞれが少しずつ何かを犠牲にしていくような、妥協の積み重ねであることがほとんどです。
意図的に、意図的に、機能を作るために
series_bars_count
現時点での1シンボル期間あたりのバー 数
長
シリーズ名
現時点での期間記号ごとの最短日
時分
本当の分なのか、それとも意図的に、現在のタイムフレームよりも高い位置に設定されたバーなのかを判断する識別子は、発明できないのではないでしょうか？
他のDTについて、心配する必要はありません。
series_bars_count
現時点でのシンボル期間別バー量
長
シリーズ名
現在のシンボル期間の最初の日付
時分
は、過去の開始日が時間軸によって異なる可能性があることを意味します。もし、すべてが分単位で保存されているならば、最初のバーの日付で開始日を得ることはできないが、識別子を使用してもよいだろうか」という疑問が生じないわけがない。ところで、デベロッパーのサーバーではすべてが時計のように動くべきで、サードパーティの仲介会社にはバグがあるはずだと思うのは私でしょうか。なぜ、「ここは最悪だから、うまくやらせてあげよう」みたいな言い方をするのか？
いずれにせよ、機能と説明文が一致していないのは事実ですが...。
自爆しちゃうよ。
私も参加します。MKの傲慢さと攻撃性の理由は明らかではありません。その結果、会社は少なからず経費を節約することができた。
そして、それはそのフォーラムの人々があまり考慮しないことについてではない、それは本当です、私はこの週末マイナス2という事実について話している。コンポを無知につけ、専門家を軽く批評した。
近年、この2人のフォロワーの貢献度は計り知れないものがあります。でも、ゴポタは気持ちいいので、安心して公開司会者に重ねることができます。
もちろん、「文句を言う」ボタンを押してもいいのですが、今は機能していないか、パーティの進行によって変化します。しかし、gopotaは、一般的に別のものから1期間のキャンドルのチャート上にすることができますどのように質問しないでください。
また、情報量を増やすために、他の商品のローソク足を放送することも可能です。
参加させていただきます。MKの傲慢さと攻撃性の理由は明らかではありません。素晴らしいフィードバックがあり、ちなみに、会社はかなりのコスト削減ができた。
私から見れば、取るに足らない問題がエスカレートして、仲良く罵り合いになっているようにしか見えません。
私たちの決断は、情報に基づくものでした。私は説明をしたのですが、「最後まで理屈をこねる」のが本当に好きな人がいるんですね。
フォーラム参加者がいろいろと配慮してくれないという話ではなく、確かにそうなのですが、この週末はマイナス2だったという話です。コンポスターは誤解され、エキスパートには優しくなじられた。
近年、この2人のフォロワーの貢献度は計り知れないものがあります。
まず、私が言ってもいないことを私のせいにしていますね。第二に、情報が少なく、片方だけに集中していることです。
また、トピックの文言や、私たちに浴びせられる蔑称にも注目してください。明確になっていないのでしょうか？
オプション1）履歴ファイルに追加パラメータBasef - バーが実際の分単位であれば0、分単位はないが時間単位がある場合、例えば、パラメータ=60、日単位であれば、パラメータ=1440です。
Anton、バーは全て 分足です。 履歴は全て分足としてのみサーバーに保存されます。 他のTFはターミナルに読み込まれる際に分足をベースに構築されます。
99年までの分足に日足のバーが見えるということは、このバー「日足」が分足に含まれているということである。あるのです。ほらね？
a) チャート読み込み時にチェックし、それぞれ、日付までの非ネイティブバー等の表示を禁止する。
b) 一度チェックし、すべてのステッチポイントを別々に記録する（履歴はどこにも残らない）
変形2) ステッチポイントの情報のみを保存 (スペースを節約するため。最近は変形1がハードディスクを占有することはないと思いますが)
どこに保存するのか、どうやって手動でコントロールするのか、どうやって履歴ファイルを埋めるのか。
私から見れば、取るに足らない問題がエスカレートして、人々が仲良く掛け声に参加したものです。
私たちの決断は、意識的なものでした。説明もされていますが、本当に「最後まで理論で勝負する」のが好きな人がいるんですね。
まず第一に、あなたは私が言ってもいないことを私に帰しています。第二に、確かに情報が少なく、片方だけに集中している。
また、トピックの文言や、私たちに浴びせられる蔑称にも注目してください。問題があることを認めたのだから、取るに足らない問題を一つ、また一つ、そして三つと解決していけば、端末は良くなるはずだ。
多くの人々によって表されるコミュニティは、最初に開発のための概念的なアイデアを与えた（無償で、すなわち）、あなたは概念に取得しないことを述べている、我々は野心的な計画を持って、あなたはそれらを知らないというように。
では、具体的にどこが嫌なのか、どこを改善すればいいのかの洗い出しに移りました。
今、具体的な話は必要ないとおっしゃいますが、実際にはどこにも行かず、端末をそのまま使い、MQ脳に迷惑をかけないようにしましょう。
まあ、シーザーにはシーザーを。
そろそろ失礼します、ここはつまらないので。
01.01以外の分単位の昼間のバーに出会った方はいらっしゃいますか？
履歴ファイルの大き さでわかります
01.01以外の分単位の昼間のバーに出会った方はいらっしゃいますか？
履歴ファイルのサイズを確認することができます
MQL5では 履歴ファイルのサイズにアクセスできないため、間接的な推定となります。
日でなければ、M5が追加されます。結局、加算は低い方から高い方へと異なる時間枠で行われる。
MQL5による接着の日付が必要なのです。プロジェクターは、どのTFまでなら接着が重要でないかを自ら判断します。
問題があることを認めたのだから、取るに足らない問題を一つ、また一つ、そして三つと解決していけば、端末は良くなっていくだろう。
MQL5による接着の日付が必要であることは明らかです。プロジェクターは、TFの接着が重要でない日付までを選択します。
どこに保存するか、どのように記録するか、どのように制御／変更するか？
なぜ、すべてが古いものから順に進んでいくと思うのですか？
が難しいです。
私のアドバイスは、MCサーバーの履歴とターミナルを使わないで、その愚かな接着剤のないブローカーを見つけることです。
どこに保存するのか、どのように書き込むのか、どのように制御・変更するのか？
スタックはいくつあってもいい。 なぜ、すべてがジュニアからシニアになるのだろう？
は難しいですね。
私のアドバイスは、MCサーバーの履歴とターミナルを使わないで、この愚かな接着剤のないブローカーを見つけることです。
ディリングが元ネタを提供し、それを修正するのがディリングです。MQは他のフォーマットからそういうストーリーを作る仕組みを作ればいいだけで、そこに仕組みの欠陥があるんです。
歴史は後輩から先輩へと縫い合わされるものだと勝手に思い込んでいたが、論理的である（間違っていたら訂正してください）。
このファイルが接着剤ポイントを持っている履歴ファイルの追加情報の導入は、それだけで余分な機能は、すべてが古いによってusurpedされますが、それでも目的の場所progeruとそれを識別するための簡単な方法が表示されます。
正直なところ、MQがなぜこのような問題を抱えているのか理解できません。
SZYは、保存する場所を伝えることができ、ファイル内の楽器の暗号化された名前がある領域であり、この情報を暗号化します。