gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Ethan A M. <merritt@u.washington.edu>]

On Monday 18 February 2008 21:56, Petr Mikulik wrote:
> > > That's not right, please have a look to the "test" command output for
> > > different terminals. Few years ago, the colour sequence has been unified  
> > > for
> > > most of the colour terminals. Typically the first 5 to 8 colours match.
> > 
> > OK , I'll try to find time to get a definate statement on this. I know in  
> > the last 6 months I was getting (entirely) different colours on screen  
> > shots and svg/png output.
> > 
> > IIRC it was svg output that was probably the inconsistant one.
> 
> You are right, the svg colour sequence is not consistent with the 
> postscript one.

The postscript sequence is ugly.  Let's not use that as a standard.

	Ethan


> 
> ---
> PM
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Petr M. <mi...@ph...>]

> > That's not right, please have a look to the "test" command output for
> > different terminals. Few years ago, the colour sequence has been unified  
> > for
> > most of the colour terminals. Typically the first 5 to 8 colours match.
> 
> OK , I'll try to find time to get a definate statement on this. I know in  
> the last 6 months I was getting (entirely) different colours on screen  
> shots and svg/png output.
> 
> IIRC it was svg output that was probably the inconsistant one.

You are right, the svg colour sequence is not consistent with the 
postscript one.

---
PM

Announcing: A Book on Gnuplot!

[Philipp K. J. <ja...@ie...>]

I would like to announce:

	Gnuplot in Action
	Manning Publications (Fall 2008)
	250 pages, USD 34.99 (paperback)
	www.manning.com/janert

This book is intended to be the first truly
comprehensive tutorial introduction to 
gnuplot, and a guide to its power features
and advanced applications.

The first part of this book is now available as 
early release directly from the publisher at:
	www.manning.com/janert

The printed book will be in the stores (including 
Amazon) later this year.

