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

Rounded dashed lines

[Theo H. <th...@ph...>]

Hi all. I'm not really sure why this happens, but if I create a graph in 
gnuplot using the epslatex (or even just plain postscript) terminal with 
rounded and dashed lines, the dashed lines come out as solid lines when 
I convert to PDF with either Distiller or epstopdf. Why? The dashed 
lines show up fine in the eps file when I preview it.

THeo

Prerelease version 4.2.1-pre1

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

I have placed a tarball on SourceForge containing a trial version
of an incremental release 4.2.1.  This is a bug-fix release, including
fixes for installation problems reported on several platforms.
It also includes a couple of minor new features that were just a little
too late for the code freeze leading up to 4.2.0

Barring any problem reports, my plan is to bump the PATCHLEVEL up
to 4.2.1 proper and release it with no changes to the code.


   	          GNUPLOT VERSION 4.2.1-pre1
	    =======================================

This is trial release of version 4.2.1, which is itself an incremental
bug-fix release for version 4.2.0.  A synopsis of the changes since 4.2.0
is given below and in the NEWS file.  Full information is given in the
ChangeLog.   Unless people report problems with this pre-release, it will
be re-tagged as 4.2.1 and released with no other changes.

New features, changes and fixes since gnuplot version 4.2.0
===========================================================
* NEW allow extra column in 2D plots containing color information
* NEW set term latex {size XX,YY}
* FIX buffering of very long input lines
* FIX clipping of image data against plot boundary
* FIX polygon clipping bugs
* FIX key sample for plots with variable color
* FIX wxt initialization on non-gnu systems
* FIX escape sequence %% handling in sprintf() format strings
* FIX Apply "set style incr user" to 3D contours and to columnstacked histograms
* FIX Allow string variable as filename for "fit via <filename>"
* CHANGE defer x11 initialization
* CHANGE clean up configuration files for amg, cyg, mgw, dj2
* CHANGE modify SVG output to accommodate non-compliant viewers
* CHANGE allow 'strcol()' as shorthand for 'stringcolumn()'
* CHANGE default to "blacktext" for TeX-based PostScript variants


Demo plots illustrating these and other features are online at

	http://gnuplot.sourceforge.net/demo_4.2/

You can download a source tarball for gnuplot version 4.2.1-pre1 from the 
gnuplot development site on SourceForge.

	http://sourceforge.net/project/showfiles.php?group_id=2055


Installation
------------
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.2.1-pre1 ; ./configure ; make
test it:
		make check
install it:
		make install


Known issues
------------
- Plot styles image and rgbimage are marked EXPERIMENTAL; their implementation
  is incomplete and may change in future versions of gnuplot
- Internationalization and locale support is incomplete in this version.
  If you encounter problems with character encodings, numerical formats, or
  other locale issues, try the CVS version on SourceForge.

Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

There is also an active gnuplot discussion forum on usenet group

	comp.graphics.apps.gnuplot

Development
-----------
Gnuplot development is quite active. The development branch (4.3) on 
SourceForge contains preliminary implementations of many new features;
feedback and additional contributions of code are very welcome.

-- 
Ethan A Merritt

Re: Win32 Gnuplot Compilation

[mrbiggles <sno...@sp...>]

David Ko wrote:
> 
> Hello all,
> 
> I've recently been trying to compile Gnuplot in MinGW, and I've gotten 
> everything working except that it crashes when I try to write a png file.
> The 
> Windows binary I downloaded from gnuplot.info works fine, and I have a
> couple 
> questions for the Win32 binary maintainer:
> 
> What build environment was used to create the Win32 binaries? I've tried
> MinGW 
> and Visual Studio .NET thus far, and everything dies when trying to write
> a png 
> file. (i.e. 'set terminal png; set output "test.png"; plot x' <- dies
> here) My 
> latest attempt was with the 'config/makefile.mgw' provided makefile in
> MinGW.
> 
> What version of libgd was used? I assume that the latest version (2.0.35)
> was 
> used, but the makefile.mgw that came w/ gnuplot referred to v.1.8 as
> "new". 
> I've tried using the libgd library built from scratch and the provided
> prebuilt 
> libraries. I've also tried the v1.8 library. Gnuplot behaves identically
> for 
> all of them (crash on png write). 
> 
> Any other tips/ideas for me? I'm not really a windows person by any means.
> 
> Thanks for your time!
> 
> - David Ko
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

=====================================================================
Assuming you are using VC 2005 and gd-2.0.35 . . .

I had the same problem. It had me stumped. Here is how I solved it.

Get the extras package from:

   http://www.libgd.org/releases/extras/gd_build_win32_deps.zip

Then extract it somewhere on your hard drive. Edit the makefile in
the windows directory of gd-2.0.35 and point EXRTRA_INCLUDE and
EXTRA_LIBS to where you extraced gd_build_win32_deps.zip files:

(below my example assumes I extracted to gd_deps inside gd-2.0.25)

   EXTRA_INCLUDE=C:\\gd-2.0.35\\gd_deps\\include
   EXTRA_LIBS=/libpath:C:\\gd-2.0.35\\gd_deps\\lib

Then compile libgd (nmake -f Makefile)

Copy the resulting bgd.dll & bgd.dll.manifest to your gunplot
install directory and you will be able to save to png.
=====================================================================
-- 
View this message in context: http://www.nabble.com/Win32-Gnuplot-Compilation-tf4201579.html#a11998357
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: cairopdf terminal help (for Japanese)

