关于实数不精确的偏执狂 [英] Paranoic about real number imprecisions
问题描述
你好，
由于计算机必须以有限的字节集存储真实的
数字这一事实，因此会产生问题。可能存储的
十进制值的一个小的不精确。我不知道，dotnet框架
如何存储双倍，但是可以肯定的是，如果我在一些
实变量中存储1.234567，那么存储在内存中就像接近
1.2345670000000000000003454786544或
1.23456699999999999999999999999999999924354324。
由于此问题，有时可能会导致一些意外
比较if中的实数时的结果声明。
一些编程语言有内置保护，只比较
有限的位数（小于声明的类型的能力），当
要求比较两个实数，因此较小的十进制
字段中的垃圾不会引起注意。我一直在使用ApproximatelyEqual。方法，比较两个实数并提供精度：
输入：A，B，精度
输出：（abs （AB）< = 10 ^（ - 精度））
示例：
A = 1.00000000000001
B = 1.00000000000007
precision = 13
abs（AB）= 0.00000000000006
10 ^（ - 精度）= 0.0000000000001
abs（ AB）< = 10 ^（ - 精度）=真
精度= 14
10 ^（ - 精度）= 0.00000000000001
abs（AB）< = 10 ^（ - precision）= false
对于我正在进行的项目，其中有多个操作使用
实数，我想确定，哪里有一些陷阱我可能会陷入其中。
比较没有自定义的实数数字是否安全ApproximatelyEqual
方法？
谢谢，
Pavils
为什么你不使用双倍？
Pavils Jurjans < PA **** @ mailbox.riga.lv> schrieb im Newsbeitrag
新闻：e8 ************** @ TK2MSFTNGP10.phx.gbl ...你好，
由于计算机必须以有限的字节集存储真实的数字，因此导致可能存储的小数值的微小不精确，这是已知的问题。我不知道，dotnet框架如何存储双打，但是可以肯定的是，如果我将1.234567存储在一些实际变量中，它会被存储在内存中，就像接近
1.2345670000000000000003454786544或
1.23456699999999999999999999999999999924354324。
由于这个问题，当比较if中的实数时，它有时可能会导致一些意想不到的结果。声明。
一些编程语言有内置保护，仅比较有限数量的数字（小于声明的类型的能力），当要求比较两个真实数字，因此较小的十进制
字段中的垃圾不被注意。我一直在使用ApproximatelyEqual。方法，
用于比较两个实数并提供精度：
输入：A，B，精度
输出：（abs（AB）< = 10 ^（ - precision） ）
例如：
A = 1.00000000000001
B = 1.00000000000007
精度= 13
abs（AB）= 0.00000000000006
10 ^（ - 精度）= 0.0000000000001
abs（AB）< = 10 ^（ - 精度）=真
精度= 14
10 ^（ - 精度）= 0.00000000000001
abs（AB）< = 10 ^（ - precision）= false
对于我正在进行的项目，有多个操作
有实数，我想确定，有一些陷阱我可能会跌入
in。比较没有自定义ApproximatelyEqual
方法的实数是否安全？
谢谢，
Pavils
对于真正的精确度，请使用十进制类型。是慢于双倍和
使用更多内存，但它更适合精确计算。
-
cody
免费软件工具，游戏和幽默
http://www.deutronium.de.vu || http://www.deutronium.tk
" Pavils Jurjans" < PA **** @ mailbox.riga.lv> schrieb im Newsbeitrag
新闻：e8 ************** @ TK2MSFTNGP10.phx.gbl ...你好，
由于计算机必须以有限的字节集存储真实的数字，因此导致可能存储的小数值的微小不精确，这是已知的问题。我不知道，dotnet框架如何存储双打，但是可以肯定的是，如果我将1.234567存储在一些实际变量中，它会被存储在内存中，就像接近
1.2345670000000000000003454786544或
1.23456699999999999999999999999999999924354324。
由于这个问题，当比较if中的实数时，它有时可能会导致一些意想不到的结果。声明。
一些编程语言有内置保护，仅比较有限数量的数字（小于声明的类型的能力），当要求比较两个真实数字，因此较小的十进制
字段中的垃圾不被注意。我一直在使用ApproximatelyEqual。方法，
用于比较两个实数并提供精度：
输入：A，B，精度
输出：（abs（AB）< = 10 ^（ - precision） ）
例如：
A = 1.00000000000001
B = 1.00000000000007
精度= 13
abs（AB）= 0.00000000000006
10 ^（ - 精度）= 0.0000000000001
abs（AB）< = 10 ^（ - 精度）=真
精度= 14
10 ^（ - 精度）= 0.00000000000001
abs（AB）< = 10 ^（ - precision）= false
对于我正在进行的项目，有多个操作
有实数，我想确定，有一些陷阱我可能会跌入
in。比较没有自定义ApproximatelyEqual
方法的实数是否安全？
谢谢，
Pavils
>为什么你不使用双倍？
使用双重类型无法解决这个问题。
Pavils
Hallo,
It is know issue that due to the fact that computer has to store the real
numbers in limited set of bytes, thus causing a minor imprecision from the
decimal value that likely was stored. I don''t know, how dotnet framework
stored doubles, but it''s certain, that if I store, say, 1.234567 in some
real variable, it is stored in memory like something close to
1.2345670000000000000003454786544 or
1.234566999999999999999999999999999924354324.
Due to this problem it may sometimes cause some unexpected results when
comparing the real numbers in "if" statement.
Some programming languages have built-in protection, that compares only
limited number of digits (less than declared capability of the type), when
asked to compare two real numbers, thus the garbage in the lesser decimal
fields goes unnoticed. I have been using an "ApproximatelyEqual" method, for
comparing two real numbers and providing precision:
input: A, B, precision
output: (abs(A-B) <= 10^(-precision))
Example:
A = 1.00000000000001
B = 1.00000000000007
precision = 13
abs(A-B) = 0.00000000000006
10^(-precision) = 0.0000000000001
abs(A-B) <= 10^(-precision) = true
precision = 14
10^(-precision) = 0.00000000000001
abs(A-B) <= 10^(-precision) = false
For a project I am working on, where there are done multiple operations with
real numbers, I wanted to be sure, where there are some traps I may fall in.
Is it safe to compare the real numbers without custom "ApproximatelyEqual"
method?
Thanks,
Pavils
Why you don''t use double?
"Pavils Jurjans" <pa****@mailbox.riga.lv> schrieb im Newsbeitrag
news:e8**************@TK2MSFTNGP10.phx.gbl...Hallo,
It is know issue that due to the fact that computer has to store the real
numbers in limited set of bytes, thus causing a minor imprecision from the
decimal value that likely was stored. I don''t know, how dotnet framework
stored doubles, but it''s certain, that if I store, say, 1.234567 in some
real variable, it is stored in memory like something close to
1.2345670000000000000003454786544 or
1.234566999999999999999999999999999924354324.
Due to this problem it may sometimes cause some unexpected results when
comparing the real numbers in "if" statement.
Some programming languages have built-in protection, that compares only
limited number of digits (less than declared capability of the type), when
asked to compare two real numbers, thus the garbage in the lesser decimal
fields goes unnoticed. I have been using an "ApproximatelyEqual" method, for comparing two real numbers and providing precision:
input: A, B, precision
output: (abs(A-B) <= 10^(-precision))
Example:
A = 1.00000000000001
B = 1.00000000000007
precision = 13
abs(A-B) = 0.00000000000006
10^(-precision) = 0.0000000000001
abs(A-B) <= 10^(-precision) = true
precision = 14
10^(-precision) = 0.00000000000001
abs(A-B) <= 10^(-precision) = false
For a project I am working on, where there are done multiple operations with real numbers, I wanted to be sure, where there are some traps I may fall in. Is it safe to compare the real numbers without custom "ApproximatelyEqual"
method?
Thanks,
Pavils
For real good precicion use the decimal type. Is is slower than double and
uses more memory but it is much more suited for precise calculations.
--
cody
Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"Pavils Jurjans" <pa****@mailbox.riga.lv> schrieb im Newsbeitrag
news:e8**************@TK2MSFTNGP10.phx.gbl...Hallo,
It is know issue that due to the fact that computer has to store the real
numbers in limited set of bytes, thus causing a minor imprecision from the
decimal value that likely was stored. I don''t know, how dotnet framework
stored doubles, but it''s certain, that if I store, say, 1.234567 in some
real variable, it is stored in memory like something close to
1.2345670000000000000003454786544 or
1.234566999999999999999999999999999924354324.
Due to this problem it may sometimes cause some unexpected results when
comparing the real numbers in "if" statement.
Some programming languages have built-in protection, that compares only
limited number of digits (less than declared capability of the type), when
asked to compare two real numbers, thus the garbage in the lesser decimal
fields goes unnoticed. I have been using an "ApproximatelyEqual" method, for comparing two real numbers and providing precision:
input: A, B, precision
output: (abs(A-B) <= 10^(-precision))
Example:
A = 1.00000000000001
B = 1.00000000000007
precision = 13
abs(A-B) = 0.00000000000006
10^(-precision) = 0.0000000000001
abs(A-B) <= 10^(-precision) = true
precision = 14
10^(-precision) = 0.00000000000001
abs(A-B) <= 10^(-precision) = false
For a project I am working on, where there are done multiple operations with real numbers, I wanted to be sure, where there are some traps I may fall in. Is it safe to compare the real numbers without custom "ApproximatelyEqual"
method?
Thanks,
Pavils
> Why you don''t use double?
Using double type will not save from this problem.
Pavils
这篇关于关于实数不精确的偏执狂的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
