Hi Alan,
I have looked at the locale behaviour with the small program below:
/* chklocale.c --
Check the behaviour of the locale - printf() and friends
*/
#include <stdio.h>
#include <locale.h>
int main( int argc, char *argv[] ) {
float x = 1.2;
setlocale(LC_NUMERIC, "");
printf( "Number: %f\n", x );
if ( argc > 1 ) {
sscanf( argv[1], "%f", &x );
printf( "Read: %f\n", x );
}
}
Setting LC_NUMERIC to "nl_NL.UTF-8" gives the following
results:
> chklocale 1.3
chklocale 1.3
Number: 1,200000
Read: 1,000000
> chklocal 1,3
chklocale 1.3
Number: 1,200000
Read: 1,300000
So indeed - as was to be expected, the comma is used on input and
output instead of a period. If PLplot's setting of the locale is visible
outside the PLplot functions, this may give very nasty errors!
Regards,
Arjen
On 2009-09-04 08:59, Arjen Markus wrote:
> Hi Alan,
>
> much as I appreciate the use of commas instead of periods (living in
> a country where commas are used - or should be - as the decimal
> separator), I do see a number of problems:
> - If a user sets the locale in his/her program before a call to
> plinit(), a default enforced by PLplot might cause a different
> behaviour than expected.
> - If PLplot sets the locale, does this have consequences for
> functions like fscanf()? I have never dug into the specifics,
> but it might all of a sudden read "1,2" as the number 1.2.
>
> The effect of introducing setlocale() in PLplot should, in my
> opinion, be limited entirely to calls to the PLplot library.
> Otherwise there could be all manner of trouble that is difficult
> to hunt down.
>
> Maybe I am pessimistic, but I have seen too many bizarre consequences
> from half-hearted implementations of locale settings. (Older versions
> of MS Excel made spreadsheets written in one locale unuseable in
> another locale, because "1.2" suddenly was a literal string instead
> of a number. Even more troublesome: current versions use function
> names that are specific to the human language the operating system
> is set to. At home I need to type SOM(A1:A10) instead of SUM(A1:A10),
> as the OS is set to Dutch.)
>
> Regards,
>
> Arjen
>
> On 2009-09-03 21:48, Alan W. Irwin wrote:
>> I have assigned a new subject because this topic deserves its own thread.
>>
>> On 2009-09-01 11:24-0700 Alan W. Irwin wrote:
>>
>>> [...] Thus, I think our best solution to this whole issue is to save
>>> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then
>>> restore the user locale in both cmap0_palette_read and plspal1. This method
>>> absolutely guards against any locale issue (say for a different library than
>>> qt) ever again screwing up palette file reading so this is what I like.
>>>
>>> What do you think of this idea?
>> I have continued to think some more about LC_NUMERIC issues in PLplot, and
>> to give some context to further discussion of this, have a look at
>> http://en.wikipedia.org/wiki/File:DecimalSeparator.png. My own country of
>> Canada has different decimal separators depending upon whether you are
>> located in Quebec or otherwise, and a substantial fraction of the countries
>> in the world use the comma for the separator rather than a period.
>>
>> The current status is our plots all correspond to
>>
>> setlocale(LC_NUMERIC, "C");
>>
>> That is they use the period as the decimal separator on axis labels. This is
>> probably consistent with the policy of many scientific publishers out there,
>> but there are almost guaranteed to be some publishers that accept a decimal
>> separator in plots that is whatever the author likes and even some that
>> demand the comma separator regardless of the locale of the author. In
>> addition, although we advertise PLplot as a scientific plotting library, it
>> is also used in other contexts as well where there may be a need to follow
>> the local locale with a comma decimal separator. Thus, for maximum PLplot
>> usefulness, I think we should have a global variables local_locale set to 0
>> or 1 at user option so that plinit calls either
>>
>> setlocale(LC_NUMERIC, "C");
>>
>> for local_locale = 0
>>
>> or
>>
>> setlocale(LC_NUMERIC, "");
>>
>> for local_locale = 1,
>>
>> where the first one should be the default, and the latter one gives complete
>> flexibility since it obtains LC_NUMERIC from the environment (which can be
>> set to anything by the user).
>>
>> Furthermore, this would fit in with my proposed solution to the above issue
>> if we always setlocale(LC_NUMERIC, "C"); before reading palette files
>> regardless of local_locale and restore to either of the above two choices
>> depending on local_locale. Finally, in qt.cpp we should change back to the
>> PLplot locale specified by local_locale just in case the Qt4 libraries
>> change it.
>>
>> I hope to implement all of this later today or early tomorrow so please let
>> me know quickly your comments on my proposal to deal with LC_NUMERIC issues
>> in PLplot.
>>
>> Alan
>> __________________________
>>
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state implementation
>> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
>> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
>> Linux Links project (loll.sf.net); and the Linux Brochure Project
>> (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
