问题描述
有没有人知道为什么在VB.NET中将
浮点除法（''/''）的结果转换为
整数类型，例如语句如
Dim x As Integer = 2/3''赋值后，x为1，而理智的人
会说它应该是0
微软是否有理由做出这一设计决定？我理解
这种类型的舍入可以通过减少累积错误的数量来减少长期计算链中的整体错误
忽略中间结果的小数部分，但为什么
特别是VB.NET这样做？ IMO似乎非常不自然;我不能用b $ b来考虑任何其他编程语言。如果VB.NET通过简单地删除小数点后的所有内容来执行浮点数到整数转换，那么它将更有意义。
更有意义。它使
甚至没有必要使用整数除法（''\''）运算符时
你需要明确表示你-don'' t-希望它执行
舍入。在那个问题上，我认为他们得到了''/''和''\\'''语法
倒退。恕我直言......
''/''运算符（目前是什么？b
$ b浮点除法 - 转换为舍入到 - -integer）应该
的行为类似于''/''运算符在大多数其他
编程语言中的行为：该除法应该在
$ b中执行$ b浮点数;如果结果然后转换为整数，则应该简单地抛出
小数部分而不进行任何舍入。
''\''运算符（所谓的整数除法）应该在VB.NET中执行'/''
目前所做的事情。也就是说，如果小数部分大于或等于0.5，它应该执行除法和
然后向上舍入。
想一想。大多数编程语言只有一个部门
运算符，它通常按照惯例用''/'编写。通过
约定，大多数编程语言中的'/''表示VB.NET中''\\''（整数
除法）的含义。 VB.NET完全是颠倒的。有时
我觉得微软有意不顾一切地想要遵守约定或先例，或者考虑任何可能被认为是b $ b的东西''正常。'';-)
那是我的咆哮。我很想看到其他所有人都想到的这一切，如果有人确实知道为什么微软选择以这种方式做分工
。
-
Mike S
我建议打开''Option Strict''。舍入并不是作为分区的一部分而发生的，而是由于分区'
结果的隐式转换引起的，即0.666。 ..，''整数''。由于显而易见的原因，0.666 ...四舍五入为
整数1。使用''Option Strict On''你会有'/ b $ b'来写''Dim x As Integer = CInt（2/3）''。
-
MS Herfried K. Wagner
MVP< URL：http：//dotnet.mvps.org/>
VB < URL：http：//classicvb.org/petition/>
对。我知道这不是师的一部分。这就是为什么我问为什么
将结果*转换为*整数类型。
即0.666 ...，到''整数''。 0.666 ...由于显而易见的原因四舍五入为整数1。
是否显而易见我想是经验问题。对我来说，如果转换导致分数部分被丢弃，而不是四舍五入，那么
将是显而易见的。例如，如果你用
在C ++中这样做：
#include< iostream>
int main （无效）
{
int x = 2/3;
std :: cout<< x<< std :: endl;
返回0;
}
输出为0。我认为这是显而易见的结果，因为我说，大多数编程语言将通过
进行整数转换，从而减少答案的小数部分。事实上，在VB.NET，
整数转换导致答案被舍入而不是如果你来自不同的语言背景，则反直觉。我的
点是大多数（如果不是全部）其他编程语言将
将0.66666转换为整数0，而不是1.
带'' Option Strict On''你会写''Dim x As Integer = CInt（2/3）''。
'只是一个更冗长的方式来做同样的事情：
Dim x As Integer = 2/3
，Option Strict Off（这是无论如何编译器默认）。
CInt（2/3）仍然是1.我的论点是CInt（2/3）= 0将是
更多逻辑和扩展隐式整数转换也应该是
不圆，因为隐式整数转换（显然）应该与显式CInt给出的相同。 />
我不希望改变VB.NET语言规范，我只是简单地指出
，这是非常反直觉的行为恕我直言。 ..
-
Mike S
好吧，对于像我这样拥有强大BASIC背景的人来说，
行为似乎非常直观。在执行
转换时，我不认为剥掉所有内容后小数点后的b $ b比舍入更直观。此外，我认为四舍五入更自然。因为它更好地保留了实际价值。它只是更高级别。
-
MS Herfried K. Wagner
MVP< URL： http://dotnet.mvps.org/>
VB< URL：http：//classicvb.org/petition/>
Does anyone know the logic behind why in VB.NET the result of a
floating-point division (''/'') is -rounded- on being converted to an
integer type, such as with statements like
Dim x As Integer = 2/3 ''after assignment, x is 1, whereas a sane person
would say it should be 0
Does Microsoft have a reason for this design decision? I understand
that this type of rounding can reduce the overall error in long
computation chains by reducing the amount of error that accumulates
from ignoring the fractional part of intermediate results, but why
specifically does VB.NET do this? It seems very unnatural IMO; I can''t
think of any other programming language that does this. It would make
much more sense if VB.NET performed floating-point to integer
conversions by simply dropping everything after the decimal. It makes
even less sense to have to use the integer division (''\'') operator when
you need to make it explicit that you -don''t- want it to perform
rounding. On that note, I think they got the ''/'' and ''\'' syntax
backwards. IMHO...
The ''/'' operator (what is currently
floating-point-division-with-rounding-on-conversion-to-integer) should
behave similar to how the ''/'' operator behaves in most other
programming languages: the division should be performed in
floating-point; if the result is then converted to an integer, the
fractional part should simply be thrown out without any rounding.
The ''\'' operator (so-called "integer division") should do what ''/''
currently does in VB.NET. That is, it should perform the division and
then round up if the fractional part is greater than or equal to 0.5.
Think about it. Most programming languages only have one division
operator, which is usually written with ''/'' by convention. And by
convention, ''/'' in most programming languages means what ''\'' (integer
division) means in VB.NET. VB.NET is completely upside-down. Sometimes
I get the feeling that Microsoft intentionally goes out of its way to
avoid following conventions or precedent, or anything that might be
considered ''normal.'' ;-)
That''s my rant. I''m interested to see what everyone else thinks of all
this, and if anyone indeed knows why Microsoft chose to do division
this way.
--
Mike S
I recommend to turn ''Option Strict'' on. The rounding doesn''t occur as part
of the division, it''s caused by the implicit conversion of the division''s
result, which is 0.666..., to ''Integer''. 0.666... is rounded to the
integral number 1 for obvious reasons. With ''Option Strict On'' you''ll have
to write ''Dim x As Integer = CInt(2 / 3)''.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Right. I know it''s not part of the division. That''s why I asked why
does it round the result *on being converted to* an integer type.
which is 0.666..., to ''Integer''. 0.666... is rounded to the
integral number 1 for obvious reasons.
Whether it''s "obvious" is a matter of experience, I guess. To me, it
would be obvious if the the conversion caused the fractional part to be
discarded, rather than for the rounding to occur. For example, if you
do this in C++:
#include <iostream>
int main(void)
{
int x = 2/3;
std::cout << x << std::endl;
return 0;
}
The output will be ''0''. I think this is the obvious result because, as
I said, most programming languages will do integer conversions by
dropping the fractional part of the answer. The fact that in VB.NET,
the integer conversion causes the answer to be rounded instead is
counter-intuitive if you come from a different language background. My
point is that most, if not all, other programming languages would
convert 0.66666 to integer 0, not 1.
With ''Option Strict On'' you''ll have
to write ''Dim x As Integer = CInt(2 / 3)''.
That''s just a more verbose way to do the same thing as:
Dim x As Integer = 2 / 3
with Option Strict Off (which is the compiler default anyway).
CInt(2 / 3) is still 1. My argument is that CInt(2 / 3) = 0 would be
more logical and by extension implicit integer conversions should also
not round, since an implicit integer conversion should (obviously) be
the same as what an explicit CInt would give.
I''m not hoping to change the VB.NET language specs, I''m simply pointing
out that this is awfully counter-intuitive behavior IMHO...
--
Mike S
Well, for somebody like me who is having a strong BASIC background the
behavior seems very intuitive. I don''t think that stripping off everything
after the decimal point is more intuitive than rounding when performing the
conversion. Moreover I think that rounding is more "natural" because it
better preserves the actual value. It''s simply more high-level.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
这篇关于将“/”除法的结果分配给整数类型会导致舍入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！