string_cat_real() crashing about quip

[albapa]

Here is an idea: for the real format, let's switch to the "g" format specifier instead of the "f". The advantage of "g" is that it switches to the exponent-based form automatically. E.g. g0.17 produces:

10**(-10) =   0.10000000000000000E-009
10**0       =   1.0000000000000000
10**16     =   10000000000000000.
10**79     =   0.10000000000000001E+080

The only caveat is how to determine the string length. With "f" it's easy based on the log10 of the real. With "g" my suggestion would be writing out the real into a fixed length character variable which is longer than the longest possible expression (with "g" this is limited) and then call a len_trim() to determine the actual length. I know it's not as elegant but it should be quite robust.

If there is no objection, I'll make these changes soon.

[jameskermode]

Sounds like a good plan to me - there may be some test regressions that will need to be fixed.

[albapa]

I have made these changes - the tests passed so all seems to be well. Let me know of any problems!

[tdaff]

It looks like using g with a width of 0 can only be used with ifort version 12.1 or newer (it's broken in 12.0 and will not compile in 11 or earlier, see #46).

Some options are:

• use g with a fixed width in the formatting; 17 decimal places plus -0. and +Exxx should be enough for any double?
• does g alone give the same thing? -- I think probably not
• make minimum required ifort 12.1 -- we'll need to install some newer compilers for testing.

[albapa]

In addition to this, there is a bug reported by Aidan Thompson where the length is not determined correctly if default_precision=0.

[albapa]

To work around this, keeping the former behaviour and keep intel 11 support, I have essentially reimplemented the "g" format specifier for our real "cat" functions (followed the FORTRAN specifications). This should eliminate the original bug and the intel issues. How does this sound?

I'll push my changes as soon as they clear the test, let me know of any problems.

@tdaff once the changes are here, could you please run the intel test suite to confirm it's OK? I'll test if it compiles with a more recent intel on Darwin.

[albapa]

I've also added support for the case when default_precision=0. Originally this converted the real to int and printed that. This will fail if r > huge(1). In this situation, it would simply fall back to the real format, with precision = 15. What do you think?

[tdaff]

Thanks! The fix looks good and the Intel builds are passing again.

Is the expected output tested anywhere? I know it's an operator embedded quite deeply in Fortran and the tests run at the Python level, but would there be a simple way to just have inputs and expected outputs? If not, I think testing it something that should probably be looked at at the hackathon anyway...

-- Tom