FAQ Topic - How do I convert a Number into a String with exactly 2 decimal places?
FAQ server
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.
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/en-us/script56/html/js56jsmthToFixed.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://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.
Dr J R Stockton
<457f428a$0$49209$1472...@news.sunsite.dk>, Wed, 13 Dec 2006 00:00:01,
FAQ server <javas...@dotinternet.be> wrote:
> 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) }
The functions on my site have been updated since that was put in the
FAQ.
function Sign(X) { return X>0 ? "+" : X<0 ? "-" : " " }
function PrfxTo(S, L, C) { S += ""
if (C.length>0) while (S.length<L) S = C + S ; return S }
function SpcsTo(S, L) { S += "" // SpcsTo is a reduction of PrfxTo
while (S.length<L) S = " " + S ; return S }
function StrU(X, M, N) { // X > -0.5e-N ; to M digits point N digits
var S = String(Math.round(X*Math.pow(10, N)))
if (/\D/.test(S)) return SpcsTo(X, M+N+1) // cannot cope
S = PrfxTo(S, M+N, '0') ; var T = S.length - N
return S.substring(0, T) + '.' + S.substring(T) }
function StrS(X, M, N) { return Sign(X) + StrU(Math.abs(X), M, N) }
Given that some of the function set are intended to give fixed-width
results, ISTM that Sign should give fixed-width output. When that's
*not* wanted, removing a bit of the code will be easy.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
<URL:http://www.jibbering.com/faq/> A FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Randy Webb
All of the code snippets, every one of them, will be reviewed and
re-written for 10.0 with some documentation and better variable names to
make them easier for newbes to be able to read and learn from. The FAQ
isn't geared to experienced users that can decipher code such as that
above, it is for people who *can't* write code such as that above but
want to learn from it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
RobG
Randy Webb wrote:
[...]
> All of the code snippets, every one of them, will be reviewed and
> re-written for 10.0 with some documentation and better variable names to
> make them easier for newbes to be able to read and learn from. The FAQ
> is for people who *can't* write code such as that above but
> want to learn from it.
Amen to that.
--
Rob
Dr J R Stockton
Wed, 13 Dec 2006 21:35:57, Randy Webb <HikksNo...@aol.com> wrote:
>
>All of the code snippets, every one of them, will be reviewed and re-
>written for 10.0 with some documentation and better variable names to
>make them easier for newbes to be able to read and learn from. The FAQ
>isn't geared to experienced users that can decipher code such as that
>above, it is for people who *can't* write code such as that above but
>want to learn from it.
Where a FAQ entry is headed by a request for an algorithm, a coding
tutorial is not called for. The Notes are the place for that.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Randy Webb
> In comp.lang.javascript message <8eKdnfuCxe4...@telcove.net>,
> Wed, 13 Dec 2006 21:35:57, Randy Webb <HikksNo...@aol.com> wrote:
>> All of the code snippets, every one of them, will be reviewed and re-
>> written for 10.0 with some documentation and better variable names to
>> make them easier for newbes to be able to read and learn from. The FAQ
>> isn't geared to experienced users that can decipher code such as that
>> above, it is for people who *can't* write code such as that above but
>> want to learn from it.
>
> Where a FAQ entry is headed by a request for an algorithm, a coding
> tutorial is not called for. The Notes are the place for that.
Is there a point to that? I will repeat what I said "All of the code
snippets, every one of them, will be reviewed and *rewritten for 10.0*.
krs
On Dec 13 2006, 2:32 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
wrote:
> FAQ server <javascr...@dotinternet.be> wrote:
> The functions on my site have been updated since that was put in the
> FAQ.
>
> function Sign(X) { return X>0 ? "+" : X<0 ? "-" : " " }
>
> function PrfxTo(S, L, C) { S += ""
> if (C.length>0) while (S.length<L) S = C + S ; return S }
>
> function SpcsTo(S, L) { S += "" // SpcsTo is a reduction of PrfxTo
> while (S.length<L) S = " " + S ; return S }
>
> function StrU(X, M, N) { // X > -0.5e-N ; to M digits point N digits
> var S = String(Math.round(X*Math.pow(10, N)))
> if (/\D/.test(S)) return SpcsTo(X, M+N+1) // cannot cope
> S = PrfxTo(S, M+N, '0') ; var T = S.length - N
> return S.substring(0, T) + '.' + S.substring(T) }
>
> function StrS(X, M, N) { return Sign(X) + StrU(Math.abs(X), M, N) }
>
> Given that some of the function set are intended to give fixed-width
> results, ISTM that Sign should give fixed-width output. When that's
> *not* wanted, removing a bit of the code will be easy.
can someone else confirm that StrS(1.035,1,2) returns +1.03, instead of
the correct value of +1.04, on Firefox2 (winxp)?
-ks
Evertjan.
Both FF2.0.0.1 and IE7 return:
+1.03
Why would +1.04 be the correct value?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
VK
Evertjan. wrote:
> > can someone else confirm that StrS(1.035,1,2) returns +1.03, instead
> > of the correct value of +1.04, on Firefox2 (winxp)?
>
> Both FF2.0.0.1 and IE7 return:
>
> +1.03
>
> Why would +1.04 be the correct value?
Because:
If the number you are rounding is followed by 5, 6, 7, 8, or 9, the
number has to be rounded up.
If the number you are rounding is followed by 0, 1, 2, 3, or 4, round
the number down.
If some other rounding logic implemented then it must be spelled in the
code comments.
In this aspect the native toFixed method follows the common rounding
rules only on IE (JScript):
alert(1.035.toFixed(2)); // gives 1.04
Both FF and Opera show 1.03
But alert(1.036.toFixed(2)); // show 1.04 on all test browsers
This way FF and Opera seems implementing an altered rounding rule:
If the number you are rounding is followed by 6, 7, 8, or 9, the number
has to be rounded up.
If the number you are rounding is followed by 0, 1, 2, 3, 4 or 5 round
the number down.
Could anyone comment on "the bugs in JScripts implementation" - what is
exactly meant by that?
Evertjan.
1
I would prefer to use regex when molding a string into shape:
<script type='text/javascript'>
function toFixed2prot(N) {
var re = new RegExp('(\d{'+N+'})$','')
return Math.floor(this*Math.pow(10, N)+.5).toString()
.replace(/(\d{2}$)/,'.$1')
}
Number.prototype.toFixed2 = toFixed2prot
// testing:
var x = (1.0351).toFixed2(2)
document.write(x+'<br>')
var x = (1.035).toFixed2(2)
document.write(x+'<br>')
</script>
The 1.035 problem i will adress in answer to VK
Evertjan.
> Evertjan. wrote:
>> > can someone else confirm that StrS(1.035,1,2) returns +1.03, instead
>> > of the correct value of +1.04, on Firefox2 (winxp)?
>>
>> Both FF2.0.0.1 and IE7 return:
>>
>> +1.03
>>
>> Why would +1.04 be the correct value?
>
> Because:
> If the number you are rounding is followed by 5, 6, 7, 8, or 9, the
> number has to be rounded up.
> If the number you are rounding is followed by 0, 1, 2, 3, or 4, round
> the number down.
>
True, if you define it that way, but a totally wrong argument.
document.write(1.035 + 0.005);
will return:
1.0399999999999998
so a decimal string like 1.035 seems to be internally represented and
stored by something a bit less than exactly 1.035.
When rounding 1.035 so in reality something like 1.0344444444444449,
would you expect the .toFixed to make an educated guess if
eiter 1.035 or 1.0344444444444449 was entered, as a string of the source
code or in a user input, before it was stored?
No. I for one would not! That is not the job expected from either
Math.round() or .toFixed().
I would have those functions to do exactly what is intended and fix the
problem of the binary conversion [the root of all this evil] sepretately.
If I needed to have an exact BCD [Binary Coded Decimal] effect,
I better construct this myself using strings or integer values with
exponents.
====================
btw:
That
document.write(1.035);
outputs:
1.035
is probably an effect of internal rounding by the write()
and the alert() methods.
document.write(1.0344444444444449);
outputs:
1.034444444444445
also a rounding effect, it seems.
VK
Evertjan. wrote:
> document.write(1.035 + 0.005);
>
> will return:
>
> 1.0399999999999998
>
> so a decimal string like 1.035 seems to be internally represented and
> stored by something a bit less than exactly 1.035.
I thought that the proposed proc was for rounding _provided_ numbers,
not for rounding internal IEEE-754 representations. The whole purpose
of such algorithm IMO is to make as close as possible i) the strict
"human" math learned at the school and ii) the approximate PC math. If
it was not a purpose then this code is misplaced to FAQ - let it be
moved to some PC-math specific site. For a user seeking for a quick
answer it is irrelevant that
US$ calculated price of 10.05 is really internally stored as
10.05XXXXXXXXXXX. All she wants to know is now to round it without
monetarily abusing himself or her buyer.
> When rounding 1.035 so in reality something like 1.0344444444444449,
> would you expect the .toFixed to make an educated guess if
> eiter 1.035 or 1.0344444444444449 was entered, as a string of the source
> code or in a user input, before it was stored?
Yes, absolutely. Rounding goes from rightmost number to left, with
0,1,3,4 rounded down and 5,6,7,8,9 rounded up. This is the school/bank
math and the proc either has to work this way or no use of it.
>1.0344444444444449
>1.034444444444445
>1.03444444444445
>1.0344444444445
>1.034444444445
>1.03444444445
>1.0344444445
>1.034444445
>1.03444445
>1.0344445
>1.034445
>1.03445
>1.0345
>1.035
If some proc cannot outperform this then no use to start the mess on
the first place, as there are no advantages over the native toFixed()
method.
Evertjan.
> If some proc cannot outperform this then no use to start the mess on
> the first place, as there are no advantages over the native toFixed()
> method.
>
Indeed.
However, I think there where / are some real bugs in .toFixed,
that have to be fixed. John S. knows such things.
However having or building a BCD library or using integer cents/pennies
throughout is always a possibility, when dealing with currency.
Richard Cornford
> Evertjan. wrote:
>> document.write(1.035 + 0.005);
>>
>> will return:
>>
>> 1.0399999999999998
>>
>> so a decimal string like 1.035 seems to be internally represented
>> and stored by something a bit less than exactly 1.035.
>
> I thought
If you appreciated for yourself how badly you do that you might be in a
position to see it as flagging the imminent arrival of another of your
streams of irrational, irrelevant, ill-considered and worthless
nonsense. Of course to appreciate your shortcomings you would have to
not suffer from them.
> that the proposed proc was for rounding _provided_ numbers,
> not for rounding internal IEEE-754 representations.
In a system where all numbers are IEEE floating point numbers it is not
possible to provide a number in any other form.
> The whole purpose of such algorithm IMO
You opinions are, as always, wothless.
> is to make as close as possible i) the strict "human" math
> learned at the school
Where in school? Basic arithmetic classes, introductory statistics, at
Accountancy school, degree level pure mathematics?
> and ii) the approximate PC math.
"And"? And what is "approximate PC math"? You have spouted a great deal
of twaddle on the subject of number representations in computers over
the years, which has made it obvious that you hardly understand what
computers do (or can do) when representing and manipulating numbures.
> If it was not a purpose then this code is misplaced to
> FAQ -
The code in the FAQ is intended to be an alternative to - toFixed - that
produces the same output as the ECMA 262 specified algorithm for -
toFixed - (ECMA 262. 3rd Ed. section 15.7.4.5). This allows for
consistent and predictable behaviour in the face of implementation bugs
in - toFiexed -, and says nothing as to the appropriateness of the code
(or of - toFixed -) for any particular task.
> let it be moved to some PC-math specific site.
An alternative to - tofixed - is appropriate in a javascript FAQ.
> For a user seeking for a quick answer it is irrelevant that
> US$ calculated price of 10.05 is really internally stored as
> 10.05XXXXXXXXXXX. All she wants to know is now to round it
> without monetarily abusing himself or her buyer.
You won't see it (being fundamentally incompetent yourself) but for
someone attempting to program a system that handles currency to take
such a cavalier attitude would be inept.
Because I have worked with them I know that UK share trading systems
employ 64 bit integer values for all currency values (representing
multiples of 1/1000 of the currency unit) and only perform integer
arithmetic on those values. Thus fractional results are truncated, not
rounded.
>> When rounding 1.035 so in reality something like 1.0344444444444449,
>> would you expect the .toFixed to make an educated guess if
>> eiter 1.035 or 1.0344444444444449 was entered, as a string of the
>> source code or in a user input, before it was stored?
>
> Yes, absolutely.
Why am I not surprised by that?
> Rounding goes from rightmost number to left, with
> 0,1,3,4 rounded down and 5,6,7,8,9 rounded up.
So you think that there is only one way to round a number?
> This is the school/bank math
You have never heard of "Banker's rounding"? And never been educated
beyond basic arithmetic?
> and the proc either has to work this way or no use of it.
That is so often you answer. You encounter something that does not work
the way your deranged mind expects and so you declare it unusable.
>>1.0344444444444449
>>1.034444444444445
>>1.03444444444445
>>1.0344444444445
>>1.034444444445
>>1.03444444445
>>1.0344444445
>>1.034444445
>>1.03444445
>>1.0344445
>>1.034445
>>1.03445
>>1.0345
>>1.035
>
> If some proc cannot outperform this then no use to start
> the mess on the first place, as there are no advantages
> over the native toFixed() method.
While the native - toFixed - method produces inconsistent results across
implementations (and particularly while it is evidently faulty in IE) a
consistent alternative has many advantages. It may be that what you
think the code should do is not what it does do, and it may be that it
is inappropriate for many of the tasks that the inconsiderate would
apply it to (particularly systems handling currency), but so long as
what it does do is consistent then its use is appropriate in contexts
where that is the desired behaviour.
Richard.
VK
<snip irrelevant>
> The code in the FAQ is intended to be an alternative to - toFixed - that
> produces the same output as the ECMA 262 specified algorithm for -
> toFixed - (ECMA 262. 3rd Ed. section 15.7.4.5).
On the entire Earth there are 2 to many 3 people giving some sh** on
such subject. This way for FAQ it is irrelevant
> This allows for
> consistent and predictable behaviour in the face of implementation bugs
> in - toFiexed -, and says nothing as to the appropriateness of the code
> (or of - toFixed -) for any particular task.
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?
<snip>
So I would propose to remove all this irrelevant self-exposure stuff -
I am taking that JRS is cool in all imaginable aspects of math, but
this poor FAQ topic is not a place to fall it out.
Just answer straight to the question with the promised results, so
6.57634 becomes 6.58
and - by the way -
1.035 becomes 1.04
P.S. Obviously when someone is asking "How do I convert 10.5678 into a
String with exactly 2 decimal places?"
she doesn't mean " "How do I convert 10.5678 into 10.56". Even for ones
with C on calculus the presumed result is 10.57 and not 10.56
Thus way "how to round?" is always presumed, not "how to truncate". For
the latter a one-liner code is sufficient. What do IEEE-754 or
IEEE-754r tell is irrelevant for this FAQ: though anyone is welcome to
analyze it up to any depth in personal blog and advertise in post
signatures.
Dr J R Stockton
glegroups.com>, Mon, 15 Jan 2007 18:08:14, krs <karl.a...@gmail.com>
posted:
>
>can someone else confirm that StrS(1.035,1,2) returns +1.03, instead of
>the correct value of +1.04, on Firefox2 (winxp)?
It should on all systems return +1.03, because
1.035*100 -> 103.49999999999998
in IEEE Doubles.
If you want exact results for currency including halfpennies, you need
to work in units such that halfpenny quantities are stored exactly.
Study the second paragraph of the FAQ entry.
Read IEEE 754, if that's the right number; ECMA 262 should tell you.
The code in the FAQ is not exactly what I currently use.
<FAQENTRY>
The FAQ lacks the word "currency" which might well be a search target.
IMHO it would be better to omit the first three words of FAQ 4.6, "When
formatting money" and to create a new 4.x on the general topic of "How
should currency calculations be done?".
Points to include : reference to 4.6 & 4.7; distinction between
accounting (must be exact) and finance (often approximate)<g>[*]</g>;
converting to new currencies (e.g. DMk to Euro) has exact rules.
</FAQENTRY>
For the handling of currency (in Delphi), Google News for "Herbster" and
for "JohnH".
Any astrodynamicists or orbital mechanics here?
[*] "A billion here, a billion there ... it soon adds up to real
money!".
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dr J R Stockton
, Tue, 16 Jan 2007 16:42:41, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>In a system where all numbers are IEEE floating point numbers it is not
>possible to provide a number in any other form.
One might consider that to be tautological.
But one can represent numbers in other ways. In strings, for example,
or in arrays/objects. I have Pascal code for computing with integers of
up to about 65000 digits (bases 2 to 16), though the largest native size
is 32-bit.
>The code in the FAQ is intended to be an alternative to - toFixed - that
>produces the same output as the ECMA 262 specified algorithm for -
>toFixed - (ECMA 262. 3rd Ed. section 15.7.4.5). This allows for
>consistent and predictable behaviour in the face of implementation bugs
>in - toFiexed -, and says nothing as to the appropriateness of the code
>(or of - toFixed -) for any particular task.
Not in the opinion of its author. The code was intended to do the
required job, including leading zeroes or spaces, as is commonly
required and generally provided in other languages. It was NOT intended
to match a (debugged) toFixed.
>Because I have worked with them I know that UK share trading systems
>employ 64 bit integer values for all currency values (representing
>multiples of 1/1000 of the currency unit) and only perform integer
>arithmetic on those values. Thus fractional results are truncated, not
>rounded.
Truncation is not a necessary consequence.
Delphi "currency" type is scaled by 10,000.
>>> When rounding 1.035 so in reality something like 1.0344444444444449,
>>> would you expect the .toFixed to make an educated guess if
>>> eiter 1.035 or 1.0344444444444449 was entered, as a string of the
>>> source code or in a user input, before it was stored?
In such cases, the algorithm should round to, say, an integer of
micropounds, convert to string, add a decimal point and chop trailing
zeroes as needed.
>Why am I not surprised by that?
>
>> Rounding goes from rightmost number to left, with
>> 0,1,3,4 rounded down and 5,6,7,8,9 rounded up.
Unreasonable anti-2 prejudice.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
Richard Cornford
> Richard Cornford posted:
>
>> In a system where all numbers are IEEE floating point numbers
>> it is not possible to provide a number in any other form.
>
> One might consider that to be tautological.
It is tautological. VK is the only person who would ever need being told
(and probably would not see the inevitability even then).
> But one can represent numbers in other ways.
Where a number is an entity of a strictly defined type and form being a
representation of a number is not necessarily being a number. Otherwise,
yes. Numbers, in the mathematical sense, can be represented in all sorts
of ways in javascript, and arbitrary mathematical operations applied to
those representations by javascript code.
<snip>
>> The code in the FAQ is intended to be an alternative to - toFixed -
>> that produces the same output as the ECMA 262 specified algorithm
>> for - toFixed - (ECMA 262. 3rd Ed. section 15.7.4.5). This allows
>> for consistent and predictable behaviour in the face of
>> implementation bugs in - toFiexed -, and says nothing as to the
>> appropriateness of the code (or of - toFixed -) for any particular
>> task.
>
> Not in the opinion of its author. The code was intended to do the
> required job, including leading zeroes or spaces, as is commonly
> required and generally provided in other languages. It was NOT
> intended to match a (debugged) toFixed.
Fair enough. I wrote a step-by-step implementation of the - toFixed -
algorithm to verify bugs in implementations, and it is not a piece of
code that I would want to use.
>> Because I have worked with them I know that UK share trading
>> systems employ 64 bit integer values for all currency values
>> (representing multiples of 1/1000 of the currency unit) and
>> only perform integer arithmetic on those values. Thus
>> fractional results are truncated, not rounded.
>
> Truncation is not a necessary consequence.
> Delphi "currency" type is scaled by 10,000.
>
>>>> When rounding 1.035 so in reality something like
>>>> 1.0344444444444449, would you expect the .toFixed to make an
>>>> educated guess if
>>>> eiter 1.035 or 1.0344444444444449 was entered, as a string of the
>>>> source code or in a user input, before it was stored?
>
> In such cases, the algorithm should round to, say, an integer of
> micropounds, convert to string, add a decimal point and chop
> trailing zeroes as needed.
<snip>
You cannot pay out, or receive, a micropound. Centipouds are as small as
British money gets ;)
Richard.
Dr J R Stockton
, Tue, 16 Jan 2007 12:26:51, Evertjan. <exjxw.ha...@interxnl.net>
posted:
>I would prefer to use regex when molding a string into shape:
Agreed.
Here's a rough first try, undertested, unsigned, PrfxTo cf FAQ 4.6
Stretch :-
function Hasty1(X) { var Y, Z, Q=0 // Trunc; Q=5 to Round. Bankers???
Y = String(Math.round(X*1000)+Q)
Z = PrfxTo(Y, 4, "0").replace(/(\d\d)(\d)$/, ".$1")
return Z }
OTOH, for a variable number of decimal places, substr/substring may be
easier than RegExp.
Evertjan.
> In comp.lang.javascript message <Xns98BA88CBE8778eejj99@
194.109.133.242>
> , Tue, 16 Jan 2007 12:26:51, Evertjan. <exjxw.ha...@interxnl.net>
> posted:
>>I would prefer to use regex when molding a string into shape:
>
> Agreed.
>
> Here's a rough first try, undertested, unsigned, PrfxTo cf FAQ 4.6
> Stretch :-
>
> function Hasty1(X) { var Y, Z, Q=0 // Trunc; Q=5 to Round.
> Y = String(Math.round(X*1000)+Q)
Y = String(Math.floor(X*1000+Q))
> Z = PrfxTo(Y, 4, "0").replace(/(\d\d)(\d)$/, ".$1")
You would not need the second ()
Z = ... .replace(/(\d\d)\d$/, ".$1")
> return Z }
Would it be an idea if one defines x.xx5 as always round up,
thinking for the moment only of positive values,
to add a tiny bit:
round: Q = 5.0001
floor: Q = 0.0001
Is it true that the binary converion problem always gives result
differences that are slightly to low, [or correct of course]?
> Bankers???
Personally, I do not need or want this silly idea of toggled rounding.
It is not important in scientific measurement, where an exact value is
never obtained anyway, only with currency, perhaps, in the amount
nonvirtual mortals only dream of.
So it cannot be that important in clientside(!) javascript.
> OTOH, for a variable number of decimal places, substr/substring may be
> easier than RegExp.
var Q = .0001 //5.0001
var NN = 1; for var i=0;i<N;i++) NN*=10
var Y = String(Math.floor(X*NN+Q))
.... .replace(new RegExp("(\\d{"+N+"})\\d$"), ".$1")
[N>0]
or:
var NN='1000000000000'.substr(0,N+1)
VK
toFixed() method as described in specs is a brut force liking of the
Holy Grail and a hot grill :-)
One part of task is to ensure that numbers without fractional part or
with a fractional part shorter than specified will be padded by the
needed amount of zeros. This say with pattern *.dd
2 > "2.00"
1.2 > "1.20"
and similar. This is a purely textual task without any math really
involved, just like padding hours and minutes with zero if lesser than
10.
Other part is to _round_ the numbers with fractional part longer than
needed so to fit it into pattern. This say with pattern *.dd
2.234 > 2.23
1.035 > 1.04
5.56789 > 5.57
and similar. This task presumes the conventional rounding mechanics
where the rounding goes from rightmost number to left, with 0,1,2,3,4
rounded down and 5,6,7,8,9 rounded up.
btw thanks to Dr.Stockton for correction, I don't have any "anti-2
prejudice" :-) that was a typo in my previous post.
There could be some exact IEEE-imposed limits for the second task
calculated based on the famous tables by Lasse Reichstein Nielsen:
<http://groups.google.com/group/comp.lang.javascript/msg/3833df1762d81fee>
and Thomas Lahn
<http://groups.google.com/group/comp.lang.javascript/msg/efec4b1ca3ddfbe9>
but truthfully I think that anyone in need to round say US
$10.66666666666666666666666666 needs not a programming but a medical
assistance - and urgently. So there is nothing wrong to set a proc
imposed limit for argument - say no more than 10 digits after period -
and after that either throw exception or return NaN.
P.S. IMO because toFixed() was defined so ambiguously by its actual
purpose, different producers concentrated either on the first task -
and then 1.035.toFixed(2) == '1.03' - or on the second task - and then
1.035.toFixed(2) == '1.04'
So a really useful program would do both task equally effectively but
keeping in code obvious that these are really two very weakly related
objectives. Such program IMO would be both practically useful and
educational.
Dr J R Stockton
, Wed, 17 Jan 2007 01:20:53, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>> In such cases, the algorithm should round to, say, an integer of
>> micropounds, convert to string, add a decimal point and chop
>> trailing zeroes as needed.
><snip>
>
>You cannot pay out, or receive, a micropound. Centipouds are as small as
>British money gets ;)
Alas, we used almost to have a millipound capability; and a worthwhile
one too.
I am now thinking that for two decimal digits, handling rounding error
at the cost of reduced range, one should multiply by 1000. Then add 5
for rounding, for Bankers decrement if mod20 is 5, drip the last digit
and insert a point.
Presently in <URL:http://www.merlyn.demon.co.uk/js-round.htm#CR> and
being worked on as time permits.
Dr J R Stockton
, Wed, 17 Jan 2007 18:39:54, Evertjan. <exjxw.ha...@interxnl.net>
posted:
>Dr J R Stockton wrote on 17 jan 2007 in comp.lang.javascript:
>> Here's a rough first try, undertested, unsigned, PrfxTo cf FAQ 4.6
>> Stretch :-
>>
>> function Hasty1(X) { var Y, Z, Q=0 // Trunc; Q=5 to Round.
>> Y = String(Math.round(X*1000)+Q)
>
>Y = String(Math.floor(X*1000+Q))
No; the idea is first to *round* anything which is very near to an exact
2-decimal number to represent that exact number; but with a bias Q so
that subsequent tail-chopping ends up with the desired Round or Trunc.
Converting to exact ASAP saves worrying about inexactness later, and
goes as near as possible to the PROPER solution, which is to have done
the preceding work exactly with X being cents not euros.
>> Z = PrfxTo(Y, 4, "0").replace(/(\d\d)(\d)$/, ".$1")
>
>You would not need the second ()
>
>Z = ... .replace(/(\d\d)\d$/, ".$1")
Agreed.
>Would it be an idea if one defines x.xx5 as always round up,
>thinking for the moment only of positive values,
>to add a tiny bit:
>
>round: Q = 5.0001
>
>floor: Q = 0.0001
Not needed.
>Is it true that the binary converion problem always gives result
>differences that are slightly to low, [or correct of course]?
I very much doubt it.
>> Bankers???
>
>Personally, I do not need or want this silly idea of toggled rounding.
>It is not important in scientific measurement, where an exact value is
>never obtained anyway, only with currency, perhaps, in the amount
>nonvirtual mortals only dream of.
It is now easily handled by if (B) if (J%20==5) J--
where J = Math.round(X*Math.pow(10, N+1))
and for those who don't want the possibility it is easy to remove from
the code. It should be there. for those who need it.
>var NN = 1; for var i=0;i<N;i++) NN*=10
>var NN='1000000000000'.substr(0,N+1)
Those should be tested for speed in comparison with Math.pow; I found
Math.pow faster than what is in the FAQ (Number("1e"+N)). The for loop
should be marginally faster as a while loop.
Code in <URL:http://www.merlyn.demon.co.uk/js-round.htm#CR> seems OK for
unsigned Trunc Round Bankers, except that inputs of null or undefined
are not handled ideally in the test - may be an artefact of testing.
In it, my administrative handling of argument Q seems inelegant.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
Dr J R Stockton
rlyn.invalid>, Thu, 18 Jan 2007 12:49:16, Dr J R Stockton
<repl...@merlyn.demon.co.uk> posted:
>
>Code in <URL:http://www.merlyn.demon.co.uk/js-round.htm#CR> seems OK for
>unsigned Trunc Round Bankers, except that inputs of null or undefined
>are not handled ideally in the test - may be an artefact of testing.
>In it, my administrative handling of argument Q seems inelegant.
It was an artefact of testing. New version uploaded.
ANNOUNCE : I now have easy access to IE7, but still use mainly IE6.
--
VK
> No; the idea is first to *round* anything which is very near to an exact
The idea is that the problem is not solvable by using math operations
on the involved number. Namely you are trying to get some exact
rounding results from IEEE-754 by using IEEE-754 dependant operations
on the number. This is the same as trying to find x out of y where
neither x nor y are known.
<http://www.merlyn.demon.co.uk/js-round.htm#CR> in this aspect is no
better than N of previous versions, say 1.039 > 1.03 if rounded to two
digits after period. I don't know what IEEE / banker standard does it
correspond to, very well can be that it is profoundly correct by some
spec #12345-67890bis - but the practical application of it is none.
The problem is solvable only with exact math - thus with exactly
represented integers. That means that we are working only with the
provided _string_ representation of the number.
Over the last three years as I remember this FAQ was nothing but a
subject of "it fails on X" or "it fails on Y" comments. Each time it
was some "new updated" version failing on Z, X1, Y1.
I guess I have to write myself a normal proc for the FAQ which would be
called sprintfRound: so it would pad with 0 the missing positions or
properly round to fit into template, depending on what is needed. I
don't know neither I care in what accordance would it be with IEEE-754
standards and toFixed specs, but this is what FAQ names implies and
this is what the public expectations are.
VK
be happy with. That could be bugs of course and locale treatment
("multinatiaonalization" on c.l.j. lingo) could be more sophicticated.
Yet I think that all main parts are here, and any bugs would be a
_finite_ work to adjust.
What do you think to use it for the FAQ instead of the current code?
Working testcase:
<http://www.geocities.com/schools_ring/sprintfround/index.xml>
- yes, .xml so do not be bothered with extra ads. I placed Yahoo!
banner though so to stay in agreement.
Full source with quick comments:
String.prototype.sprintfRound = function(m, comma) {
/* this points to string representation of
* the number to process.
*
* m argument defines the amount of decimal
* numerals in the fractional part.
*
* Optional argument comma if true indicates
* that in string representation comma
* separator is used instead of decimal point.
*/
/* First some basic validity check for [this]
* and m. More robust check - slower the proc.
* This way anyone is welcome either to add a
* complex RegExp test for [this] or to skip
* on any checks at all - yours to decide.
* Say the behavior is not defined if feeding
* numbers in scientific notation. I don't
* care of such twists but someone else may.
*/
if (this.length) {
var F = Math.abs(parseInt(m, 10)) || 0;
var S = (comma) ? ',' : '.';
var isFractional = (this.indexOf(S) != -1);
}
else {
return '';
}
/* If requested to drop fractional part
* and there is not fractional part then
* return verbatim right away.
*/
if ( (F == 0) && (!isFractional) ) {
return this;
}
/* Integer part (before separator)
*/
var integrum = (isFractional) ?
this.substring(0, this.indexOf(S)) : this;
/* Fractional part (after separator)
*/
var fraction = (isFractional) ?
this.substring(this.indexOf(S)+1) : '';
/* If fractional part fits into template
* by default then return verbatim.
*/
if (F == fraction.length) {
return this;
}
/* If requested to drop the fractional part
* completely then go by lesser-than-half
* rule.
*/
if (F == 0) {
return (fraction.charAt(0) < 5) ?
(''+Math.floor(this)) : (''+Math.ceil(this));
}
/*************************************************
* "small blood" ways did not go, so going on full
*************************************************/
/* If fractional part is shorter than F then
* pad it with zeros from the right side.
*/
if (fraction.length < F) {
var pad = F - fraction.length;
for (var i=0; i<pad; i++) {
fraction+= '0';
}
return integrum.concat(S, fraction);
}
/* If fractional part is longer than F then
* round to the given point.
*/
var digit = new Array();
for (var i=0; i<fraction.length; i++) {
digit[i] = fraction.charAt(i);
}
for (i = digit.length; i>=F; i--) {
if (digit[i] >= 5) {
++digit[i-1];
}
digit[i] = '';
}
return integrum.concat(S, digit.slice(0,F).join(''));
}
Dr J R Stockton
glegroups.com>, Fri, 19 Jan 2007 13:44:48, VK <school...@yahoo.com>
posted:
>
>What do you think to use it for the FAQ instead of the current code?
> ...
>String.prototype.sprintfRound = function(m, comma) {
Since its input is a String and not a Number, it cannot possibly serve
as a replacement for the code presently in FAQ 4.6 "How do I convert a
Number into a String with exactly 2 decimal places?".
On the test page, the name "Submit" of the button suggests that the work
is not being done on the page itself.
Math.floor(this) should not be needed as a string operation should
suffice. IMHO, 5 should be "5" to save unnecessary conversion.
<FAQENTRY> The reference to "IEEE-754 Doubles" in FAQ 4.7 should become
"IEEE-754 (IEC 559) Doubles", presuming that the equivalence and
currentness of 559 can be verified. Probably the full text costs money;
but a link to an overview of 754 or 559 could be useful.
See http://burks.bton.ac.uk/burks/foldoc/66/55.htm
--
Richard Cornford
> OK, here is the proc where I - silly IEEE-unaware
> John VK Doe - would be happy with.
I can believe that of the author of:-
<URL:
http://groups.google.co.uk/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8 >
On the other hand a programmer will look at a method that returns an object
at one point, a string at another and a number in a third and see the work
of an author who is not capable of understanding the consequences of their
design decisions, and so is also extremely unlikely to have thought out the
process being implemented.
> That could be bugs of course
'Being bugs' seems quite a good description of your code.
> and locale treatment ("multinatiaonalization" on c.l.j.
> lingo) could be more sophicticated.
> Yet I think that all main parts are here,
We have seen your half-ass analysis of the problem, so it is not too
surprising that you should see what you have written as "all main parts".
The effectiveness of the outcome says all that needs saying.
> and any bugs would be a _finite_ work to adjust.
For some people maybe, but you seem to tend to give up after failing for the
second or third time.
> What do you think to use it for the FAQ instead of
> the current code?
<snip>
You method is utter rubbish. I know that your failure to comprehend logic
prevents you from analysing a problem to the extent of creating a
comprehensive specification for the code you write, and that your not
understanding javascript stops you understanding what the code you write
actually does (preventing you implementing any full specification even if
you could create one), but the quality of your testing must be well below
all else if you have not found for yourself how inconsistent this garbage
is, or how easily it outputs utter nonsense. You proposal is orders of
magnitude worse than the code that is already in the FAQ.
'0.1'.sprintfRound(0, false) -> 0
'-0.1'.sprintfRound(0, false) -> -1
'0.9'.sprintfRound(0, false) -> 1
'-0.9'.sprintfRound(0, false) -> 0
'0.99'.sprintfRound(1, false) -> 0.10
'-0.99'.sprintfRound(1, false) -> -0.10
'-9.9'.sprintfRound(0, false) -> -9
'9.9'.sprintfRound(0, false) -> 10
'9.9999999'.sprintfRound(4, false) -> 9.99910
'999999999999999999999.9'
.sprintfRound(0, false) -> 1e+21
'9999999999999999999.9999999999999999999'
.sprintfRound(0, false) -> 10000000000000000000
'9999999999999999999.9999999999999999999'
.sprintfRound(1, false) -> 9999999999999999999.10
'9999999999999999999.9999999999999999999'
.sprintfRound(2, false) -> 9999999999999999999.910
'9999999999999999999.9999999999999999999'
.sprintfRound(3, false) -> 9999999999999999999.9910
'9999999999999999999.9999999999999999999'
.sprintfRound(1e+21, false)-> 9999999999999999999.10
'15555555555555555555555.5'
.sprintfRound(0, false) -> 1.5555555555555554e+22
'1555555555555555555555.5'
.sprintfRound(0, false) -> 1.5555555555555557e+21
'155555555555555555555.5'
.sprintfRound(0, false) ->155555555555555540000
'15555555555555555555.5'
.sprintfRound(0, false) -> 15555555555555555000
'1555555555555555555.5'
.sprintfRound(0, false) -> 1555555555555555600
'155555555555555555.5'
.sprintfRound(0, false) -> 155555555555555550
VK
Richard Cornford wrote:
> a method that returns an object at one point, a string at another and a number in a third
Are you sure you are commenting on the code I posted? Where does it
return object or number?
<snip>
> '0.1'.sprintfRound(0, false) -> 0
>
> '-0.1'.sprintfRound(0, false) -> -1
<snip>
1.035
My code => 1.04
Current code => 1.03
My code => good, current code => garbage
999999999999999999.66666666666666666666
My code => I dont give a damn as no one else does
Current code => see the right side of the expression above.
Sorry to all participants of the current code, I'm just taking the
argumentation model proposed by the opponent.
Dr J R Stockton
glegroups.com>, Sun, 21 Jan 2007 16:25:34, VK <school...@yahoo.com>
posted:
>1.035
>My code => 1.04
>Current code => 1.03
>
>My code => good, current code => garbage
The code in the FAQ starts with a Number, an IEEE Double. You can try
to assign the literal 1.035 to a variable; but it cannot hold that
value. What it gets is a little less.
We know that 1.0 is held exactly :
1.035 - 1.0 -> 0.03499999999999992
So the actual value is less than 1.035, and is correctly rounded by the
FAQ code.
If the FAQ maintainer had wanted to, he could have written a section
"How do I convert a numeric String to exactly 2 decimal places?". But
that question is not commonly asked.
In rounding a number to two places, there is an obvious possible
problem, when the number is less than, say, 10 but is large enough that
it should round to "10.00" - 9.997 is such a number. Your code (in
<URL: http://www.geocities.com/schools_ring/sprintfround/index.xml>),
rounding 9.997 to two decimals with point separator, gives "9.910".
With comma separator, it gives "9.997,00" .
RBTD.
It's a good idea to read the newsgroup and its FAQ. See below.
--
Richard Cornford
> Richard Cornford wrote:
>> a method that returns an object at one point, a string
>> at another and a number in a third
>
> Are you sure you are commenting on the code I posted?
As sure as I am that you don't understand the code that you posted.
> Where does it return object or number?
You returned an object where you wrote:-
return this;
- (there are two occurrences of that in your code). In javascript the -
this - keyword _always_ refers to an object, so if you return - this - you
will be returning an object.
> <snip>
>
>> '0.1'.sprintfRound(0, false) -> 0
>>
>> '-0.1'.sprintfRound(0, false) -> -1
>
> <snip>
>
> 1.035
> My code => 1.04
> Current code => 1.03
It is not possible to input 1.035 into the current code as that number
cannot be represented in a javascript numeric type value.
> My code => good, current code => garbage
A function that outputs 0.10 when rounding 0.99 to one decimal place is
anything but good. Mathematically the result is way off, and it has more
decimal places than requested.
> 999999999999999999.66666666666666666666
> My code => I dont give a damn as no one else does
> Current code => see the right side of the expression above.
>
> Sorry to all participants of the current code, I'm just
> taking the argumentation model proposed by the opponent.
If you mean my argument then you have missed the point, which was that the
code you proposed (and declared yourself "happy with") has design flaws that
result in its outputting self-evidently wrong values. That really has
nothing to do with the code in the FAQ, which is designed for a different
task to your code.
Richard.
Dr J R Stockton
, Mon, 22 Jan 2007 21:59:23, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>
>It is not possible to input 1.035 into the current code as that number
>cannot be represented in a javascript numeric type value.
... not exactly represented ...
New code at <URL:http://www.merlyn.demon.co.uk/js-misc0.htm#IEEE>,
executed in a test form under "Number to Four Words as IEEE Double and
Back", shows that it will be stored as
0011111111110000 1000111101011100 0010100011110101 1100001010001111
and that the exact value stored is
1.0349999999999999200639422269887290894985198974609375
It's a good idea to read the newsgroup and write its FAQ. See below.
--
VK
wrote:
> We know that 1.0 is held exactly :
> 1.035 - 1.0 -> 0.03499999999999992
> So the actual value is less than 1.035, and is correctly rounded by the
> FAQ code.
1.0 is "held" none a bit more "exactly" than 1.035
Please stop mixing the rounding and internal number representations. By
default IEEE-754 math engine implements co-called "unbiased rounding"
(aka "round to nearest even"). This compromise algorithm sacrifices
exactness for speed, with micro errors on each calculation mutually
compensated by 50:50 distribution of rounding: 50% of times towards
zero, 50% towards infinity. As any compromise this one is not perfect:
the main problem is that 50:50 distribution is the average one, but on
each particular calculation sequence there can be short-living
fluctuations. I'm staying away of deep math ever since college, but
these IEEE peculiarities are inevitable to deal with in 3D vector
graphics.
To visualize the problem: our moon being rotated around the Earth by
IEEE-754 calculated formulas would be a rather strange object shaking
around the orbit by a pseudo-random rule. It means that by knowing two
previous points one could predict the next "shake", but overall shakes'
distribution would be in random sequence. By bringing it into scale,
our moon would make shakes ~ 50-500 miles towards the Earth and away
the Earth during the rotation; with a high probability approx. within
100,000,000 years the moon would fail into long-living fluctuation so
started to either fall onto Earth or go away. This way IEEE-754 is the
most misfortunate system to rotate anything 3D - a periodical rotation
center adjustment is needed. Unfortunately it is the system to deal
with client-side for scripting.
But again: the exact IEEE-754 rounding algorithm should bother anyone
no more than say exact algorithm of the internal garbage collector. It
is even more strange to try to re-implement IEEE-754 rounding algorithm
atop of the native one by JavaScript means. And even if such attempt
would be made, the current FAQ algorithm is very far from IEEE-754
unbiased rounding. It is some kind of proprietary "five-biased towards
zero rounding" I did not see anywhere yet except clj FAQ.
This way my code for the FAQ is not to imitate IEEE-754 nor fixed point
systems nor any particular system as such. It is for people who are:
1) being able to pass this junior school rounding test:
<http://www.aaamath.com/est27a-rounding.html>
2) do agree with the correct answers implied by this test.
Within this frame I do appreciate all criticism from responses.
Randy Webb
> On Jan 22, 4:10 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
> wrote:
>> We know that 1.0 is held exactly :
>> 1.035 - 1.0 -> 0.03499999999999992
>> So the actual value is less than 1.035, and is correctly rounded by the
>> FAQ code.
>
> 1.0 is "held" none a bit more "exactly" than 1.035
Are you really that ignorant? Any whole number that can be converted to
a Base 2 whole number is represented *exactly* as it first converts it
to Base 2, does arithmetic and then converts it back.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK
> Any whole number that can be converted to
> a Base 2 whole number is represented *exactly*
In what system and in what circumstances? Not in IEEE-754 machine math
and not in situation like 1.035 - 1
See again the convenience tables I linked before.
Overall as a FAQ maintainer you should say if a) "5 cannot be
represented exactly" discover remains - respectively with
clj-proprietary rounding results or b) the final code has to match the
school rounding test I linked.
RobG
On Jan 16, 9:25 pm, "VK" <schools_r...@yahoo.com> wrote:
[...]
> Because:
> If the number you are rounding is followed by 5, 6, 7, 8, or 9, the
> number has to be rounded up.
> If the number you are rounding is followed by 0, 1, 2, 3, or 4, round
> the number down.
It is illogical to say 0 is rounded either up or down - it isn't
rounded at all.
The rounding algorithm above results in a bias toward higher numbers.
It is not possible to define a general rounding algorithm that will
suit all cases. The act of rounding infers that an approximation is
about to be made and that some error (in the majority of cases) is
about to be introduced. Not knowing the use to which the number is to
be put infers ignorance of the consequences of errors introduced by
that approximation, hence the impossibility of defining how to deal
with it.
It might be possible to identify a number of common or reasonable
scenarios and attempt to deal with those, but some have conflicting
requirements.
In many situations, numbers ending in 5 are rounded to the closest even
number. In others, truncation is used and the resulting bias is dealt
with in other ways. The point in a process at which rounding is
employed can be important or irrelevant, the effects of rounding could
be immaterial or result in an infinite loop. Given a list of numbers
to round, should the sum of rounded numbers be equal to the rounded sum
of un-rounded numbers?
There are a number of threads in this group regarding rounding of
numbers. The primary revelation for me has been that discussion of a
general rounding algorithm is fairly pointless since there is no "one
size fits all". Any rounding function should clearly state the purpose
for which it is designed and any bias or systematic effects it may
produce.
--
Rob
Randy Webb
> On Jan 25, 2:20 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Any whole number that can be converted to
>> a Base 2 whole number is represented *exactly*
>
> In what system and in what circumstances?
In any Base 2 based system.
> Not in IEEE-754 machine math and not in situation like 1.035 - 1
I said nothing about 1.035, please learn to read and comprehend what I
said before you reply to what I said.
> See again the convenience tables I linked before.
Any reference provided to me by you is, well, suspicious to me.
> Overall as a FAQ maintainer you should say
As "FAQ maintainer" I should say what I think is the best answer to a
proposed question. And my thoughts are directly related to the responses
in this group. And how much weight I give a particular response is
directly related to the quality of the response. So far, the quality of
your responses in this thread has been zero. When confronted with
situations where your code fails - catastrophically - your response was
"I don't care about that situation" and that attitude is what makes your
very limited contributions worth about as much as a grain of salt on a
Pacific Ocean island to me.
Now, you can start your "Its an anti-VK campaign" if you want to. It
will display your intelligence level once again. And I say that because
if you think I have an anti-VK bias by disagreeing with you then it only
takes a simple search to find some of the arguments/disagreements I have
had with nearly every long time poster to this group. Richard Cornford?
Yes, many. John Stockton? Yes, too many. It goes on and on. But I
respect the opinions of both of those people but if I think they are
wrong then I will say what I think. The difference is I think it out
*before* I say it, not after someone has pointed it out to me.
> if a) "5 cannot be represented exactly" discover remains
The Number 5 can be represented exactly in Base 2 - 11 - so discover
does not remain. The issue comes in when a decimal point gets introduced.
> respectively with clj-proprietary rounding results
And "rounding results" are proprietary (read RobG's post to see why, I
don't feel like repeating a good explanation) so I am not sure what your
point is there.
> or b) the final code has to match the school rounding test I linked.
If, and only if, "school rounding" is the desired results. I don't think
a bank would agree with your b) solution.
VK
1) Unbiased towards nearest even (must be the default one)
2) Biased towards zero
3) Biased towards positive infinity
4) Biased towards negative infinity
IEEE 754r (ongoing revision)
Extends 1) to permit languages to define a default rounding mode for
decimals;
also added:
5) Biased round to nearest, ties away from zero
The added one (5) is exactly what poor children are being tortured with
in the school; as a post-traumatic syndrom this is the way they round
everything later throughtout the life and this is what they do expect
from round operations. :-)
It is clear that IE toFixed() implements the schools's biased round to
nearest, ties away from zero using IEEE 754r. This is why
1.035.toFixed(2) => 1.04
-1.035.toFixed(2) => -1.04
It is also clear that Gecko stays on the default internal unbiased
towards nearest even from IEEE-754. This is why:
1.035.toFixed(2) => 1.03
-1.035.toFixed(2) => -1.03
Neither one is right or wrong IMO. As RobG pointed out, there is not
some universal "throughoutly correct" rounding for IEEE-754x It all
depends for what are we rounding for.
First of all for internal chain calculations unbiased towards nearest
even (1) is the only option. Any biased algorithm would soon degrade to
a long-living fluctuation towards zero or towards infinity. Taking my
moon sample from the previous post, it would fly hell out off the orbit
in lesser than 100 years. :-)
This way the question can be only what rounding to use to _display_
results and overall to retrieve numeral string representations matching
the given pattern.
I stay on the school math as the most common and the most expected one.
This way I see IE's toString() as correct by default and toFixed() on
Gecko as a "lazy dump" of internal algorithms. This way IMO this is
Gecko's toFixed() to override for uniform results in the FAQ code.
I also stay on that the current code doesn't match neither of five
official IEEE-754 roundings. It is some kind of "random biased
ties-let's-see-to-what" algorithm.
Dr J R Stockton
oglegroups.com>, Wed, 24 Jan 2007 14:46:52, VK <school...@yahoo.com>
posted:
>
>This way my code for the FAQ is not to imitate IEEE-754 nor fixed point
>systems nor any particular system as such. It is for people who are:
>1) being able to pass this junior school rounding test:
The code you use at http://www.geocities.com/schools_ring/sprintfround/i
ndex.xml, when called upon to round 0.995 t0 2 places, gives 0.910.
It cannot therefore be deemed fit for purpose, though it is a sufficient
demonstration of your coding ability.
Even if you can fix that, it's not appropriate for FAQ 4.15 because it
is not compatible with the title of 4.15.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Dr J R Stockton
Wed, 24 Jan 2007 18:20:41, Randy Webb <HikksNo...@aol.com> posted:
>VK said the following on 1/24/2007 5:46 PM:
>> On Jan 22, 4:10 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>> wrote:
>>> We know that 1.0 is held exactly :
>>> 1.035 - 1.0 -> 0.03499999999999992
>>> So the actual value is less than 1.035, and is correctly rounded by the
>>> FAQ code.
>> 1.0 is "held" none a bit more "exactly" than 1.035
>
>Are you really that ignorant? Any whole number that can be converted to
>a Base 2 whole number is represented *exactly* as it first converts it
>to Base 2, does arithmetic and then converts it back.
I cannot really decide whether that is meaningless or incorrect - I
don't think it can be both.
ALL whole numbers can be converted to Base 2, remaining whole. ALL
finite numbers can be expressed in Base 2, though an infinite number of
digits may be needed after the binary point.
Any whole number not exceeding 2^53 in magnitude, and some larger ones,
is held without error in an IEEE Double.
Any such number multiplied by any power of 2, positive or negative, is
also held exactly, unless it is too big or too small (the limits being
about 10^+-308).
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
VK
On Jan 25, 3:15 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
wrote:
> ALL whole numbers can be converted to Base 2, remaining whole. ALL
> finite numbers can be expressed in Base 2, though an infinite number of
> digits may be needed after the binary point.
>
> Any whole number not exceeding 2^53 in magnitude, and some larger ones,
> is held without error in an IEEE Double.
>
> Any such number multiplied by any power of 2, positive or negative, is
> also held exactly, unless it is too big or too small (the limits being
> about 10^+-308).
OK, thanks for explaining the basics.
If the current FAQ is so profoundly standard friendly - then could you
please name the exact IEEE algorithm it conforms to?
I'm pretty much sure about IE with (5) but Gecko is still a puzzle: (1)
unbiased towards nearest even or (2) biased towards zero. One needs
either to study the source or to feed milestones values to see it. In
either case your own "Stockton's conditionally biased" rounding
algorithm is a jerk. If poor Biggle flit this way it is no wonder it
got smashed on Mars - it is a bigger wonder it got a chance to be
smashed at all - instead of flying straight to the Hell Raiser galaxy.
Yeah... I've lost a juicy contract today so I'm grunchy.
Any way one has to spell first who's right by clj's opinion: Gecko or
IE; also what is the name of the right rounding method and what are
limitations of this method.
Randy Webb
> In comp.lang.javascript message <3qOdnT1av9x...@telcove.net>,
> Wed, 24 Jan 2007 18:20:41, Randy Webb <HikksNo...@aol.com> posted:
>> VK said the following on 1/24/2007 5:46 PM:
>>> On Jan 22, 4:10 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>>> wrote:
>>>> We know that 1.0 is held exactly :
>>>> 1.035 - 1.0 -> 0.03499999999999992
>>>> So the actual value is less than 1.035, and is correctly rounded by the
>>>> FAQ code.
>>> 1.0 is "held" none a bit more "exactly" than 1.035
>> Are you really that ignorant? Any whole number that can be converted to
>> a Base 2 whole number is represented *exactly* as it first converts it
>> to Base 2, does arithmetic and then converts it back.
>
>
> I cannot really decide whether that is meaningless or incorrect - I
> don't think it can be both.
It served no other purpose than to show VK's lack of understanding and
lack of ability to read something that simple. Nothing more, nothing less.
Dr J R Stockton
glegroups.com>, Wed, 24 Jan 2007 19:16:59, RobG <rg...@iinet.net.au>
posted:
>On Jan 16, 9:25 pm, "VK" <schools_r...@yahoo.com> wrote:
>[...]
>> Because:
>> If the number you are rounding is followed by 5, 6, 7, 8, or 9, the
>> number has to be rounded up.
>> If the number you are rounding is followed by 0, 1, 2, 3, or 4, round
>> the number down.
>
>It is illogical to say 0 is rounded either up or down - it isn't
>rounded at all.
>The rounding algorithm above results in a bias toward higher numbers.
To larger numbers. Numbers can be negative.
>It is not possible to define a general rounding algorithm that will
>suit all cases.
Well, one can if it has enough control parameters to select what is
required. The code for ordinary rounding, banker's rounding, and
truncation can be very similar, and the similar parts can be shared.
> The act of rounding infers that an approximation is
>about to be made and that some error (in the majority of cases) is
>about to be introduced.
Not necessarily. Example : 100*(0.01 + 0.06) -> 6.999999999999999, so
Math.round(100*(0.01 + 0.06)) -> 7 unmakes a previous approximation.
> Not knowing the use to which the number is to
>be put infers ignorance of the consequences of errors introduced by
>that approximation, hence the impossibility of defining how to deal
>with it.
That's why the purpose of a routine should be stated, as you yourself
say.
In particular, one should indicate whether it deals with negative
numbers (just those which should round to 0.00, or any?) and whether
Round(-X) = -Round(X) or Round(X+N) = N + Round(X) for X<0 and
'any' N.
In <URL:http://www.merlyn.demon.co.uk/js-round.htm#RAQ>, ApRnd does
ordinary rounding, banker's rounding, and truncation of approximately
accurate values, including choice of digits after the point and
characters before the point, in ten lines of code (using 2 library
functions each of 2 lines).
It's a good idea to read the newsgroup and its FAQ. See below.
--
Evertjan.
>>The rounding algorithm above results in a bias toward higher numbers.
>
> To larger numbers. Numbers can be negative.
"higher number(s) [of]" wrongly suggesting a higher positive(!) integer(!!)
count, like in:
"To review the "protective" effects of having a higher number of siblings
for the risk of atopic eczema, asthma wheezing, hay fever, and allergic
sensitisation."
Evertjan.
> Dr J R Stockton wrote on 25 jan 2007 in comp.lang.javascript:
>
>>>The rounding algorithm above results in a bias toward higher numbers.
>>
>> To larger numbers. Numbers can be negative.
> [..]
What about rounding to a negative number of decimals?
<script type='text/javascript'>
Number.prototype.roundToDecimals =
function(x){
var r = Math.round(this*Math.pow(10, x)).toString()
var re = new RegExp('(\\d{'+ x +'})$')
return (x>0)
? r.replace(re,'.$1')
: r * Math.pow(10, -x)
}
a = 99163456.66
r = a.roundToDecimals(1)
document.write(r + '<br>') // 99163456.7
r = a.roundToDecimals(0)
document.write(r + '<br>') // 99163457
r = a.roundToDecimals(-5)
document.write(r + '<br>') // 99200000
</script>
Dr J R Stockton
oglegroups.com>, Thu, 25 Jan 2007 13:05:34, VK <school...@yahoo.com>
posted:
>On Jan 25, 3:15 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>wrote:
>> ALL whole numbers can be converted to Base 2, remaining whole. ALL
>> finite numbers can be expressed in Base 2, though an infinite number of
>> digits may be needed after the binary point.
>>
>> Any whole number not exceeding 2^53 in magnitude, and some larger ones,
>> is held without error in an IEEE Double.
>>
>> Any such number multiplied by any power of 2, positive or negative, is
>> also held exactly, unless it is too big or too small (the limits being
>> about 10^+-308).
>
>OK, thanks for explaining the basics.
>If the current FAQ is so profoundly standard friendly - then could you
>please name the exact IEEE algorithm it conforms to?
There's no need to bother with IEEE standards; they are merely local
preferences. The appropriate authority for general international work
is ISO. In fact, this group should not be referring to ECMA-262, but to
ISO/IEC 16262 (I suppose USians prefer using even European standards to
International ones, where they lack a native one). "ECMA-262" should be
considered as essentially a nickname.
The FAQ should be changed accordingly.
Function StrU rounds correctly by the normal definition; but one must
realise that in javascript it is NOT POSSIBLE for the Number which it is
given to be 1.035 exactly.
If a Number which is nominally 1.035 (and converts by default to
"1.035") is to be rounded - ordinary or Banker's - as if it were exactly
1.035, then the task can be done either by conversion to "1.035"
followed by character manipulation (you have demonstrated that to be
beyond your powers) or much as done in function ApRnd (/op cit/).
A first cut at taking a Number, using the default conversion to String,
and then doing the rest by character manipulation is now, as function
StRnd, at <URL:http://www.merlyn.demon.co.uk/js-round.htm#RAQ> under
"Textually". It seems OK, but is not optimised or tested, except by the
default tests, to which 999.995 has been added.
It's a good idea to read the newsgroup and its FAQ. See below.
--
John G Harris
Stockton <repl...@merlyn.demon.co.uk> writes
<snip>
>In fact, this group should not be referring to ECMA-262, but to
>ISO/IEC 16262 (I suppose USians prefer using even European standards to
>International ones, where they lack a native one). "ECMA-262" should be
>considered as essentially a nickname.
You forgot to say how much the ISO document costs (a lot), and how much
the ECMA document costs (it's free).
You can probably get a PDF version of the ISO document from the ANSI doc
store but it will cost you about $25. You may need broadband access if
the ANSI server still times out too quickly.
>The FAQ should be changed accordingly.
<snip>
I expect ECMA used their fast-track facility to turn ECMA 262 into an
ISO standard. It's likely that there was no change of wording, though
the spelling might have mutated.
Ultimately, the FAQ should quote whatever is stated in the browser
makers' documentation. Does Microsoft still say ECMA 262 ?
John
--
John Harris
Dr J R Stockton
, Fri, 26 Jan 2007 09:11:38, Evertjan. <exjxw.ha...@interxnl.net>
posted:
>Evertjan. wrote on 26 jan 2007 in comp.lang.javascript:
>
>> Dr J R Stockton wrote on 25 jan 2007 in comp.lang.javascript:
>>
>>>>The rounding algorithm above results in a bias toward higher numbers.
>>>
>>> To larger numbers. Numbers can be negative.
>> [..]
>
>What about rounding to a negative number of decimals?
IMHO, that's a different question.
>Number.prototype.roundToDecimals =
> function(x){
> var r = Math.round(this*Math.pow(10, x)).toString()
> var re = new RegExp('(\\d{'+ x +'})$')
> return (x>0)
> ? r.replace(re,'.$1')
> : r * Math.pow(10, -x)
> }
I may be testing it wrong, but I don't like what it gives for rounding
0.015 to two decimals,
If the job is coded as a function
function Thingy(X, M, N) { // A function rounding X, M, N
<body>
}
then the body can be pasted into js-round.htm#TRPF "Body of Function"
and tested with a selection of good tests plus anything you want. X is
to be rounded to N decimals and padded to at least M digits before the
point; but M can be ignored.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Dr J R Stockton
ospam.invalid>, Fri, 26 Jan 2007 19:58:31, John G Harris
<jo...@nospam.demon.co.uk> posted:
>In article <cvoCLvcc...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>Stockton <repl...@merlyn.demon.co.uk> writes
>
> <snip>
>>In fact, this group should not be referring to ECMA-262, but to
>>ISO/IEC 16262 (I suppose USians prefer using even European standards to
>>International ones, where they lack a native one). "ECMA-262" should be
>>considered as essentially a nickname.
>
>You forgot to say how much the ISO document costs (a lot), and how much
>the ECMA document costs (it's free).
Unimportant : ISO/IEC provide the *International* authority, and the
ECMA page linked from FAQ 2.6 assures us that the ECMA and ISO standards
agree. So, in essence does ECMA-262 itself, on the fifth sheet (un-
numbered; the Romans provided no obvious means of numbering the page
before ii
>I expect ECMA used their fast-track facility to turn ECMA 262 into an
>ISO standard. It's likely that there was no change of wording, though
>the spelling might have mutated.
ECMA uses correct spelling, AFAIR - why should ISO/IEC have changed it?
--
Randy Webb
<snip>
> Ultimately, the FAQ should quote whatever is stated in the browser
> makers' documentation. Does Microsoft still say ECMA 262 ?
The FAQ does, and will continue to, refer to ECMA 262 and it won't be
changed until ECMA comes out with a different number for it or drops
ECMAScript from its repertoire.
Richard Cornford
<snip>
> ... . ALL finite numbers can be expressed in Base 2, though an
> infinite number of digits may be needed after the binary point.
"Can be expressed" is a little questionable. We can know that a
hypothetical infinite sequence of digits would express some numbers
precisely, in the same way as a decimal point followed by an infinite
number of 3s would exactly express 1/3 as a decimal fraction. On the
other hand we also know that creating an infinite sequence of digits is
an impossibility.
Richard.
Dr J R Stockton
, Sun, 28 Jan 2007 21:14:57, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
One third to base 2 is "zero point (zero one recurring)". That is an
exact base 2 expression, of finite length, describing an infinite number
of digits. I did *not* write "can be written in Base 2".
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
In MS OE, choose Tools, Options, Send; select Plain Text for News and E-mail.
Don't quote more than is needed, and respond after each quoted part.
VK
> You forgot to say how much theISOdocument costs (a lot), and how much
> the ECMA document costs (it's free).
ISO charges 230 Swiss francs (~ US $186) per _notarial paper_ copy of
standard specifications:
<http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?
CSNUMBER=33835>
An electronic copy can be officially downloaded free of charge at
<<http://standards.iso.org/ittf/PubliclyAvailableStandards/
c033835_ISO_IEC_16262_2002(E).zip>
The current ISO standard for ECMAScript is ISO/IEC 16262:2002
"This second edition cancels and replaces the first edition (ISO/IEC
16262:1998), which has been technically revised."
AFAICT it contains a lot of textual changes in informal (informative)
sections compared to ECMA variant. In the technical (scripting
language) aspect they are equal (?)