View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

Problem with %f in printf

emma wrote on May 23, 2012

Hi Mike,

I've just come across a weird behaviour when using %f in printf. I've noticed this happens with IRAF 2.14.1 and IRAF 2.15.1a (but not with PyRAF):

ecl> real my_number
ecl> my_number = 3.0
ecl> printf ("%f\n", my_number)
3.000000000000000/
ecl> my_number = 3.1
ecl> printf ("%f\n", my_number)
3.0999999999999999
ecl> my_number = 3.0
ecl> printf ("%g\n", my_number)
3.

Notice the back slash at the end of the first printf statement.

Many thanks,

Emma :)

emma wrote on May 23, 2012

*forward* slash (sorry!)

Mike Fitzpatrick wrote on May 23, 2012

What platform is this, it seems to work fine on v2.16 macintel. Note that the CL implements the 'real' type internally as double-precision which explains the extra digits, pyraf simply has it's own printf() function.

emma wrote on May 23, 2012

This is on my redhat linux machine (RHEL 5).

I'm not worried about the extra digits, just the trailing forward slash that shouldn't be there ;)

Thanks!

Emma :)

Mike Fitzpatrick wrote on May 23, 2012

I can confirm this is still present in the latest v2.16 system, but only on 32-bit linux systems. It appears to be some sort of round-off problem in the converter code, i.e. if the test value is 1.0, or 5.0, or 2.0 then the last character will be different. A '/' char comes immediately before a '0' in ascii but the converter isn't constraining the result.

I'll fix this for the next update, the workaround for now is to specify some level of precision, e.g. "%.8f"

emma wrote on May 23, 2012

Thanks, Mike! :)

Last post on May 23, 2012