[Shigeharu T. <sh...@ie...>]

shige 08/03 2007
----------------

Ethan Merritt wrote:
> On my linux systems, the Japanese + cairopdf problem can be
> solved by adding a call to 
>         setlocale(LC_CTYPE,"");
> on program entry. That may or may not be an acceptable change, however.
> 
> Perhaps it would be better to make this part of the "set encoding"
> command.  For terminals such as cairopdf it would be sufficient
> to add an option
>         set encoding locale
> without actually adding to the internal table of known encodings.
> I append a patch below that implements this.

I tested your patch and it works fine on Solaris 9 and FreeBSD 
5.4. 

http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/cairopdf-euc-1.pdf
http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/cairopdf-utf-1.pdf

are the result of the followings:
 
  set encoding locale
  set term cairopdf
  set out 'cairopdf.pdf'
  set title "ABCDE (jastring)" font "Sazanami Gothic,20"
  set xlabel "ABCDE (jastring)" font "IPAGothic,16"
  set ylabel "ABCDE (jastring)" font "IPAMincho,14"
  set label "ABCDE (jastring)" rotate by 60 \
    font "Sazanami Mincho,24" tc lt 3
  plot sin(x)
  set out

> I was already planning to add utf8 (needed for png terminal + Adobe
> symbol font, and for PostScript using patchset #1746352).
> Perhaps we also should have some or all of 
>     EUC-JP shift-jis ujis iso_2022_jp
> But I really don't know how to support these for most terminal types.

I think this is not so easy. 

For example, gdlib 2.X supports unicode encoding fonts and we can
use UTF-8 string by gdImageStringTTF(). But for other encoding 
strings (EUC-JP, Shift_JIS, ISO-2022-JP), we must build the gdlib
with the compilation flag -DJISX0208. That is, the treatment of 
Japanese encoding strings depends on the library itself. To give 
the EUC-JP strings to default gdlib, we must convert the string 
encoding to utf-8 in gnuplot (by iconv(3), for example).

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: cairopdf terminal help (for Japanese)

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

On Wednesday 01 August 2007 00:40, Shigeharu TAKENO wrote:
> 
> In Japanese environment, to print the correct Japanese strings
> in the pdf file by the cairopdf terminal, we may need to set the
> environment variable CHARSET to the corresponding value of the
> script encoding, especially in the case 'gnuplot script_file'.
> In this case we cannot get the correct output even if the script
> file is UTF-8 encoding and LANG=ja_JP.UTF-8.

This seems to be an actual bug. We should try to fix the bug first,
and then afterwards we can see if we still need to document a
work-around.

On my linux systems, the Japanese + cairopdf problem can be
solved by adding a call to 
	setlocale(LC_CTYPE,"");
on program entry. That may or may not be an acceptable change, however.

Perhaps it would be better to make this part of the "set encoding"
command.  For terminals such as cairopdf it would be sufficient
to add an option
	set encoding locale
without actually adding to the internal table of known encodings.
I append a patch below that implements this.

For some other terminals we might have to also add explicit known
encoding labels.

For reference, the current list is

gnuplot> help set encoding

 Valid values are
    default     - tells a terminal to use its default encoding
    iso_8859_1  - the jmost common Western European font used by many
                  Unix workstations and by MS-Windows. This encoding is
                  known in the PostScript world as 'ISO-Latin1'.
    iso_8859_2  - used in Central and Eastern Europe
    iso_8859_15 - a variant of iso_8859_1 that includes the Euro symbol
    koi8r       - popular Unix cyrillic encoding
    koi8u       - ukrainian Unix cyrillic encoding
    cp437       - codepage for MS-DOS
    cp850       - codepage for OS/2, Western Europe
    cp852       - codepage for OS/2, Central and Eastern Europe
    cp1250      - codepage for MS Windows, Central and Eastern Europe

I was already planning to add utf8 (needed for png terminal + Adobe
symbol font, and for PostScript using patchset #1746352).
Perhaps we also should have some or all of 
    EUC-JP shift-jis ujis iso_2022_jp
But I really don't know how to support these for most terminal types.


The following patch implements "set encoding locale"

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/set.c     2007-06-22 01:05:19.000000000 -0700
+++ gnuplot-cvs/src/set.c 2007-08-01 15:37:07.000000000 -0700
@@ -1217,7 +1217,11 @@
 
     if(END_OF_COMMAND)
        temp = S_ENC_DEFAULT;
-    else {
+    else if (equals(c_token,"locale")) {
+       c_token++;
+       setlocale(LC_CTYPE,"");
+       return;
+    } else {
        temp = lookup_table(&set_encoding_tbl[0],c_token);
 
        if (temp == S_ENC_INVALID)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

	Ethan


>
> I propose to add the following explanation to cairopdf terminal 
> help, which is unified diff to
> 
>  $Id: cairo.trm,v 1.2 2007/07/20 19:12:50 tlecomte Exp $
> 
> ----- From here -----
> --- cairo.trm.ORG	2007-07-21 04:12:50.000000000 +0900
> +++ cairo.trm	2007-08-01 16:28:08.000000000 +0900
> @@ -687,6 +687,16 @@
>  " OpenOffice Symbol fonts, and remove the Microsoft one.",
>  " Other non-conform fonts, such as \"wingdings\" have been observed working.",
>  "",
> +" If you use another encoding which is not supported by `set encoding`",
> +" (ex. using the title string in Japanese), you may need to set the",
> +" environment variable CHARSET for your glib, especially in case you give",
> +" the script file as the form \'gnuplot script_file\'. In the case, you",
> +" can solve the problem by setting the environment variable CHARSET as",
> +" the corresponding value to the script encoding. For example, if the",
> +" script is Japanese EUC encoding (EUC-JP), you should set CHARSET to",
> +" \"EUC-JP\", if UTF-8 encoding, set CHARSET to \"UTF-8\", and if",
> +" Shift_JIS encoding, set CHARSET to \"SHIFT_JIS\".",
> +"",
>  " The rendering of the plot cannot be altered yet. To obtain the best output",
>  " possible, the rendering involves two mechanisms : antialiasing and",
>  " oversampling.",
> ----- To here ----- 
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+

-- 
Ethan A Merritt 

Re: Contouring in GnuPlot

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

On Tue, 31 Jul 2007 23:28:01 +0200, Paul <ps...@dr...> wrote:

>> This will almost certainly need to be done outside gnuplot by
>> preprocessing the data. Catmull-Romm spline would probably be a good
>> choice to interpolate your example contour at 175mm
>
> Hello,
>
>   Do you know of a good software application in linux which will do th=
is
> preprocessing?
>
>

Sorry I dont recall your data. If it's regular in x,y intervals you coul=
d  =

possibly try presenting it as a bitmap to gimp.

I've toyed with this idea a couple of times but never done it.

Your z coordinate would be the "colour" as a greyscale. You could then  =

scale up the image using "cubic" which uses catmull-rom algorithm. This =
 =

would effectively interpolate without affecting your existing points as =
 =

long as you use and integer multiple of the number of points.

One word of warning, the splines tend to over shoot if the data has shar=
p  =

changes in direction within the range of it's four anchors. Like any  =

interpolation, it is fiction. You need to insure that the results make  =

sense.


If you cannot do it with gimp you could probably process your data using=
  =

awk . The spline fit is very simple and fast to execute


/* Catmull-Rom spline - not bad
   * basic intro http://www.mvps.org/directx/articles/catmull/
   * This formula will calculate an interpolated point between pt1 and p=
t2
   * dx=3D0 returns pt1; dx=3D1 returns pt2
   */

static inline gdouble
cubic_spline_fit (gdouble dx,
                   gint    pt0,
                   gint    pt1,
                   gint    pt2,
                   gint    pt3)
{

   return (gdouble) ((( ( - pt0 + 3 * pt1 - 3 * pt2 + pt3 ) * dx +
       ( 2 * pt0 - 5 * pt1 + 4 * pt2 - pt3 ) ) * dx +
       ( - pt0 + pt2 ) ) * dx + (pt1 + pt1) ) / 2.0;
}

This is cut from the Gimp GPL source code in /app/paint-funcs/scale-func=
s.c


Please let me know how you get on . I'm curious to know if the technique=
  =

works.

;)






>
>
>
> ----------------------------------------------------------------------=
---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser=
.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

cairopdf terminal help (for Japanese)

[Shigeharu T. <sh...@ie...>]

shige 08/01 2007
----------------

In Japanese environment, to print the correct Japanese strings
in the pdf file by the cairopdf terminal, we may need to set the
environment variable CHARSET to the corresponding value of the
script encoding, especially in the case 'gnuplot script_file'.
In this case we cannot get the correct output even if the script
file is UTF-8 encoding and LANG=ja_JP.UTF-8.

I propose to add the following explanation to cairopdf terminal 
help, which is unified diff to

 $Id: cairo.trm,v 1.2 2007/07/20 19:12:50 tlecomte Exp $

----- From here -----
--- cairo.trm.ORG	2007-07-21 04:12:50.000000000 +0900
+++ cairo.trm	2007-08-01 16:28:08.000000000 +0900
@@ -687,6 +687,16 @@
 " OpenOffice Symbol fonts, and remove the Microsoft one.",
 " Other non-conform fonts, such as \"wingdings\" have been observed working.",
 "",
+" If you use another encoding which is not supported by `set encoding`",
+" (ex. using the title string in Japanese), you may need to set the",
+" environment variable CHARSET for your glib, especially in case you give",
+" the script file as the form \'gnuplot script_file\'. In the case, you",
+" can solve the problem by setting the environment variable CHARSET as",
+" the corresponding value to the script encoding. For example, if the",
+" script is Japanese EUC encoding (EUC-JP), you should set CHARSET to",
+" \"EUC-JP\", if UTF-8 encoding, set CHARSET to \"UTF-8\", and if",
+" Shift_JIS encoding, set CHARSET to \"SHIFT_JIS\".",
+"",
 " The rendering of the plot cannot be altered yet. To obtain the best output",
 " possible, the rendering involves two mechanisms : antialiasing and",
 " oversampling.",
----- To here ----- 

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Win32 Gnuplot Compilation

[David Ko <dk...@uc...>]

Hello all,

I've recently been trying to compile Gnuplot in MinGW, and I've gotten 
everything working except that it crashes when I try to write a png file. The 
Windows binary I downloaded from gnuplot.info works fine, and I have a couple 
questions for the Win32 binary maintainer:

What build environment was used to create the Win32 binaries? I've tried MinGW 
and Visual Studio .NET thus far, and everything dies when trying to write a png 
file. (i.e. 'set terminal png; set output "test.png"; plot x' <- dies here) My 
latest attempt was with the 'config/makefile.mgw' provided makefile in MinGW.

What version of libgd was used? I assume that the latest version (2.0.35) was 
used, but the makefile.mgw that came w/ gnuplot referred to v.1.8 as "new". 
I've tried using the libgd library built from scratch and the provided prebuilt 
libraries. I've also tried the v1.8 library. Gnuplot behaves identically for 
all of them (crash on png write). 

Any other tips/ideas for me? I'm not really a windows person by any means.

Thanks for your time!

- David Ko

Re: Contouring in GnuPlot

[Paul <ps...@dr...>]

> This will almost certainly need to be done outside gnuplot by  
> preprocessing the data. Catmull-Romm spline would probably be a good  
> choice to interpolate your example contour at 175mm

Hello,

  Do you know of a good software application in linux which will do this
preprocessing?

Polishing the new PDF terminal (cairopdf)

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

I'd like to collect comments and suggestions on any rough edges
marring the new cairopdf terminal driver.

I know of 3 problems, 2 of which are illustrated by 
fillbetween.dem

1) The pattern fill scales as a bitmap rather than as
   a vector pattern.  This is ugly at high resolution.
   If we can't make the vector pattern scale correctly,
   then in monochrome mode we should probably replace
   the pattern fill with incremental solid shading.
   pattern 1 = no fill
   pattern 2 = black
   pattern 3 = 50% grey
   etc

2) The fill area is not clipped to the plot boundaries.
   This puzzles me, because I thought that the clipping
   was done by the core code.  But other terminals do not
   show this, so...

The 3rd problem may or may not be a gnuplot bug.

3) Under some conditions the entire plot has a black background.
   I only see this on machines with very different versions of
   cairo/pango/kde/kpdf/... so I'm having difficulty figuring
   out which program or library  is at fault.  But even if it is
   a viewer bug, there may still be a fix to gnuplot that would
   avoid triggering it

