ちょっとびっくり :)私は、共有し、NOT修辞的な質問をすることを考えました。 - ページ 21 1...141516171819202122232425 新しいコメント Academic 2011.04.03 17:57 #201 Renat:失敗した発言から別の発言に飛び火するのは簡単です。 有理数データ型を 持つプロセッサがあり、SSExxxコマンドの別のセットがdoubleよりも高速に処理できるようになったら、計算の高速化に関する議論に有理数を持ち込むことができます。SMAの計算方法を変えたテストを公開し、2倍以上の勝率を示したら、それは実践の言霊となるでしょう。一方、整数に切り替えることで実際の数学の計算が加速されるという当初の発言は失敗に終わった。なんだと!?私は何もジャンプしていません。半分だけ読んだら嗚呼。有理数分数については、20回くらい言っています。しかし、私が分数であることを指摘するまで、誰も理解してくれませんでした。:)バカバカしいと言ってるんだ。嗚呼。:( :)失敗-整数とPOINTの概念について話していたのですが、POINTは常に分母なのです。13000ポイント 1ポイントが10000に相当する場合、その値は=13000/10000=1.3 :) Mykola Demko 2011.04.03 18:18 #202 Academic:何してるんだ!?私はどこにも飛び込んでいません。半分だけ読んだら申し訳ございません。合理的な貯水槽については、もう20回も話しています。しかし、私が分数であることを指摘するまで、誰も理解してくれませんでした。:)バカバカしいと言ってるんだ。嗚呼。:( :)失敗-整数とPOINTの概念について話していたのですが、POINTは常に分母なのです。13000ポイント 1ポイントが10000に相当する場合、その値は=13000/10000=1.3 :) 8バイトのダブルではなく、8バイトのロング(整数部+分母+分子)を3つ処理することを提案しています。また、ロングを短いものに切り始めると、かなり適当な計算でオーバーフローしてしまいます。3イントでも、それらは1テイク以上です。 Academic 2011.04.03 18:23 #203 Urain: 8バイトのダブルではなく、8バイトのロング(整数部+分母+分子)を3つ処理することを提案しています。また、ロングを何か短いものに切り始めると、かなり適当な計算でオーバーフローが発生します。最悪の実装方法を選んでしまったね。あなたの話からすると、腑に落ちないことがあります。どっちが詳しいんだ? キロメートル単位の数値があり、それはint32で、他には何も必要ありません。別次元の値で足し算しなければいいだけです。:)キロメートル以上の精度が必要なら、ナノメートルにすればいい。:)そして、整数として保存する。:) Vladimir Gomonov 2011.04.03 18:28 #204 TheXpert:そして第二に、doubleを使った演算が有理数より遅いというのは、非常に疑問です。ワプチェット・スローしかし、彼は間違ったリンクを私たちに提供しました。 1.BOOSTでの実装では、それらを使って演算ごとに配給数を正規化する。これは高価なので、いちいち行う必要はない。分母のオーバーフローが本当に心配なときだけ実行するのがよいでしょう。2.共通分母への還元(正確には最大公約数の計算)は、最速のアルゴリズムではそこで行われない。圧倒的に速いです。訂正して、有理数の速さについては正しいです。算術演算 リロードが可能なら、mqlにもあるんだけどね。これがないと、私の構文は非常に面倒(関数的)になってしまうので、忘れてください...。С++ :-)--でも、プロセッサーレベルでサポートがあれば、本当にクールだと思うのですが...。 Mykola Demko 2011.04.03 18:45 #205 MetaDriver:ワプケッタ・スローただ、彼が示したリンクは間違っていた。 1.BOOSTの実装では、演算のたびに配給数を正規化する。高いからいちいちやらなくていいよ。分母のオーバーフローが本当に心配なときだけ実行するのがよいでしょう。2.共通分母への還元(正確には最大公約数の計算)は、最速のアルゴリズムではそこで行われない。圧倒的に速いものがあります。とはいえ、比率の速さについては、彼の言うとおりです。算術演算 リロードが可能なら、mqlにもあるんだけどね。これがないと、とても面倒な構文(関数)になるので、忘れてください...。С++ :-)--でも、CPUレベルでのサポートがあれば、すごくいいんですけどね...。演算自体が遅くなるのは、やはり浮動小数点を扱わなければならないからで(純粋なdouble演算とlong演算を比較した場合です)、doubleを整数演算に変換してしまうと負けです。NODの再計算だけでもlog(N)回の演算が必要であり、さらに乗算演算のたびにオーバーフローをチェックする必要があることは言うまでもない。さらに4分割(NODによる2分割、整数部と分数余りの抽出)。その上、この無意味なものを保存するために、テイクのために必要な以上のメモリを割り当てる必要があります。 TheXpert 2011.04.03 19:09 #206 MetaDriver:ワプチェット・スロー彼が引用したリンクだけが残念だった。 証拠は?確かに私の目には原作者より権威があるように映りますが、強引な発言ですね。ですから、比較テストをお願いしたいですね。 Vladimir Gomonov 2011.04.03 19:18 #207 Urain:演算自体は、やはり浮動小数点を扱わなければならないので遅くなります(純粋なダブル演算とロング演算を比較すればの話ですが)。 1. 倍速を整数演算に変換したら負け。 2. 再帰NODの計算だけで、log(N)の演算が必要になることは言うまでもありません。 3. 各乗算演算は、オーバーフローをチェックするifが必要です。 4. さらに4分割(NODによる2分割、整数部と分数余りの抽出)。5. さらに、このような無意味なものを保存するために、撮影に必要なメモリーよりも多くのメモリーを割り当てる必要があります。1.テイクごとに1回の操作になる。損は微々たるもの、ならば得はしっかりある。:)元の商を一度対数化して整数表現に変換しているのでしょう。2.これは正しいです。ビットシフトを使った高速なアルゴリズムがあるので、高速ですが。3.オーバーフローチェック以上のものはない。4. 整数部は全く割り当てる必要がない。分数はlongのペア、可能ならintのペアで格納される。5.longのペアとして格納される場合は全く同じ量、intが十分にある場合は半分の量(アルゴリズムの要件に依存します)。主なメモリ消費者が見積もりであることを考慮すれば、整数表現によるスペースの獲得は否定できない。ポイントはメモリ節約ではなく、高速化にあるのですが。この方がよっぽど重要です。--アカデミアの問題は、彼が間違っていることではありません。他人を悪者にしていることです。 それが、その場にいる人を苛立たせ、健全な考えを拒絶する...。汚れた水と一緒に...。:( Vladimir Gomonov 2011.04.03 19:23 #208 TheXpert:ですから、比較テストをお願いしたいですね。試してみます。mql5で、もしそうなったら...。:) 少し時間が必要です。ライブラリーを書かなければならないだろう。 TheXpert 2011.04.03 19:25 #209 MetaDriver:試してみます。mql5では、もしそうなったら...。:) 何のために?C++が使用可能です。MetaDriver。 学者の問題は、彼が間違っていることではありません。他人を悪者にしていることです。問題は、自分が他人より賢いと思っていて、常に誰かを馬鹿にしようとすることだ。 そして、彼はしくじる。あるところでは、たくさん。 Academic 2011.04.03 19:25 #210 MetaDriver:学者の問題は、彼が間違っていることではありません。他人を悪者にしてしまうことです。 これが、その場にいる人たちを苛立たせ、健全な考えを拒むことになる...。汚れた水と一緒に...。:(私は誰の頭にも入りません。しかし、私は反転しています。:)"テーマで行くべきか "というアドバイスを呼びかけてきたのは誰だ?:) そして、私がその一人になってしまう... :)まあ、私のところには来ないでください。 一般的に何が違うのか? 何を議論する必要があるのか?IMHO - すべてのものは、それがそうであったように同じ胚発生レベルで残っています。だから、私には何の問題もない。まるで私が存在しないかのようだ。:) 1...141516171819202122232425 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
失敗した発言から別の発言に飛び火するのは簡単です。
有理数データ型を 持つプロセッサがあり、SSExxxコマンドの別のセットがdoubleよりも高速に処理できるようになったら、計算の高速化に関する議論に有理数を持ち込むことができます。SMAの計算方法を変えたテストを公開し、2倍以上の勝率を示したら、それは実践の言霊となるでしょう。
一方、整数に切り替えることで実際の数学の計算が加速されるという当初の発言は失敗に終わった。
なんだと!?私は何もジャンプしていません。半分だけ読んだら嗚呼。有理数分数については、20回くらい言っています。しかし、私が分数であることを指摘するまで、誰も理解してくれませんでした。:)バカバカしいと言ってるんだ。嗚呼。:(
:)失敗-整数とPOINTの概念について話していたのですが、POINTは常に分母なのです。13000ポイント 1ポイントが10000に相当する場合、その値は=13000/10000=1.3 :)
何してるんだ!?私はどこにも飛び込んでいません。半分だけ読んだら申し訳ございません。合理的な貯水槽については、もう20回も話しています。しかし、私が分数であることを指摘するまで、誰も理解してくれませんでした。:)バカバカしいと言ってるんだ。嗚呼。:(
:)失敗-整数とPOINTの概念について話していたのですが、POINTは常に分母なのです。13000ポイント 1ポイントが10000に相当する場合、その値は=13000/10000=1.3 :)
8バイトのダブルではなく、8バイトのロング(整数部+分母+分子)を3つ処理することを提案しています。また、ロングを短いものに切り始めると、かなり適当な計算でオーバーフローしてしまいます。
3イントでも、それらは1テイク以上です。
8バイトのダブルではなく、8バイトのロング(整数部+分母+分子)を3つ処理することを提案しています。また、ロングを何か短いものに切り始めると、かなり適当な計算でオーバーフローが発生します。
最悪の実装方法を選んでしまったね。あなたの話からすると、腑に落ちないことがあります。どっちが詳しいんだ?
キロメートル単位の数値があり、それはint32で、他には何も必要ありません。別次元の値で足し算しなければいいだけです。:)キロメートル以上の精度が必要なら、ナノメートルにすればいい。:)そして、整数として保存する。:)
TheXpert:
そして第二に、doubleを使った演算が有理数より遅いというのは、非常に疑問です。
ワプチェット・スローしかし、彼は間違ったリンクを私たちに提供しました。
1.BOOSTでの実装では、それらを使って演算ごとに配給数を正規化する。これは高価なので、いちいち行う必要はない。分母のオーバーフローが本当に心配なときだけ実行するのがよいでしょう。
2.共通分母への還元(正確には最大公約数の計算)は、最速のアルゴリズムではそこで行われない。圧倒的に速いです。
訂正して、有理数の速さについては正しいです。
算術演算 リロードが可能なら、mqlにもあるんだけどね。これがないと、私の構文は非常に面倒(関数的)になってしまうので、忘れてください...。С++ :-)
--
でも、プロセッサーレベルでサポートがあれば、本当にクールだと思うのですが...。
ワプケッタ・スローただ、彼が示したリンクは間違っていた。
1.BOOSTの実装では、演算のたびに配給数を正規化する。高いからいちいちやらなくていいよ。分母のオーバーフローが本当に心配なときだけ実行するのがよいでしょう。
2.共通分母への還元(正確には最大公約数の計算)は、最速のアルゴリズムではそこで行われない。圧倒的に速いものがあります。
とはいえ、比率の速さについては、彼の言うとおりです。
算術演算 リロードが可能なら、mqlにもあるんだけどね。これがないと、とても面倒な構文(関数)になるので、忘れてください...。С++ :-)
--
でも、CPUレベルでのサポートがあれば、すごくいいんですけどね...。
演算自体が遅くなるのは、やはり浮動小数点を扱わなければならないからで(純粋なdouble演算とlong演算を比較した場合です)、doubleを整数演算に変換してしまうと負けです。NODの再計算だけでもlog(N)回の演算が必要であり、さらに乗算演算のたびにオーバーフローをチェックする必要があることは言うまでもない。さらに4分割(NODによる2分割、整数部と分数余りの抽出)。
その上、この無意味なものを保存するために、テイクのために必要な以上のメモリを割り当てる必要があります。
ワプチェット・スロー彼が引用したリンクだけが残念だった。
証拠は?確かに私の目には原作者より権威があるように映りますが、強引な発言ですね。
ですから、比較テストをお願いしたいですね。
演算自体は、やはり浮動小数点を扱わなければならないので遅くなります(純粋なダブル演算とロング演算を比較すればの話ですが)。
1. 倍速を整数演算に変換したら負け。
2. 再帰NODの計算だけで、log(N)の演算が必要になることは言うまでもありません。
3. 各乗算演算は、オーバーフローをチェックするifが必要です。
4. さらに4分割(NODによる2分割、整数部と分数余りの抽出)。
5. さらに、このような無意味なものを保存するために、撮影に必要なメモリーよりも多くのメモリーを割り当てる必要があります。
1.テイクごとに1回の操作になる。損は微々たるもの、ならば得はしっかりある。:)元の商を一度対数化して整数表現に変換しているのでしょう。
2.これは正しいです。ビットシフトを使った高速なアルゴリズムがあるので、高速ですが。
3.オーバーフローチェック以上のものはない。
4. 整数部は全く割り当てる必要がない。分数はlongのペア、可能ならintのペアで格納される。
5.longのペアとして格納される場合は全く同じ量、intが十分にある場合は半分の量(アルゴリズムの要件に依存します)。
主なメモリ消費者が見積もりであることを考慮すれば、整数表現によるスペースの獲得は否定できない。
ポイントはメモリ節約ではなく、高速化にあるのですが。この方がよっぽど重要です。
--
アカデミアの問題は、彼が間違っていることではありません。他人を悪者にしていることです。
それが、その場にいる人を苛立たせ、健全な考えを拒絶する...。汚れた水と一緒に...。:(
ですから、比較テストをお願いしたいですね。
試してみます。mql5で、もしそうなったら...。:)
少し時間が必要です。ライブラリーを書かなければならないだろう。
試してみます。mql5では、もしそうなったら...。:)
何のために?C++が使用可能です。
学者の問題は、彼が間違っていることではありません。他人を悪者にしていることです。
問題は、自分が他人より賢いと思っていて、常に誰かを馬鹿にしようとすることだ。
そして、彼はしくじる。あるところでは、たくさん。
学者の問題は、彼が間違っていることではありません。他人を悪者にしてしまうことです。
これが、その場にいる人たちを苛立たせ、健全な考えを拒むことになる...。汚れた水と一緒に...。:(
私は誰の頭にも入りません。しかし、私は反転しています。:)"テーマで行くべきか "というアドバイスを呼びかけてきたのは誰だ?:)
そして、私がその一人になってしまう... :)まあ、私のところには来ないでください。
一般的に何が違うのか? 何を議論する必要があるのか?IMHO - すべてのものは、それがそうであったように同じ胚発生レベルで残っています。だから、私には何の問題もない。まるで私が存在しないかのようだ。:)