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

Re: pointer syntax

[<br...@ph...>]

Daniel J Sebald wrote:
> gp_alloc in alloc.c casts the pointer to char * rather than generic *.  
> (gp_realloc casts to a gneric *.

Fixed.

Re: gnuplot manual misprint (no.19)

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

> I found a point that seems to be a misprint. I send the unified
> diff file for them.
 
 Committed. You missed one:

> ----- From here -----
> --- term/aquaterm.trm.ORG	Wed Mar  1 21:34:32 2006
> +++ term/aquaterm.trm	Thu Mar 16 20:39:00 2006
> @@ -866,7 +866,7 @@
>  " The aqua terminal support enhanced text mode (see `enhanced`), except for",
>  " overprint. Font support is limited to the fonts available on the system.",
>  " Character encoding can be selected by `set encoding` and currently supports",
> -" iso_latin_1, iso_latin2, and cp1250 with iso_latin_1 being the dafault."  
> +" iso_latin_1, iso_latin_2, and cp1250 with iso_latin_1 being the dafault."  
                                                                      ^

 s/a/e/ :)

Re: What's left for a 4.2 release? [drivers]

[Bastian M. <bma...@we...>]

Lately I have been working a bit on the windows terminal. It now has
image, font selection and enhanced text support. Is there anything
else you miss for a 4.2 release? Multiple window support is a candidate 
that most likely could be added rather easily. Btw. I am not claiming to
be that champion ;)

>  - Old but not obsolete drivers
>    + Windows is the 800 pound gorilla here.  It has fallen behind 
>      the other interactive drivers in capability, and it does not
>      seem to have a champion on the development team to bring it up
>      to par.  Can we move to the wxWidgets driver instead, and 
>      retain the existing windows driver only for older systems that
>      don't support wxWidgets?

On my list of changes for win.trm are a changes to WIN_options()
to make it accept similar options as other terminals. The menu file
wgnuplot.mnu definitely could do with some update before 4.2 as well.

The current code as it is does not run on NT4 and possibly Win95 and 
Win32s. This is due to the new directory selection dialog introduced
by me. I can think of these options to handle that:
1) provide a separate version for these systems (probably not Win32s ;-)
2) add more code to make it run on all systems
3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, too), 
Is there an agreement what to do?

Below some short comments on bugs specific to windows:

> windows:
> #1232950        -persist option does not work in Version 4.0.0 (Windows)
A bug that needs to be fixed for 4.2. I will look into it.

> #1413021        [Wgnuplot] pause 1;reread; blocks interaction
Cannot comment.

> #561418         (MS Windows) 100% CPU Usage during pause
I cannot reproduce this.

> #982293         can't print color in win32 gnuplot 4.0
> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)
Printing via win.trm in general seems to be buggy. This feature
should probably be disabled for now. Bernhard recommends not to use
it anyway.

Bastian

gnuplot manual misprint (no.19)

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

shige 03/16 2006
----------------

In term/aquaterm.trm

 * $Id: aquaterm.trm,v 1.20 2006/02/28 17:50:38 persquare Exp $

I found a point that seems to be a misprint. I send the unified
diff file for them.

----- From here -----
--- term/aquaterm.trm.ORG	Wed Mar  1 21:34:32 2006
+++ term/aquaterm.trm	Thu Mar 16 20:39:00 2006
@@ -866,7 +866,7 @@
 " The aqua terminal support enhanced text mode (see `enhanced`), except for",
 " overprint. Font support is limited to the fonts available on the system.",
 " Character encoding can be selected by `set encoding` and currently supports",
-" iso_latin_1, iso_latin2, and cp1250 with iso_latin_1 being the dafault."  
+" iso_latin_1, iso_latin_2, and cp1250 with iso_latin_1 being the dafault."  
 END_HELP(aqua)
 #endif /* TERM_HELP */
----- To here ----- 

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

To distribute of translated manual

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

shige 03/16 2006
----------------

The gnuplot "Copyright" file does not seem to say about the 
translations of documents to foreign languages, or to another 
formats. I want to know whether it is permitted, and what 
conditions I must satisfy to distribute them.

For example: 

on our WWW site, 

