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.
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"
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum