printf (awk,perl,shell) float rounding issue

Hi guys,

could someone throw some light on the following behaviour of printf (I'll start with info about the system and the tool/shell/interpreter versions)?:

$ uname -a
Linux linux-86if.site 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux

$ bash --version
GNU bash, version 4.2.10(1)-release (x86_64-suse-linux-gnu) 

$ awk --version
GNU Awk 4.0.0 

$ perl --version
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi 

$ ksh ### using ksh now
$ echo ${.sh.version}
Version JM 93t+ 2010-06-21 

$ exit ### back to bash

$ type printf
printf is a shell builtin

$ printf "%.0f\n" 4.5
4

$ printf "%.0f\n" 5.5
6

$ awk 'BEGIN{printf "%.0f\n",4.5}'
4

$ awk 'BEGIN{printf "%.0f\n",5.5}'
6

$ perl -e 'printf "%.0f\n",4.5'
4

$ perl -e 'printf "%.0f\n",5.5'
6

$ ksh ### now to ksh
$ whence -v printf
printf is a shell builtin

$ printf "%.0f\n" 4.5
5

$ printf "%.0f\n" 5.5
6

Only the printf builtin in ksh93t+ seems to give me what I expect (4.5 being rounded to 5 and 5.5 to 6).

Why so? And if this has anything to do with the internal representation of numbers, why does ksh93t+ make an exception?

With perl try these:

$ perl -e 'printf "%.4f\n",4.5'
4.5000

$ perl -e 'printf "%1.1f\n",4.5'
4.5

$ perl -e 'printf "%1.0f\n",4.5'
5

$ perl -e 'printf "%f\n",4.5'
4.500000

Because floating point doesn't work that way. It doesn't count in nice 1.0 jumps, and forcing it to do so removes a lot of the point of having a floating point -- both figuratively and literally.

It's not really a missing feature, anyway. Add 0.5 before you print the decimal and that gets you rounding.

And why does it seem to work in ksh93?

---------- Post updated at 12:54 AM ---------- Previous update was at 12:48 AM ----------

Could you elucidate?

My perl 5.12.4 gives:

$ perl -e 'printf "%1.0f\n",4.5'
4
$ perl -e 'printf "%.0f\n",4.5'
4

So does bash 3.2.48 and dash 0.5.7:

$ printf "%1.0f\n" 4.5
4

but ksh93u:

$ printf "%1.0f\n" 4.5
5

They employ different tie-braking rules for rounding of half-integers: "round half up" vs. "round half to even". It is tie-breaking since for example 1.5 is as far removed from 1 as it is from 2.

There are some statistics books that recommend rounding even values down (4.5 -> 4) and odd values up (5.5 -> 6) assuming that doing so will produce sums of rounded numbers closer to the value of the sums of the unrounded values. But I doubt that ksh is trying to provide that capability. I would guess that this could easily be caused by some programs using float, others using double, and still others using long double and having the process of converting 4.5 to the closest value in those formats sitting on opposite sides of the not quite exact value 4.5 representable in the various formats.

They must have taken effort to make it do so. I don't know why they bothered, since it's not a feature really needed, undesirable in most cases, and easy to do yourself if you really want it.

Floating point numbers are represented internally as an exponent, like 1.5*10^3 or so forth.

If it were something that is a random consquence of some conversion, then I think the rounding would not be as consistent as it is in those shells other than ksh... The rounding of half-integers are a special case and a choice needs to be made...

Apparently "round half to even" is the default and/or recommended way according to IEE754

On the machines most of us work on, floating point numbers are represented as x2^y or x16^y rather than x*10^y, but .5 is exactly representable in any of them. On the other hand 0.1 is not exactly representable on any system that uses an exponent of 2 or 16.

As pointed out by Scrutinizer, the real answer lies in the rounding mode being used by whatever function is converting the internal floating point value to a printable decimal representation of that value.

I know how it works. It wasn't too relevant to the example. The point is it uses an exponent, it's not stored literally.

0.5 is. Anything else .5 depends.

Yes, which I pointed out most generally don't. ksh93 would be an exception.