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):
Notice the back slash at the end of the first printf statement.
Many thanks,
Emma :)
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 :)
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"
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