Missing features:

4) There should be a dashlength option (similar to postscript)

5) Circles (e.g. point types 6 and 7) look jagged.
   This is ultimately the fault of the cairo library, but perhaps
   we could work around it by scaling a well-hinted character
   glyph instead?

Any other observations?

-- 
Ethan A Merritt

fit.c and Levenberg-Marquardt parameter lambda (fwd)

[Henri P G. <hp...@Du...>]

Hello Gnuplot-ers!

   First, I'd like to say that the Gnuplot fit function has always worked very 
well every time I've used it.  (Thank you.)

   Second, however, I think there is a bug (or "feature") in the implementation 
of the Levenberg-Marquardt algorithm, which may not have been intended.

   I think line 376 of fit.c should read

         tmp_C[num_data + i][i] = sqrt(*lambda);

   instead of

         tmp_C[num_data + i][i] = *lambda;


    The following explains why I think so.  (Please forgive the Matlab-oriented 
notation.)

   The Gnuplot implementation of Levenberg-Marquardt solves the
over-determined system of equations

   [ J ; lambda*eye(n) ] * da = [ dy ; zeros(n,1) ];  ,

which is related to

   [ J'*J + lambda^2*eye(n) ] * da = dy;

in which lambda is squared ... not necessarily the same as
the method proposed by Marquardt, ...

    http://en.wikipedia.org/wiki/Levenberg-Marquardt_algorithm

   On the other hand, the over-determined system of equations

    [ J ; sqrt(lambda)*eye(n) ] * da = [ dy ; zeros(n,1) ];

is related to

   [ J'*J + lambda*eye(n) ] * da = dy;

which *is* the usual form for the Levenberg-Marquardt equations.

Also see equation (1.4) of the Argonne National Lab page:

http://www-fp.mcs.anl.gov/otc/GUIDE/OptWeb/continuous/unconstrained/nonlinearls/section2_1_2.html


   Should fit.c be changed in the next release of Gnuplot?

   I'm not sure, since the fit function ain't necessarily broke, and since it 
converges really well every time I use it.  Although I've studied and studied 
fit.c, I may not have noticed where the sqrt(*lambda) comes in, if it does.

   Is the current implementation an improvement over the usual 
Levenberg-Marquardt method?

   This question would bear further investigation.

   At any rate, I'd be happy to know the outcome of this bug-report.


Henri Gavin


_________________________________________________________________________
Henri P. Gavin                                      Hen...@Du...
Department of Civil and Environmental Engineering   tel: 919 - 660 - 5201
Duke University, Box 90287                          fax: 919 - 660 - 5219
Durham, NC 27708--0287                              www.duke.edu/~hpgavin/

Re: embedding gnuplot x window into gtk app

[<tim...@en...>]

>
> Hello,
>  I have been developing a GTK application and I am now using GnuPlot to
> create some graphical output.
>
>  I was hoping to embed the gnuplot x window results into my GTK
> application.
> So far I have been unable to do that can anyone give me any tips on how I
> would go about this?
>
> Thanks,
>
> Kiran

Hi Kiran,

Thanks for sharing your interest in gnuplot. There are several possible
answers to your question:

1) You could do it in two steps: first, output to png (or whatever
format), using gnuplot 'png' terminal, and then display the png inside
your application, where you want it to be.
Pros: quite easy
Cons: Overhead of the png writing and displaying

2) You could use the following patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1027032&group_id=2055&atid=302055

