double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
gravity001 писал (а): На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял. У меня были ошибки при сравнении, когда я использовал такую конструкцию:
double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
SK. писал (а): うまくいく場合もありますが、そうでない場合もあります。この「必ずしもそうではない」というのは、コンピュータのメモリに値を格納する際の特殊な方法によって決まる。まさにそれです。 コンピュータのメモリに値を保存する方法について知っている。:)プログラミング歴は約20年です。過去には、大学生にプログラミングを教えたこともあります。
double a = 4.0;
double b = 2.0;
double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
(т.е. появление цифр отличных от нуля после точки)?
もろもろの比較という意味でそう言ったのです。
つまり、ビューコンストラクションが常に機能するとは限らないということです。
変数a,bに 割り当てられた結果は正規化され、その後、比較することができますが、両者には何も起こりません。
Renatは別のことを書いていますが、その例では、正規化された値の引き算の 結果は、順番に、正規化されて いません。
演算の 最終結果を正規化すれば、それを変数に代入してさらに操作することができる。主な内容は、変数自体がさらにその値を変えてはいけないということです。
多いか少ないかのチェックはしていませんが、平等かどうかのチェックはしています。
この構造を使うと、比較エラーが発生しました。
なぜ、わからないのですか？
どのようなエラーですか？
そして、私にとっては、ONE AND ONEという 結果の1番目と2番目のことです。
これはうまくいく場合もありますが、そうでない場合もあります。この「常にではない」というのは、コンピュータのメモリに値が格納される際の特殊な方法によって決まる。まさにそれです。
aと bの 変数に割り当てられた結果は正規化され、それらをさらに比較することが できますが、それらには何も起こりません。
無理 でしょう。つまり、何をやってもいいのですが、確実な結果を得るためには、比較演算を含む式の中で直接NormalizeDouble()を適用すべきです。
Renatは別のことを書いています。彼の例では、正規化された値の引き算の 結果が正規化されて いないからです。
しかし、だからといって、あなたのこれまでの発言が正しいとは限りません。
演算の最終結果を正規化すれば、それを変数に代入してさらに操作することができる。主な点は、変数自体がそれ以上値を変えてはいけないということです。
使用されている特定のコンピュータ技術のために、最後の桁で値を変えることができます。これは、ユーザーが気づかないうちに起こる可能性がありますし、実際に起こっています。そこがポイントです。場合によっては（例えばプログラムのデバッグ時）うまくいくこともありますが、このプログラムを使うときは、しがないプログラマーの期待通りに動くこともあれば、うまくいかないこともあります。
新規ユーザーに対して1000回も同じことを説明しなければならない開発者の方々には、心からお悔やみを申し上げます。
この工事では、多いか少ないかのチェックはしていませんが、平等かどうかのチェックはしています。
この構造を使うと、比較エラーが発生しました。
なぜ、わからないのですか？
どのような失敗ですか？
また、メモリからの変数doubleの格納や読み出しでエラーが発生するのはなぜでしょうか？演算処理に 誤りがあるのでは？
このような場合、誤りはあり得ないとお考えですか？
double a = 4.0; double b = 2.0; double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки (т.е. появление цифр отличных от нуля после точки)?На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял.
У меня были ошибки при сравнении, когда я использовал такую конструкцию:
Почему, не знаете?
条件が満たされない、つまり平等性が満たされないのでは？
また、メモリからの変数doubleの格納や読み出しでエラーが発生するのはなぜでしょうか？演算処理に誤りがあるのでは？
その際、エラーはあり得ないと思っているのでしょうか。
除算の操作自体は正しく実行されていると思います。
ある変数の値（計算の結果得られた値であれ、変数の初期化によって得られた値であれ）をどのように得るかではなく、プログラムの実行中、さらにはコンピュータの動作中にその変数の値がどのように推移するかということが論点になっています。そして、その運命は予測不可能です。したがって、論理演算をプログラミングする場合は、赤字のNormalizeDouble()関数を使用する必要があります。
塗ることは良いことです。正しく適用することは非常に良いことです。
使わないのは悪いことです。誤った使い方-悪いこと
---
休日は......したい
うまくいく場合もありますが、そうでない場合もあります。この「必ずしもそうではない」というのは、コンピュータのメモリに値を格納する際の特殊な方法によって決まる。まさにそれです。
コンピュータのメモリに値を保存する方法について知っている。:)プログラミング歴は約20年です。過去には、大学生にプログラミングを教えたこともあります。
aと bの 変数に割り当てられた結果は正規化され、それらをさらに比較することが できますが、それらには何も起こりません。
無理 でしょう。したがって、どのような方法でもかまいませんが、確実な結果を得るためには、比較演算を含む式の中でNormalizeDouble() を正しく適用する必要があります。
当然ながら、式の計算結果を何かと比較する前に、それを正規化する必要があります誰がそれに反論できるんだ!しかし、それは我々の議論とは無関係です。私は、コードのアイデンティティについて話していたのです。違いは、2番目のケースでは、正規化の結果が変数に格納されていることである。それでおしまい
つまり、NormalizeDouble関数はdoubleより大きいビットサイズの結果を持つ（この関数の結果が少なくとも1ビットのメモリを占有する）と主張していますね。これだけで、関数の結果を変数に保存したときの損失（あるいは変化）を説明できる。 あるいは、代入するときに、あるメモリセルから別のメモリセルへデータを1バイトずつ重複させるだけでなく、何かトリッキーな操作が行われているのだ。
繰り返しますが、私は比較演算の右オペランドと左オペランドを別々に正規化することの正しさなどについては議論していません。 ただ、上の2つのコードの断片の結果が同じかどうかを問うているのです。
演算結果を正規化すれば、それを変数に代入してさらに演算することができる。要は変数自体がそれ以上値を変えてはいけないということです。
使用されている特定のコンピュータ技術のために、最後の桁で値が変わってしまうことがあります。これは、ユーザーが気づかないうちに起こる可能性がありますし、実際に起こっています。そこがポイントです。場合によっては（例えばプログラムのデバッグ時）、このプログラムを使うと、しがないプログラマーの期待通りに動作することが多いし、動作しないこともある。
ワオッ! また、「特定のコンピューター技術」とは、どのようなものを指すのでしょうか？ユーザーにとっては「気づかない」ことも多いのですが、何しろ私たちはプログラマー ですからね。:)そうでなければ、コンピューターではなく、予測不可能な結果を生み出すジェネレーターになってしまうからです。:)それとも、私たちのコンピューターがすでに誤動作しているのでしょうか？一方的に読まされる...。もう1回！実数を使った算術演算では、確かに結果は絶対的に厳密 ではない（実数の表現方法と関係がある）。しかし、これは割り当て操作には適用されません。NormalizeDouble 関数が動作してdouble 型の結果を返すと、この結果を単純にコピーして変数に入れます（すべてのバイトが一致します）。さらに、変数の値は変化しないまま（つまり、読めるだけで、何も書き込まれていない）、原型が保たれ、どこにも符号が浮かばない。読めば、同じことがわかる。しかし、ただ1を掛けて結果を書き戻すだけでは、何も保証されません。
新規ユーザーに対して1000回も 同じことを説明しなければならない開発者の方々には、心からお悔やみを申し上げます。
このような場合、間違いがあるはずがないと思っているのでしょう。
非常に遠い桁の誤差は、実数の表現方法に起因している可能性が十分にある。