MT5とスピードの関係 - ページ 60 1...535455565758596061626364656667...94 新しいコメント fxsaber 2020.10.26 14:18 #591 Anton:テストコード このコードは、作者が問題を理解していないことを示しています。 証明しなさい。 // Классический SYMBOL_BID vs Альтернативный SYMBOL_BID. // Запускать только на демо-счетах. #include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006 #define Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK) bool GetPosition( const int Type = OP_BUY ) { bool Res = false; for (int i = PositionsTotal() - 1; (i >= 0) && !Res; i--) Res = PositionGetTicket(i) && (PositionGetInteger(POSITION_TYPE) == Type) && (PositionGetString(POSITION_SYMBOL) == _Symbol); return(Res); } // Альтернативный способ получения Bid-цены текущего символа. // Запускать только на демо-счетах. double GetBid() { static const TICKET_TYPE Ticket = GetPosition() ? PositionGetInteger(POSITION_TICKET) : OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, 0); return(PositionSelectByTicket(Ticket) ? PositionGetDouble(POSITION_PRICE_CURRENT) : 0); } #define TOSTRING(A) ", "#A + " = " + (string)(A) #define MACROS(A, B) \ const ulong StartTime##A = GetMicrosecondCount(); \ const double A = B; \ const ulong Interval##A = GetMicrosecondCount() - StartTime##A; \ \ if (Interval##A > 100) \ Time##A += (long)Interval##A; long TimeBid1 = 0; // Суммарное время на длительный SYMBOL_BID long TimeBid2 = 0; // Суммарное время на длительный GetBid() const bool Init = EventSetTimer(10) && GetBid(); // Будем выводить статистику каждый 10 секунд. void OnTimer() { // На сколько отстает один вариант от другого по времени выполнения. Alert(TOSTRING(TimeBid1 - TimeBid2) + " mcs." + TOSTRING(TimeBid1) + TOSTRING(TimeBid2)); } void OnTick() { const uint StartTime = GetTickCount(); // return; while (!IsStopped() && (GetTickCount() - StartTime < 10000)) { MACROS(Bid1, SymbolInfoDouble(_Symbol, SYMBOL_BID)) MACROS(Bid2, GetBid()) // if (Bid1 != Bid2) // Alert("Error!" + TOSTRING(Bid1) + TOSTRING(Bid2)); // Sleep(0); // Специально убрал. } } このEAでは、2つの方法で現在のシンボルのビッド価格を取得します。それぞれについて、実行時間が長い場合の実行時間を集計している。そして、両者の違いを示す。 6/8 エージェントを搭載。そして、RannForex-Serverの デモで6つのチャート（異なるシンボル）でこのEAを実行しました。結果 2020.10.26 16:10:40.596 Test9 (EURNZD,H1) Alert: , TimeBid1-TimeBid2 = 236507295 mcs., TimeBid1 = 246491044, TimeBid2 = 9983749 2020.10.26 16:10:42.596 Test9 (CAC40,H1) Alert: , TimeBid1-TimeBid2 = 235249710 mcs., TimeBid1 = 241768964, TimeBid2 = 6519254 2020.10.26 16:10:44.267 Test9 (DAX30,H1) Alert: , TimeBid1-TimeBid2 = 243552816 mcs., TimeBid1 = 253424672, TimeBid2 = 9871856 2020.10.26 16:10:44.382 Test9 (DJI30,H1) Alert: , TimeBid1-TimeBid2 = 265778370 mcs., TimeBid1 = 272279313, TimeBid2 = 6500943 2020.10.26 16:10:44.623 Test9 (ASX200,H1) Alert: , TimeBid1-TimeBid2 = 210921561 mcs., TimeBid1 = 219901110, TimeBid2 = 8979549 2020.10.26 16:10:44.732 Test9 (FTSE100,H1) Alert: , TimeBid1-TimeBid2 = 226824499 mcs., TimeBid1 = 235809635, TimeBid2 = 8985136 SYMBOL_BIDの総実行時間（TimeBid1）は、代替のビッド価格を得るために（TimeBid2）悲惨なほど負けていることが完全に証明されているのです。 この松葉杖型の現在値取得方法は、MQL5のメイン機能そのものの性能に勝っている。この証明に賛成ですか？ この雄弁な松葉杖をもっと前に考えていればよかった。 ZZZY EAが動作するためには、アルゴ取引を許可する必要があります。そのため、デモ口座での運用にとどめてください。 Andrey Khatimlianskii 2020.10.26 14:45 #592 fxsaber:このEAでは、2つの方法で現在のシンボルのビッド価格を取得します。 POSITION_PRICE_CURRENTが スナップされた？ では、何と比較するのか？最後に保存された(いつ？)価格を取得することと、端末に知られている最後の価格を取得すること？ まあと8コアのうち6コくらいは素直に言ってくれました。なぜそのような テストをするのか。 Anton 2020.10.26 15:10 #593 fxsaber:このコードは、作者が問題を理解していないことを示しています。 あなたの発言は、あなたが明白なことを見ようとしないことを証明しています。 このコードでは、"SymbolInfoTick braking "が存在しないことがわかります。 多かれ少なかれ、最新のハードウェアでは、SymbolInfoTickのランタイムは1マイクロ秒未満です。 このExpert Advisorは、現在のシンボルのBid価格を2つの方法で取得します。それぞれについて、実行時間が長い場合の実行時間を集計している。そして、その差を見せつける。 6/8 エージェントを搭載。そして、RannForex-Serverの デモで6つのチャート（異なるシンボル）でこのEAを実行しました。結果 SYMBOL_BIDの総実行時間（TimeBid1）は、代替のビッド価格を得るために（TimeBid2）悲惨なほど負けていることが完全に証明されているのです。 この松葉杖型の現在値取得方法は、MQL5のメイン機能そのものの性能に勝っている。この証明に賛成ですか？ この雄弁な松葉杖をもっと前に考えていればよかった。 ZZZY EAは、アルゴ取引ができるようにする必要があります。そのため、デモ口座のみでの運用が有効な場合があります。 いや、それは証拠にはならない。真面目にやってはいけない、絶対に不潔なテスト。 詳細は省きますが、GetMicrosecondCount()を使って再び1回の呼び出しでタイミングをとっていること、バックグラウンドで4カーネルCPUで「Loaded 6/8 Agents」を使っていることです。 この方法でも「x++」実行時のイマジナリーブレーキを見つけることが可能であることは、すでに上記で明確に示しました。 SymbolInfoTickブレーキ」についてのあなたの発言は、私のコードによって初歩的にチェックされ、反論されています、非常にシンプルで明白です。 SymbolInfoTickのオリジナルの実装は非常に高速でしたが、マルチスレッドに負荷がかかると個々のスレッドで散発的な実行時間の スパイクが発生することがありました。 最新のビルドでは、この欠点もありません。 実装を見て、さまざまなモードでプロファイルできるなど、自分の言っていることを正確に理解している人と議論を続けるのは、ただただすごいことです。 "牡蠣やココナッツの味は、食べた人と議論しよう "ということです。 fxsaber 2020.10.26 16:46 #594 Andrey Khatimlianskii:POSITION_PRICE_CURRENTが スナップされた？ いいえ、MT4Ordersはポジションを置くためにのみ使用されます。 では、何と比較するのか？最後に保存された価格の取得（いつ） vs. 端末が知っている最後の価格の取得？ Market Watchから価格を取得する期間とポジションを比較しています。もちろん価格も一致している。 そして、8コアのうち6コアが直接言った。なぜそのような テストをするのか。 ただ、盲人にも問題があることがわかるように。Bid-priceがポジションによってスローダウンしないのに、SymbolInfoTickが恐ろしく遅れるのはナンセンスです。 このMQの壁は、フォーラムユーザーのサポートがないと乗り越えられないような気がしています。コードは短いので、専門家ならすぐに理解できるはずです。欠点がないんです。マーケットウォッチよりポジションの方が、価格の取得が早いことがよくわかる。どうしてMQは、この当たり前のことに気づかないのだろう--私には理解できない。 fxsaber 2020.10.26 16:53 #595 Anton:あなたの発言は、あなたが明白なことを見ようとしないことを証明しています。 このコードでは、"SymbolInfoTick braking "が存在しないことがわかります。多かれ少なかれ、最新のハードウェアでは、SymbolInfoTickの実行時間は1マイクロ秒を超えることはありません。 いや、証明にはならない。絶対にまともに受けられない雑なテスト。詳細は省きますが、GetMicrosecondCount()による1回の呼び出しの時間を、4コアCPUで「Loaded 6/8 Agents」のバックグラウンドで再度計測しているという事実で十分です。この方法でも「x++」実行時のイマジナリーブレーキを見つけることが可能であることは、すでに上記で明確に示しました。SymbolInfoTickブレーキ」についてのあなたの発言は、私のコードによって初歩的にチェックされ、反論されています、非常にシンプルで明白です。 SymbolInfoTickのオリジナルの実装は非常に高速でしたが、マルチスレッドに負荷がかかると個々のスレッドで散発的な実行時間の スパイクが発生することがありました。最新のビルドでは、この欠点もありません。実装を見て、さまざまなモードでプロファイルできるなど、自分の言っていることを正確に理解している人と議論を続けるのは、ただただすごいことです。"牡蠣やココナッツの味は、食べた人と議論しよう "ということです。 コードを見てないんですね。私は無能を信じない。 if (Interval##A > 100) \ Time##A += (long)Interval##A; 実行が100μs以上続いた場合のみ、カウントされる条件です。小さな値だと思ったら、一桁長くしてください。効果は同じです。 比較する両機能は全く同じ条件である。一方はエンドブレーキングで、もう一方はそうではありません。コードが何を測定しているのか、もう一度よく見てみましょう。 現時点では、戦闘用EAのSymbolInfoTickを提案された松葉杖で置き換えると、現在の価格の取得に関連するほとんどすべてのラグを取り除くことができます。妄想ですが、残念ながらそうなっています。 HI OnTickのwhileに注意してください。OnTickが受理された後に来たティックを意図的にキャッチするように作られているのです。コードはいきなり書かれたものではありません。理想的な条件下で病院の平均気温を測定する、完全に人工的なフォーサイクルではありません。 Maxim Dmitrievsky 2020.10.26 17:01 #596 fxsaber:このMQの壁は、フォーラムのメンバーのサポートなしには乗り切れないと感じています。コードは短いので、プロでもすぐに分かるはずです。そこに欠点はない。マーケットウォッチよりも、ポジションを通した価格の方が、はるかに速く取得できることがよくわかります。どうしてMQは当たり前のことがわからないのだろう--。コードにエラーはないので、SymbolInfoTickはオープンポジションの 価格を取得するよりも遅いです 価格とポジションがこんなに違うとは思いませんでした。 Igor Makanu 2020.10.26 17:13 #597 fxsaber:ただ、目の見えない人でも問題があることがわかるように。まあ、Bid price through positionは遅くないのに、SymbolInfoTickがとんでもなくラグいのはナンセンスですが。 シンボルインフォティックの テストは、市場概要に1つのシンボルしかない場合と、数十のシンボルがある場合で、1つのシンボルを要求する場合、あなたの例のように試してみてください。 サーバーがトラフィックを圧縮している可能性が高く、SymbolInfoTickがデータを解凍する際にこのような断続的な遅延が発生します。 すなわち、キャラクターが多いと、テスト時間の落ち込みがさらに頻繁になったり、深くなったりします。 ということで、もしこれが本当なら、アーキテクチャを全部やり直すことになるのですが......。ぎもんし fxsaber 2020.10.26 18:13 #598 Igor Makanu:シンボルインフォティックのテストは、市場概要に1つのシンボルしかない場合と、数十のシンボルがある場合で、1つのツールに依頼することを試してみてください。サーバーが圧縮されたトラフィックを送信している可能性が高く、データを解凍する際にSymbolInfoTickが断続的にスローダウンしています。つまり、シンボルの数が多い場合、テスト時間の落ち込みがさらに頻繁になったり、深くなったりするのです。 この仮説は、Market Watchの価格がtumblrの価格より遅れている（またはその逆）場合を指して いる。しかし、ここまでは、Terminal内部でのSymbolInfoTick自体の制動についての話であり、価格の関連性の問題には触れていない。 Andrey Khatimlianskii 2020.10.26 18:26 #599 fxsaber:比較される2つの機能は、まったく同じ条件である。 少なくとも、SymbolInfoDoubleの後にGetBidが呼ばれる。入れ替えても、結果は同じでしょうか？ POSITION_PRICE_CURRENT は保存された価格を取得し、新しい価格を取得しないような気がするのですが、どうでしょうか？ それから、80％負荷のCPUでテストする意味はないと思います。必要な機能ではなく、巻き上げによるCPU性能やリソース配分をテストしているのです。 fxsaber 2020.10.26 20:32 #600 Andrey Khatimlianskii:少なくとも、SymbolInfoDoubleの後にGetBidが呼ばれます。入れ替えても、結果は同じでしょうか？ 出版前に実験してみました。いいえ、そんなことはありません。 POSITION_PRICE_CURRENT は保存された価格を取得し、新しい価格を取得しないような気がするのですが、どうでしょうか？ そこがポイントで、MQL-programはターミナルに来た最後の価格を必要としているのであって、他の何かではありません。Terminalにティックが入ると、すべてのポジション/注文テーブルが自動的に更新されます。 まあ、そしてまた、80％負荷のCPUでテストする意味はないと思います。必要な機能ではなく、CPUの性能とリソースの割り当てを巻き取りでテストしているのです。 主な条件は、両機能の環境が同一であることです。不一致の可視化については、CPU負荷がより顕著な要因となっています。 20個のEAが並行してSymbolInfoTickを同時に呼び出すことがあり、その時はミリ秒単位で負荷がかかりラグが発生します。私は、問題がすぐにわかるように、明示的に行うことを提案しただけです。 ここでも、両機能のテスト条件は同じです。事実です。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム MT5とスピードの関係 fxsaber, 2020.10.26 17:53 現時点では、戦闘用EAのSymbolInfoTickを提案した松葉杖に 置き換えることで、現在価格の取得に関連するブレーキをほとんどすべて取り除く ことができます。妄想ですが、残念ながらそうなっています。 1...535455565758596061626364656667...94 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
テストコード
このコードは、作者が問題を理解していないことを示しています。
このEAでは、2つの方法で現在のシンボルのビッド価格を取得します。それぞれについて、実行時間が長い場合の実行時間を集計している。そして、両者の違いを示す。
6/8 エージェントを搭載。そして、RannForex-Serverの デモで6つのチャート（異なるシンボル）でこのEAを実行しました。結果
SYMBOL_BIDの総実行時間（TimeBid1）は、代替のビッド価格を得るために（TimeBid2）悲惨なほど負けていることが完全に証明されているのです。
この松葉杖型の現在値取得方法は、MQL5のメイン機能そのものの性能に勝っている。この証明に賛成ですか？
この雄弁な松葉杖をもっと前に考えていればよかった。
ZZZY EAが動作するためには、アルゴ取引を許可する必要があります。そのため、デモ口座での運用にとどめてください。
このEAでは、2つの方法で現在のシンボルのビッド価格を取得します。
POSITION_PRICE_CURRENTが スナップされた？
では、何と比較するのか？最後に保存された(いつ？)価格を取得することと、端末に知られている最後の価格を取得すること？
まあと8コアのうち6コくらいは素直に言ってくれました。なぜそのような テストをするのか。
このコードは、作者が問題を理解していないことを示しています。
あなたの発言は、あなたが明白なことを見ようとしないことを証明しています。
このコードでは、"SymbolInfoTick braking "が存在しないことがわかります。
多かれ少なかれ、最新のハードウェアでは、SymbolInfoTickのランタイムは1マイクロ秒未満です。
このExpert Advisorは、現在のシンボルのBid価格を2つの方法で取得します。それぞれについて、実行時間が長い場合の実行時間を集計している。そして、その差を見せつける。
6/8 エージェントを搭載。そして、RannForex-Serverの デモで6つのチャート（異なるシンボル）でこのEAを実行しました。結果
SYMBOL_BIDの総実行時間（TimeBid1）は、代替のビッド価格を得るために（TimeBid2）悲惨なほど負けていることが完全に証明されているのです。
この松葉杖型の現在値取得方法は、MQL5のメイン機能そのものの性能に勝っている。この証明に賛成ですか？
この雄弁な松葉杖をもっと前に考えていればよかった。
ZZZY EAは、アルゴ取引ができるようにする必要があります。そのため、デモ口座のみでの運用が有効な場合があります。
いや、それは証拠にはならない。真面目にやってはいけない、絶対に不潔なテスト。
詳細は省きますが、GetMicrosecondCount()を使って再び1回の呼び出しでタイミングをとっていること、バックグラウンドで4カーネルCPUで「Loaded 6/8 Agents」を使っていることです。
この方法でも「x++」実行時のイマジナリーブレーキを見つけることが可能であることは、すでに上記で明確に示しました。
SymbolInfoTickブレーキ」についてのあなたの発言は、私のコードによって初歩的にチェックされ、反論されています、非常にシンプルで明白です。
SymbolInfoTickのオリジナルの実装は非常に高速でしたが、マルチスレッドに負荷がかかると個々のスレッドで散発的な実行時間の スパイクが発生することがありました。
最新のビルドでは、この欠点もありません。
実装を見て、さまざまなモードでプロファイルできるなど、自分の言っていることを正確に理解している人と議論を続けるのは、ただただすごいことです。
"牡蠣やココナッツの味は、食べた人と議論しよう "ということです。
POSITION_PRICE_CURRENTが スナップされた？
いいえ、MT4Ordersはポジションを置くためにのみ使用されます。
では、何と比較するのか？最後に保存された価格の取得（いつ） vs. 端末が知っている最後の価格の取得？
Market Watchから価格を取得する期間とポジションを比較しています。もちろん価格も一致している。
そして、8コアのうち6コアが直接言った。なぜそのような テストをするのか。
ただ、盲人にも問題があることがわかるように。Bid-priceがポジションによってスローダウンしないのに、SymbolInfoTickが恐ろしく遅れるのはナンセンスです。
このMQの壁は、フォーラムユーザーのサポートがないと乗り越えられないような気がしています。コードは短いので、専門家ならすぐに理解できるはずです。欠点がないんです。マーケットウォッチよりポジションの方が、価格の取得が早いことがよくわかる。どうしてMQは、この当たり前のことに気づかないのだろう--私には理解できない。
あなたの発言は、あなたが明白なことを見ようとしないことを証明しています。
このコードでは、"SymbolInfoTick braking "が存在しないことがわかります。
多かれ少なかれ、最新のハードウェアでは、SymbolInfoTickの実行時間は1マイクロ秒を超えることはありません。
いや、証明にはならない。絶対にまともに受けられない雑なテスト。
詳細は省きますが、GetMicrosecondCount()による1回の呼び出しの時間を、4コアCPUで「Loaded 6/8 Agents」のバックグラウンドで再度計測しているという事実で十分です。
この方法でも「x++」実行時のイマジナリーブレーキを見つけることが可能であることは、すでに上記で明確に示しました。
SymbolInfoTickブレーキ」についてのあなたの発言は、私のコードによって初歩的にチェックされ、反論されています、非常にシンプルで明白です。
SymbolInfoTickのオリジナルの実装は非常に高速でしたが、マルチスレッドに負荷がかかると個々のスレッドで散発的な実行時間の スパイクが発生することがありました。
最新のビルドでは、この欠点もありません。
実装を見て、さまざまなモードでプロファイルできるなど、自分の言っていることを正確に理解している人と議論を続けるのは、ただただすごいことです。
"牡蠣やココナッツの味は、食べた人と議論しよう "ということです。
コードを見てないんですね。私は無能を信じない。
実行が100μs以上続いた場合のみ、カウントされる条件です。小さな値だと思ったら、一桁長くしてください。効果は同じです。
比較する両機能は全く同じ条件である。一方はエンドブレーキングで、もう一方はそうではありません。コードが何を測定しているのか、もう一度よく見てみましょう。
現時点では、戦闘用EAのSymbolInfoTickを提案された松葉杖で置き換えると、現在の価格の取得に関連するほとんどすべてのラグを取り除くことができます。妄想ですが、残念ながらそうなっています。
HI OnTickのwhileに注意してください。OnTickが受理された後に来たティックを意図的にキャッチするように作られているのです。コードはいきなり書かれたものではありません。理想的な条件下で病院の平均気温を測定する、完全に人工的なフォーサイクルではありません。
このMQの壁は、フォーラムのメンバーのサポートなしには乗り切れないと感じています。コードは短いので、プロでもすぐに分かるはずです。そこに欠点はない。マーケットウォッチよりも、ポジションを通した価格の方が、はるかに速く取得できることがよくわかります。どうしてMQは当たり前のことがわからないのだろう--。
コードにエラーはないので、SymbolInfoTickはオープンポジションの 価格を取得するよりも遅いです
価格とポジションがこんなに違うとは思いませんでした。ただ、目の見えない人でも問題があることがわかるように。まあ、Bid price through positionは遅くないのに、SymbolInfoTickがとんでもなくラグいのはナンセンスですが。
シンボルインフォティックの テストは、市場概要に1つのシンボルしかない場合と、数十のシンボルがある場合で、1つのシンボルを要求する場合、あなたの例のように試してみてください。
サーバーがトラフィックを圧縮している可能性が高く、SymbolInfoTickがデータを解凍する際にこのような断続的な遅延が発生します。
すなわち、キャラクターが多いと、テスト時間の落ち込みがさらに頻繁になったり、深くなったりします。
ということで、もしこれが本当なら、アーキテクチャを全部やり直すことになるのですが......。ぎもんし
シンボルインフォティックのテストは、市場概要に1つのシンボルしかない場合と、数十のシンボルがある場合で、1つのツールに依頼することを試してみてください。
サーバーが圧縮されたトラフィックを送信している可能性が高く、データを解凍する際にSymbolInfoTickが断続的にスローダウンしています。
つまり、シンボルの数が多い場合、テスト時間の落ち込みがさらに頻繁になったり、深くなったりするのです。
この仮説は、Market Watchの価格がtumblrの価格より遅れている（またはその逆）場合を指して いる。しかし、ここまでは、Terminal内部でのSymbolInfoTick自体の制動についての話であり、価格の関連性の問題には触れていない。
比較される2つの機能は、まったく同じ条件である。
少なくとも、SymbolInfoDoubleの後にGetBidが呼ばれる。入れ替えても、結果は同じでしょうか？
POSITION_PRICE_CURRENT は保存された価格を取得し、新しい価格を取得しないような気がするのですが、どうでしょうか？
それから、80％負荷のCPUでテストする意味はないと思います。必要な機能ではなく、巻き上げによるCPU性能やリソース配分をテストしているのです。
少なくとも、SymbolInfoDoubleの後にGetBidが呼ばれます。入れ替えても、結果は同じでしょうか？
出版前に実験してみました。いいえ、そんなことはありません。
POSITION_PRICE_CURRENT は保存された価格を取得し、新しい価格を取得しないような気がするのですが、どうでしょうか？
そこがポイントで、MQL-programはターミナルに来た最後の価格を必要としているのであって、他の何かではありません。Terminalにティックが入ると、すべてのポジション/注文テーブルが自動的に更新されます。
まあ、そしてまた、80％負荷のCPUでテストする意味はないと思います。必要な機能ではなく、CPUの性能とリソースの割り当てを巻き取りでテストしているのです。
主な条件は、両機能の環境が同一であることです。不一致の可視化については、CPU負荷がより顕著な要因となっています。
20個のEAが並行してSymbolInfoTickを同時に呼び出すことがあり、その時はミリ秒単位で負荷がかかりラグが発生します。私は、問題がすぐにわかるように、明示的に行うことを提案しただけです。
ここでも、両機能のテスト条件は同じです。事実です。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
MT5とスピードの関係
fxsaber, 2020.10.26 17:53
現時点では、戦闘用EAのSymbolInfoTickを提案した松葉杖に 置き換えることで、現在価格の取得に関連するブレーキをほとんどすべて取り除く ことができます。妄想ですが、残念ながらそうなっています。