It is entitled "Connect gnuplot_x11 to exterior application window" and
does  what you want by allowing you to pass an XID in the 'set term x11'
command.

Pros: no overhead, mousing (zoom) should even work
Cons: non-upstream patch, read the patch page for details

3) You could use the 'xlib' terminal. This one (not really restricted to
xlib) will write low-level drawing commands to a file or a pipe, so that
you can then draw by yourself on your window.

Pros: you use the gdk API
Cons: you have to interpret the drawing commmands, as it is done in
gplot_x11.c

I hope this can be useful.

Best regards,

Timothée Lecomte

Re: Axis rescaling

[James R. V. Z. <jr...@co...>]

  Ethan Merritt wrote:

  > But that's not an issue of failing to store input data; it's an
  > issue of whether you apply axis scaling upon input or wait until
  > later.

Currently the data are scaled and replaced.  That means if the user
reverts to linear scaling, the data has to be unscaled.  Any
nonpositive data points will have been lost.  It also means we need an
"unscale" function.  The probability scaling in my patch uses the same
kind of implementation.

I would like to implement general scaling by a user-defined function,
and would rather not force the user to supply its inverse too.  We
could do that with "just in time scaling" - i.e. store the data as
read in from the file, and apply scaling immediately before
calculating screen positions.  If we agree that's the way to go, then
it makes sense to make that change before applying [a version of] my
axis scaling patch. 

            - Jim Van Zandt

