FAQ Topic - How do I convert a Number into a String with exactly 2 decimal places?

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]

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.

 

[VK]

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]

Dr J R Stockton said the following on 1/25/2007 7:15 AM:

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.

 

[Evertjan.]

Dr J R Stockton wrote on 25 jan 2007 in comp.lang.javascript:

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.]

Evertjan. wrote on 26 jan 2007 in comp.lang.javascript:

Dr J R Stockton wrote on 25 jan 2007 in comp.lang.javascript:

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]

In comp.lang.javascript message <[email protected]

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

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.

 

[John G Harris]

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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
ospam.invalid>, Fri, 26 Jan 2007 19:58:31, John G Harris

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]

John G Harris said the following on 1/26/2007 2:58 PM:

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]

Dr J R Stockton wrote:

... . ALL finite numbers can be expressed in Base 2, though an
infinite number of digits may be needed after the binary point.

<snip>

"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]

In comp.lang.javascript message <[email protected]>
, Sun, 28 Jan 2007 21:14:57, Richard Cornford

Dr J R Stockton wrote:

<snip>

"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.

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".

 

[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 (?)