1) to distribute tar ball manuals including:
 [a] the Japanese translation of gnuplot.doc
 [b] a patch for Japanese translations of term/*.trm
 [c] README for Japanese user

(cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
  20050620/gp400-20050620.tar.gz)

2) to distribute 1) [a] only

(cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
  current/gp410-20060312.doc.gz)

3) to distribute 1) [b] only

(cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
  current/term410-20060312.diff.gz)

4) to distribute another format file made from 1) [a] by 
 doc/doc2* tools

(cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
  20050620/gp400-20050620.{html,gih,ps,pdf,...})

5) to distribute 
 [e] the Japanese translation of faq/faq.tex 
   (http://cvs.sourceforge.net/viewcvs.py/gnuplot/faq/faq.tex)

(cf. http://takeno.iee.niit.ac.jp/~shige/unix/
  gnuplot/faq-j-20050318.tex) 

6) to distribute another format file made from 5) [e] 

(cf. http://takeno.iee.niit.ac.jp/~shige/unix/
  gnuplot/faq-j-20050318.{html,pdf,ps,...})

7) to distribute an archive including Japanized files for 
 wgnuplot:
 [f] the Japanese translation of wgnuplot.mnu
 [g] wgnuplot.hlp made from 1) [a]
 [h] README for Japanese user
 [i] gnuplot's original Copyright file

(cf. http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/
  wgp-jp/wgp400-20050625.zip)

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

"4.2 ready"

[Daniel J S. <dan...@ie...>]

I think I've pretty much taken care of all the items I've had on my list to address before 4.2.

Dan

Re: memory leak?

[Daniel J S. <dan...@ie...>]

OK, valgrind has isolated a couple leaks in the pipe works (patch attached):

==10516==
==10516== ERROR SUMMARY: 137 errors from 11 contexts (suppressed: 27 from 1)
==10516== malloc/free: in use at exit: 144724 bytes in 1160 blocks.
==10516== malloc/free: 177326 allocs, 176166 frees, 505192128 bytes allocated.
==10516== For counts of detected errors, rerun with: -v
==10516== searching for pointers to 1160 not-freed blocks.
==10516== checked 5955140 bytes.
==10516==
==10516==
==10516== 1029 bytes in 2 blocks are definitely lost in loss record 1 of 5
==10516==    at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==10516==    by 0x804B568: gp_alloc (alloc.c:268)
==10516==    by 0x80BB3D8: X11_args (x11.trm:291)
==10516==    by 0x8090785: main (plot.c:380)

This one is happening at line 291 of x11.trm.  This command:

    xargv = (char **) gp_alloc(argc * sizeof(char *), "<xargv>");

uses xargv like a normal pointer (i.e., ++) and never attempts to free the memory within X11_args().  The patch makes xargv a local static variable and duplicates the pointer as p_xargv used as ++p_xargv, etc.

==10516==
==10516==
==10516== 1130 bytes in 76 blocks are definitely lost in loss record 2 of 5
==10516==    at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==10516==    by 0x283AEF: strdup (in /lib/tls/libc-2.3.3.so)
==10516==    by 0x805F403: push (eval.c:484)
==10516==    by 0x805F5BB: execute_at (eval.c:587)

This is right before the bad line in question.

    /* WARNING - This is a memory leak if the string is not later freed */

I'll write off line on this one.

Dan

Re: pointer syntax

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

