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