You will find more information, including a
full table of contents on the publisher's
site, and on my (the author's) site at:
	http://www.principal-value.com/my-book.php

Here are some highlights:
- Graphics Export Made Easy
- Using Gnuplot and LaTeX
- Getting Timeseries Just Right
- Color and Palettes
- Gnuplot for the Web
- Topical Options Reference
... and much more

A word about the author: I have been using
Gnuplot for years and it is one of the three
or four indispensable tools in my toolbox.
In this book, I have tried to condense my
experience using this tool, in a format that
makes it accessible even to people who don't
have a Math/Physics background and have
never used Gnuplot before.

VERY IMPORTANT: While I am finishing up the 
manuscript, I am very interested to hear 
feedback, questions, suggestions about the
book so far. Please email me directly, or post 
a comment to Manning's Author Forum. 

I am looking forward to your comments.

Best,

		Ph.

Re: [Gnuplot-info] color blindness and gnuplot default colors

[<pl...@pi...>]

On Mon, 18 Feb 2008 17:44:13 +0100, Petr Mikulik <mi...@ph...>  
wrote:

>> it seems that there is no relation between the default colours used by  
>> wx
>> or x11 and , say, svg or png output.
> That's not right, please have a look to the "test" command output for
> different terminals. Few years ago, the colour sequence has been unified  
> for
> most of the colour terminals. Typically the first 5 to 8 colours match.

OK , I'll try to find time to get a definate statement on this. I know in  
the last 6 months I was getting (entirely) different colours on screen  
shots and svg/png output. I sent a gnuplot to a college and had to refer  
to the lines by title because the colours bore no relation to what I was  
seeing on wxterminal.

IIRC it was svg output that was probably the inconsistant one.

thx.

RE: circle and ellipse object patch

[m s. <mw...@us...>]

With regard to the comments a few days ago.  One use I see for the patch is the ability to put a background color on a polar gridded plot.  For now I have to multi-plot with a filled curve followed by my real data.  It gets the desired effect but can be confusing to non-gnuplot experts.

I vote for adding the patch.  It is a natural companion to the rectangle objects.

Mike Sutton


-- 
Want an e-mail address like mine?
Get a free e-mail account today at www.mail.com!

Re: Files and pipes only?

[Lars H. <lhe...@us...>]

> -    !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
> -    os_error(name_token, "\"%s\" is not a regular file or pipe",
> +    S_ISDIR(statbuf.st_mode)) {
> +    os_error(name_token, "\"%s\" is a directory",
> 
> works for me.
 
 Ok. I have committed this to cvs, but am still uncertain whether we should
 explicitly disallow block devices.

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Petr M. <mi...@ph...>]

> I agree it would be a worthwhile change. Since the way the colours come  
> out always seems semi random anyway I dont think it will cause backwards  
> compatability issues. Anywhere where colours are important they will  
> require to be specified directly in the plot command.

Gnuplot is used as a plotting engine for some other applications. The change 
of colours would affect them as well. (Octave was an example, however, it 
has changed to explicit rgb recently.)

I'm opposed to change the colour sequence for compatibility reasons. The old 
graphs should be rendered as before. The postscript colour sequence is the 
master sequence.

I would expect that some Matlab user could also come and ask to change the 
colour sequence. Try e.g.
	x=1:100; y=x/1000;
	plot(x,[y;1+y;2+y; 3+y; 4+y; 5+y; 6+y])
Nowadays, Octave has switched to this sequence.

> it seems that there is no relation between the default colours used by wx 
> or x11 and , say, svg or png output.

That's not right, please have a look to the "test" command output for 
different terminals. Few years ago, the colour sequence has been unified for 
most of the colour terminals. Typically the first 5 to 8 colours match.


I propose that somebody contributes a script based on Ethan's 
suggestion:
	...
	set style line 5 lc 2
	set style increment user
We could put it to the gnuplot web page, FAQ, etc. This way, it won't be 
necessary to change all the terminals again, and it will be easy for anybody 
to tune colours according to the particular preferences.

Note that two versions should be prepared, for white and black background.

---
PM

Re: [Gnuplot-info] color blindness and gnuplot default colors

[<pl...@pi...>]

On Sun, 17 Feb 2008 23:42:56 +0100, Timothée Lecomte  
<tim...@lp...> wrote:

> Hi all,
> I am in favour of changing the defaults to a sequence whose two (or
> three if reasonably possible) first colors are distinguishable by color
> blind people. I know that those settings can be changed by the user, but
> it is an additional pain as for every tweak of that kind.

Hi,

I agree it would be a worthwhile change. Since the way the colours come  
out always seems semi random anyway I dont think it will cause backwards  
compatability issues. Anywhere where colours are important they will  
require to be specified directly in the plot command.

BTW T.L. , that is probably the easiest solution for you and your  
colleges. Check out help plot if you are not aware of how to set colours  
for each line.

This relates to one issue I have already raised, that of having more  
consistant output colours in the various terminals. While some terminals  
will have resistrictions it seems that there is no relation between the  
default colours used by wx or x11 and , say, svg or png output.

regards, Peter.

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Timothée L. <tim...@lp...>]

Ethan A Merritt wrote:
> On Saturday 16 February 2008 12:37, Micha Wiedenmann wrote:
>   
>> Hi,
>>
>> Are there any arguments against changing gnuplots default colors to help 
>>   people with color blindness? I think red and green following 
>> immediatly each other is rather poor.
>>     
>
> In the current version of gnuplot you can choose any colors you like,
> in any order you like.
>
>   
Hi all,

I am in favour of changing the defaults to a sequence whose two (or 
three if reasonably possible) first colors are distinguishable by color 
blind people. I know that those settings can be changed by the user, but 
it is an additional pain as for every tweak of that kind.

It turns out that my PhD advisor is color-blind, as is the student that 
works next to me. As I am too lazy to change the defaults by myself, I 
keep having to tell them which curve is what data everytime I discuss 
with them. This is an accessibility problem.

Best regards,

Timothee

P.S.: The oscilloscope I am currently using in the lab as the same 
problem : channel 1 is yellow, 2 is green so these two are 
indistinguishable, and 3 and 4 are purple and gray, not the best choices 
either... and impossible to change

Re: Files and pipes only?

[Scott W. <sw...@ch...>]

>  Scott, can you compile your own with this change to datafile.c: replace
>  the code around line 1293
> 
>                 !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
> 
>  with
> 
>                 S_ISDIR(statbuf.st_mode)) {
> 
>  and test?


-    !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
-    os_error(name_token, "\"%s\" is not a regular file or pipe",
+    S_ISDIR(statbuf.st_mode)) {
+    os_error(name_token, "\"%s\" is a directory",

works for me.

Re: Files and pipes only?

[Scott W. <sw...@ch...>]

Ethan A Merritt wrote:
> On Sunday 17 February 2008 02:22, Scott Worley wrote:
>> gnuplot <<< 'plot "'<(echo -e '1\n3\n2')'" with lines; pause 10'
> 
> Which one of those two redirections is causing the error?

The <() redirection.  The above effectively becomes

    gnuplot <<< 'plot "/dev/fd/63" with lines; pause 10'

(as demonstrated by replacing "gnuplot" with "cat":

    $ cat <<< 'plot "'<(echo -e '1\n3.5\n2')'" with lines; pause 10'
    plot "/dev/fd/63" with lines; pause 10
    $ ls -l <( echo foo )
    crw-rw-rw-  1 root  wheel   22,  63 Sep 23  2005 /dev/fd/63

) and then gnuplot refuses to read from /dev/fd/63 because it's neither 
a file nor a pipe in *BSD.


This syntax used to work because in earlier versions of bash <() was 
implemented with named pipes in /tmp.  Under bash 3.1:

    $ cat <<< 'plot "'<(echo -e '1\n3.5\n2')'" with lines; pause 10'
    plot "/var/tmp//sh-np-3368567213" with lines; pause 10
    $ ls -l <( echo foo )
    prw-------  1 chkno  wheel  0 Feb 17 08:34 /var/tmp//sh-np-1203260826

Re: Files and pipes only?

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 17 February 2008 02:22, Scott Worley wrote:
> gnuplot <<< 'plot "'<(echo -e '1\n3\n2')'" with lines; pause 10'

Which one of those two redirections is causing the error?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Files and pipes only?

[Scott W. <sw...@ch...>]

>> I often use bash's <() process substitution syntax to generate data to 
>> plot.  
> 
> I do not quite follow what you mean. Could you please provide an example
> set of commands?

A simple example:

   gnuplot <<< 'plot "'<(echo -e '1\n3\n2')'" with lines; pause 10'

Re: Files and pipes only?

[Ethan A M. <merritt@u.washington.edu>]

On Friday 15 February 2008 15:54, Scott Worley wrote:
> Why are data files required to be regular files or pipes?

I don't know.

> There's a S_ISREG or S_ISFIFO check performed in src/datafile.c around 
> line 1303.
> 
> I often use bash's <() process substitution syntax to generate data to 
> plot.  

I do not quite follow what you mean. Could you please provide an example
set of commands?   The thing that confuses me is that if you type a 
command like
   plot '< (grep toe ~/aardvarks)' using lines

it should work without passing through the code at line 1303,
because the '<' is trapped as a special case and treated separately
(line 1276).

To prove the point, here is the output from a stupid test run:
gnuplot> plot '/dev/null'
              ^
         "/dev/null" is not a regular file or pipe
         util.c: Success

gnuplot> plot '< (cat /dev/null)'
              ^
         warning: Skipping data file with no valid points
                                 ^
         x range is invalid




> This works great in GNU/Linux, and worked in FreeBSD, OpenBSD,  
> and NetBSD with bash versions less than 3.2.  Starting with bash 3.2.0, 
> bash uses /dev/fd/63 and similar for these substitutions.  In Linux, 
> these "devices" are pipes -- they are S_ISFIFO.  In *BSD, they are 
> character devices -- S_ISCHR.
> 
> What is the S_ISREG or S_ISFIFO test for, anyway?  It's been in gnuplot 
> since the sourceforge cvs import (rev 1.1, 1999), so there's no commit 
> log there to explain the reason for adding it.  Also, the test is simply 
> skipped ifndef HAVE_SYS_STAT_H.
> 
> 
> Removing the test from gnuplot allowed my graphing scripts to work in 
> *BSD again.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 16 February 2008 12:37, Micha Wiedenmann wrote:
> Hi,
> 
> Are there any arguments against changing gnuplots default colors to help 
>   people with color blindness? I think red and green following 
> immediatly each other is rather poor.

In the current version of gnuplot you can choose any colors you like,
in any order you like.

> >>  I think it would be helpful for people with color blindness to change
> >>  that order into
> >>
> >>  1 red
> >>  2 blue
> >>  3 magenta
> >>  4 cyan
> >>  5 green

So put this in your ~/.gnuplot initialization file:

 set style line 1 lc rgb "red"
 set style line 2 lc rgb "blue"
 set style line 3 lc rgb "magenta"
 set style line 4 lc rgb "cyan"
 set style line 5 lc rgb "forest-green"
 set style increment user

As I see, Hernan has already suggested this.

 
> Here is my email from gnuplot-info:
> 
> Hernán Gonzalo Asorey wrote:
> > On Thu, Feb 14, 2008 at 8:57 AM, Micha Wiedenmann <mw...@gm...> wrote:
> >> Hi there,
> >>
> >>  gnuplot default colors seem to be
> >>
> >>  1 red
> >>  2 green
> >>  3 blue
> >>  4 magenta
> >>  5 cyan
> >>  ...
> >>
> >>  I think it would be helpful for people with color blindness to change
> >>  that order into
> >>
> >>  1 red
> >>  2 blue
> >>  3 magenta
> >>  4 cyan
> >>  5 green
> >>
> >>  This makes the clas of red and green less likely.
> >>
> >>  A workaround is using linetype in the plot command as in
> >>
> >>  plot [][-1:1] sin(x), cos(x) lt 3, tan(x) lt 4, x lt 5, x**2 lt 2, x**3
> >>
> >>  or defining line styles
> >>
> >>  set style line 2 lc 3
> >>  set style line 3 lc 4
> >>  set style line 4 lc 5
> >>  set style line 5 lc 2
> >>  set style increment user
> >>  plot [][-1:1] sin(x), cos(x), tan(x), x, x**2, x**3
> >>
> >>  But this is lots of work on a day by day basis and I see no argument
> >>  against change gnuplots default, at least moving green down in the color
> >>  list.
>  >
>  > This is a good idea. As far as I know you can "pseudo-implement" that
>  > by seting the .gnuplot file (or GNUPLOT.INI) in your home directory:
>  >
>  > "[...] If the initialization file is found, `gnuplot` executes the
>  > commands in it.
>  >  These may be any legal `gnuplot` commands, but typically they are 
> limited to
>  >  setting the terminal and defining frequently-used functions or 
> variables."
>  >
>  > (see help .gnuplot for further details).
>  > Cheers,
>  >
>  > Hernán
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Files and pipes only?

[Lars H. <lhe...@us...>]

> 1998-09-16  Lars Hecking  <lhe...@nm...>
> 
>          * datafile.c: Modified version of Alexander Mai's stat(2) patch
>          (check if regular file or pipe before opening data file).
> 
> Good luck trying to find Alexander and getting him to remember what his 
> rationale for that patch was, over nine years ago.
 
 I can't find the actual patch, nor can I find a complete info-gnuplot-beta
 archive here, but the rationale was simply to avoid opening objects that
 don't  make sense in the context, e.g. directories. So, if there can be
 a more elegant or general solution, no problem.

Re: Files and pipes only?

[Hans-Bernhard B. <HBB...@t-...>]

Scott Worley wrote:
> Why are data files required to be regular files or pipes?

Because the source says so. ;-)

> What is the S_ISREG or S_ISFIFO test for, anyway?  It's been in gnuplot 
> since the sourceforge cvs import (rev 1.1, 1999), so there's no commit 
> log there to explain the reason for adding it.

But there's a ChangeLog entry for it, in the "old" logfile:

1998-09-16  Lars Hecking  <lhe...@nm...>

         * datafile.c: Modified version of Alexander Mai's stat(2) patch
         (check if regular file or pipe before opening data file).

Good luck trying to find Alexander and getting him to remember what his 
rationale for that patch was, over nine years ago.

> Also, the test is simply skipped ifndef HAVE_SYS_STAT_H.

Of course it is --- without that header, we can't use stat(), so there 
would be no way to do the test.

Re: [Gnuplot-info] color blindness and gnuplot default colors

[Micha W. <mw...@gm...>]

Hi,

Are there any arguments against changing gnuplots default colors to help 
  people with color blindness? I think red and green following 
immediatly each other is rather poor.

Here is my email from gnuplot-info:

Hernán Gonzalo Asorey wrote:
> On Thu, Feb 14, 2008 at 8:57 AM, Micha Wiedenmann <mw...@gm...> wrote:
>> Hi there,
>>
>>  gnuplot default colors seem to be
>>
>>  1 red
>>  2 green
>>  3 blue
>>  4 magenta
>>  5 cyan
>>  ...
>>
>>  I think it would be helpful for people with color blindness to change
>>  that order into
>>
>>  1 red
>>  2 blue
>>  3 magenta
>>  4 cyan
>>  5 green
>>
>>  This makes the clas of red and green less likely.
>>
>>  A workaround is using linetype in the plot command as in
>>
>>  plot [][-1:1] sin(x), cos(x) lt 3, tan(x) lt 4, x lt 5, x**2 lt 2, x**3
>>
>>  or defining line styles
>>
>>  set style line 2 lc 3
>>  set style line 3 lc 4
>>  set style line 4 lc 5
>>  set style line 5 lc 2
>>  set style increment user
>>  plot [][-1:1] sin(x), cos(x), tan(x), x, x**2, x**3
>>
>>  But this is lots of work on a day by day basis and I see no argument
>>  against change gnuplots default, at least moving green down in the color
>>  list.
 >
 > This is a good idea. As far as I know you can "pseudo-implement" that
 > by seting the .gnuplot file (or GNUPLOT.INI) in your home directory:
 >
 > "[...] If the initialization file is found, `gnuplot` executes the
 > commands in it.
 >  These may be any legal `gnuplot` commands, but typically they are 
limited to
 >  setting the terminal and defining frequently-used functions or 
variables."
 >
 > (see help .gnuplot for further details).
 > Cheers,
 >
 > Hernán

Status of patch 1827826? (enhancements to dgrid3d)

[Philipp K. J. <ja...@ie...>]

I was wondering what your plans are for patch 1827826, 
which adds some additional features to gnuplot's dgrid3d 
facility.

I find that some of the additional smoothing functions
it provides make it significantly easier to obtain good 
surface plots from noisy or non-gridded data.

Any chance it might make it into the trunk version? Let
me know if I can help with testing or documentation.

Best,

		Ph.

Comment on INSTALL in the CVS trees

[Tatsuro M. <tma...@ya...>]

Dear gnuplot developpers

The gnuplot is the one of the most essntial tool for my reseach work in my university.
I appreciate the all developpers to make such a good software.  

As a one of the user, I have a comment on 'INSTALL'.

I have build two binaries wgnuplot and gnuplot-djgpp.
First I have read INSTALL. 

MS-Windows
----------
General install instructions:
 Change into the "src" subdirectory.
 Build the program using one of the ways shown below this note.
 Put wgnuplot.exe, wgnuplot.hlp and wgnuplot.mnu all in a single
  directory somewhere.  You may want to add that directory to your PATH.
 There's no installer for gnuplot, so if you want a desktop link,
  program manager group or an association of *.plt or *.gpl files to
  wgnuplot, you'll have to do all that yourself.

However, in the config/makefile.mgw config/makefile.dj2
The following are described
# - compile the package: go to directory 'gnuplot' and therefrom run
#	 make -C src -f ../config/makefile.mgw
#

#       from the main gnuplot directory, do:
#       make -C src -f ../config/makefile.dj2


According to the makefile instruction, we have to go the gnuplot directry but not to gnuplot/src.
However, in the INSTALL, we should go to the  gnuplot/src

I made the binary according to the instruction in the makefile.

Why the this confilction being not to be corrected?
I think that the instructions in comment in the makefile is newer.

At least, the sentenses like the followindg should be added to the INSTALL

The more latest information of install is described in the comments in each makefile.xxx (xxx is the
name of the platfrom.).  Please also read it before install.

Regards

Tatsuro

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Files and pipes only?

[Scott W. <sw...@ch...>]

Why are data files required to be regular files or pipes?

There's a S_ISREG or S_ISFIFO check performed in src/datafile.c around 
line 1303.

I often use bash's <() process substitution syntax to generate data to 
plot.  This works great in GNU/Linux, and worked in FreeBSD, OpenBSD, 
and NetBSD with bash versions less than 3.2.  Starting with bash 3.2.0, 
bash uses /dev/fd/63 and similar for these substitutions.  In Linux, 
these "devices" are pipes -- they are S_ISFIFO.  In *BSD, they are 
character devices -- S_ISCHR.

What is the S_ISREG or S_ISFIFO test for, anyway?  It's been in gnuplot 
since the sourceforge cvs import (rev 1.1, 1999), so there's no commit 
log there to explain the reason for adding it.  Also, the test is simply 
skipped ifndef HAVE_SYS_STAT_H.


Removing the test from gnuplot allowed my graphing scripts to work in 
*BSD again.

Re: Intended scope of "set locale" and "set decimalsign"?

[Petr M. <mi...@ph...>]

> Questions
> =========
> The current documentation for "set decimal locale" is incorrect for
> both 4.2 and CVS; it is not applied to "all input and output".
> 
> - Should the locale be applied to data output via "set table 'filename'"?
>   Both 4.2 and CVS do this, although it is not specifically documented.    
> 
> - Should the locale be applied to output from "print foo"?
>   4.2 does this; CVS does not.
> 
> - Should the locale be applied to output from "show variables"?
>   Neither 4.2 nor CVS does this.
> 
> I am inclined to say "yes" to the first, and "no" to the other two.
> But it's not a strong opinion.

I agree.
An option "set table 'filename' {no}locale" could be added to allow this 
particular choice.

> - What do we really want the "set locale" command to do?

Two principle ways of usage:
- produce graphs with "," in decimal numbers
- read datafiles with ","

> Sorry, this is probably not very helpful, but from experience with 
> gretl I'd say: use of anything other than '.' as decimal separator 
> is evil

We have to accept that "," is traditional in many european countries.

Re: Intended scope of "set locale" and "set decimalsign"?

[Allin C. <cot...@wf...>]

On Thu, 14 Feb 2008, Ethan Merritt wrote:

> - What do we really want the "set locale" command to do?

Sorry, this is probably not very helpful, but from experience with 
gretl I'd say: use of anything other than '.' as decimal separator 
is evil, and given that it's an option at all, the more tightly 
it can be corralled, the better.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Intended scope of "set locale" and "set decimalsign"?

[Ethan M. <merritt@u.washington.edu>]

The current documentation for "set decimalsign" says:

   The `set decimalsign` command selects a decimal sign for numbers
   printed into tic labels or `set label` strings.

The current documentation for "set locale" says:

   The `locale` setting determines the language with which 
   `{x,y,z}{d,m}tics` will write the days and months.

Both of those statements describe a very limited scope, although they
disagree about whether label text falls within this scope.

The current documenation for "set decimal locale 'foo'" descibes a
larger scope:

   This instructs the program to format all input and output in
   accordance with locale "foo", which must be installed.

4.2
===
It is worth noting that locale support in version 4.2 is currently
broken in a number of ways.  For example, issuing "set decimal locale"
for a locale with comma as a decimal separator breaks output to
the postscript and svg terminals.  This is because (notwithstanding
the documentation quoted above) the scope of the "set decimal" command
is quite broad.

CVS
===
Locale handling in the CVS version was re-worked to avoid the problems
in 4.2   In the CVS code, the locale is always set to "C" except for
three specific cases:
(1) Data input
(2) Formatting by the internal function gprintf()
    - Used internally to format the axis tick labels.
    - Also available as a user-callable function
(3) Formatting by the user-callable function sprintf()


Questions
=========
The current documentation for "set decimal locale" is incorrect for
both 4.2 and CVS; it is not applied to "all input and output".

- Should the locale be applied to data output via "set table 'filename'"?
  Both 4.2 and CVS do this, although it is not specifically documented.    

- Should the locale be applied to output from "print foo"?
  4.2 does this; CVS does not.

- Should the locale be applied to output from "show variables"?
  Neither 4.2 nor CVS does this.

I am inclined to say "yes" to the first, and "no" to the other two.
But it's not a strong opinion.

- What do we really want the "set locale" command to do?

The current use is so restricted as to be confusing.
I am inclined to say this command should be deprecated in favor of
a "locale" keyword for "set timefmt". But I never use this, so I defer
to people for whom it actually matters.



-- 
Ethan A Merritt

Re: [Fwd: german locale Problem]

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 12 February 2008 16:05, Hans-Bernhard Bröker wrote:
> Hello, guys,
> 
> I received mail from a German user of gnuplot on Win32 who observes 
> strange behaviour, apparently from 'set decimalsign locale' being set to 
> German:
> 
> Version:
>          G N U P L O T
>          Version 4.2 patchlevel 2
>          last modified 31 Aug 2007
>          System: MS-Windows 32 bit
> 
> [Condensed] script to reproduce:
> 
> set datafile separator ';'
> set decimalsign locale 'german'
> p1              = -22.5
> p2              = 52.5
> p3              = 30
> p(x)=p1*(x-2001)**2+p2*(x-2001)+p3
> print p(2005)
> print p(2005.5)
> 
> Output from the two print commands is:
> 
> -120.0
> -189,375
> 
> Note that it's -120.0, with a '.', instead of the requested and expected 
> ',', while the output of -189,375 worked as expected.  Does this ring a 
> bell with anyone?

No. But after a bit of poking around I found this routine in show.c
num_to_str(double r)
{
    static int i = 0;
    static char s[4][25];
    int j = i++;

    if (i > 3)
        i = 0;

    sprintf(s[j], "%.15g", r);
    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");

    return s[j];
}

As you can see, it gratuitiously adds ".0" to the end of integers without
regard to the current locale. I suppose this is fixable if necessary.

But now I have another question.  In current CVS the "print" command is not
one of the special cases for which the current locale is checked.
All output from "print" is processed in the C locale. Should it be?
The documentation is silent on this precise issue, but implies that the
locale is used only for numberic output to the graph itself, not to the terminal.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742