キャンバスがカッコいい! - ページ 49 1...424344454647484950515253545556...93 新しいコメント Nikolai Semko 2020.01.18 17:24 #481 Aleksey Vyazmikin: さて、私が理解していないのは、グラフ上でハイライトされた部分（折れ曲がった曲線でハイライトされている部分）が、どのようにデータ配列と関連付けられているかということです。それ以外のデータそのものについては問わない。 絵そのものが既成の価値観で形成されているのに、なぜ絵からやるのか。これらの価値を集めて、好きなように組み立てて、必要なところに送ることができます。 Aleksey Vyazmikin 2020.01.18 17:34 #482 Nikolai Semko: 既成の価値観から自分でイメージを形成できるのに、なぜイメージからやるのか。これらの値を集めて、好きなようにコンパイルして、必要なところに送ればいいのです。 ポイントは、空間の安定した層の形で指標の数を見ていることです。 あなたは、指標を切り替え、座標系を保存する必要があります - 例えば、あなたは利益によって構築された、選択した領域は、指標の数によって収益性などで構築し、結果としてあなたが仕事をする島を得た。 Nikolai Semko 2020.01.18 17:50 #483 Aleksey Vyazmikin: ポイントは、指標を切り替えながら、座標系を維持したまま、空間の安定したレイヤーという形で多くの指標を見ていくことです。例えば、利益で建て、地域を選び、収益性で建て、というように、多くの指標によって、最終的に、さらに働くことに意味のある島を手に入れることができたのです。 私はあなたを理解していません。 もし、これらの島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよいのです。 なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。 Aleksey Vyazmikin 2020.01.18 18:00 #484 Nikolai Semko: あなたのことがわからないんです。 もし、この島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよく、あとはこれらの配列を分析するのみです。 なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。 問題は、選定結果の可視化ではなく、適切なサイトを選定するためのツールです。 問題は、選択結果のビジュアル化 ではなく、適切な領域を選択するためのツールについてです。例えば、計算系（座標系）の異なる対数面積の選択を自動化する方法は、私にはほとんど想像がつきません。 Artyom Trishkin 2020.01.18 18:01 #485 Nikolai Semko: あなたのことがわからないんです。 もし、この島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよく、あとはその配列を解析するテクニックの問題である。 なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。 3Dグラフィックスのデータセクションを手動で選択することを意味すると思われます。 Aleksey Vyazmikin 2020.01.18 18:09 #486 Artyom Trishkin: おそらく、3Dグラフィックスのデータの一部を手動でハイライトすることを意味します。 そうですね。 Nikolai Semko 2020.01.18 18:39 #487 Aleksey Vyazmikin: そうですね。 それなら、まず思い浮かぶのは、マウスのホイールで3次元を移動することでしょう。やろうと思えば、何でもできるんです。 Dmitry Fedoseev 2020.01.18 19:15 #488 絵を描くとき、どの画素がどこから来るのかがわかる。絵を描くときは、2次元に配列された構造を埋めていく。配列の次元は画素の座標に対応し，構造体は目的のデータまたは目的のデータへの参照を含む． Nikolai Semko 2020.01.18 19:24 #489 Dmitry Fedoseev: 絵を描くとき、どの画素がどこから来るかわかるようにする。絵を描くときは、2次元に配列された構造を埋めていく。配列の次元はピクセル座標に対応し、構造体は必要なデータまたは必要なデータへの参照を含む。 また、ダイバーシティが実装されておらず（1つのピクセルが複数のオブジェクトに属することがある）、オブジェクトがお互いの下になく、アクセスする必要がある場合にも可能である。どう考えても、3Dマウスは必要です。せめてソフトウエアマウスだけでも。 Maxim Kuznetsov 2020.01.18 20:07 #490 Nikolai Semko: https://www.mql5.com/en/code/27662 スピードとコードサイズに気を配る しかも、これはすべてDirect Xなしでの話です。 熱狂的なネズミたちは、今頃はみんなキーキー言っているのでしょうか？ 座標とスケール "r "の計算が誤っていることに気づきました。 しかし、正しく、読みやすくするためには、カレンダー（バーではなく、リアルタイム）と、半径について考えるための何かが必要です - 偏差は読みやすくありません。 またはrはログスケールか何かが必要です。 1...424344454647484950515253545556...93 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
さて、私が理解していないのは、グラフ上でハイライトされた部分（折れ曲がった曲線でハイライトされている部分）が、どのようにデータ配列と関連付けられているかということです。それ以外のデータそのものについては問わない。
絵そのものが既成の価値観で形成されているのに、なぜ絵からやるのか。これらの価値を集めて、好きなように組み立てて、必要なところに送ることができます。
既成の価値観から自分でイメージを形成できるのに、なぜイメージからやるのか。これらの値を集めて、好きなようにコンパイルして、必要なところに送ればいいのです。
ポイントは、空間の安定した層の形で指標の数を見ていることです。 あなたは、指標を切り替え、座標系を保存する必要があります - 例えば、あなたは利益によって構築された、選択した領域は、指標の数によって収益性などで構築し、結果としてあなたが仕事をする島を得た。
ポイントは、指標を切り替えながら、座標系を維持したまま、空間の安定したレイヤーという形で多くの指標を見ていくことです。例えば、利益で建て、地域を選び、収益性で建て、というように、多くの指標によって、最終的に、さらに働くことに意味のある島を手に入れることができたのです。
私はあなたを理解していません。
もし、これらの島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよいのです。
なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。
あなたのことがわからないんです。
もし、この島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよく、あとはこれらの配列を分析するのみです。
なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。
問題は、選定結果の可視化ではなく、適切なサイトを選定するためのツールです。
問題は、選択結果のビジュアル化 ではなく、適切な領域を選択するためのツールについてです。例えば、計算系（座標系）の異なる対数面積の選択を自動化する方法は、私にはほとんど想像がつきません。
あなたのことがわからないんです。
もし、この島を見つけることをアルゴリズム化したいのであれば、アルゴリズムは可視化を必要とせず、n次元空間の点またはオブジェクトの配列があればよく、あとはその配列を解析するテクニックの問題である。
なぜなら、私たちの脳のパターン認識システムは、物体を視覚化することに基づいており、4次元以上の空間では視覚化が必要だからです。
おそらく、3Dグラフィックスのデータの一部を手動でハイライトすることを意味します。
そうですね。
そうですね。
絵を描くとき、どの画素がどこから来るかわかるようにする。絵を描くときは、2次元に配列された構造を埋めていく。配列の次元はピクセル座標に対応し、構造体は必要なデータまたは必要なデータへの参照を含む。
https://www.mql5.com/en/code/27662
スピードとコードサイズに気を配る
しかも、これはすべてDirect Xなしでの話です。
熱狂的なネズミたちは、今頃はみんなキーキー言っているのでしょうか？
座標とスケール "r "の計算が誤っていることに気づきました。
しかし、正しく、読みやすくするためには、カレンダー（バーではなく、リアルタイム）と、半径について考えるための何かが必要です - 偏差は読みやすくありません。
またはrはログスケールか何かが必要です。