On Sat, 16 Oct 2004, GOTO Kentaro wrote:
> sprintf(3) conform to ISO 31-0 but Float#round doesn't.
>
> puts 0.5.round #=> 1
> puts sprintf("%.0f", 0.5) #=> 0
>
Both are (IIRC) ISO 31-0 conformant, but one uses ISO 31-0 B.3 rule A
and the other uses ISO 31-0 B.3 rule B.
That said, one of the rules (the one sprintf uses, to round down
following even digits is an abomination and should be eliminated from the
face of the earth. nnn.nn5 should ALWAYS round up and rounded values
should not be re-rounded (which is what the contrary rule assumes is
happening).
Yes, that's exactly why it's there. But there are several reasons
(e.g. Benford's Law http://mathworld.wolfram.com/BenfordsLaw.html\) why
it doesn't even work for its intended purpose. The real answer is to
not re-round the data.
As for developing strong feelings about it, all you need to do is
work downstream from someone who swears by it and try to do some valid
numerical analysis. The only person I ever knew with a worse lament was
a friend who worked downstream of an astronomy professor (who should
have been emeritusized years before) that routinely converted his images
to jpeg "to save disk space."
-- Markus
···
On Fri, 2004-10-15 at 17:58, trans. (T. Onoma) wrote:
On Friday 15 October 2004 07:23 pm, markus@reality.com wrote:
> > puts 0.5.round #=> 1
> > puts sprintf("%.0f", 0.5) #=> 0
>
> Both are (IIRC) ISO 31-0 conformant, but one uses ISO 31-0 B.3 rule A
> and the other uses ISO 31-0 B.3 rule B.
>
> That said, one of the rules (the one sprintf uses, to round down
> following even digits is an abomination and should be eliminated from the
> face of the earth. nnn.nn5 should ALWAYS round up and rounded values
> should not be re-rounded (which is what the contrary rule assumes is
> happening).
Apparently the idea of even vs. odd rounding was to help prevent "inflational"
rounding --successive rounding pushing values upward. I think K&R actually
supported the idea. I'm not sure how I feel about it.
"Markus" <markus@reality.com> schrieb im Newsbeitrag
news:1097901288.21256.339.camel@lapdog.reality.com...
> > > puts 0.5.round #=> 1
> > > puts sprintf("%.0f", 0.5) #=> 0
> >
> > Both are (IIRC) ISO 31-0 conformant, but one uses ISO 31-0 B.3
rule A
> > and the other uses ISO 31-0 B.3 rule B.
> >
> > That said, one of the rules (the one sprintf uses, to round
down
> > following even digits is an abomination and should be eliminated
from the
> > face of the earth. nnn.nn5 should ALWAYS round up and rounded
values
> > should not be re-rounded (which is what the contrary rule assumes is
> > happening).
>
> Apparently the idea of even vs. odd rounding was to help prevent
"inflational"
> rounding --successive rounding pushing values upward. I think K&R
actually
> supported the idea. I'm not sure how I feel about it.
Yes, that's exactly why it's there. But there are several reasons
(e.g. Benford's Law http://mathworld.wolfram.com/BenfordsLaw.html\) why
it doesn't even work for its intended purpose. The real answer is to
not re-round the data.
As for developing strong feelings about it, all you need to do is
work downstream from someone who swears by it and try to do some valid
numerical analysis. The only person I ever knew with a worse lament was
a friend who worked downstream of an astronomy professor (who should
have been emeritusized years before) that routinely converted his images
to jpeg "to save disk space."
A real "star destroyer"... :-))
*chuckle*
robert
···
On Fri, 2004-10-15 at 17:58, trans. (T. Onoma) wrote:
> On Friday 15 October 2004 07:23 pm, markus@reality.com wrote:
No, I wasn't fully paying attention to this thread, but did see the talk about alternating rounding. I didn't know if it applied to the sprintf case, so, just in case it was a pseudo-random result I was checking if perhaps it varied between 0/1.
Now, is this due to the Ruby version or rather the libC version (I tested
with cygwin)?
Dunno; I simply offer my data point for observation, and will let others figger out the discrepancy.
