常见问题主题 - 如何将数字转换为精确到2位小数的字符串？ [英] FAQ Topic - How do I convert a Number into a String with exactly 2 decimal places?
问题描述
----------------------------------------------- ------------------------
常见问题解答主题 - 如何使用
$将数字转换为字符串b $ b正好是2位小数？
---------------------------------- -------------------------------------
什么时候格式化钱，例如，格式化6.57634到
6.58,6.5到6.50和6到6.00？
舍入x.xx5是不确定的，因此数字不是
完全代表。有关舍入问题，请参阅第4.7节。
N = Math.round（N * 100）/ 100仅将N转换为值数值
接近a 0.01的倍数;但document.write（N）不给
尾随零。
ECMAScript Ed。 3.0（JScript 5.5 [但是buggy]和JavaScript 1.5）
介绍了N.toFixed，这个主要问题是
JScripts实现中的错误。
大多数实现都失败了一些数字，例如0.07。
以下适用于M> 0，N> 0：
函数Stretch（Q，L，c）{var S = Q
if（c.length> 0）while（S.length< L）{S = c + S}
返回S
}
函数StrU（X，M，N）{// X> = 0.0
var T， S = new String（Math.round（X * Number（" 1e" + N）））
if（S.search&& S.search（/ \ D /）！ = -1）{return''''+ X}
with（new String（Stretch（S，M + N，''0''）））
return substring（0，T =（length-N））+''。''+ substring（T）
}
function Sign（X）{return X< 0？ '' - ''：''''; }
函数StrS（X，M，N）{返回符号（X）+ StrU（Math.abs（X），M，N）}
Number.prototype.toFixed = new函数（''n''，''返回StrS（this，1，n）''）
http://www.merlyn.demon.co.uk/js-round.htm
http://msdn.microsoft.com/library/de...34c0f6d6f0.asp
===
这样的发布每天自动发送一次。他们的b
目标是回答重复的问题，并将内容提供给社区进行持续评估/改进。完整的
comp.lang.javascript常见问题解答位于 http： //jibbering.com/faq/index.html 。
FAQ工作人员是一群志愿者。
2月12日凌晨3:00，FAQ服务器 < javascr ... @ dotinternet.bewrote：
舍入x.xx5是不确定的，因为这些数字不是
完全代表。
另一件需要修理的事情 - 连同我之后的舍入程序
完成。
1.035很高兴地存储在IEEE-754 DP-FP中而没有丢失位数。
相同的说1.055 - IEEE-754单精度有点损失但是
与IEEE-754主题无关。
如果完全用于某些其他特殊含义那么请问
有人解释一下吗？ AFAICT这是一些遗留的errouneus结果
解释要更正。
有关舍入问题，请参阅第4.7节。
这是一个有趣的问题，需要在强大的
舍入算法发布之前解决。
对于结果检查一个人需要安装任何版本的IE，其他人
必须信任我:-)
按规格，JavaScript和JScript都实现了IEEE- 754 DP-FP，所以
相同的VBScript双号（？）我不完全确定
VBScript，但是使用JavaScript / JScript它是采取什么给定。
现在让我们进行两次IEEE-754 DP-FP规则的附加操作。
我从FAQ中取值4.7及其周围。抱歉，如果有人有这些不需要的
换行符：此事需要相当长的
序列。您可能需要重新调整您的新闻阅读器设置。
所以：
另外1：0.05 + 0.01
A + 1.100110011001100110011001100110011001100110011001 1010 * 2-5 =
B + 1.010001111010111000010100011110101110000101000111 1011 * 2-7 =
0.01
对齐步骤
A + 1.100110011001100110011001100110011001100110011001 1010 | 000 * 2-5
B + 0.010100011110101110000101000111101011100001010001 1110 | 110 * 2-5
A + B + 1.111010111000010100011110101110000101000111101011 1000 | 110 * 2-5
后正规化步骤
A + B + 1.111010111000010100011110101110000101000111101011 1000 | 11 * 2- 5
隐含舍入规则可能产生的结果：
回合零
A + B + 1.111010111000010100011110101110000101000111101011 1000 * 2-5 =
0.06
即将到来的最后一周
A + B + 1.1110101110000101 00011110101110000101000111101011 1001 * 2-5 =
0.060000000000000005
回合无穷大
A + B + 1.111010111000010100011110101110000101000111101011 1001 * 2-5 =
0.060000000000000005
回合减去无限
A + B + 1.111010111000010100011110101110000101000111101011 1000 * 2-5 =
0.06
实际JS结果：0.060000000000000005
实际VBS结果：0.06
---- ------------------------
加法2：0.06 + 0.01
A + 1.111010111000010100011110101110000101000111101011 1000 * 2-5 =
0.06
B + 1.010001111010111000010100011110101110000101000111 1011 * 2-7 =
0.01
对齐步骤
A + 1.111010111000010100011110101110000101000111101011 1000 | 000 * 2-5
B + 0.010100011110101110000101000111101011100001010001 1110 | 110 * 2-5
A + B + 10.0011110101110000 1010001111010111000010100011110 10110 | 110
* 2-5
后正规化步骤
A + B + 1.000111101011100001010001111010111000010100011110 1011 | 11 * 2-4
隐式舍入规则可能产生的结果：
回合零
A + B + 1.000111101011100001010001111010111000010100011110 1011 * 2-4 =
0.06999999999999999
回合最近的偶数
A + B + 1.000111101011100001010001111010111000010100011110 1100 * 2-4 =
0.07
Round to Plus Infinity
A + B + 1.000111101011100001010001111010111000010100011110 1100 * 2-4 =
0.07
轮到减去无限
A + B + 1.000111101011100001010001111010111000010100011110 1011 * 2-4 =
0.06999999999999999
实际JS结果：0.06999999999999999
实际VBS结果：0.07
------------- ----------------
简单的comp很明显，J（ava）脚本和
VBScript都不符合IEEE-754 DP-FP Round To Nearest Even规则 -
这应该是默认值内部舍入IEEE-754
规格。此外，在任何一种情况下，很难说_what_舍入规则是
的默认值。我的印象是，在纯IEEE-754之上添加了一些额外的运行时逻辑。
我错误地解释了结果。
-----------------------------
测试结果是通过以下两个几乎完全相同的页面获得的。
VBScript中的类型支持与VBA和其他更强大的Basic方言相比更加卑鄙。所以为了确保
不是一些隐藏的douncasting我通过VarType使用了一种环绕的方式。
在任何一种情况下，单独的JavaScript结果都很奇怪 - 再次如果
我对生产架构是对的。
---------------------- -------
< html>
< head>
< title>加法1< / title>
< meta http-equiv =" Content-Type"
content =" text / html; charset = iso-8859-1">
< script type =" text / javascript">
function init（）{
var MyForm = document.forms [0];
MyForm.output.value + =''JS：\ n''+
''0.05 + 0.01 =''+（0.05 + 0.01）+
''\ nNIEEE-754双精度浮点数'';
}
window.onload = init;
< / script>
< script type =" text / vbscript">
Sub Window_OnLoad
Dim MyForm
昏暗的结果，ResultType
Dim NL
设置MyForm = Document.forms.item（0）
结果= 0.05 + 0.01
如果是VarType （结果）= 5然后
ResultType ="（IEEE-754？）双精度浮点数"
否则
ResultType =精度不足的类型
结束如果
NL = vbNewLine
MyForm.output。值= MyForm.output.value& _
NL& NL& " VBS：" &安培; NL& 0.05 + 0.01 = &安培; _
结果& NL& ResultType
结束子
< / script>
< / head>
< body>
< form action ="">
< fieldset>
< legend>输出< / legend>
< textarea name =" output" COLS = QUOT; 64" rows =" 8">< / textarea>
< / fieldset>
< / form>
< /正文>
< / html>
----------------------- ------
< html>
< head>
< title> Addition 2< / title>
< meta http-equiv =" Content-Type"
content =" text / html; charset = iso-8859-1">
< script type =" text / javascript">
function init（）{
var MyForm = document.forms [0];
MyForm.output.value + =''JS：\ n''+
''0.06 + 0.01 =''+（0.06 + 0.01）+
''\ nNIEEE-754双精度浮点数'';
}
window.onload = init;
< / script>
< script type =" text / vbscript">
Sub Window_OnLoad
Dim MyForm
昏暗的结果，ResultType
Dim NL
设置MyForm = Document.forms.item（0）
结果= 0.06 + 0.01
如果是VarType （结果）= 5然后
ResultType ="（IEEE-754？）双精度浮点数"
否则
ResultType =精度不足的类型
结束如果
NL = vbNewLine
MyForm.output。值= MyForm.output.value& _
NL& NL& " VBS：" &安培; NL& 0.06 + 0.01 = &安培; _
结果& NL& ResultType
结束子
< / script>
< / head>
< body>
< form action ="">
< fieldset>
< legend>输出< / legend>
< textarea name =" output" COLS = QUOT; 64" rows =" 8">< / textarea>
< / fieldset>
< / form>
< /正文>
< / html>
VK写道：
2月12日凌晨3点，FAQ服务器写道：
> x.xx5的舍入是不确定的，因为这些数字不是
完全代表。
需要修复的另一件事 - 与我的b
完成后的舍入过程一起完成。
1.035很高兴地存储在IEEE-754 DP-FP中，没有位丢失。
如果你不同意所有人的意见那么至少你可以b / b $ b发表某种形式的演示。结果我们得出了这个结论。
然后有人可以告诉你，你的错误概念导致了哪一个错误的结论。
相同而言1.055 - 在IEEE上有点损失-754单精度但
与IEEE-754主题无关。
如果完全用于某些其他特殊含义然后请
任何人都可以解释？ AFAICT这是一些遗留的errouneus结果
解释得到纠正。
完全正确的意思。您需要做的是解释为什么您认为
语句不正确。
< snip>
通过简单的比较，很明显J（ava）脚本
和VBScript都不符合IEEE-754 DP-FP Round To Nearest
甚至规则 - 应该是IEEE-754规范的默认内部
四舍五入。此外很难说
_what_舍入规则是两种情况下的默认值。
我的印象是存在一些额外的运行时逻辑
在纯IEEE-754上面添加。我有可能将
误解为结果。
< snip>
你肯定错误地解释了结果。看看
如何javascript将源代码中的数字文字转换为
IEEE双精度浮点数（正如我上次告诉你的那样;它是
在ECMA 262，第3版，第7.8.3节）。你在哪里找到类似的细节
for VBScript是另一回事，JScript并非没有自己的
错误，但是你无法说出任何有用的操作
是根据IEEE双精度浮点数执行的，直到你知道你真正用什么数字开头的
。在此之前所有
来自你的噪音浪费了每个人的时间。
Richard。
2月13日，上午1:58，Richard Cornford < Rich ... @ litotes.demon.co.uk>
写道：
VK写道：
2月12日凌晨3:00，FAQ服务器写道：
舍入x.xx5是不确定的，因为这样的数字不是完全代表
。
另一件需要修复的事情 - 与
我的完成后的舍入过程一起完成。
1.035很高兴地存储在IEEE-754 DP-FP中，没有丢失位。
如果你不同意所有人的意见那么至少你可以b / b $ b发表某种形式的演示结果我们得出了这个结论。
我无意不同意所有人。我无意以
与IEEE-754标准争论 - 尽管实际的
功能可能因实现而有所不同。
1.035在IEEE-754 DP-FP表格中存储为
00111111111100001000111101011100001010001111010111 00001010001111
SEEEEEEEEEEEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
可以你指出可能会发生什么样的损失？
更可能是有人在尾数中找不到领先的1 -
因为它是_implied_但是未呈现非零指数：
并且由此产生错误的精确损失。得出结论。
-----------------------------------------------------------------------
FAQ Topic - How do I convert a Number into a String with
exactly 2 decimal places?
-----------------------------------------------------------------------
When formatting money for example, to format 6.57634 to
6.58, 6.5 to 6.50, and 6 to 6.00?
Rounding of x.xx5 is uncertain, as such numbers are not
represented exactly. See section 4.7 for Rounding issues.
N = Math.round(N*100)/100 only converts N to a Number of value
close to a multiple of 0.01; but document.write(N) does not give
trailing zeroes.
ECMAScript Ed. 3.0 (JScript 5.5 [but buggy] and JavaScript 1.5)
introduced N.toFixed, the main problem with this is the bugs in
JScripts implementation.
Most implementations fail with certain numbers, for example 0.07.
The following works successfully for M>0, N>0:
function Stretch(Q, L, c) { var S = Q
if (c.length>0) while (S.length<L) { S = c+S }
return S
}
function StrU(X, M, N) { // X>=0.0
var T, S=new String(Math.round(X*Number("1e"+N)))
if (S.search && S.search(/\D/)!=-1) { return ''''+X }
with (new String(Stretch(S, M+N, ''0'')))
return substring(0, T=(length-N)) + ''.'' + substring(T)
}
function Sign(X) { return X<0 ? ''-'' : ''''; }
function StrS(X, M, N) { return Sign(X)+StrU(Math.abs(X), M, N) }
Number.prototype.toFixed= new Function(''n'',''return StrS(this,1,n)'')
http://www.merlyn.demon.co.uk/js-round.htm
http://msdn.microsoft.com/library/de...34c0f6d6f0.asp
===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers.
On Feb 12, 3:00 am, "FAQ server" <javascr...@dotinternet.bewrote:Rounding of x.xx5 is uncertain, as such numbers are not
represented exactly.Another thing to fix - together with the rounding proc after mine is
done.
1.035 is happily stored in IEEE-754 DP-FP without bit loss.
Same for say 1.055 - with a bit loss on IEEE-754 single-precision but
it is irrelevant for IEEE-754 topics.
If "exactly" is used in some other special meaning then please could
anyone explain? AFAICT it is some legacy errouneus results
interpretation to be corrected.
See section 4.7 for Rounding issues.That is really an interesting question to solve before a robust
rounding algorithm released.
For the results check one needs any version of IE installed, others
have to trust me :-)
By specs both JavaScript and JScript implements IEEE-754 DP-FP, so
same for VBScript Double numbers (?) I''m not totally sure about
VBScript, but with JavaScript/JScript it is what is taken as given.
Now let''s take two addition operations made by IEEE-754 DP-FP rules.
I''m taking values from FAQ 4.7 and around them. Sorry for unwanted
line breaks if anyone has them: the matter requires rather long
sequences. You may want to re-adjust your news reader settings then.
So:
Addition 1 : 0.05 + 0.01
A + 1.100110011001100110011001100110011001100110011001 1010 *2-5 =
0.05
B + 1.010001111010111000010100011110101110000101000111 1011 *2-7 =
0.01
Alignment Step
A + 1.100110011001100110011001100110011001100110011001 1010|000 *2-5
B + 0.010100011110101110000101000111101011100001010001 1110|110 *2-5
A+B + 1.111010111000010100011110101110000101000111101011 1000|110 *2-5
Postnormalization Step
A+B + 1.111010111000010100011110101110000101000111101011 1000|11 *2-5
Possible outcome by the implicit rounding rule:
Round to Zero
A+B + 1.111010111000010100011110101110000101000111101011 1000 *2-5 =
0.06
Round to Nearest Even
A+B + 1.111010111000010100011110101110000101000111101011 1001 *2-5 =
0.060000000000000005
Round to Plus Infinity
A+B + 1.111010111000010100011110101110000101000111101011 1001 *2-5 =
0.060000000000000005
Round to Minus Infinity
A+B + 1.111010111000010100011110101110000101000111101011 1000 *2-5 =
0.06
Actual JS outcome: 0.060000000000000005
Actual VBS outcome: 0.06
----------------------------
Addition 2 : 0.06 + 0.01
A + 1.111010111000010100011110101110000101000111101011 1000 *2-5 =
0.06
B + 1.010001111010111000010100011110101110000101000111 1011 *2-7 =
0.01
Alignment Step
A + 1.111010111000010100011110101110000101000111101011 1000|000 *2-5
B + 0.010100011110101110000101000111101011100001010001 1110|110 *2-5
A+B + 10.00111101011100001010001111010111000010100011110 10110|110
*2-5
Postnormalization Step
A+B + 1.000111101011100001010001111010111000010100011110 1011|11 *2-4
Possible outcome by the implicit rounding rule:
Round to Zero
A+B + 1.000111101011100001010001111010111000010100011110 1011 *2-4 =
0.06999999999999999
Round to Nearest Even
A+B + 1.000111101011100001010001111010111000010100011110 1100 *2-4 =
0.07
Round to Plus Infinity
A+B + 1.000111101011100001010001111010111000010100011110 1100 *2-4 =
0.07
Round to Minus Infinity
A+B + 1.000111101011100001010001111010111000010100011110 1011 *2-4 =
0.06999999999999999
Actual JS outcome: 0.06999999999999999
Actual VBS outcome: 0.07
-----------------------------
By simple comparison it is obvious that neither J(ava)Script nor
VBScript are conforming IEEE-754 DP-FP Round To Nearest Even rule -
which is supposed to be the default internal rounding by IEEE-754
specs. Moreover it is difficult to say _what_ rounding rule is the
default one in either case. I have an impression that there is some
extra run-time logic added atop of pure IEEE-754.
It is as well possible that I misinterpreted the results.
-----------------------------
The test results are obtained over two nearly identical pages below.
The type support in VBScript is pretty much bastardized in comparison
to VBA and other more powerful Basic dialects. So to ensure that there
is not some hidden douncasting I used a round-around way via VarType.
In either case JavaScript results alone are rather strange - again if
I''m right with the production schema.
-----------------------------
<html>
<head>
<title>Addition 1</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
var MyForm = document.forms[0];
MyForm.output.value += ''JS:\n'' +
''0.05 + 0.01 = '' + (0.05 + 0.01) +
''\nIEEE-754 Double-Precision Floating-Point number'';
}
window.onload = init;
</script>
<script type="text/vbscript">
Sub Window_OnLoad
Dim MyForm
Dim Result, ResultType
Dim NL
Set MyForm = Document.forms.item(0)
Result = 0.05 + 0.01
If VarType(Result) = 5 Then
ResultType = "(IEEE-754 ?) Double-Precision Floating-Point number"
Else
ResultType = "a under-precision type"
End If
NL = vbNewLine
MyForm.output.value = MyForm.output.value & _
NL & NL & "VBS:" & NL & "0.05 + 0.01 = " & _
Result & NL & ResultType
End Sub
</script>
</head>
<body>
<form action="">
<fieldset>
<legend>Output</legend>
<textarea name="output" cols="64" rows="8"></textarea>
</fieldset>
</form>
</body>
</html>
-----------------------------
<html>
<head>
<title>Addition 2</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
var MyForm = document.forms[0];
MyForm.output.value += ''JS:\n'' +
''0.06 + 0.01 = '' + (0.06 + 0.01) +
''\nIEEE-754 Double-Precision Floating-Point number'';
}
window.onload = init;
</script>
<script type="text/vbscript">
Sub Window_OnLoad
Dim MyForm
Dim Result, ResultType
Dim NL
Set MyForm = Document.forms.item(0)
Result = 0.06 + 0.01
If VarType(Result) = 5 Then
ResultType = "(IEEE-754 ?) Double-Precision Floating-Point number"
Else
ResultType = "a under-precision type"
End If
NL = vbNewLine
MyForm.output.value = MyForm.output.value & _
NL & NL & "VBS:" & NL & "0.06 + 0.01 = " & _
Result & NL & ResultType
End Sub
</script>
</head>
<body>
<form action="">
<fieldset>
<legend>Output</legend>
<textarea name="output" cols="64" rows="8"></textarea>
</fieldset>
</form>
</body>
</html>
VK wrote:On Feb 12, 3:00 am, FAQ server wrote:>Rounding of x.xx5 is uncertain, as such numbers are not
represented exactly.
Another thing to fix - together with the rounding proc after
mine is done.
1.035 is happily stored in IEEE-754 DP-FP without bit loss.If you are going to disagree with everyone about that the least you could
do is post some sort of demonstration of whatever it was that resulted in
our making that conclusion. Then someone could tell you which of your
misconceptions resulted in your erroneous conclusion.
Same for say 1.055 - with a bit loss on IEEE-754 single-precision but
it is irrelevant for IEEE-754 topics.
If "exactly" is used in some other special meaning then please
could anyone explain? AFAICT it is some legacy errouneus results
interpretation to be corrected.Exactly means exactly. What you need to do is explain why you think the
statement is incorrect.
<snip>By simple comparison it is obvious that neither J(ava)Script
nor VBScript are conforming IEEE-754 DP-FP Round To Nearest
Even rule - which is supposed to be the default internal
rounding by IEEE-754 specs. Moreover it is difficult to say
_what_ rounding rule is the default one in either case.
I have an impression that there is some extra run-time logic
added atop of pure IEEE-754. It is as well possible that I
misinterpreted the results.<snip>
It is dam near certain you misinterpret the results. Stat with looking at
how javascript transforms a numeric literal in its source code into an
IEEE double precision floating-point number (as I told you last time; it
is in ECMA 262, 3rd Ed. Section 7.8.3). Where you find similar details
for VBScript is a different matter, and JScript is not without its own
bugs, but you will not be able to say anything useful about operations
performed upon IEEE double precision floating point numbers until you
know what numbers you are really handing to start with. Until then all
this noise from you is a waste of everyone''s time.
Richard.
On Feb 13, 1:58 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:VK wrote:On Feb 12, 3:00 am, FAQ server wrote:Rounding of x.xx5 is uncertain, as such numbers are not
represented exactly.
Another thing to fix - together with the rounding proc after
mine is done.
1.035 is happily stored in IEEE-754 DP-FP without bit loss.
If you are going to disagree with everyone about that the least you could
do is post some sort of demonstration of whatever it was that resulted in
our making that conclusion.I have no intention to disagree with "everyone". I have no intention
to argue with IEEE-754 standards for instance - though the actual
functionning may differ by implementations.
1.035 in IEEE-754 DP-FP form is stored as
00111111111100001000111101011100001010001111010111 00001010001111
SEEEEEEEEEEEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFF
Can you point where exactly a bit loss may occur?
More probably someone just couldn''t find the leading 1 in mantissa -
because it is _implied_ but not presented with a non-zero exponent:
and from this a false "precision loss" conclusion was drawn.
这篇关于常见问题主题 - 如何将数字转换为精确到2位小数的字符串？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
