トレーディングにおける機械学習：理論、モデル、実践、アルゴトレーディング - ページ 211 1...204205206207208209210211212213214215216217218...3399 新しいコメント Alexey Burnakov 2016.11.14 14:07 #2101 レナト・ファットフーリン1) 残念ながら、あなたは質問を不完全に言い表し、吟味されていない、簡潔で丁寧な「関係ない」という答えを得たのです。あなたは、質問自体にそれを定式化することで、「そう合意した／合意した」という答えを望んでいたのです。しかし、ダンカンは一度目は「正しいこと」で逃げ、二度目はそれを繰り返した。2）Rでの精度の確認が取れず、なぜ他のパッケージで結果が違うのかの回答が得られなかったこと。なぜ他のパッケージでは答えが違うのか」という問いの解析の方が重要であり、トピックを明らかにすることが可能です。3）私たちの立場 выражение для dgamma(x)= 1/(s^a Gamma(a)) x^(a-1) e^-(x/s) for x ≥ 0, a > 0 and s > 0 в точке 0 является неопределенным.R では、この点を計算に含めても、dgamma(0,0.5,1) のように無限大であっても限界値を取ることができると考えています。しかし、ゼロ点で無限大を与えて確率を計算すると、dgammaからの積分はすべて形式的に無限大になり、この論理によってpgammaはすべてのxの値に対して無限大に等しくなるはずである。 しかし、これは、すべての値が有限であることが判明したpgammaの結果と矛盾している。点x=0では密度が0であると仮定しているので、正しい。1）はい、詳しい回答は得られませんでした。まとめたものの...。自分の意見を押し付けているわけではなく、私も正直言って議論に疲れているんです。この方の言葉は、私たちの最初のメッセージとほぼ同じであったことに注目していただきたい。極点での密度をどう決めるかは重要ではなく、積分を正しく計算することが重要です。厳密には、点ゼロにおけるガンマ分布の密度は不定であることを宣言する。そして、右の極限を取ると、密度は1になる。このことから、「Rの計算ミス」というのは正しくないのではないかと考えています。より正確には、次数0の表現に等しいと考えるよりも、という慣習の問題である。ガンマ分布の密度を点ゼロでゼロに等しくすることは、いかなる条件下でも行われないようです。2）私の方からは、正確さについての話は一切ありませんでした。点ゼロの密度は精度の問題ではなく、関数の結果としてどのように導き出すか、つまり非収束（NaN）か極限かゼロに等しいか、ということです。要は、積分の計算には関係ないのです。3）訂正された記事の本文を読み直しました。そして、dgammaの挙動をエラーと見なさないことにしたのはよかったと思います。しかし、この:dgammaからのすべての積分は形式的に無限大になり、この論理によってpgammaはxのすべての値に対して無限大に等しくなるはずです。奇遇ですね、レナートさん。pgammaは原理的に無限大にはならない。なぜなら、ingegralは上から値1によって束縛されているからである。正規分布を例にとるとinf,+inf]上で定義される。この区間全体で分布関数の積分＝1。しかし、無限に大きなサポート上の密度の和（積分）は、なぜか無限和にならないことが判明した。ただし、どの領域でもキープ全体の密度は !=0 である。また、dgmammaの場合、その密度== infの点x==0は（ところで、この点で密度が1に傾く場合を考慮しておらず、ここから積分についてどんな結論を出すのか・・・）どのくらいの頻度で発生するのでしょうか。それはないと言い切れます。任意の連続分布において、ある確率変数が任意の点== 0で実現する確率...統計学者なら誰でも知っていることだ。この密度は、xの周りの無限小の領域に対する確率の近似値であると考えられている。 このことから、極点での密度がどんなに大きくても、全体のイングラルへの影響は0であることがわかる。考えてみてください...考えすぎなのでは？) でも、議論して解決するつもりはない。いつか気づいて、ダンカンの代わりに自分で答えるかもしれませんね。)ありがとうございます。 Renat Fatkhullin 2016.11.14 14:22 #2102 Rは素晴らしいシステムで、個人的にはMetaTrader/MQLが「複雑な計算を簡単に、今すぐに」という本当のニーズからいかにかけ離れていたかに目を開かされました。私たち（C++開発者）は、「自分で何でもできるから、低レベルのベースと計算のスピードをあげる」というアプローチを血肉にしています。MQL5は64bitで素晴らしいパフォーマンスを発揮します。私自身がRに取り組み始めたとき、1行にできるだけ多くの強力な関数が必要であり、一般的な研究ができるようにする必要があることに気づきました。 そこで、急転直下、MetaTrader 5のバージョンアップに着手しました。以前書き直した数学ライブラリ Alglib と Fuzzy をユニットテスト付きで標準提供。Rから統計関数のアナログを開発し、テストを実行し、テストでカバーする。作業はまだ進行中であり、ライブラリは拡張中であるR の plot のアナログとして Graphics ライブラリの最初のベータ版を開発した。表形式データを扱えるようにターミナル出力ウィンドウのインターフェース変更、出力方向の変更、不要なカラムの削除、Expert Advisor 出力ウィンドウのフォントを等幅に変更した。構造体を含む配列の自動印刷を行う強力なArrayPrint 機能が追加されました。配列のディスクへの保存/読み込みを高速に行うためのFileLoad/FileSave 関数を追加しました。 もちろん、まだ道半ばですが、正しい努力のベクトルはすでに明確です。 Dr. Trader 2016.11.14 14:22 #2103 7ステップの統合は確かに物足りない。これが1,000本。> pgamma(0.8, 0.5, 1)[1] 0.7940968#а теперь велосипедное интегрирование:> integration_steps <- seq(0, 0.8, length.out=1001)> integration_result <- 0> for(i in 2:length(integration_steps)){+ integration_result <- integration_result + dgamma(integration_steps[i], 0.5, 1) * (integration_steps[i] - integration_steps[i-1])+ }> integration_result[1] 0.7709089#погрешность ~0.02, но тут способ уже проще некуда, и так сойдёт :) . Бесконечность при x=0 не мешает. Machine learning in trading: Universal MA Cross EA ユニバーサルMAクロスEA Renat Fatkhullin 2016.11.14 14:26 #2104 アレクセイ・ブルナコフ1）はい、詳しい回答は得られませんでした。総括していたものの...。自分の意見を押し付けているわけではなく、私も正直言って議論に疲れているんです。この方の言葉が、私たちの当初のメッセージとほぼ同じであったことに注目していただきたいと思います。詳細や検証もなく、丁寧な対応でした。しかも、その答えがWolfram AlphaとMatlabで一致していないのが問題でした。横道にそれる必要はない - 根本的な疑問は明確に述べられた。 Quantum 2016.11.14 14:28 #2105 Dr.トレーダー #погрешность ~0.02, но тут способ уже велосипедней некуда, и так сойдёт :) . Бесконечность при x=0 не мешает.関数1/xを0から1まで、境界点を含めて積分し、解析的な計算結果と比較することができます。Wolframは、x=0に特異点があるため、積分は収束しないと言っています。 Dr. Trader 2016.11.14 14:52 #2106 量子力学。関数1/xを0から1まで、境界点を含めて積分し、解析計算の結果と比較することができる。同じコード-7.485471で。Rは76.3342まで行って、それ以上進まない、それは正確な結果ではない、不正解だと言いました。 Wolframはただすぐに、結果は加算されないと言い、何も答えられませんでした。 正解は......わからない、どれくらい？まさか、1/xの積分が求まらないから、dgamma(x)の積分も求まらないということはないでしょうね。2つの関数はx→0+で無限大になりますが、その速さは異なり、その速さが積分を求めることができるかどうかに影響します。 Dr. Trader 2016.11.14 15:06 #2107 関数 -log(x) がある。x->0で無限大に傾きます。マイナスがなくてもできますが、そうすると下に傾いてしまうので、それは困ります。そして、0から1までの積分を持ち、無限大は干渉しない。 Yury Reshetov 2016.11.14 16:31 #2108 レナト・ファットフーリンRは、個人的にはMetaTrader/MQLで「今、複雑な計算をシンプルにわかりやすくしたい」という本当のニーズからどれだけかけ離れていたかに目を開かされた素晴らしいシステムだと思います。...そこで急転直下、MetaTrader 5のバージョンアップを開始しました。以前書き直した Alglib と Fuzzy math ライブラリを標準搭載し、ユニットテストを網羅したRから統計関数のアナログを開発し、テストを実行し、テストでカバーする。作業はまだ進行中であり、ライブラリは拡張中であるR の plot のアナログとして Graphics ライブラリの最初のベータ版を開発した。表形式のデータを操作できるように、端末の出力ウィンドウのインターフェイスを変更した。出力方向の変更、不要な列の無効化、Expert Advisorの出力ウィンドウのフォントを等幅に変更した。構造体を含む配列の自動印刷を行う強力なArrayPrint 機能が追加されました。ディスク上の配列を素早くロード/アンロードするためのFileLoad/FileSave 関数を追加した。 もちろん、今はスタート地点ですが、努力の正しいベクトルはすでに明確です。Rは、他の多くのプログラミング言語と同様に、配列データ処理のための機能セットを内蔵しているため、MQLと比較して機械学習には圧倒的に便利です。機械学習のサンプルは2次元のデータ配列であることがほとんどなので、配列を扱うための関数が必要だということです。小さい次元の配列として、行と列を別の配列に挿入する。配列の行と列を、より小さいサイズの配列に置き換えること配列から行や列を削除する（例えば，重要でない予測因子や明らかに「外れ値」のある例を選択から削除する）アレイをパーツに分割することで，元のアレイのパーツである2つ以上のアレイを得ることができます（サンプルをトレーニングパーツとテストパーツに分割したり，ウォーリングフォワードなどでより多くのパーツに分割する際に必要です）．均等に分布する配列の行と列をランダムにシャッフルする（それらの、またはサンプルからの他の例が異なる部分に入ることが必要で、できればこれらの部分に均等に分布していることが望ましい）。行や列ごとのデータ処理のための各種機能（行や列ごとの算術平均や分散の計算、行内の最大値や最小値を求めてさらに正規化する等）。などなど。MQLが配列のサンプルを扱うために必要な前述の機能を実装するまでは、機械学習アルゴリズムの開発者の多くは、すでにこのすべてが利用可能な他のプログラミング言語を好むだろう。あるいは、私の記憶が正しければ、便宜上2次元配列を1次元で表現しているAlgLibライブラリの気取らないMLP（1960年代のアルゴリズム）を使うことになるのだろう。もちろん、ランダムな分布の密度を表す関数も必要な機能である。しかし、このような関数は機械学習のタスクでは必ずしも必要ではなく、全く使われないタスクもある。しかし、多次元配列と同様にサンプルを使った操作は、機械学習アルゴリズムの実装では、どんなタスクでも欠かすことができない。もちろん、些細なCWRから既知の正規化データを学習するためのグリッドを学習するタスクは別である。 Vladimir Perervenko 2016.11.14 16:34 #2109 レナト・ファットフーリンRは素晴らしいシステムで、個人的にはMetaTrader/MQLが「複雑な計算を簡単に、今すぐに」という本当のニーズからいかにかけ離れていたかに目を開かされました。私たち（C++開発者）は、「自分で何でもできるから、低レベルのベースと計算のスピードをあげる」というアプローチを血肉にしています。MQL5は64bitで素晴らしいパフォーマンスを発揮します。私自身がRに取り組み始めたとき、1行にできるだけ多くの強力な関数が必要であり、一般的な研究ができるようにする必要があることに気づきました。 そこで、急転直下、MetaTrader 5のバージョンアップに着手しました。以前書き直した数学ライブラリ Alglib と Fuzzy をユニットテスト付きで標準提供。Rから統計関数のアナログを開発し、テストを実行し、テストでカバーする。作業はまだ進行中であり、ライブラリは拡張中であるR の plot のアナログとして Graphics ライブラリの最初のベータ版を開発した。表形式のデータを操作できるように、端末の出力ウィンドウのインターフェイスを変更し始めました。 出力の方向の変更、不要な列の無効化、Expert Advisorの出力ウィンドウのフォントを等幅に変更するなどです。構造体を含む配列の自動印刷を行う強力なArrayPrint 機能が追加されました。配列のディスクへの書き込み/読み込みを高速に行うためのFileLoadと FileSaveを 追加した。 もちろん、まだ道半ばですが、正しい努力のベクトルはすでに明確です。バランスよく、驚くほど客観的にRを評価しています。建設的な議論をした部分は無駄にはならなかった。Rユーザーからのコメントや提案に耳を傾けていますね。私たちもプラットフォームの改良に関心があります。もちろん、まだ始まったばかりですが、いずれにせよ、RワクチンによってMCLは強化されます。がんばってください。 СанСаныч Фоменко 2016.11.14 16:45 #2110 ブルナコフが言っていたコンベンションについて。全く異なる3つのケースを考えてみましょう。1.ゼロに等しい定数で除算する。 Rでは、次のような結果が得られます。> 1/0[1] Inf正しい結果なのでしょうか？インタプリタにとっては、Rを終了させることができないので、この結果は正しいと考えなければならない。コンパイラにとって、この結果は正しい。例外的な状況が発生した場合、プログラムの実行を中断し、この例外的な状況を処理するための制御が行われ、さもなければクラッシュします。その違いにご注目ください2.変数による除算で、ゼロに等しい。> a<-0> 1/a[1] Inf厳密には、このバリエーションは従来のものとは異なります。関数1/aはa=0を除くすべての場所で連続であり、このとき左の極限=-Inf、右の極限=+Infとなる。Rはこれを理解できないが、マイナス無限とプラス無限の違いは、プログラムコードではなく、数学で意味をなすので、受け入れることができる3.二つの無限小の量のゼロへの吸引における分割> sin(a)/a[1] NaNNaNの意味は、私には全く説明がつきません。しかし、Rが制限というものを理解していないことは、2.からも明らかです。これらはプログラミングシステムとしてのRのエラーなのでしょうか？どうだろう。おそらくRのドキュメントにはそのようなニュアンスのことが書かれているはずですが、では、現時点で約13万関数の分散開発でどのように実装すればいいのでしょうか。必要なのか？そこから生まれた議論というのは、どういう意味なのでしょうか。意思決定は陸上で行う。 1.Rを取り込んで、ぶっきらぼうにMKLにコードを転送している。同時に、上記のような変形は、Rの異なる機能において異なる解釈をする可能性があることを認識する必要があります。2.私が述べたケースでどの値を受け入れるか、合意を宣言する（リストは不完全かもしれません）。Rのコードを徹底的にチェックし、我々の設定に合わない場合は、我々の取り決めに従って修正しながらRからMCLに移植しています。この場合、集中開発により、採用された規約を一貫して実施しており、その意味でより良いシステムになっています。 1...204205206207208209210211212213214215216217218...3399 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1) 残念ながら、あなたは質問を不完全に言い表し、吟味されていない、簡潔で丁寧な「関係ない」という答えを得たのです。
あなたは、質問自体にそれを定式化することで、「そう合意した／合意した」という答えを望んでいたのです。しかし、ダンカンは一度目は「正しいこと」で逃げ、二度目はそれを繰り返した。
2）Rでの精度の確認が取れず、なぜ他のパッケージで結果が違うのかの回答が得られなかったこと。なぜ他のパッケージでは答えが違うのか」という問いの解析の方が重要であり、トピックを明らかにすることが可能です。
3）私たちの立場
выражение для dgamma
(x)= 1/(s^a Gamma(a)) x^(a-1) e^-(x/s)
for x ≥ 0, a > 0 and s > 0в точке 0 является неопределенным.
R では、この点を計算に含めても、dgamma(0,0.5,1) のように無限大であっても限界値を取ることができると考えています。
しかし、ゼロ点で無限大を与えて確率を計算すると、dgammaからの積分はすべて形式的に無限大になり、この論理によってpgammaはすべてのxの値に対して無限大に等しくなるはずである。
しかし、これは、すべての値が有限であることが判明したpgammaの結果と矛盾している。点x=0では密度が0であると仮定しているので、正しい。1）はい、詳しい回答は得られませんでした。まとめたものの...。自分の意見を押し付けているわけではなく、私も正直言って議論に疲れているんです。この方の言葉は、私たちの最初のメッセージとほぼ同じであったことに注目していただきたい。極点での密度をどう決めるかは重要ではなく、積分を正しく計算することが重要です。
厳密には、点ゼロにおけるガンマ分布の密度は不定であることを宣言する。そして、右の極限を取ると、密度は1になる。
このことから、「Rの計算ミス」というのは正しくないのではないかと考えています。より正確には、次数0の表現に等しいと考えるよりも、という慣習の問題である。ガンマ分布の密度を点ゼロでゼロに等しくすることは、いかなる条件下でも行われないようです。
2）私の方からは、正確さについての話は一切ありませんでした。点ゼロの密度は精度の問題ではなく、関数の結果としてどのように導き出すか、つまり非収束（NaN）か極限かゼロに等しいか、ということです。要は、積分の計算には関係ないのです。
3）訂正された記事の本文を読み直しました。そして、dgammaの挙動をエラーと見なさないことにしたのはよかったと思います。
しかし、この:
dgammaからのすべての積分は形式的に無限大になり、この論理によってpgammaはxのすべての値に対して無限大に等しくなるはずです。
奇遇ですね、レナートさん。
pgammaは原理的に無限大にはならない。なぜなら、ingegralは上から値1によって束縛されているからである。
正規分布を例にとるとinf,+inf]上で定義される。この区間全体で分布関数の積分＝1。しかし、無限に大きなサポート上の密度の和（積分）は、なぜか無限和にならないことが判明した。ただし、どの領域でもキープ全体の密度は !=0 である。
また、dgmammaの場合、その密度== infの点x==0は（ところで、この点で密度が1に傾く場合を考慮しておらず、ここから積分についてどんな結論を出すのか・・・）どのくらいの頻度で発生するのでしょうか。それはないと言い切れます。任意の連続分布において、ある確率変数が任意の点== 0で実現する確率...統計学者なら誰でも知っていることだ。この密度は、xの周りの無限小の領域に対する確率の近似値であると考えられている。
このことから、極点での密度がどんなに大きくても、全体のイングラルへの影響は0であることがわかる。考えてみてください...
考えすぎなのでは？) でも、議論して解決するつもりはない。いつか気づいて、ダンカンの代わりに自分で答えるかもしれませんね。)
ありがとうございます。
Rは素晴らしいシステムで、個人的にはMetaTrader/MQLが「複雑な計算を簡単に、今すぐに」という本当のニーズからいかにかけ離れていたかに目を開かされました。
私たち（C++開発者）は、「自分で何でもできるから、低レベルのベースと計算のスピードをあげる」というアプローチを血肉にしています。MQL5は64bitで素晴らしいパフォーマンスを発揮します。
私自身がRに取り組み始めたとき、1行にできるだけ多くの強力な関数が必要であり、一般的な研究ができるようにする必要があることに気づきました。
そこで、急転直下、MetaTrader 5のバージョンアップに着手しました。
もちろん、まだ道半ばですが、正しい努力のベクトルはすでに明確です。
7ステップの統合は確かに物足りない。これが1,000本。
[1] 0.7940968
#а теперь велосипедное интегрирование:
> integration_steps <- seq(0, 0.8, length.out=1001)
> integration_result <- 0
> for(i in 2:length(integration_steps)){
+ integration_result <- integration_result + dgamma(integration_steps[i], 0.5, 1) * (integration_steps[i] - integration_steps[i-1])
+ }
> integration_result
[1] 0.7709089
#погрешность ~0.02, но тут способ уже проще некуда, и так сойдёт :) . Бесконечность при x=0 не мешает.
1）はい、詳しい回答は得られませんでした。総括していたものの...。自分の意見を押し付けているわけではなく、私も正直言って議論に疲れているんです。この方の言葉が、私たちの当初のメッセージとほぼ同じであったことに注目していただきたいと思います。
詳細や検証もなく、丁寧な対応でした。しかも、その答えがWolfram AlphaとMatlabで一致していないのが問題でした。
横道にそれる必要はない - 根本的な疑問は明確に述べられた。
#погрешность ~0.02, но тут способ уже велосипедней некуда, и так сойдёт :) . Бесконечность при x=0 не мешает.
関数1/xを0から1まで、境界点を含めて積分し、解析的な計算結果と比較することができます。
Wolframは、x=0に特異点があるため、積分は収束しないと言っています。
関数1/xを0から1まで、境界点を含めて積分し、解析計算の結果と比較することができる。
同じコード-7.485471で。Rは76.3342まで行って、それ以上進まない、それは正確な結果ではない、不正解だと言いました。 Wolframはただすぐに、結果は加算されないと言い、何も答えられませんでした。
正解は......わからない、どれくらい？
まさか、1/xの積分が求まらないから、dgamma(x)の積分も求まらないということはないでしょうね。2つの関数はx→0+で無限大になりますが、その速さは異なり、その速さが積分を求めることができるかどうかに影響します。
関数 -log(x) がある。x->0で無限大に傾きます。マイナスがなくてもできますが、そうすると下に傾いてしまうので、それは困ります。
そして、0から1までの積分を持ち、無限大は干渉しない。
Rは、個人的にはMetaTrader/MQLで「今、複雑な計算をシンプルにわかりやすくしたい」という本当のニーズからどれだけかけ離れていたかに目を開かされた素晴らしいシステムだと思います。
...
そこで急転直下、MetaTrader 5のバージョンアップを開始しました。
もちろん、今はスタート地点ですが、努力の正しいベクトルはすでに明確です。
Rは、他の多くのプログラミング言語と同様に、配列データ処理のための機能セットを内蔵しているため、MQLと比較して機械学習には圧倒的に便利です。機械学習のサンプルは2次元のデータ配列であることがほとんどなので、配列を扱うための関数が必要だということです。
MQLが配列のサンプルを扱うために必要な前述の機能を実装するまでは、機械学習アルゴリズムの開発者の多くは、すでにこのすべてが利用可能な他のプログラミング言語を好むだろう。あるいは、私の記憶が正しければ、便宜上2次元配列を1次元で表現しているAlgLibライブラリの気取らないMLP（1960年代のアルゴリズム）を使うことになるのだろう。
もちろん、ランダムな分布の密度を表す関数も必要な機能である。しかし、このような関数は機械学習のタスクでは必ずしも必要ではなく、全く使われないタスクもある。しかし、多次元配列と同様にサンプルを使った操作は、機械学習アルゴリズムの実装では、どんなタスクでも欠かすことができない。もちろん、些細なCWRから既知の正規化データを学習するためのグリッドを学習するタスクは別である。
Rは素晴らしいシステムで、個人的にはMetaTrader/MQLが「複雑な計算を簡単に、今すぐに」という本当のニーズからいかにかけ離れていたかに目を開かされました。
私たち（C++開発者）は、「自分で何でもできるから、低レベルのベースと計算のスピードをあげる」というアプローチを血肉にしています。MQL5は64bitで素晴らしいパフォーマンスを発揮します。
私自身がRに取り組み始めたとき、1行にできるだけ多くの強力な関数が必要であり、一般的な研究ができるようにする必要があることに気づきました。
そこで、急転直下、MetaTrader 5のバージョンアップに着手しました。
もちろん、まだ道半ばですが、正しい努力のベクトルはすでに明確です。
バランスよく、驚くほど客観的にRを評価しています。
建設的な議論をした部分は無駄にはならなかった。Rユーザーからのコメントや提案に耳を傾けていますね。私たちもプラットフォームの改良に関心があります。
もちろん、まだ始まったばかりですが、いずれにせよ、RワクチンによってMCLは強化されます。
がんばってください。
ブルナコフが言っていたコンベンションについて。
全く異なる3つのケースを考えてみましょう。
1.ゼロに等しい定数で除算する。
Rでは、次のような結果が得られます。
[1] Inf
正しい結果なのでしょうか？
インタプリタにとっては、Rを終了させることができないので、この結果は正しいと考えなければならない。
コンパイラにとって、この結果は正しい。例外的な状況が発生した場合、プログラムの実行を中断し、この例外的な状況を処理するための制御が行われ、さもなければクラッシュします。
その違いにご注目ください
2.変数による除算で、ゼロに等しい。
> 1/a
[1] Inf
厳密には、このバリエーションは従来のものとは異なります。
関数1/aはa=0を除くすべての場所で連続であり、このとき左の極限=-Inf、右の極限=+Infとなる。
Rはこれを理解できないが、マイナス無限とプラス無限の違いは、プログラムコードではなく、数学で意味をなすので、受け入れることができる
3.二つの無限小の量のゼロへの吸引における分割
[1] NaN
NaNの意味は、私には全く説明がつきません。しかし、Rが制限というものを理解していないことは、2.からも明らかです。
これらはプログラミングシステムとしてのRのエラーなのでしょうか？どうだろう。おそらくRのドキュメントにはそのようなニュアンスのことが書かれているはずですが、では、現時点で約13万関数の分散開発でどのように実装すればいいのでしょうか。必要なのか？
そこから生まれた議論というのは、どういう意味なのでしょうか。
意思決定は陸上で行う。
1.Rを取り込んで、ぶっきらぼうにMKLにコードを転送している。同時に、上記のような変形は、Rの異なる機能において異なる解釈をする可能性があることを認識する必要があります。
2.私が述べたケースでどの値を受け入れるか、合意を宣言する（リストは不完全かもしれません）。Rのコードを徹底的にチェックし、我々の設定に合わない場合は、我々の取り決めに従って修正しながらRからMCLに移植しています。この場合、集中開発により、採用された規約を一貫して実施しており、その意味でより良いシステムになっています。