Re: Axis rescaling

[James R. V. Z. <jr...@co...>]

Petr Mikulik <mi...@ph...> wrote:
> > I've just uploaded a patch that implements probability axes:
> > Probability axes simplify the presentation of certain kinds of data.
>
> It's just a particular scaling for one case. I would prefer Ethan's 
> proposal:
>
> > > I would like to be able to do something like:
> > >
> > >	   set axis x1  x                 # will use for Energy
> > >	   set axis x2  k/x               # will use for Wavelength
> > >	   set axis y1  log(y)            # log scale value to be plotted
> > >

I would like to see a more general mechanism too.  For the general
case, I would write something like

  set axis x1 f(x)     # how the x1 axis labels and tic marks relate
                       # to the "number being plotted"
  set axis x2 g(x)     # how the x2 axis labels and tic marks relate
                       # to the "number being plotted"
  set x scale h(x)     # how screen distances relate to the "number
                       # being plotted"
  plot (k($1)):2       # how the "number being plotted" relates to the
                       # data in column 1 of the data file

For an ordinary linear plot:   f(x) = g(x) = h(x) = x

For a log scale:               f(x) = g(x) = x
                               h(x) = log10(x)

For probability scaling:       f(x) = g(x) = x
                               h(x) = inverse_normal_func(x)

One tricky part is placing the tic marks and labels if f(h(x)) or
g(h(x)) is nonlinear.  That's what my code in transform.c does.

The other tricky part is actually allowing the user to define the
functions.  I know the expression parsing and function evaluation is
in gnuplot, but I have not been able to hook that up to my code.  I'm
hoping one of the other developers will consider that an easy job :-)

There are two more issues:

1) The range of validity for log scaling is hard-coded in, of course.
I did the same thing for probability scaling.  If we let the user
define a function, I think we'll have to let him define its range of
validity too.  That holds for each of the functions f(), g(), and h().
So for Ethan's wavelength scale we would have something like

  set axis x1 x
  set axis x2 k/x  valid x>0
  set x scale log(x)  valid x>0

or for probabilty scales

  set x scale inverse_normal_func(x)  valid  ((0<x) && (x<1))

2) For either linear or log scales, gnuplot can "round out" the plot
range so it can put a labeled tic mark at each end of the axis.  If
the two axes are related by a function, then we cannot generally do
that.  (A user-defined function may not even be defined outside the
range of the data provided.)  My code does not round out.



> > > Even better if there is a way to automatically lock x1 to x2, so that
> > > they are forced to span the same range.

I don't follow this.  It looks to me that Ethan's syntax does force
the two axes to span the same range.

               - Jim Van Zandt

Re: gnuplot manual misprint (no.23)

[<HBB...@t-...>]

Shigeharu TAKENO wrote:
> the following example may have a misprint which was pointed out 
> in Japanese gnuplot BBS by Prof. Tatsuro MATSUOKA. I send the 
> unified diff file for it.
> 
> ----- From here -----
> --- gnuplot.doc~	2007-07-24 11:26:58.000000000 +0900
> +++ gnuplot.doc	2007-07-24 11:27:43.000000000 +0900
> @@ -3694,7 +3694,7 @@
>   a different data set but having a common decay time, estimate the values of
>   the parameters.  If the datafile has the format x:z:s, then
>        f(x,y) = (y==0) ? a*exp(-x/tau) : b*exp(-x/tau)
> -      fit f(x,y) 'datafile' using  1:-1:2:3  via a, b, tau
> +      fit f(x,y) 'datafile' using  1:-2:2:3  via a, b, tau

That's not really a misprint.  As the text above mentions, both -1 and 
-2 can be correct.  It depends on how the data are formatted (separation 
by single or double blank records).

Re: Contouring in GnuPlot

[Theo H. <th...@ph...>]

MartinOShea wrote:
> Hello
> 
> I have a set of sample data as follows:
> 
> CEMI (x) ggbs(y) FLOW MM (z)
> 
> 0.0        90.0     0
> 6.5        58.7     166
> 6.6        59.0     169
> 7.3        65.0     141
> 6.1        54.5     162		
> 8.5        76.2     217
> 7.1        64.2     174
> 6.0        54.2     209 
> 7.0        63.0     198 
> 7.6        68.3     171
> 
> which produces a simple set of points on a 3D graph using splot. However,
> what I would like is to do is to interpolate between points to calculate the
> coordinates for a flow contour of, for example, 175 mm?
> 
> Can anyone advise how I might do this?

