NormalizeDoubleのパラドックス - ページ 2 123456789...12 新しいコメント Vladimir Pastushak 2015.03.16 15:42 #11 transcendreamer: 正規化してもテールが残っているのがパターンブレイクです 正規化後のテールがない...。人を惑わさないこと。 transcendreamer 2015.03.16 18:58 #12 VOLDEMAR: 正規化してもテールが出ない...人を惑わさないこと。入らない・・・・。が、私は例えば、2倍の数値を正規化して端末のグローバル変数に 書き込み、それを読み込んで再度正規化するとtailsになる、というような状況です。最後に - 私にはこの尻尾を捕まえる力はありません - DoubleToStr(current,2) を使って強制的に尻尾を切りました。 Vladimir Pastushak 2015.03.16 19:14 #13 transcendreamer:入らない・・・・。が、私は例えば、2倍の数値を正規化して端末のグローバル変数に 書き込み、それを読み込んで再度正規化するとtailsになる、というような状況です。結果的に、この尻尾を捕まえる力はなく、DoubleToStr(current,2)を使って無理やり切り落としただけです。変数doubleを例えば5文字に正規化すると、その変数には5文字が格納されます。ラプリンタなどの場合、変数を別のデータ型に変換するので、テールが発生することがあります。しかし、正規化した後のダブルにはテールがない...。クラッシュしないためには、アプリケーションのポイントで正規化を行う必要があります、計算の途中では、その必要はありません...。 transcendreamer 2015.03.16 21:04 #14 VOLDEMAR:例えばdouble変数を5桁に正規化した場合、変数には5桁が格納されますが、再印刷などの際に別のデータ型に変換してしまい、結果としてtailが発生することがあります。が、正規化後のダブルにはテールがない...。クラッシュしないためには、正規化はアプリケーションポイントで行うべきで、計算の途中で行うことはできないのでは...。 つまり、例えば、私が変換を行う場合(string)currentということは、この変換中に正確にテールを出すことができるのでしょうか？知らん顔おつかれさま Vladimir Pastushak 2015.03.17 07:06 #15 transcendreamer: つまり、例えば、私が変換を行う場合(string)currentということは、この変換プロセスで正確にテールを出すことができるのでしょうか？は知りませんでした。ありがとうございました。 はい、できます。DoubleToString(, 5)は正しいです。 Dmitry Fedoseev 2015.03.17 07:57 #16 stringo:NormalizeDoubleは次のように動作します（最初のMQL以来、常にこのように動作しています）。10 の累乗を掛けて整数化し（端数は 切り捨てる）、さらに 10 の累乗で割る。ここで何が問題なのか？パターンブレイクはあるのか？端数部分は捨てられるのですか？四捨五入は、以下の通りです。NormalizeDouble(1.25,1) = 1.3 Slava 2015.03.17 08:11 #17 Integer:端数部分は廃棄されるのですか？四捨五入が行われる。NormalizeDouble(1.25,1) = 1.3 そうだ、四捨五入の話を忘れていた。整数にする場合は、四捨五入を行う。 pavlick_ 2015.03.17 08:48 #18 transcendreamer: そのため、例えば変換を行う場合(string)currentということは、この変換プロセスで正確にテールを出すことができるのでしょうか？は知りませんでした。おつかれさまでしたそうでもないんです。2進法 != 10進法。2進数の小数点以下は、0.5 / 0.25 / 0.125 / 0.0625 / 0.03125 などとなります。これらのレンガからすべての小数点以下の数字を足し算することはできない。例えば、10進数で0.3という数字を正確に並べることは不可能であり（近似値しか並べられない）、2進法では少し小さいか少し大きいかのどちらかになる。この尻尾はこうして現れる。 1/2^各乗で余りなく割り切れる数だけを正確に表現しています。つまり、10進数を2進数で表そうとすると、数字が歪んでしまうのだ。 pavlick_ 2015.03.17 11:03 #19 そんな例えがある。 私たちは、1/3の演算 結果を正確に書き留めないために、切り上げなければならないという事実に慣れている。しかし、3元系では演算の正確な表現 == 0.1がある。もし、私たちの母国語が3進数で、PCが10進数で動いていたとしたら、0.1troicという数字を3進数に変換したときに、ビットのゴミに驚くだろう。 transcendreamer 2015.03.17 11:30 #20 pavlick_: そんな例えがある。 私たちは、切り上げなければならない1/3演算の 結果を正確に書かないことに慣れているのです。しかし、3元系では、0,1という演算の厳密な表現がある。もし、私たちの母国語が3進数で、パソコンが10進数で動いていたら、0.1troicという数字を3進数に変換するときに、ビットのゴミに驚くだろうね。それはそうですね。しかし、なぜか1円玉電卓でも、メモリから数字を読み込んで、そこに書かれている通りの数字を返すことができる。分数1.23を書き出すと、尾を引かずにちょうど1.23が戻ってくる。そして、ここにコツがあります。理論的には、バイナリ形式で数値を提示するようなルーチンからユーザが解放されるはずです<ボアモードオフ>。 123456789...12 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
正規化してもテールが残っているのがパターンブレイクです
正規化してもテールが出ない...人を惑わさないこと。
入らない・・・・。が、私は
例えば、2倍の数値を正規化して端末のグローバル変数に 書き込み、それを読み込んで再度正規化するとtailsになる、というような状況です。
最後に - 私にはこの尻尾を捕まえる力はありません - DoubleToStr(current,2) を使って強制的に尻尾を切りました。
入らない・・・・。が、私は
例えば、2倍の数値を正規化して端末のグローバル変数に 書き込み、それを読み込んで再度正規化するとtailsになる、というような状況です。
結果的に、この尻尾を捕まえる力はなく、DoubleToStr(current,2)を使って無理やり切り落としただけです。
変数doubleを例えば5文字に正規化すると、その変数には5文字が格納されます。ラプリンタなどの場合、変数を別のデータ型に変換するので、テールが発生することがあります。
しかし、正規化した後のダブルにはテールがない...。
クラッシュしないためには、アプリケーションのポイントで正規化を行う必要があります、計算の途中では、その必要はありません...。
例えばdouble変数を5桁に正規化した場合、変数には5桁が格納されますが、再印刷などの際に別のデータ型に変換してしまい、結果としてtailが発生することがあります。
が、正規化後のダブルにはテールがない...。
クラッシュしないためには、正規化はアプリケーションポイントで行うべきで、計算の途中で行うことはできないのでは...。
ということは、この変換中に正確にテールを出すことができるのでしょうか？
知らん顔
おつかれさま
つまり、例えば、私が変換を行う場合
ということは、この変換プロセスで正確にテールを出すことができるのでしょうか？
は知りませんでした。
ありがとうございました。
NormalizeDoubleは次のように動作します（最初のMQL以来、常にこのように動作しています）。
10 の累乗を掛けて整数化し（端数は 切り捨てる）、さらに 10 の累乗で割る。
ここで何が問題なのか？パターンブレイクはあるのか？
端数部分は捨てられるのですか？四捨五入は、以下の通りです。
NormalizeDouble(1.25,1) = 1.3
端数部分は廃棄されるのですか？四捨五入が行われる。
NormalizeDouble(1.25,1) = 1.3
そのため、例えば変換を行う場合
ということは、この変換プロセスで正確にテールを出すことができるのでしょうか？
は知りませんでした。
おつかれさまでした
そうでもないんです。2進法 != 10進法。2進数の小数点以下は、0.5 / 0.25 / 0.125 / 0.0625 / 0.03125 などとなります。これらのレンガからすべての小数点以下の数字を足し算することはできない。例えば、10進数で0.3という数字を正確に並べることは不可能であり（近似値しか並べられない）、2進法では少し小さいか少し大きいかのどちらかになる。この尻尾はこうして現れる。
1/2^各乗で余りなく割り切れる数だけを正確に表現しています。
つまり、10進数を2進数で表そうとすると、数字が歪んでしまうのだ。
私たちは、1/3の演算 結果を正確に書き留めないために、切り上げなければならないという事実に慣れている。しかし、3元系では演算の正確な表現 == 0.1がある。もし、私たちの母国語が3進数で、PCが10進数で動いていたとしたら、0.1troicという数字を3進数に変換したときに、ビットのゴミに驚くだろう。
そんな例えがある。
私たちは、切り上げなければならない1/3演算の 結果を正確に書かないことに慣れているのです。しかし、3元系では、0,1という演算の厳密な表現がある。もし、私たちの母国語が3進数で、パソコンが10進数で動いていたら、0.1troicという数字を3進数に変換するときに、ビットのゴミに驚くだろうね。
それはそうですね。
しかし、なぜか1円玉電卓でも、メモリから数字を読み込んで、そこに書かれている通りの数字を返すことができる。
分数1.23を書き出すと、尾を引かずにちょうど1.23が戻ってくる。
そして、ここにコツがあります。
理論的には、バイナリ形式で数値を提示するようなルーチンからユーザが解放されるはずです
<ボアモードオフ>。