Rの古いバージョンを使用しています。MRAN- Microsofn R OpenのウェブサイトからRバージョン3.3.1（2016-06-21）を取得する必要があります。その際、MKLのインストールは必須です。マイクロソフトは、前述のRのリリースで、いくつかのパッケージや関数の実行速度を最大50倍（！）向上させることができたと主張している。
Microsoft R Open, formerly known as Revolution R Open (RRO), is the enhanced distribution of R from Microsoft Corporation. It is a complete open source platform for statistical analysis and data science. The current version, Microsoft R Open 3.3.1, is based on (and 100% compatible with) R-3.3.1, the most widely used statistics software in the...
Rの古いバージョンを使用しています。MRAN- Microsofn R OpenのウェブサイトからRバージョン3.3.1（2016-06-21）を取得する必要があります。その際、MKLのインストールは必須です。Microsoftは、Rのリリースで、いくつかのパッケージや関数の実行速度を最大50倍（！）向上させることに成功したと主張している。
次に、一様な連続分布の場合、極点での密度が正で積分が0になることを、直訳順にコメントします。https://en.wikipedia.org/wiki/Uniform_distribution_(連続)
記事のRの誤りについて、最初の発言に戻ろう。
私たちの意見は、エラーは存在し、それは実装の不注意によって引き起こされるものです。
つまり、@Quantumは MQL5におけるR mathライブラリのアナログの純粋な実装と完全なチェックである。
これは理論家の推理ではありません。そして、ライブラリが正しいことを保証するユニットテストを書くときも、深く掘り下げている。
Rですべてが正しいとアプリオリに決めつけてはいけない。逆に言えば、そこにC++で実装された関数があったとしても、すべてがかなり原始的なものだと言えるでしょう。また、スピードの面でも、当社のコンパイラでソースコードに含まれるMQL5ライブラリが平均3倍で勝っていることがわかります。
わざわざダブルチェックを行い、明らかな誤りを発見したのです。これらのエラーは確認されています。
出版物の日付を見てください。科学者のアドバイスを受けながら、作業がどのように進んでいるかがわかります。
それに、@Quantumを 科学者だと思わないのは間違いです。
レナートへ
あなたの最近の投稿について、私にとっては原則的な事柄ですが、次のような疑問があります。
1.記事の掲載時期から判断すると、2003年のことですね。当然、Rも他のソフトウェアシステムと同様にエラーがあり、リリース時には必ず修正リストが公開されます。同時に、Rの利点として、非常に多くのユーザーがいることによるバグの少なさを強調してきた。そして、ここでは2003年からアルゴリズムのバグが出版レベルで検出され、それが修正されていないのです。これは私にはわかりません。
この件に関して、R社に問い合わせをしましたか？
2.RとMQL5の性能を比較したコードを見てみたいです。
あらかじめご了承ください。
レナートへ
最近の投稿について、私にとっては基本的なことなのですが、以下のような疑問があります。
1.記事の掲載時期から判断すると、2003年である。当然、Rも他のソフトウェアシステムと同様にエラーがあり、リリース時には必ず修正リストが公開されます。同時に、非常に多くのユーザーがいることによるバグの少なさは、Rの美点であることを常に強調してきた。そして、ここでは2003年からアルゴリズムのバグが出版レベルで検出され、それが修正されていないのです。これは私にはわかりません。
初歩的なことですが、絶対的にわかりやすいです。
誰にでも失敗はある。それが開発者の仕事だ。失敗を重ねても、くじけずに頑張る。
Rのこのエラーは、ただ不注意から、ある基本的な関数に依存して、他の関数を台無しにしたものです。修正されることになります。
この件に関して、Rに要望を出したか？
私たちは、テストを行い、すべてを詳細に調べながらライブラリを作成し、MQL5、Wolfram Alpha、Rの結果を常に比較し、結果を示し、それに対して公に答える用意があるのです。もちろん、私たちの数学パッケージには、ユニットテストとベンチマークを含む3つの大きなスクリプトを添付しました（これはソースコードにあります）。
きっと@Quantumが Rでバグレポートを書いてくれるでしょう。つい数時間前に更新された記事が公開されました。
RとMQL5の性能を比較したコードを見てみたいです。
MQL5のベンチマークコードは \scriptsUnitTestsTestStatBenchmark.mq5 に、RコードはStatistical Distributions in MQL5 - take the best from R and make it faster, see "Appendix" の末尾に掲載されています。統計関数の時間軸を計算した結果」。
MetaQuotes-Demoサーバーに接続し、必ずMetaTrader 5 build 1467にアップグレードしてください。このベータ版には、新しいライブラリとすべてのテスト用スクリプトが含まれています。
これは初歩的なことで、全く理解できることです。
誰にでも失敗はある、それが開発者の性です。失敗を重ねても、くじけずに頑張る。
Rのこのエラーは、ただ一つの基本的な機能に対する不注意と信頼から、他の機能を台無しにしてしまったのです。修正されることになります。
私たちは、テストを行い、すべてを詳細に調べながらライブラリを作成し、常にMQL5とWolfram Alpha、Rを比較し、結果を示し、それに対して公に答える用意があるのです。もちろん、私たちの数学パッケージには、ユニットテストとベンチマークを含む3つの大きなスクリプトを添付しました（これはソースコードにあります）。
きっと@Quantumが Rでバグレポートを書いてくれるでしょう。つい数時間前に更新された記事が公開されました。
MQL5でのベンチマークコードは \scriptsUnitTestsTestBenchmark.mq5 に、RでのコードはStatistical Distributions in MQL5 - take the best from R and make it fast in "Appendix" の記事の最後に記載されています。統計関数の時間計算の結果」。
MetaQuotes-Demoサーバーに接続し、必ずMetaTrader 5 build 1467にアップグレードしてください。このベータ版には、新しいライブラリとすべてのテスト用スクリプトが含まれています。
性能比較については、まだ自分の意見がまとまりません。そして、これは原則的な問題です。
Rは開発のための理想的な環境、一言で言えばインタプリタであるということです。しかし、開発中に存在するコードは、作業中のコードとは大きく異なります。何倍もの行数で。一方、ワーキングコードは、非常に短く、非常に容量が大きいです。そのため、計算量の多いアルゴリズムや行列演算、全コアに負荷をかけるランダムフォレストなど、取引の意思決定をする際に意味のあるパッケージの機能を比較する必要があります。
PS.
Rの古いバージョンを使用しています。MRAN- Microsofn R OpenのウェブサイトからRバージョン3.3.1（2016-06-21）を取得する必要があります。その際、MKLのインストールは必須です。マイクロソフトは、前述のRのリリースで、いくつかのパッケージや関数の実行速度を最大50倍（！）向上させることができたと主張している。
性能比較については、まだ意見がまとまりません。そして、これは原則的な問題です。
Rは開発のための理想的な環境、一言で言えばインタプリタであるということです。しかし、開発中に存在するコードは、作業中のコードとは大きく異なります - 何倍もの行数で。一方、ワーキングコードは、非常に短く、非常に容量が大きいです。そのため、例えばランダムフォレストのように、計算量の多いアルゴリズムや行列演算、全コアへの負荷など、取引を決定する上で意味のあるパッケージの機能を比較する必要があるのです......。
Rの機能を体系的にMQL5に変換しています。そして、関数呼び出しの本質が非常に似ていることが判明するような形で。
以下は、記事中の通信文の例です。
ユニフォーム
RからのコードをMQL5で書くのと、サイズや時間がほぼ同じになるようにしています。
明日は、グラフィカルなライブラリのベータ版をリリースし、RとMQL5で同じ大きさのコードの塊を画像と一緒にデモします。
Rの純正バージョンが急にスピードアップすることはないでしょう。そこのコードはあまり変わっていないのです。特にマトリックス関数は、高速化できるものがあるのは明らかです。そして、あなたの発言は、Rのコードは性能の面でかなりぞんざいに書かれているという私の意見を裏付けるものです。
記事を読んでいただければ、マルチスレッドやMKLを使わない基本的な機能でも最大46倍の高速化を実現したことがおわかりいただけると思います。
計算は、Intel Core i7-4790, 3.6 Ghz CPU, 16 GB RAM, Windows 10 x64で行いました。計算時間の結果はマイクロ秒単位
PDF計算時間(µs)
PDF計算時間(µs)
R/MQL5
CDF計算時間(µs)
CDF計算時間(µs)
R/MQL5
量子化時間 (µs)
量子化計算時間 (µs)
R/MQL5
乱数発生時間 (µs)
乱数発生時間（μs）
R/MQL5
しかし、指定されたバージョンはもちろんテストされます。スピードも性能も。
"間違った答え "は間違いです
...
例えば、MQLのドキュメントにはアークサインに関する例があり、arcsine(2)=infinityと記載されています。これは正確ではありません。その通り: arcsinus(2) = NaN、つまり数値がない、arcsinus(1) = Inf、しかし取引中の気配値欠落 = NA、つまりあるべき(または週末にあり得る)のにない。
誤答を少し皮肉って書きました。スマイリーフェイスを付ければよかった・・・。実は最後に、定義されていない機能領域でのコンパイラやインタプリタの動作は、システムアーキテクチャや開発者に完全に依存するため、どちらの場合もバグではないことを書き加えました。その場合はナンを返した方がいいに決まっている。
つまり、定義されていないパラメータで関数を呼び出して、他のライブラリと結果を比較するのはやめましょう。そうしないと、何百もの「バグ」を見つけることができますよ。
ところで、アークシヌスを使った例も面白いですね。
mql -
MathArcsin(1) = MathArcsin(2) = -nan(ind)
ウルフラム
アークサイン(1) = Pi/2
Arcsin(2) = 何か複雑なもの。有効な結果を伴う解答はない。
R -
asin(1) = Pi/2
asin(2) = nan (答えは実数の場合)
asin(2+0i) = wolframのような複雑なもの
wiki によると asin(1) はまだ定義されているようです(https://en.wikipedia.org/wiki/Inverse_trigonometric_functions)。servicedesk にバグレポートを書くことができます。
しかし、asin(2)は未定義の領域なので、どこでもOKでマッチします。
また、前回の投稿についてですが、単純な数学で0による除算は不可能なので、mqlスクリプトがエラーでクラッシュするのは論理的なことであり、ここにバグはないのです。しかし、小数点以下16桁まで結果を精密にし、ゼロで割ることが何らかの理由で不可能な場合はnanやInfを返す、そんなきめ細かさがとても不思議です。Infに戻して、スクリプトの突然のクラッシュで開発者を苦しめないようにする必要があると思います。
実数値分割制御を無効にするには、metaeditor.ini ファイルの [Experts] セクションにあるパラメータ FpNoZeroCheckOnDivision=1 を使用します。
このパラメータがある場合、以下のコードでinfが生成されます。
もちろん、このパラメータがあっても、定数0.0で割るときのコンパイルエラー は防げません。
'0.0' - division by zero in the constant expression s1.mq5 8 12
Renatさん、今回のRからmqlへの一部機能の移管は、本当にサプライズだったのですか？
いいえ。
サプライズは意味がないので、MQL5とMetaTrader 5の中ですべて行います。
このパラメータがある場合、以下のコードでinfが表示されます。