[The original thread

<http://groups.google.com/group/comp....se_frm/thread/

b495b4898808fde0>

is more than one month old - this may pose problem for posting over

some news servers. This is why I'm starting a new one]

I'd still like to finish this rounding mess. As a startup lemma we can

take that VK is the worst programmer of all times and places: let's

move from here forward please.

The usability of any program depends on exact behavior description.

This way it is a must to know i) what argument we can feed into and

ii) what results to expect.

The usability of the current FAQ code in this aspect is zero. "take

power of x, extract y" and similar is not a behavior description - it

is a description of the formal algorithm. It is the same as instead

remote control manual provide a detailed electronic schema of the

control. Obviously a reference to some other formal algorithm ("in

accordance with ECMA-262 section...") doesn't add any usability.

So first it has to be defined what common rules (behavior) are used

for rounding.

The key points are:

1) how to round with losses (when some signs have to be dropped)

2) how to round equipoint (in decimal system it will be 5)

3) how to round negative

As milestone values used everywhere further are

1) 1.033

2) 1.035

3) -1.035

IEEE-754/IEEE-754r define five methods of rounding for numeral string

representation:

(the specification order is changed, the implemented methods moved

atop)

1) Biased round to nearest, ties away from zero

Implemented by IE's toFixed method. Overall the most known as studied

at the school

toFixed(2)

1.033 = 1.03

1.035 = 1.04 (equipoint ties away zero, so to positive infinity

for positive values)

-1.035 =-1.04 (equipoint ties away zero, so to negative infinity

for negative values)

2) Biased towards zero

Implemented by Gecko and Opera toFixed method.

toFixed(2)

1.033 = 1.03

1.035 = 1.03 (equipoint ties towards zero)

-1.035 =-1.03 (equipoint ties towards zero)

3) Biased towards positive infinity

No known ECMAScript implementations (?)

toFixed(2)

1.033 = 1.03

1.035 = 1.04 (equipoint ties towards positive infinity)

-1.035 =-1.03 (equipoint ties towards positive infinity)

4) Biased towards negative infinity

No known ECMAScript implementations (?)

toFixed(2)

1.033 = 1.03

1.035 = 1.03 (equipoint ties towards negative infinity)

-1.035 =-1.04 (equipoint ties towards negative infinity)

This is as far as IEEE-754 currently goes. As it was pointed by some

posters, rounding is not some "natural" feature coming out of numbers

themselves. It is merely a contract behavior: "let's make it as

this...". This way it can be a rule combining two or more rules from

IEEE or even all separate custom algorithm. In the latter case of

course any appellations to "standards" and "bug fixes" must be

dropped. In any case exact behavior description has to be given.

This way I am insistently asking to explain what rounding rule is

considered correct by FAQ maintainer:

1) Biased round to nearest, ties away from zero (IE) - thus Gecko

needs a fix

2) Biased towards zero (Gecko, Opera) - thus IE needs a fix

3) some third - thus everyone needs a fix

In the 3rd case what this rounding rule is?