Regional Settings When Writing Real Numbers

[Nick2]

Hello,

I noticed something odd...

I have some statements that look like this:

WRITE (IFIL,*) XOUT, (PLTVAL(J,I),J=1,IPTS)

These statements write out real numbers as I would expect.

But when I switch the Regional and Language settings in the Control Panel, say to Swedish, where the numbers should be in the 123456,76 format rather than the US 123456.76 format, my output seems to ignore the Regional and Language settings change, and the numbers are still output in the US format. This is with either CVF 6.6 or IFORT 11.1.051.

Am I missing something?

Thanks!

Nick

[Steven_L_Intel1 · Accepted solution]

You are missing that the Fortran standard does not specify that the defaults for the radix point change based on regional settings. The standard behavior is that DECIMAL='POINT' if not explicitly overridden. The standard makes no mention of some external way of establishing regional preferences.

[DavidWhite]

I have this problem when writing out tab-delimited text files which are sometimes opened in Excel. When used with the Regional settings where the decimal point is a comma, I have problems.

I got around it with

! Set NLS Flag

i = NLSGetLocaleInfo( NLS$LI_SDECIMAL, DECIMAL)

NLSComma=(DECIMAL==",")
...
Then before writing out each line of text to the file:

IF (NLSComma) THEN

DO

I = INDEX(STRING, ".")

IF (I==0) EXIT

STRING(I:I)=","

END DO

END IF

Regards,

David

[Steven_L_Intel1]

David, I don't understand your post. The default, no matter what the locale, is to use "period" (or "POINT" in Fortran terms) as the radix indicator. Or if you wanted to write out commas, use DECIMAL="COMMA" when opening the file. There are also the DP and DC format items to change the indicator "on the fly".

[Jugoslav_Dujic]

I think that David meant to say that he has problem reading the files from Excel, because its input expectations depend on regional settings, so he had to tweak the Fortran code to accomodate for that.

In my book, the idea that file format depends on user's regional settings, so that a French user's software cannot read files generated by in the US, without tweaking the options, ranks among the highest on the list of Most Stupid Design Decisions Ever. (And in Canada, they can't even exhcange the files within the same country).

[Arjen_Markus]

I second that - I have even seen that the _names_ of the functions were translated!
That is: I was using a Dutch version of MS Excel and I had to write SOM(...) instead of SUM(...).
I do not remember if that was translated in the file itself to SUM(...) so that it remained useable
in an English version, but even so, one can try to be too helpful.

Regards,

Arjen

[mecej4]

I think that what David suggested is to assemble each line of text (using an internal file, perhaps), replace '.' by the national decimal point (he needs to handle all occurrences of '.' within the line) and then print the line to file.

That would be a verbose and laborious way of solving the problem. Rather than intersperse a big Fortran program with all these conversions, it would be better to use Steve's recommendations or to write a utility to filter the output of the program, replacing the periods by the national decimal points.

[mecej4]

At that rate, we may have NLS-aware linkers some day! That should be a lot of fun.

[Arjen_Markus]

Oh, can we have grammar-aware programming languages then? I mean: it would be so much
more fun, if you can just explain to the computer what you want done in your own (English, Dutch,
Latin, ancient Greek, ...) words, instead of having to translate them into these dull programming
languages we are stuck with today!

Regards,

Arjen

[Jugoslav_Dujic]

I've read somewhere (cannot find a proof at the moment) that back in 50s or 60s, Russians had their own version of FORTRAN, complete with keywords in Cyrillic. According to the Wikipedia article, it was actually ALGOL-68; there is even a link to the Russian standard.

[rase]

In the early sixties there was a Swedish ALGOL compiler using keywords in Swedish, such as "tryk" for "print" (or something like that). The Swedish abondoned their national sonderweg quickly when they found out that the international exchange of programs was impossible. By the way: it is possible to override the national default settings in MS-EXCEL, for example DECIMAL='COMMA' by DECIMAL='POINT'.

[DavidWhite]

Steve,

Jugoslav's reply to your post is correct - Excel uses the local language settings when converting text files on input. I usetab-delimited format asdatabases for my Fotran programs. Normally, when writing or reading the files in Fortran everything is OK. For US/UK type language settings, these files can be opened automatically in Excel, but in locales where comma is the decimal separator, Excel cannot understand the data values on reading.

So when running my program in a locale with comma as a decimal separator, I need to convert all of the normal decimals to commas. As the database could have been created with US locale, I need to convert all of the values in the multi-column database.

Seeing your examples, I could clean up my codeusing "POINT" and "COMMA" which I had not seen before.

Regards,

David