Contouring requires that the data be in grid format, i.e., with an equal 
number of 'y' values for every 'x' value. See `help grid_data` for 
details. You can use `set dgrid3d` to convert a non-gridded data set to 
gridded, but the results of the default algorithm are (to my sight) 
generally unsatisfactory. If you're willing to build gnuplot from 
source, there is an option to replace the default dgrid3d algorithm with 
a more sophisticated one that produces results which are (again, to my 
sight) more pleasing. Try './configure --enable-thin-splines'.

In either case, once you've used `set dgrid3d` to produce an 
interpolated surface, this surface can be used to create contours. Since 
contours are a global setting, and not a per-dataset one, you'll likely 
want to use `set table` to output the contours to a file, then plot that 
file with your original data.

THeo

Re: Axis rescaling

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

> I've just uploaded a patch that implements probability axes:
> Probability axes simplify the presentation of certain kinds of data.

It's just a particular scaling for one case. I would prefer Ethan's 
proposal:

> > I would like to be able to do something like:
> >
> >	   set axis x1  x                 # will use for Energy
> >	   set axis x2  k/x               # will use for Wavelength
> >	   set axis y1  log(y)            # log scale value to be plotted
> >
> > Even better if there is a way to automatically lock x1 to x2, so that
> > they are forced to span the same range.


> (By the way, I do have CVS write access, but I figured this would be
> too big a change to apply to the head.  I am not comfortable enough
> with my CVS skills to start a new branch, let alone to try and merge
> later on.)

Your proposal is a major patch, so it should be discussed and agreed on the 
mailing list. Don't make a branch, stay with a patch.

---
PM

Re: gnuplot manual misprint (no.23)

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

> the following example may have a misprint

> -      fit f(x,y) 'datafile' using  1:-1:2:3  via a, b, tau
> +      fit f(x,y) 'datafile' using  1:-2:2:3  via a, b, tau

thanks, applied.

---
PM

gnuplot manual misprint (no.23)

[Shigeharu T. <sh...@ie...>]

shige 07/24 2007
----------------

In docs/gnuplot.doc of current CVS version

 RCS $Id: gnuplot.doc,v 1.441 2007/07/16 20:37:25 sfeam Exp $

the following example may have a misprint which was pointed out 
in Japanese gnuplot BBS by Prof. Tatsuro MATSUOKA. I send the 
unified diff file for it.

----- From here -----
--- gnuplot.doc~	2007-07-24 11:26:58.000000000 +0900
+++ gnuplot.doc	2007-07-24 11:27:43.000000000 +0900
@@ -3694,7 +3694,7 @@
  a different data set but having a common decay time, estimate the values of
  the parameters.  If the datafile has the format x:z:s, then
       f(x,y) = (y==0) ? a*exp(-x/tau) : b*exp(-x/tau)
-      fit f(x,y) 'datafile' using  1:-1:2:3  via a, b, tau
+      fit f(x,y) 'datafile' using  1:-2:2:3  via a, b, tau
 
  For a more complicated example, see the file "hexa.fnc" used by the
  "fit.dem" demo.
----- To here ----- 

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: 1/0 - problem while rendering with lines

[Theo H. <th...@ph...>]

