Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-10 17:38:11
|
>=20
> >Comment By: Petr Mikulik (mikulik)
> Date: 2005-06-10 09:24
>=20
> I hope gnuplot's reading will not depend on environmental
> variables as it would immediately became non-portable.
I think you have this backwards. The LOCALE mechanism is our
best and probably only path toward true portability.
=20
> I would rather prefer
> set decimalsign input ","
We can discuss the choice of gnuplot commands at leisure,
but the fact is that the only way to take action on such a
request is via the LOCALE mechanism, and for better or for
worse that affects both input (scanf, atof, strtod, ...) and
output (printf, ...) in parallel.
This is the code I have been testing:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
/* process 'set decimalsign' command */
static void
set_decimalsign()
{
c_token++;
if (END_OF_COMMAND) {
if (decimalsign !=3D NULL)
free(decimalsign);
decimalsign=3DNULL;
#ifdef HAVE_LOCALE_H
} else if (equals(c_token,"locale")) {
c_token++;
setlocale(LC_NUMERIC,"");
fprintf(stderr,"decimal_sign in locale is %s\n", (localeconv()->dec=
imal_point));
decimalsign =3D gp_strdup(localeconv()->decimal_point);
#endif
} else if (!(decimalsign =3D try_to_get_string()))
int_error(c_token, "expecting string");
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
So to read an input file with numeric formatting in the convention
of your local environment, you would say
set decimal locale
plot "foo" ...
So far as I know, it is not possible to hard-code the LOCALE choice
entirely internal to gnuplot, because gnuplot has no control over
what locales are installed or supported on the machine it runs on.
We are guaranteed that the "C" locale is available, which uses=20
'.' as a decimal sign, but I have been unable to find any guaranteed
locale that would use ',' instead.
=46rom the command line on linux you can say
setenv LC_NUMERIC ,
and `locale -c -k` claims that the decimal sign is now "," but upon
testing I find that it does not in fact have any effect on formatting
and anyhow the equivalent request from inside a program via setlocale()
is not accepted at all.
(I'll be out of town for several days, so I won't see any replies for
a while)
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-13 02:24:21
|
On Saturday 11 June 2005 02:41 am, SourceForge.net wrote: > >Comment By: Hans-Bernhard Broeker (broeker) > > I.e. we need a new command > > set locale {input|output|both} <locale_name> > > (or equivalent additions to 'set style data' and 'set > format'), and maybe even a per-file handling option in > {s}plot to override this. I was under the impression that there is no way of separating the locale used for input (e.g. scanf) from the locale used for output (e.g. printf). Do you know otherwise? As to "set locale xx_YY.ZZ", we could create such a command easily. But the documentation must be as clear as possible that such a command will only *work* if the appropriate locale is already installed on the user's machine. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-06-13 08:02:01
|
Ethan Merritt wrote: > I was under the impression that there is no way of separating the locale > used for input (e.g. scanf) from the locale used for output (e.g. printf). > Do you know otherwise? Well, we know when we're doing what, so we could conceivably switch between the two at the correct times during the process. Worst thing that could happen is slightly unexpected error messages in input locale rather than output locale, if they are printed during datafile reading. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-13 17:23:52
|
On Monday 13 June 2005 01:02 am, Hans-Bernhard Broeker wrote: > Ethan Merritt wrote: > > > I was under the impression that there is no way of separating the locale > > used for input (e.g. scanf) from the locale used for output (e.g. printf). > > Do you know otherwise? > > Well, we know when we're doing what, so we could conceivably switch > between the two at the correct times during the process. Worst thing > that could happen is slightly unexpected error messages in input locale > rather than output locale, if they are printed during datafile reading. It would have to be a very fine-grained switch, bracketing each scanf/printf call. For instance a plot command like plot 'foo' using 1:2:(sprintf(format,column(3))) with labels will be mixing scanf and sprintf during the parsing of every data line. Could be done, but I can already here the screams about the performance hit :-) -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-06-13 17:32:27
|
Ethan Merritt wrote: > It would have to be a very fine-grained switch, bracketing each > scanf/printf call. For instance a plot command like > plot 'foo' using 1:2:(sprintf(format,column(3))) with labels > will be mixing scanf and sprintf during the parsing of every data line. > > Could be done, but I can already here the screams about the performance > hit :-) Well, since we wouldn't be forcing anyone to use any locale setting at all, and the default should be "all locales are 'C', so no setlocale() calls needed", I consider that a negligible risk. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-13 18:18:37
|
On Monday 13 June 2005 10:33 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
>
> > It would have to be a very fine-grained switch, bracketing each
> > scanf/printf call. For instance a plot command like
> > plot 'foo' using 1:2:(sprintf(format,column(3))) with labels
> > will be mixing scanf and sprintf during the parsing of every data line.
> >
> > Could be done, but I can already hear screams about the performance
> > hit :-)
>
> Well, since we wouldn't be forcing anyone to use any locale setting at
> all, and the default should be "all locales are 'C', so no setlocale()
> calls needed", I consider that a negligible risk.
I've uploaded a patchset to SourceForge that implements
set decimalsign { <value> | {locale {<LOC>}}
My thought is that people can try this out and report back whether
there is a need to separate out the input and output locales.
By the way, it may be obvious but let me state it explicitly:
The existing `set locale` command only affects LC_TIME, the format used
for time/date strings.
The new command options to `set decimalsign` only affect LC_NUMERIC,
the format conventions used by the C library for scanf and printf.
Neither of these affects LC_CTYPE, which controls the character set
and font encoding.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
