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

V

VK

I still think that FAQ 4.6, the proposed code _and_ the native
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.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>
, Wed, 17 Jan 2007 01:20:53, Richard Cornford
<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.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]>
Dr J R Stockton wrote on 17 jan 2007 in comp.lang.javascript:

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.

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

Dr J R Stockton

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Thu, 18 Jan 2007 12:49:16, Dr J R Stockton
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.
 
V

VK

Dr said:
No; the idea is first to *round* anything which is very near to an exact
2-decimal number to represent that exact number.

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

VK

OK, here is the proc where I - silly IEEE-unaware John VK Doe - would
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 = fraction.charAt(i);
}


for (i = digit.length; i>=F; i--) {
if (digit >= 5) {
++digit[i-1];
}
digit = '';
}
return integrum.concat(S, digit.slice(0,F).join(''));
}
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
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
 
R

Richard Cornford

VK said:
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
 
V

VK

Richard said:
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?

'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.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
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.
 
R

Richard Cornford

VK said:
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>

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

Dr J R Stockton

In comp.lang.javascript message <[email protected]>
, Mon, 22 Jan 2007 21:59:23, Richard Cornford
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.
 
V

VK

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

Randy Webb

VK said the following on 1/24/2007 5:46 PM:
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.
 
V

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

RobG

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

Dr J R Stockton

In comp.lang.javascript message <[email protected]
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.
 
D

Dr J R Stockton

In comp.lang.javascript message said:
VK said the following on 1/24/2007 5:46 PM:

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).
 
R

Randy Webb

VK said the following on 1/24/2007 6:54 PM:
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.
 
V

VK

IEEE-754 (stable release) defines 4 rounding algorithms:

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top