Martin Giersich wrote:
> 
> No change using 0/0. Same broken line drawing. I attached a plot- output 
> of th above plot-command.
> 
> This rendering problems appear using MacOSX 10.4.... and gnuplot 4.0, 
> 4.2, 4.3.
> 
> Btw, the official gnuplot-documentation (Thomas Williams & Colin 
> Kelley, "gnuplot - An Interactive Plotting Program", 3 March 2007, 
> available at: http://www.gnuplot.info/docs/gnuplot.pdf) describes at 
> page 25 using "1/0" as a way that "may be used to generate an 
> "undefined" flag, which 
> causes a point to ignored". No other method to do this is refered.
> If there is another method to do this - besides change of dat-file 
> format - i'd like to know...
> 

gnuplot is behaving exactly as documented. If you plot `with 
linespoints`, you will see that the expected points are present. 
However, not all points are joined with lines, because there is missing 
or invalid data between them. This is usually important information, and 
so gnuplot indicates this. If you really want to have the lines joined, 
you can do something like:

plot "<awk '$3==1 { print }' AGdata-test.dat" using 4:5 w li

You're effectively changing the data file format on the fly to omit the 
invalid data. gnuplot won't see it, and so will draw lines between the 
valid data points.

THeo

make install failure

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

 There might be a problem with recent changes to the gnuplot.doc, or the .texi
 file generation in current cvs:

$ make gnuplot.info
/bin/sh ${HOME}/src/cvs/gnuplot/missing --run makeinfo -I. ./gnuplot.texi --no-split --output=gnuplot.info
./gnuplot.texi:11756: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:11277: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10938: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10717: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10706: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10697: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10680: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:10678: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:8592: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:5973: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:5954: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:5943: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:4551: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
./gnuplot.texi:3154: Cross reference to nonexistent node `origin' (perhaps incorrect sectioning?).
makeinfo: Removing output file `gnuplot.info' due to errors; use --force to preserve.
make: *** [gnuplot.info] Error 1

Re: 1/0 - problem while rendering with lines

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

On Monday 16 July 2007, Martin Giersich wrote:
> Btw, the official gnuplot-documentation (Thomas Williams & Colin
> Kelley, "gnuplot - An Interactive Plotting Program", 3 March 2007,
> available at: http://www.gnuplot.info/docs/gnuplot.pdf) describes at
> page 25 using "1/0" as a way that "may be used to generate an
> "undefined" flag, which
> causes a point to ignored". No other method to do this is refered.
> If there is another method to do this - besides change of dat-file
> format - i'd like to know...

Starting with version 4.2 there is a pre-defined variable named NaN
which may be used for this purpose.

Re: Contouring in GnuPlot

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

On Wed, 18 Jul 2007 12:06:29 +0200, MartinOShea <ap...@ds...>  
wrote:

>
> Hello
>
> I have a set of sample data as follows:
>
> CEMI (x) ggbs(y) FLOW MM (z)
>
> 0.0        90.0     0
> 6.5        58.7     166
> 6.6        59.0     169
> 7.3        65.0     141
> 6.1        54.5     162		
> 8.5        76.2     217
> 7.1        64.2     174
> 6.0        54.2     209
> 7.0        63.0     198
> 7.6        68.3     171
>
> which produces a simple set of points on a 3D graph using splot. However,
> what I would like is to do is to interpolate between points to calculate  
> the
> coordinates for a flow contour of, for example, 175 mm?
>
> Can anyone advise how I might do this?
>
> Thanks
>
> Martin O'Shea.

This will almost certainly need to be done outside gnuplot by  
preprocessing the data. Catmull-Romm spline would probably be a good  
choice to interpolate your example contour at 175mm

Re: Axis rescaling

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

On Thursday 19 July 2007 18:40, James R. Van Zandt wrote:
> 
> I've just uploaded a patch that implements probability axes:
> 
> 1757226  	  Provide "probability" scaling and axes    	   2007-07-19 21:31  	 5  	nobody  	vanzandt


Looks interesting.

But I'm heading out of town for a week, and won't be able to look at it
until I get back.

	Ethan



> 
> Rationale:
> 
> Probability axes simplify the presentation of certain kinds of data.
> 
> Recall that if Y varies as the exponential of X, then data values are
> best shown in a log plot - i.e. where you plot the logarithm of Y
> against X.  More generally, if there are very small and very large Y
> values, but all are positive, then it is convenient to use a log Y
> axis.  E.g. if you plot Y values of .002, .02, and 200 along a linear
> axis, it would be hard to tell the first two apart.  However, it would
> be easy with a log axis.
> 
> Suppose you have a collection of n data values that you think are
> normally distributed.  Find the "empirical distribution function": a
> cumulative probability distribution function that concentrates
> probability 1/n at each of the n numbers in the sample.  I.e. sort the
> values and label them X(1) through X(n).  Then let Y(k)=k/n.  If you
> plot Y vs. X, you get something like a sigmoid curve, which starts
> near the line Y=0, rises quickly near the mean of the X values, then
> gradually approaches the line Y=1.  Probability axes are the way of
> transforming Y values such that, if the X values were really normally
> distributed, then the transformed data points fall approximately along
> a straight line.
> 
> More generally, if there are both very small Y values and values very
> near 1, but none outside the range 0 to 1 (e.g. if Ys represent
> probabilities), then probability axes can make the data easier to see.
> 
> Summary of changes: Most of the added code is in the new files
> "transform.c" and the corresponding header file "transform.h".
> 
> The "probability" transformation (inverse of normal CDF) is the only
> one implemented here.  However, the logic for labeling the axis is
> quite general.  The goal is to select a set of tics and minitics such
> that:
>  - tic labels are "simple"
>  - tic labels do not overlap
>  - the distances between tics are roughly equal
>  - the numeric value corresponding to any minitic is unambiguous
>  - the distances between minitics are roughly equal, and small enough
>    that the numeric value of any point can be estimated by eye.
> 
> The current code for log axes uses the functional forms for both the
> data transform log(x) and its inverse 10^x.  This patch for
> probability axes does the same.  However the part that calculates tic
> and minitic locations uses the function form only for the forward
> transformation -- inverse values are found numerically.  My hope is
> that this more general implementation can be easily applied to other
> transform functions, including user-supplied ones without a convenient
> inverse.
> 
> axis_array[axis].log is now an enum, with values SCALE_LINEAR,
> SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and
> AXIS_DE_LOG_VALUE are functions instead of macros.
> 
> TODO: 
>  - Rename axis_array[axis].log to axis_array[axis].scale
>  - Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case.
>  - Implement several other kinds of axes, including "weibull plots".
>  - Implement a user-supplied scaling function.
>  - Implement scaling only of axis labels, without scaling the data.
>  - New command syntax [axis] "set scale linear|log|probability|f(x) x|y|..."
> 
> 
> Ethan Merritt wrote:
> > > > 
> > > > My request was simply that you leave the existing log scale code
> > > > in place until a general mechanism was ready to replace it.
> > > 
> > > What do you mean by general?  Able to apply mappings other than
> > > log scale?
> >
> > Exactly.  I gave a bunch of examples earlier.  The most common
> > request (and hardest to work around) is marking off the X-axis as
> > 1/x.  For instance, we crystallographers have to deal with
> > inconsistent usage all the time; some quantities are given in terms
> > of energy while others are given in terms of wavelength.  There is
> > an inverse relationship:
> >	   Energy = k / Wavelength
> > where k is an appropriate constant.  It is a pain to try to persuade
> > gnuplot to mark off both Energy and Wavelength on axes of the same plot.
> >
> > I would like to be able to do something like:
> >
> >	   set axis x1  x                 # will use for Energy
> >	   set axis x2  k/x               # will use for Wavelength
> >	   set axis y1  log(y)            # log scale value to be plotted
> >
> > Even better if there is a way to automatically lock x1 to x2, so that
> > they are forced to span the same range.
> >
> > -- 
> > Ethan A Merritt
> 
> Ethan wants to rescale one or both axes without changing the data.  I
> would like to think that this patch is a first step toward that
> capability.  The patch rescales the data as well as the axes.
> At least, it could easily handle the tic/minitic placement.
> 
> (By the way, I do have CVS write access, but I figured this would be
> too big a change to apply to the head.  I am not comfortable enough
> with my CVS skills to start a new branch, let alone to try and merge
> later on.)
> 
>               - Jim Van Zandt

-- 
Ethan A Merritt

Re: Axis rescaling

[James R. V. Z. <jr...@co...>]

I've just uploaded a patch that implements probability axes:

1757226  	  Provide "probability" scaling and axes    	   2007-07-19 21:31  	 5  	nobody  	vanzandt

Rationale:

Probability axes simplify the presentation of certain kinds of data.

Recall that if Y varies as the exponential of X, then data values are
best shown in a log plot - i.e. where you plot the logarithm of Y
against X.  More generally, if there are very small and very large Y
values, but all are positive, then it is convenient to use a log Y
axis.  E.g. if you plot Y values of .002, .02, and 200 along a linear
axis, it would be hard to tell the first two apart.  However, it would
be easy with a log axis.

Suppose you have a collection of n data values that you think are
normally distributed.  Find the "empirical distribution function": a
cumulative probability distribution function that concentrates
probability 1/n at each of the n numbers in the sample.  I.e. sort the
values and label them X(1) through X(n).  Then let Y(k)=k/n.  If you
plot Y vs. X, you get something like a sigmoid curve, which starts
near the line Y=0, rises quickly near the mean of the X values, then
gradually approaches the line Y=1.  Probability axes are the way of
transforming Y values such that, if the X values were really normally
distributed, then the transformed data points fall approximately along
a straight line.

More generally, if there are both very small Y values and values very
near 1, but none outside the range 0 to 1 (e.g. if Ys represent
probabilities), then probability axes can make the data easier to see.

Summary of changes: Most of the added code is in the new files
"transform.c" and the corresponding header file "transform.h".

The "probability" transformation (inverse of normal CDF) is the only
one implemented here.  However, the logic for labeling the axis is
quite general.  The goal is to select a set of tics and minitics such
that:
 - tic labels are "simple"
 - tic labels do not overlap
 - the distances between tics are roughly equal
 - the numeric value corresponding to any minitic is unambiguous
 - the distances between minitics are roughly equal, and small enough
   that the numeric value of any point can be estimated by eye.

The current code for log axes uses the functional forms for both the
data transform log(x) and its inverse 10^x.  This patch for
probability axes does the same.  However the part that calculates tic
and minitic locations uses the function form only for the forward
transformation -- inverse values are found numerically.  My hope is
that this more general implementation can be easily applied to other
transform functions, including user-supplied ones without a convenient
inverse.

axis_array[axis].log is now an enum, with values SCALE_LINEAR,
SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and
AXIS_DE_LOG_VALUE are functions instead of macros.

TODO: 
 - Rename axis_array[axis].log to axis_array[axis].scale
 - Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case.
 - Implement several other kinds of axes, including "weibull plots".
 - Implement a user-supplied scaling function.
 - Implement scaling only of axis labels, without scaling the data.
 - New command syntax [axis] "set scale linear|log|probability|f(x) x|y|..."


Ethan Merritt wrote:
> > > 
> > > My request was simply that you leave the existing log scale code
> > > in place until a general mechanism was ready to replace it.
> > 
> > What do you mean by general?  Able to apply mappings other than
> > log scale?
>
> Exactly.  I gave a bunch of examples earlier.  The most common
> request (and hardest to work around) is marking off the X-axis as
> 1/x.  For instance, we crystallographers have to deal with
> inconsistent usage all the time; some quantities are given in terms
> of energy while others are given in terms of wavelength.  There is
> an inverse relationship:
>	   Energy = k / Wavelength
> where k is an appropriate constant.  It is a pain to try to persuade
> gnuplot to mark off both Energy and Wavelength on axes of the same plot.
>
> I would like to be able to do something like:
>
>	   set axis x1  x                 # will use for Energy
>	   set axis x2  k/x               # will use for Wavelength
>	   set axis y1  log(y)            # log scale value to be plotted
>
> Even better if there is a way to automatically lock x1 to x2, so that
> they are forced to span the same range.
>
> -- 
> Ethan A Merritt

Ethan wants to rescale one or both axes without changing the data.  I
would like to think that this patch is a first step toward that
capability.  The patch rescales the data as well as the axes.
At least, it could easily handle the tic/minitic placement.

(By the way, I do have CVS write access, but I figured this would be
too big a change to apply to the head.  I am not comfortable enough
with my CVS skills to start a new branch, let alone to try and merge
later on.)

              - Jim Van Zandt