> gp_alloc in alloc.c casts the pointer to char * rather than 
> generic *.  (gp_realloc casts to a gneric *. 

That has the smell of something that would break on older/offbeat
platforms.  How long ago was (generic *) introduced?


Are you happy with the current state of the don't-send-duplicate-
palettes patch?  Should I add it to cvs?


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

pointer syntax

[Daniel J S. <dan...@ie...>]

Here's a minor syntax thing:

gp_alloc in alloc.c casts the pointer to char * rather than generic *.  (gp_realloc casts to a gneric *.

Dan

Re: valgrind

[Daniel J S. <dan...@ie...>]

I've put some comments within to indicate what the line numbers correspond to in my version of the source code:



correlation matrix of the fit parameters:

               c33    c11    c44    c13    phi0
c33             1.000
c11            -0.066  1.000
c44            -0.198 -0.278  1.000
c13            -0.141  0.028 -0.086  1.000
phi0            0.114 -0.022  0.034  0.181  1.000
==9857== Conditional jump or move depends on uninitialised value(s)
==9857==    at 0x8060111: update (fit.c:989)

    tmp = s + strlen(s) - 1;
    while (*tmp != '\\' && *tmp != '/' && *tmp != ':' && tmp - s >= 0)
[989]	tmp--;

[Not sure what valgrind is complaining about.  Maybe the memory pointed to by "s" coming into the routine is not initialized.]


==9857==    by 0x805425E: update_command (command.c:1711)
==9857==    by 0x8055157: do_line (command.c:530)
==9857==    by 0x8088576: load_file (misc.c:277)
==9857==
==9857== Conditional jump or move depends on uninitialised value(s)
==9857==    at 0x8060102: update (fit.c:989)
==9857==    by 0x805425E: update_command (command.c:1711)
==9857==    by 0x8055157: do_line (command.c:530)
==9857==    by 0x8088576: load_file (misc.c:277)
==9857==
==9857== Conditional jump or move depends on uninitialised value(s)
==9857==    at 0x8060106: update (fit.c:989)
==9857==    by 0x805425E: update_command (command.c:1711)
==9857==    by 0x8055157: do_line (command.c:530)
==9857==    by 0x8088576: load_file (misc.c:277)





******************** file world.dem ********************
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
==9857==
==9857== Use of uninitialised value of size 8
==9857==    at 0x8099B95: eval_3dplots (plot3d.c:775)

	    if (j >= 4) {
[775]		color = v[3];
		color_from_column(TRUE);

[My guess would be that v[3] is not set correctly inside datafile.c.]

==9857==    by 0x8055157: do_line (command.c:530)
==9857==    by 0x8088576: load_file (misc.c:277)
==9857==    by 0x8053036: load_command (command.c:978)
Same plot with hidden line removal
==9857==
==9857== Use of uninitialised value of size 8
==9857==    at 0x8099B95: eval_3dplots (plot3d.c:775)
==9857==    by 0x805449F: replotrequest (command.c:1843)
==9857==    by 0x8055157: do_line (command.c:530)
==9857==    by 0x8088576: load_file (misc.c:277)
Hit return to continue
******************** file prob.dem ********************






Now create a x/y datafile for plotting with vectors
and display vectors parallel to the electrostatic field
Hit return to continue


==9857==
==9857== Use of uninitialised value of size 8
==9857==    at 0x807774A: plot_vectors (graphics.c:3272)

	points[0] = plot->points[i];
[3272]	points[1].x = plot->points[i].xhigh;
[3273]	points[1].y = plot->points[i].yhigh;

[A quick search on xhigh and yhigh shows it isn't set very often.  Probably these aren't being set properly when reading in some points.]

==9857==    by 0x807A8A6: do_plot (graphics.c:1760)
==9857==    by 0x80932AD: eval_plots (plot2d.c:2181)
==9857==    by 0x8055157: do_line (command.c:530)
==9857==
==9857== Use of uninitialised value of size 8
==9857==    at 0x807774E: plot_vectors (graphics.c:3273)
==9857==    by 0x807A8A6: do_plot (graphics.c:1760)
==9857==    by 0x80932AD: eval_plots (plot2d.c:2181)
==9857==    by 0x8055157: do_line (command.c:530)
Hit return to continue********************** file tics.dem *********************H

Re: valgrind

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

Looks like you're having fun with valgrind.

I've applied your tuple[2] fix

This one is a false alarm, though the code can be re-arranged to
clarify what's going on:
  
> at 0x8099BD9: eval_3dplots (plot3d.c:775)

I recognize and will fix one of the errors below that

==1563== Use of uninitialised value of size 4
==1563==    at 0x80A8E34: parse_label_options (set.c:4664)
==1563==    by 0x80A9578: set_xyzlabel (set.c:4127)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)

I don't have time to look at the others just now.

	Ethan

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

Re: valgrind

[Daniel J S. <dan...@ie...>]

Well, I've got to hand it to valgrind.  It found an uninitialized variable in the image demo.  The problem was actually not the instruction valgrind pointed out, but a step or two back from that in a different routine.  One has to sort of trace where the memory came from.

So, attached is a short patch to fix what valgrind found.

Below are a few other things that valgrind has found for 'all.dem'.  If anything looks familiar to you as code you may have worked with, please take a look to see if there is a problem with the code.  If not, attempt a change to rid the valgrind complaint.

Thanks,

Dan

PS: The free-ing of the memory in reset_palette() has lessened the rate at which memory accumulates.  There still seems to be a leak.  I'll hunt for that later.

========================


c13            -0.141  0.028 -0.086  1.000
phi0            0.114 -0.022  0.034  0.181  1.000
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x8060155: update (fit.c:989)
==1563==    by 0x80542BA: update_command (command.c:1711)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==    by 0x80885BA: load_file (misc.c:277)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x8060146: update (fit.c:989)
==1563==    by 0x80542BA: update_command (command.c:1711)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==    by 0x80885BA: load_file (misc.c:277)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x806014A: update (fit.c:989)
==1563==    by 0x80542BA: update_command (command.c:1711)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==    by 0x80885BA: load_file (misc.c:277)






******************** file world.dem ********************
Hit return to continue
Hit return to continue
Hit return to continue
Hit return to continue
==1563==
==1563== Use of uninitialised value of size 8
[[[[[
Is it possible here Ethan that v[3] (of color = v[3];) is not being set inside df_readascii() of datafile.c but the value of j (output in datafile.c) is being incremented?
]]]]]
==1563==    at 0x8099BD9: eval_3dplots (plot3d.c:775)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==    by 0x80885BA: load_file (misc.c:277)
==1563==    by 0x8053092: load_command (command.c:978)
Same plot with hidden line removal
==1563==
==1563== Use of uninitialised value of size 8
==1563==    at 0x8099BD9: eval_3dplots (plot3d.c:775)
==1563==    by 0x80544FB: replotrequest (command.c:1843)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==    by 0x80885BA: load_file (misc.c:277)






Now create a x/y datafile for plotting with vectors
and display vectors parallel to the electrostatic field
Hit return to continue

==1563==
==1563== Use of uninitialised value of size 8
==1563==    at 0x807778E: plot_vectors (graphics.c:3272)
==1563==    by 0x807A8EA: do_plot (graphics.c:1760)
==1563==    by 0x80932F1: eval_plots (plot2d.c:2181)
==1563==    by 0x80551B3: do_line (command.c:530)
==1563==
==1563== Use of uninitialised value of size 8
==1563==    at 0x8077792: plot_vectors (graphics.c:3273)
==1563==    by 0x807A8EA: do_plot (graphics.c:1760)
==1563==    by 0x80932F1: eval_plots (plot2d.c:2181)
==1563==    by 0x80551B3: do_line (command.c:530)
Hit return to continue********************** file tics.dem *********************






Now try histograms stacked by columns
Next we do several sets of parallel histograms
==1563==
==1563== Use of uninitialised value of size 4
==1563==    at 0x80A8E34: parse_label_options (set.c:4664)
==1563==    by 0x80A9578: set_xyzlabel (set.c:4127)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x80A8F2A: parse_label_options (set.c:4730)
==1563==    by 0x80A9578: set_xyzlabel (set.c:4127)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x80A9237: parse_label_options (set.c:4744)
==1563==    by 0x80A9578: set_xyzlabel (set.c:4127)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x80A90B1: parse_label_options (set.c:4832)
==1563==    by 0x80A9578: set_xyzlabel (set.c:4127)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
==1563==
==1563== Use of uninitialised value of size 4
==1563==    at 0x80A8E34: parse_label_options (set.c:4664)
==1563==    by 0x80A9591: set_xyzlabel (set.c:4143)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
==1563==
==1563== Conditional jump or move depends on uninitialised value(s)
==1563==    at 0x80A90B1: parse_label_options (set.c:4832)
==1563==    by 0x80A9591: set_xyzlabel (set.c:4143)
==1563==    by 0x80AAA85: set_style (set.c:4879)
==1563==    by 0x80ADE33: set_command (set.c:418)
Same plot using rowstacked histogram

Re: Problems executing ./prepare

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

On Wednesday 15 March 2006 05:16 am, Hans-Bernhard Br=F6ker wrote:
> Caroline Williams wrote:
> > When I execute prepare I get the following errors:
> >=20
> > automake: configure.in: required file `../config.guess' not found
> > automake: configure.in: required file `../config.sub' not found

The linux kernel version is not relevant here.

> You need at least automake 1.7.5 or so, but you should really do=20
> yourself a favour and the current one: 1.9.6.

Yes, it's a known automake problem.
I think I was still seeing those errors with automake 1.8.something.

=46ortunately, the work-around is simple.
In the directory where this failure occurred, do
	touch ../config.guess
	touch ../config.sub
and run "make" again.  This time it will work.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Problems executing ./prepare

[<br...@ph...>]

Caroline Williams wrote:
> When I execute prepare I get the following errors:
> 
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found

That's the telltale symptom of trying to use way outdated versions of 
automake.  You're using code called a "work-in-progress" or 
"development" version.  That implies you're supposed to be able to at 
least simulate being a developer, including up-to-date tools.

You need at least automake 1.7.5 or so, but you should really do 
yourself a favour and the current one: 1.9.6.

Re: Incorrent conditional code for X11_BINARY_POLYGON

[Daniel J S. <dan...@ie...>]

Ethan,

Here is a patch to fix the issue with conditional compilation.

Now, I left the curly braces issue as is.  If this causes a problem with highlighting in your editor, let me know.  It's fine in gvim.

The thing is, I don't want to have conditional compilation in which there is code repeated.  That's really bad in this case because there is a big hunk of code two conditions share.  Don't really want to make that a function either.

Let me know if you have any ideas to deal with this.  Maybe at some point we can choose one version of X11_BINARY_POLYGON and go with that.  We could do some speed tests or something.  (I think this was for speeding up large pm3ds originally.)

...

I also noticed that the palette code in gplt_x11.c looks so similar to that in color.c.  That stuff gets repeated more than it should be.  I'm not going to worry about that now.

Dan


Ethan Merritt wrote:
> Daniel:
> 
> The #ifdef / #else / #endif blocks in gplt_x11.c are
> horribly unreadable.  So much so that they have hidden
> some serious mis-ordering of the statements.
> 
> 
> Try
>   ./configure --with-image --disable-binary-x11-polygon
>   cd src
>   make gnuplot_x11
> 
> and watch everything fall apart.
> 
> The nested #ifdef/#endif code blocks that end just before
> line 3050 of gplt_x11.c are clearly incorrect, but I cannot
> see what the original intent was.
> 
> Can you please try to clean up this code?
> I suggest that no #ifdef/#endif pair should leave unbalanced
> curly brackets in the code.  This sort of thing:
> 
> if (A) {
> #ifdef FOO
>     if (B)
> 	{
> 	blah; blah;
> #else
>    yadda; yadda;
> #endif
> 
> 
> is just asking for trouble.
>  

Re: memory leak?

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>>Notice that sm_palette.gradient is simply set to NULL.  
> 
> 
> Yup.
> Notice also that sm_palette.color is neither freed nor set
> to NULL.  I wonder if this contributes to your main problem
> of incorrect palette comparisons.

Oh yeah; I didn't notice that.  That too should be changed.

Dan

Re: memory leak?

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

On Tuesday 14 March 2006 07:19 pm, Daniel J Sebald wrote:
> I may have by chance found at least one source of a memory leak 
> without even going to valgrind yet. 

Yup.

> reset_palette()
> {
>     if (!enable_reset_palette) return;
>     sm_palette.colorMode = SMPAL_COLOR_MODE_RGB;
>     sm_palette.formulaR = 7; sm_palette.formulaG = 5;
>     sm_palette.formulaB = 15;
>     sm_palette.positive = SMPAL_POSITIVE;
>     sm_palette.ps_allcF = 0;
>     sm_palette.use_maxcolors = 0;
>     sm_palette.gradient_num = 0;
>     sm_palette.gradient = NULL;
>     sm_palette.cmodel = C_MODEL_RGB;
>     sm_palette.gamma = 1.5;
>     pm3d_last_set_palette_mode = SMPAL_COLOR_MODE_NONE;
> }

> Notice that sm_palette.gradient is simply set to NULL.  

Yup.
Notice also that sm_palette.color is neither freed nor set
to NULL.  I wonder if this contributes to your main problem
of incorrect palette comparisons.

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

Re: memory leak?

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> I ran with that construct for a few hours.  I'm still seeing memory very 
> slowly increasing.

I may have by chance found at least one source of a memory leak without even going to valgrind yet.

Here is a function in set.c:

/* default settings for palette */
void
reset_palette()
{
    if (!enable_reset_palette) return;
    sm_palette.colorMode = SMPAL_COLOR_MODE_RGB;
    sm_palette.formulaR = 7; sm_palette.formulaG = 5;
    sm_palette.formulaB = 15;
    sm_palette.positive = SMPAL_POSITIVE;
    sm_palette.ps_allcF = 0;
    sm_palette.use_maxcolors = 0;
    sm_palette.gradient_num = 0;
    sm_palette.gradient = NULL;
    sm_palette.cmodel = C_MODEL_RGB;
    sm_palette.gamma = 1.5;
    pm3d_last_set_palette_mode = SMPAL_COLOR_MODE_NONE;
}

Notice that sm_palette.gradient is simply set to NULL.  But that variable is a memory pointer assigned as

    if (sm_palette.gradient) {
	free( sm_palette.gradient );
    }
    sm_palette.gradient = (gradient_struct*)
      gp_alloc( actual_size*sizeof(gradient_struct), "pm3d gradient" );

So, there needs to be a "free()" as part of that reset_palette() routine just as with the above hunk of code.  Palettes can be big, so that could easily chew up a lot of memory for some applications.

I'd also make the argument that the routines

set_palette_defined()
set_palette_file()
set_palette_function()
check_palette_grayscale()
reset_palette()

really don't need to be inside set.c and should go inside either color.c or getcolor.c.  That would help get rid of the use of a global structure variable sm_palette.

Some improvement in organization would also be pointer-based routines like compare_palette(), copy_palette(), destroy_palette() which partially exist already.  Rather than have sm_palette, maybe that would work better as a pointer.  What is nice about that is its more suitable for object-orientation as proposed by Hans if ever gnuplot moves to keeping track of multiple plot contents (rather than just the current).

Dan

Re: palette test? [Re: patchset #1448674]

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> That makes it all even easier.
> Please test the following trivial patch and see if it solves whatever
> problems you were having.
> Also test for bad interactions with other terminal types.

OK, I've tried it.  Now, this works very well for x11.trm and the redrawing problem.  I think its performance is better than the patch that I created because, not only is there reduced code, there isn't the step of creating the palette and doing an inefficient test.  The memcmp is a much faster routine.  [I would consider verifying that the memcmp alone catches everything because there is a pointer in that structure.  Couldn't it be the case that if a new palette is built its pointer address could somehow be the same as an old palette if somehow the first palette is deleted before the second one is defined?  The contents of the memory could be different but the starting address the same.]

In any case, what I suspected for other terminals with the "further back test" has shown to be the case.  Try the following commands for the PostScript terminal:

  set term postscript color solid
  set output 'test.ps'
  set pm3d
  splot x
  set output

[now look at the file test.ps in a postscript viewer... looks fine]

  set output 'test.ps'
  replot
  set output

[now look at the file test.ps in a postscirpt viewer... doesn't work]

The problem is that the second plot isn't getting the palette information it needs in the file.

I've tried the above with the patch I created and PostScript still works.

I'm not advocating my patch anymore.  Since we've gone this far why don't we consider solving it the appropriate way.  Going back to my email of a few months back:

> On the _terminal driver side_ of the pipe is the following test:
> 
> /* Only send the palette if it is different from the last palette,
> * one hasn't been sent yet, or if the plot number is different from
> * the plot number the last time the palette was set.
> */
> 
> If one thinks through the logic for that, you'll find it avoids flaky 
> behavior on part of the palette, even in multiplot mode.
> 
> That keeps gplt_x11.c from having to reconstruct the color tables unless 
> necessary.  The refresh speedup is clearly back to what it once was.
> 
> I would add that another part of this equation is that the gnuplot core 
> doesn't need to send the palette so often.  If it followed the formula 
> that it only send the palette when the _terminal_ changes or the palette 
> commands are entered, it would reduce more wasted CPU.  (If some devices 
> need a copy of the palette for every plot, the driver should keep a copy 
> internally.)  Don't want to get into that, however.  (Note the rule 
> would change if developers went the path of the core used plots as 
> objects, Hans' desire.)

Ethan has also proposed sending a variable along with the palette

 	TBOOLEAN same_palette_as_before

which we agreed wasn't the most elegant of solutions.

I'd prefer following the above rule to cut down on extra CPU usage.  I know, I know, CPUs today are fast-fast-fast.  But I always prefer good code... my original attempt at this fix was just a patch to avoid hurting anything else.

Dan

Re: palette test? [Re: patchset #1448674]

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

On Tuesday 14 March 2006 09:42 am, Ethan A Merritt wrote:
> >    /* let the terminal make the palette from the supplied RGB triplets */
> >    term->make_palette(&sm_palette);
> 
> This is where we would like to implement Daniel's proposed
> non-redundancy test

Doh!  Actually, it isn't.  x11 does its own palette maintenance,
and gets called at the earlier call site.  

That makes it all even easier.
Please test the following trivial patch and see if it solves whatever
problems you were having.
Also test for bad interactions with other terminal types.

--- gnuplot/src/color.c	2006-02-19 21:09:15.000000000 -0800
+++ gnuplot-cvs/src/color.c	2006-03-14 11:25:47.000000000 -0800
@@ -115,7 +115,13 @@
 	   It will not change palette passed below, but non-NULL has to be
 	   passed there to create the header or force its initialization
 	 */
-	term->make_palette(&sm_palette);
+
+	if (memcmp(&save_pal, &sm_palette, sizeof(t_sm_palette))) {
+	    term->make_palette(&sm_palette);
+	    save_pal = sm_palette;
+	    FPRINTF((stderr,"make_palette: calling term->make_palette for term with ncolors == 0\n"));
+	} else
+	    FPRINTF((stderr,"make_palette: skipping duplicate palette for term with ncolors == 0\n"));
 	return 0;
     }
 


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

Re: palette test? [Re: patchset #1448674]

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

On Tuesday 14 March 2006 08:34 am, Daniel J Sebald wrote:
> 
> 1) Is this test from color.c complete?
> 
>     if (save_pal.colorFormulae < 0
> 	|| sm_palette.colorFormulae != save_pal.colorFormulae
> 	|| sm_palette.colorMode != save_pal.colorMode
> 	|| sm_palette.formulaR != save_pal.formulaR
> 	|| sm_palette.formulaG != save_pal.formulaG
> 	|| sm_palette.formulaB != save_pal.formulaB
> 	|| sm_palette.positive != save_pal.positive
> 	|| sm_palette.colors != save_pal.colors) {

I think it is not complete.
It also has some strange tests (e.g. so far as I can see,
colorFormulae can never be anything but 37).


> 2) Would it make sense to replace the above lines of code in color.c with the function
> 
> palettes_differ(t_sm_palette *p1, t_sm_palette *p2)

You mean, replace it for the purpose of printing a message?  I don't know.

But I think this code has some problems in it right now:

>    save_pal = sm_palette;

copies current palette to save_pal, including pointers

>   if (sm_palette.color != NULL) {
>        free(sm_palette.color);
>        sm_palette.color = NULL;
>    }

Bad!  Now save_pal contains a pointer to an color array
that has just been freed.

>    sm_palette.color = gp_alloc( sm_palette.colors * sizeof(rgb_color),
>                                 "pm3d palette color");
>    /*  fill sm_palette.color[]  */
>    for (i = 0; i < sm_palette.colors; i++) {
>        gray = (double) i / (sm_palette.colors - 1);    /* rescale to [0;1] */
>        rgb1_from_gray( gray, &(sm_palette.color[i]) );
>    }

OK. We allocate and fill in a new color array.
But we cannot compare it to the old one, because that one
was freed prematurely.

>    /* let the terminal make the palette from the supplied RGB triplets */
>    term->make_palette(&sm_palette);

This is where we would like to implement Daniel's proposed
non-redundancy test:

    if (palettes_differ(&sm_palette, &sav_pal))
        term->make_palette(&sm_palette);

But in order to do that, the memory allocate/free needs to be cleaned up.
Also as we discussed, there needs to be a separate test for whether this
is the same terminal as we sent the previous palette to.

Further, Daniel has worried that some terminals might require reloading
the palette every time, even if it *is* the same.  I don't think that is
the case for any real terminal. Does anyone know differently?

What do you think?  It seems to me that this would be a much smaller
and cleaner change than Daniel's patch #1448674, and it fixes the use
for all terminals, not just x11.


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

Re: Gridding and color from input data

[Julien D. <jul...@no...>]

On 3/11/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
> Julien Duponchelle wrote:
> > "color.plot", line 3: Gridding of the color column is not implemented
>
> That message is quite clear, I think.  You're using dgrid3d, but it
> doesn't know how to interpolate colors.  So don't use dgrid3d.
> Transform your data file into a gnuplot grid dataset (--> help splot
> data, help glossary) by inserting structuring blank lines.
>
> > I want to kown when this  features will be add to the dev version
>
> It's somewhat unlikely it'll ever be added.  I'm not even sure it'll
> read RGB triplet from a file in the first place, but it certainly won't
> do interpolation among them.


Thank you that's perfect.

--
Julien Duponchelle
Etudiant =E0 l'Epitech (http://www.epitech.net)

Re: Changes to gnuplot fitting submitted to sourceforge as patch

[<br...@ph...>]

Thomas Mattison wrote:
> On 10-Mar-06, at 8:52 AM, Hans-Bernhard Bröker wrote:

>>> On 8-Mar-06, at 10:34 AM, Hans-Bernhard Bröker wrote:

> I did subscribe, so I don't understand.  But I have several email accounts,
> and some of them have aliases for the mail servers, so gnuplot-beta
> may not have figured out who I am.

Mailman only knows the actual mail address you subscribed as.  If you 
use something else as the FROM: field in your submissions, it'll reject 
them.  This one passed directly.

>>>> 7.  New one-line progress-report, revert by FIT_CLASSIC_PROGRESS = 1

> When it wraps, the columns typically don't line up, so usually the only
> thing that a line-wrap parameter would improve is that a single column
> would not get broken across lines.  

That's fixable.  E.g. if the lines are set to wrap, have them wrap 
always.  I.e. put all the non-parameter info in one line, then as many 
parameters as fit per line, with some indentation to provide some visual 
guidance.

But don't let me detain you --- if you don't implement, I might just
do it myself, once we integrated your patch.

>>>> 9.  Error-rescaling control

> The remaining disagreement is what to do in the old result format,
> and what about the internal variables containing the errors.

> It sounds like providing another variable to control the behavior
> is the appropriate solution.  So I'll provide one in the next version.

OK, then.

>>> If we repeat the same experiment and fit many times, the data will
>>> have statistical fluctuations, the fit parameters will have statistical
>>> fluctuations, and the chisquare will have statistical fluctuations.

>> ... and the parameter errors will also have statistical fluctuations.
>> Which will generally be no smaller than those of chisquare itself.
>> So the dividing them doesn't actually increase the variation of the
>> reported parameter errors considerably.

> I agree that for a normal chisquare behavior we are only talking about
> fluctuations of the errors by of order a factor of 2, not a factor of 10
> or more.  But the fit _errors_ for repeated experiments should actually
> not fluctuate at all, for fixed data errors.  

Now, that's a very strange statement, I think.  How could a process 
based entirely on statistically fluctuating data *avoid* fluctuation in 
some of its results?  There's a direct algebraic connection data --> 
residuals --> parameter errors.  I really don't see how the data can 
fluctuate, but the parameters not.

>>>> 10.  Gnuplot-readable parameters and errors in one line in fit.log file

>> Because its primary purpose is to be human-readable, not
>> machine-readable.  Because for all you know, it already contains a lot
>> of data the moment you start gnuplot.  fit.log is, basically, an
>> electronic lab notebook, not a worksheet to collect data from various
>> steps of a single experiment in.

> The simplest solution sounds like my original proposal of a new file
> with the summary lines always appended, with enough comments between
> them for human editing if required.  

What I don't really like about that version is the "always".  It 
basically means the user has to re-do the entire procedure, or manually 
edit the file in the middle of a gnuplot sessions, to remove fits gone 
bad from this machine-readable log, before he forgets which fits are to 
be kept, and which not.

'update' is the existing command to, so-to-say, 'bless' a fit result as 
accepted for further usage.  That's why I think it's the right place to 
add the machine-readable session log.

 > If we don't need a way to control
> whether or not the present summary goes into fit.log, we don't need a
> way to control whether the one-line summary goes to the new file.

Because the fit.log file is for humans to read, and it provides all the 
context the user can possibly need.  A full-blown copy of it in a 
machine-readable format would not serve much of a purpose that couldn't 
already be had by machine-translating the existing fit.log.   A selected 
subset of it must have the selection done inside gnuplot, not 
afterwards.  That's where update comes in handy.

>>>> 13.  Parameter step size limit, controlled by FIT_MAX_PAR_STEP

> There is still another goal, which is to avoid long jumps
> that might find the wrong minimum or be slow to recover from,
> even if they don't cause an undefined function evaluation.

But such tactics require implied knowledge about which long jumps are 
bad, and which aren't.  I don't see how it can be part of generic 
fitting program's job to second-guess the individual problem.  If the 
user already knows where the minimum is, she shouldn't be running 'fit'
to find it.

>>>> 16. Monte Carlo search for initial fit parameters

> The goal of _this_ Monte Carlo is to find a starting point in a
> defined range, 

I'm fully aware of that, and I'm not arguing we remove it.  FWIW, MINUIT 
also has such a method available.  But I don't think anyone I know ever 
used it on a regular basis.  A well-informed guess at startup parameters 
basically always outperformed it.

Ultimately, the statement I took from the manual for fudgit still holds: 
Non-linear least-squares fitting is an art!  It takes some learning to 
master it.

Problems executing ./prepare

[Caroline W. <ca...@gm...>]

Hello

I'm trying to download and compile the dev version because I'm
desperate to get my hands on the new histogram functionality. Forgive
me if the solution to my problem is trivial, but I've never tried
downloading and compiling from CVS before.

When I execute prepare I get the following errors:

automake: configure.in: required file `../config.guess' not found
automake: configure.in: required file `../config.sub' not found

This is on Debian GNU/Linux, with kernel version 2.6.8-2-686-smp, and
I'm using the cvs copy I downloaded about 12hrs ago, which I don't
believe has been patched in the intervening period.

Are these files I'm meant to have on my own box, or is something
missing in the downloaded files?

Thanks for your help.

Caroline

Re: Changes to gnuplot fitting submitted to sourceforge as patch

[Thomas M. <mat...@ph...>]

On 10-Mar-06, at 8:52 AM, Hans-Bernhard Br=F6ker wrote:

>> On 8-Mar-06, at 10:34 AM, Hans-Bernhard Br=F6ker wrote:
>
> [A side note: you should subscribe to gnuplot-beta if you're going to
> send mail there --- if you don't, each of your submissions will sit in
> limbo until I get round to approving it...]

I did subscribe, so I don't understand.  But I have several email=20
accounts,
and some of them have aliases for the mail servers, so gnuplot-beta
may not have figured out who I am.

>
>>> 4.  Zero-change in chisquare is now "BETTER" rather than "WORSE"
>
> [...]
>> One possibility I can imagine is that a local extremum isn't a point,
> but a large exactly horizontal plateau.  This would be an ill-posed
> problem, of course, but since AFAIK nobody has ever found a way of
> teaching users not to pose any of those, there we go.  The correct
> reaction to that kind of situation, should be to find the boundaries =
of
> that plateau and see if the slope is up or down, out there.  If the
> change does that, I'm all for it.

For an exactly horizontal region, the gradients of chisquare are all=20
zero,
so the calculated step will be zero.  Continuing the iteration in this
case will just result in multiple zero-length steps, until lambda maxes=20=

out.



<change: restore internal parameters from best iteration at end of=20
regress(),
  and also always restore last internal parameter inside calculate()>

>
>>> TM: Without this, if the user interrupted the fit and tried to
>>> plot the current function on top of the data, the last
>>> internal parameter was not correct.
>>>
>>> HBB: in that case, the fit interruption handler is what needs =
fixing,
>>> not call_gnuplot
>> That would be another way of fixing things, but is there any=20
>> significant
>> reason why calculate() should not undo the perturbation of the last
>> parameter that it had just done?
>
> The problem is that a hard interruption could, in principle, happen
> anywhere inside calculate().  At least that's how I remember this =
being
> handled in the Linux versions, where this is done directly by SIGINT.

It looks like the sigint handler just sets a software flag and returns,
and regress() checks the flag to know when to run fit_interrupt().

I looked, and fit_interrupt() already does restore the internal=20
variables
from what I think is the best iteration before running any script.

So I guess there was already a workaround for the fact that calculate()
left the last parameter changed, which also restored the internal=20
variables
set to the best iteration, not necessarily the one that was interrupted.

But it was true that if regress() stopped without really converging,
that the internal parameters were not left set to the best iteration
(except for the last one!)

I still think it is better if calculate() doesn't have
mysterious side-effects, even if they are fixed elsewhere.




>>> 6.  Changed convergence criterion, with new user-variable=20
>>> FIT_LIMIT_ABS.
>
> Let's just say I'm not fully convinced that the exact usage rules of
> FIT_LIMIT_ABS will be less prone to incorrect usage than error-less=20
> fits
> already are in general.  Users tend to just see a knob they can turn
> which will let their fits print "converged" at the end, and never look
> back to find out how it works, or whether it should be used in a
> particular case.  We may be giving the poor guys a gun to shoot
> themselves with instead of teaching them how to fish.

My perspective is that the default behavior will now be to use a fully
scale-independent relative convergence criterion, which is what I think
naive users expect, and not what they got before.  If anyone has a real
need for an absolute convergence criterion, and managed to exploit the
odd behavior of the old convergence criterion to get one, now they can
get the same thing in a straightforward way.


>>> 7.  New one-line progress-report, revert by FIT_CLASSIC_PROGRESS =3D =
1
>
>> I considered adding line breaks, but decided against it.  They don't
>> solve the readability problem for narrow consoles, compared to =
letting
>> the text wrap.
>
> Line breaks with some indentation might work, though.  Maybe yet=20
> another
> new parameter: FIT_LOG_WRAP_COLUMN (zero means don't wrap)?

When it wraps, the columns typically don't line up, so usually the only
thing that a line-wrap parameter would improve is that a single column
would not get broken across lines.  At that level, I'm not sure it's
worth doing.  Even with a column split between lines it's easier to use
the new  progress report to check progress than it was to use the old
format, and the old format is still available.  I think most people=20
don't
even look at the progress reports, so it's not that big an issue.



>>> 9.  Error-rescaling control
>
>> I do advocate changing the default behavior.  It's statistically=20
>> wrong to
>> rescale the errors according to the chisquare, if the user provided=20=

>> valid
>> errors.
>
> Well, it's statistically wrong to take seriously _anything_ the fit
> prints when the chisquare/ndf is far enough away from 1 to make a
> difference.  Such fits are plain any simply inacceptable.  So to some
> extent, it doesn't matter at all what we do with them: any result will
> be just as wrong as any other.

For cases where the chisquare is close to 1/DOF, it's wrong to rescale
the errors.  I do agree that when the chisquare is grossly out of whack,
it doesn't matter much what we do.

> =46rom a different point-of-view, a chisq/ndf far from 1 means the =
data
> errors don't explain the differences between data and model.  Either=20=

> the
> data errors are correct --- then the model is wrong.  Or the data=20
> errors
> are (as they so often are) bollocks.  'fit' has no way of knowing =
which
> is the case.  It has to favour one of them blindly, or it has to give=20=

> up
> right away, and just refuse to print errors at all.

My solution, which you haven't complained about, is to print out
both raw and rescaled errors when the user provides data errors
in the new result format.

The remaining disagreement is what to do in the old result format,
and what about the internal variables containing the errors.

It sounds like providing another variable to control the behavior
is the appropriate solution.  So I'll provide one in the next version.


>> If we repeat the same experiment and fit many times, the data will
>> have statistical fluctuations, the fit parameters will have=20
>> statistical
>> fluctuations, and the chisquare will have statistical fluctuations.
>
> ... and the parameter errors will also have statistical fluctuations.
> Which will generally be no smaller than those of chisquare itself.
> So the dividing them doesn't actually increase the variation of the
> reported parameter errors considerably.

I agree that for a normal chisquare behavior we are only talking about
fluctuations of the errors by of order a factor of 2, not a factor of 10
or more.  But the fit _errors_ for repeated experiments should actually
not fluctuate at all, for fixed data errors.  Only the fit parameter
_values_ should fluctuate.


>>> 10.  Gnuplot-readable parameters and errors in one line in fit.log=20=

>>> file
>
>> The point is that I want to _append_ many fit results to a
>> gnuplot-readable file, so the results from many similar fits
>> could be conveniently plotted along with their errors.  The
>> file from the update command doesn't seem to be appropriate for
>> appending results from many fits.
>
> Not yet.  But 'update's job is more similar to what you're doing than
> that of the fit.log file.
>
> Sticking that machine-readable data into the middle of a =
human-readable
> data stream, from which it'll have to be extracted before it can be
> used, doesn't really look like a good idea.  A new command "update
> append 'myfits.dat'" or whatever would make much more sense, from a=20
> user
> interface point-of-view.  For one thing, it gives the user an
> opportunity to choose which fits to put into the summary data file, =
and
> which not to.
>
>> Can you give a reason _why_ fit.log is the wrong place?
>
> Because its primary purpose is to be human-readable, not
> machine-readable.  Because for all you know, it already contains a lot
> of data the moment you start gnuplot.  fit.log is, basically, an
> electronic lab notebook, not a worksheet to collect data from various
> steps of a single experiment in.

The simplest solution sounds like my original proposal of a new file
with the summary lines always appended, with enough comments between
them for human editing if required.  If we don't need a way to control
whether or not the present summary goes into fit.log, we don't need a
way to control whether the one-line summary goes to the new file.


>>> 13.  Parameter step size limit, controlled by FIT_MAX_PAR_STEP

>> Lambda doesn't reliably prevent this, because it can take
>> several iterations for lambda to increase far enough to limit step
>> sizes by itself.
>
> So let it take several iterations.  If necessary, help it by =
signalling
> undefined values with a penalty on chisquare.

Maybe I can figure out a way to have marquardt() return WORSE
if any function evaluation is undefined.  That would let the
lambda-adjustment mechanism do part of what I'm trying to accomplish
(recover from parameter guesses that cause undefined function values).

There is still another goal, which is to avoid long jumps
that might find the wrong minimum or be slow to recover from,
even if they don't cause an undefined function evaluation.
A separate explicit parameter step limit is the only way to get this.

>
>>> 16. Monte Carlo search for initial fit parameters
>>

>> I thought about adding simplex, but from what I've read and heard,
>> its main strength is dealing with discontinuous derivatives, which
>> chisquare fits don't normally have (though it might do better on the
>> original hemisphere-fit demo problem....)
>
> "Normally" is not something we can easily rely on.  The Simplex method=20=

> is, of course, necessary where derivatives can't be used at all, and=20=

> it's better than MC at finding a starting point in completely unknown=20=

> terrain because it doesn't restrict itself to a limited parameter=20
> range.  It worked well for me when I was still using CERN's MINUT a=20
> lot.

The goal of _this_ Monte Carlo is to find a starting point in a defined=20=

range,
for cases where this is hard manually, like the frequency-fit demo in=20
my patch.
Simplex is more like Levenberg-Marquardt in the sense of still needed a=20=

good
starting point.



                                         Cheers

Prof. Thomas Mattison, Dept. of Physics & Astronomy, Univ. of British=20
Columbia

Present Address: Stanford Linear Accelerator Center
2575 Sand Hill Road, Menlo Park, CA, 94025
Building 48 (Research Office Building), Mail Station MS35
Office:  ROB-231   Phone: 650-926-5342   Fax: 650-926-8522