|
From: Juergen W. <wie...@fr...> - 2005-09-17 07:19:12
|
On Saturday 17 September 2005 03:07 Ethan A Merritt wrote:
> On the other hand this makes many gnuplot commands ambiguous
> at best:
>
> set label 1 offset 1,2
>
> I would have expected this to set the offset to (xoff=1 yoff=3 zoff=0)
> but now it instead sets (xoff=1,2 yoff=0 zoff=0).
> Is that acceptable? Is it what a user would expect, if he has gone
> to the trouble of setting a decimalsign == comma locale?
My two pence:
This example shows quite nice that the parsing of the *script* file
should never be locale dependend. The decimal point is part of the
script language specification. It might be a feature to enable the
possibility for data files with decimal commas.
> But the current, unpatched, state of the code has problems also.
> set decimalsign locale
> show locale
> LC_CTYPE is fr_FR
> LC_NUMERIC is fr_FR
> LC_TIME is C
> PI = 3.14159
> print PI
> 3.0
> print pi
> 3,14159265358979
>
> That is both wrong, and puzzling. I can understand why PI gets
> set to 3 on input - that's the effect of sscanf() or atod() with
> LC_NUMERIC set to fr_FR. But why does it revert to a dot for the
> decimal sign on output? Notice that the internal constant "pi" is
> printed with a comma, as I would have expected. Strange.
The ".0" is explicitly added to show it is a float, not an integer.
See show.c (num_to_str):
if (strchr(s[j], '.') == NULL &&
#ifdef HAVE_LOCALE_H
strchr(s[j], ',') == NULL &&
#endif
strchr(s[j], 'e') == NULL &&
strchr(s[j], 'E') == NULL)
strcat(s[j], ".0");
> Perhaps a better way is to force LC_NUMERIC to C during the
> scanning of a gnuplot input line. That means all numbers on a
> gnuplot command line must use dot rather than comma as a
> decimal sign. Then to fix the original bug report, any code
> that *constructs* a gnuplot command line, must *also* set
> LC_NUMERIC to C while it operates.
> That would include both the built-in functions like zoom and the
> interpretation of key bindings.
ACK.
Juergen
|