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

Re: Tex on x-axis

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

On Wednesday, October 20, 2010 10:48:37 am Gandalf84 wrote:
> 
> Hi,
> i'm drawing an histogram in which on the y-axis there is the spped of an
> algorithm, and on the x-axis i would to put the algorithm name, how can i do
> this?
> I don't know how to put text instead of numbers on the x-axis!

You mean like this?

	http://gnuplot.sourceforge.net/demo/datastrings.html

Tex on x-axis

[Gandalf84 <sab...@gm...>]

Hi,
i'm drawing an histogram in which on the y-axis there is the spped of an
algorithm, and on the x-axis i would to put the algorithm name, how can i do
this?
I don't know how to put text instead of numbers on the x-axis!

Thank you
-- 
View this message in context: http://old.nabble.com/Tex-on-x-axis-tp30012324p30012324.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

exponential integral function

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

I've submitted a patch to add the exponential integral function.
Would someone be willing to accept it?  

I'd apply it myself, but the server won't let me do a commit:

>  cvs login: authorization failed: server gnuplot.cvs.sourceforge.net
>  rejected access to /cvsroot/gnuplot for user vanzandt

It's been a little over a year since I submitted anything, so maybe
I've lost write permissions?  If someone would restore that, I'd
appreciate it.

       - Jim Van Zandt

Re: CTRL_CLOSE_EVENT gives Application error for gnuplot.exe for windows using the wxt terminal

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

Hello

Sorry the patch is not sufficeint for the purpose to trap CTRL + C.

I have carried out the test.

i=0; load 'rereadtest.gp'

# rereadtest.gp
i=i+1
plot sin(x+i*0.1/pi);
reread
# end of rereadtest.gp

On the cygwin version gnuplot, thw CTLC + C on the command window works as expected.
(I can go back the gnuplot prompt.)

On the other hand, the modified gnuplot.exe for windows CTRL + C does not make gnuplot back to the
prompt.

I will consider the further. 

Regards

Tatsuro


--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> I have tried to look this phenomena in detail.
> However it is principally difficult to trace the issue by the gdb.
> And on the gdb, application error itself does  not appear.
> 
> Therefore I use the SetConsoleCtrlHandler and CtrlHandler functions in the win32api.
> 
> The issue is easy to fix to use the above.
> 
> 
> I have also retied to fix ctrc+c issue on gnuplot.exe on windows.
> 
> It seem that setjmp+longjmp routine does not work in the interrupt routine on windows.
> In windows console program, use of the SetConsoleCtrlHandler and CtrlHandler functions seem to
> be
> usual way to trap CTRL + C.
> 
> In the trapping routine, I have copied SETJMP in gnu_main( for the windows case).
> However, I cannot make the prompt 'gnuplot> ' to be appeared.  But I found that the pressing the
> return key makes the prompt to be appeared. I have write that temporal treatment.
> 
> If press the CTRL + C at gnuplot prompt,
> 
> gnuplot>
> CTRL+C detected. Press return to back to the prompt ->
> 
> If press the return, I can back to the gnuplot prompt
> The total appearances are 
> 
> gnuplot>
> CTRL+C detected. Press return to back to the prompt ->
> gnuplot>
> 
> I have attached the patch.
> 
> Comments and suggestions are welcome.
> 
> For the wnuplot, the way I have shown cannot be used.
> Perhaps, the GUI program for windows, different way should be considered.
> 
> Regards
> 
> Tatsuro
> 
> --- Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > The problem is completely different from the original issue.
> > Therefore I post the issue as a different one.
> > 
> > 
> > Explanation of CTRL_CLOSE_EVENT
> > 
> > CTRL_CLOSE_EVENT : Close the window consoleby clicking on the x at the upper right corner.
> > 
> > 
> > I have confirmed the same phenomena at gnuplot 4.4.0 on the gnuplot official site.
> > 
> > I also confirmed the same pehnomena at gnuplot 4.4.0 for octave-mingw32 bundled with
> > octave-3.2.4
> > mingw32 which is prepared by Benjamin.
> > 
> > Perhaps it is not specific to the current my build system.
> > 
> > One of the way to avoid this issue is to trap the CTRL_CLOSE_EVENT using win32api and exit
> > gnuplot
> > using the function (at_exit? ) used inside gnuplot.
> > 
> > If I implement this, I will write the routine in the plot.c
> > 
> > However I will look at what is happing further.
> > 
> > Regards
> > 
> > Tatsuro 
> > 
> > 
> > 
> > ***************************************************
> > --- Tatsuro MATSUOKA  wrote:
> > 
> > > This is well known issue for windows console applications.
> > > The octave also has the similar issue.
> > 
> > Seeing phenomena in detail, the issue pointed is not the same as that of the octave for
> windows.
> > 
> > Please try,
> > 
> > set term win
> > plot x
> > 
> > and quit gnuplot by clicking on the x at the upper right corner.
> > In my case, gnuplot terminates normally.
> > 
> > set term emf 
> > set out 'test.emf'
> > plot x
> > 
> > and quit gnuplot by clicking on the x at the upper right corner.
> > In this case, gnuplot also terminates normally.
> > (test.emf was correctly generated so that gnuplot terminated with normal quit process.)
> > 
> > 
> > This phenomenon seems to be specific to the wxt terminal + gnuplot.exe.
> > 
> > I have to see the code of the wxt terminal related codes so that it will take time to correct
> > it.
> > 
> > Regards
> > 
> > Tatsuro
> >  
> > 
> > > 
> > > However, to avoid this issue one have to trap CTRL_CLOSE_EVENT (that is you described as
> > > clicking on
> > > the x at the upper right corner) using SetConsoleCtrlHandler function, which is the win32api
> > > function.
> > > 
> > > However, I have tried to trap CTRL+C by this api function to overcome the SIGINT issue for
> > > gnuplot for
> > > windows, the results was not successful.  
> > > 
> > > I can try to fix CTRL_CLOSE_EVENT issue but I do not have any confidence to avoid to it.
> > > 
> > > One possible way to treat the issue in tricky way is to execute gnuplot.exe on the cmd.exe
> > > wrapper
> > > application like 'ckw'.
> > > 
> > > I am using the Japanese software the ckw downloaded from 
> > > http://sites.google.com/site/craftware/ckw/download/ckw-0.8.10-mod4-20100508.zip
> > > 
> > > The reference is translated by me.
> > > http://www.tatsuromatsuoka.com/ckw/Reference-en.txt
> > > 
> > > Known bug for the ckw-0.8.10-mod4-20100508.  
> > > If the ckw command is execute by shortcut, it fails to hide the cmd console.
> > > To avoid this, you execute ckw using the start command in the cmd.
> > >   cmd /c start ckw (options)
> > > 
> > > Please also see the help of start command by typing 'help start' at cmd prompt.
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > > 
> > > 
> > > 
> > > --- Petr Mikulik wrote:
> > > 
> > > > > I've tried the latest distribution from
> > > > > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/, and the fix is
> > > > > confirmed!
> > > > > 
> > > > > However, I've found something else. Steps to reproduce:
> > > > > 
> > > > > 1) Start gnuplot.exe - either from an Explorer window or from the console
> > > > > 2) Plot anything - for example 'plot x'
> > > > > 3) Close the window, not by typing exit, but by clicking on the x at
> > > > > the upper right corner
> > > > > 4) Observe the error window: 'Application error: The instruction at
> > > > > "0x00000000" referenced memory at "0x00000000". The memory could not
> > > > > be "read".'
> > > > > 
> > > > > It's always 0x00000000, and it's 100% reproducible on both Windows XP
> > > > > (32 bit) machines I've tried.
> > > > > 
> > > > > Notes: this happens only with gnuplot.exe, but not with wgnuplot.exe.
> > > > > Also, this doesn't occur if you change the terminal to "windows"
> > > > > instead of "wxt".
> > > > 
> > > > I set wine to "winxp" and gnuplot.exe works correctl
> > 
> > --------------------------------------
> > Learn more about breast cancer - Pink Ribbon Campaign 2010
> > http://yj.pn/JAy9L7
> > 
> 
> 
> --------------------------------------
> Learn more about breast cancer - Pink Ribbon Campaign 2010
> http://yj.pn/JAy9L7


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: CTRL_CLOSE_EVENT gives Application error for gnuplot.exe for windows using the wxt terminal

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

Hello

I have tried to look this phenomena in detail.
However it is principally difficult to trace the issue by the gdb.
And on the gdb, application error itself does  not appear.

Therefore I use the SetConsoleCtrlHandler and CtrlHandler functions in the win32api.

The issue is easy to fix to use the above.


I have also retied to fix ctrc+c issue on gnuplot.exe on windows.

It seem that setjmp+longjmp routine does not work in the interrupt routine on windows.
In windows console program, use of the SetConsoleCtrlHandler and CtrlHandler functions seem to be
usual way to trap CTRL + C.

In the trapping routine, I have copied SETJMP in gnu_main( for the windows case).
However, I cannot make the prompt 'gnuplot> ' to be appeared.  But I found that the pressing the
return key makes the prompt to be appeared. I have write that temporal treatment.

If press the CTRL + C at gnuplot prompt,

gnuplot>
CTRL+C detected. Press return to back to the prompt ->

If press the return, I can back to the gnuplot prompt
The total appearances are 

gnuplot>
CTRL+C detected. Press return to back to the prompt ->
gnuplot>

I have attached the patch.

Comments and suggestions are welcome.

For the wnuplot, the way I have shown cannot be used.
Perhaps, the GUI program for windows, different way should be considered.

Regards

Tatsuro

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> The problem is completely different from the original issue.
> Therefore I post the issue as a different one.
> 
> 
> Explanation of CTRL_CLOSE_EVENT
> 
> CTRL_CLOSE_EVENT : Close the window consoleby clicking on the x at the upper right corner.
> 
> 
> I have confirmed the same phenomena at gnuplot 4.4.0 on the gnuplot official site.
> 
> I also confirmed the same pehnomena at gnuplot 4.4.0 for octave-mingw32 bundled with
> octave-3.2.4
> mingw32 which is prepared by Benjamin.
> 
> Perhaps it is not specific to the current my build system.
> 
> One of the way to avoid this issue is to trap the CTRL_CLOSE_EVENT using win32api and exit
> gnuplot
> using the function (at_exit? ) used inside gnuplot.
> 
> If I implement this, I will write the routine in the plot.c
> 
> However I will look at what is happing further.
> 
> Regards
> 
> Tatsuro 
> 
> 
> 
> ***************************************************
> --- Tatsuro MATSUOKA  wrote:
> 
> > This is well known issue for windows console applications.
> > The octave also has the similar issue.
> 
> Seeing phenomena in detail, the issue pointed is not the same as that of the octave for windows.
> 
> Please try,
> 
> set term win
> plot x
> 
> and quit gnuplot by clicking on the x at the upper right corner.
> In my case, gnuplot terminates normally.
> 
> set term emf 
> set out 'test.emf'
> plot x
> 
> and quit gnuplot by clicking on the x at the upper right corner.
> In this case, gnuplot also terminates normally.
> (test.emf was correctly generated so that gnuplot terminated with normal quit process.)
> 
> 
> This phenomenon seems to be specific to the wxt terminal + gnuplot.exe.
> 
> I have to see the code of the wxt terminal related codes so that it will take time to correct
> it.
> 
> Regards
> 
> Tatsuro
>  
> 
> > 
> > However, to avoid this issue one have to trap CTRL_CLOSE_EVENT (that is you described as
> > clicking on
> > the x at the upper right corner) using SetConsoleCtrlHandler function, which is the win32api
> > function.
> > 
> > However, I have tried to trap CTRL+C by this api function to overcome the SIGINT issue for
> > gnuplot for
> > windows, the results was not successful.  
> > 
> > I can try to fix CTRL_CLOSE_EVENT issue but I do not have any confidence to avoid to it.
> > 
> > One possible way to treat the issue in tricky way is to execute gnuplot.exe on the cmd.exe
> > wrapper
> > application like 'ckw'.
> > 
> > I am using the Japanese software the ckw downloaded from 
> > http://sites.google.com/site/craftware/ckw/download/ckw-0.8.10-mod4-20100508.zip
> > 
> > The reference is translated by me.
> > http://www.tatsuromatsuoka.com/ckw/Reference-en.txt
> > 
> > Known bug for the ckw-0.8.10-mod4-20100508.  
> > If the ckw command is execute by shortcut, it fails to hide the cmd console.
> > To avoid this, you execute ckw using the start command in the cmd.
> >   cmd /c start ckw (options)
> > 
> > Please also see the help of start command by typing 'help start' at cmd prompt.
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > 
> > --- Petr Mikulik wrote:
> > 
> > > > I've tried the latest distribution from
> > > > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/, and the fix is
> > > > confirmed!
> > > > 
> > > > However, I've found something else. Steps to reproduce:
> > > > 
> > > > 1) Start gnuplot.exe - either from an Explorer window or from the console
> > > > 2) Plot anything - for example 'plot x'
> > > > 3) Close the window, not by typing exit, but by clicking on the x at
> > > > the upper right corner
> > > > 4) Observe the error window: 'Application error: The instruction at
> > > > "0x00000000" referenced memory at "0x00000000". The memory could not
> > > > be "read".'
> > > > 
> > > > It's always 0x00000000, and it's 100% reproducible on both Windows XP
> > > > (32 bit) machines I've tried.
> > > > 
> > > > Notes: this happens only with gnuplot.exe, but not with wgnuplot.exe.
> > > > Also, this doesn't occur if you change the terminal to "windows"
> > > > instead of "wxt".
> > > 
> > > I set wine to "winxp" and gnuplot.exe works correctl
> 
> --------------------------------------
> Learn more about breast cancer - Pink Ribbon Campaign 2010
> http://yj.pn/JAy9L7
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: not_a_number for MinGW build (gcc-4.5.0)

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

Hello

I have confirmed the fix of cvs source and also confirmed that binaries built with the fixed source
fixes the problem.

Thanks!!

Regards
 

--- "sfeam (Ethan Merritt)" wrote:

> On Sunday, October 10, 2010, Tatsuro MATSUOKA wrote:
> > 
> > > So I changed from
> > > #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) 
> > > to
> > > #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) || defined (__MinGW32__)
> > > but pr NaN gives 0.0.
> > 
> > I have just make a mistake in define MinGW.
> > 
> > The macro 'defined (__MinGW32__)' should be 'defined (__MINGW32__)'.
> > 
> > I have attached the patch. This makes 'pr NaN gives NaN.'.
> 
> Added to CVS.
> Thanks,
> 
> 	Ethan
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: not_a_number for MinGW build (gcc-4.5.0)

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, October 10, 2010, Tatsuro MATSUOKA wrote:
> 
> > So I changed from
> > #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) 
> > to
> > #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) || defined (__MinGW32__)
> > but pr NaN gives 0.0.
> 
> I have just make a mistake in define MinGW.
> 
> The macro 'defined (__MinGW32__)' should be 'defined (__MINGW32__)'.
> 
> I have attached the patch. This makes 'pr NaN gives NaN.'.

Added to CVS.
Thanks,

	Ethan

Re: Cross-hatching issue under pdfcairo in gnuplot 4.4 patchlevel 0

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

On Saturday, October 09, 2010, Eric Wayman wrote:
> Hello,
> 
> When creating a rowstacked histogram in gnuplot 4.4 patchlevel 0 under
> the pdfcairo terminal, I get a very ugly result compared to the
> postscript eps terminal. Specifically, the cross-hatching patterns
> look thick and ugly. 

Yeah. I prefer to use greyscale instead:

plot 'foo' using 2 fs solid 0.0 lt -1, \
        '' using 3 fs solid 1.0 lt -1, \
        '' using 4 fs solid 0.5 lt -1



> I have attached the example output
> "election.pdf."
> 
> Code:
> 
> set datafile separator ","
> set out "election.pdf"
> set term pdfcairo font "IPAMincho"
> set title "日本語のフォントが使えます" font "IPAPMincho"
> set xlabel "X軸" font "IPAPMincho"
> set ylabel "Y軸" font "IPAPMincho"
> set style histogram rowstacked
> set style data histogram
> plot 'election.csv' using 2 fs pattern 0 lt -1, \
>            '' using 3 fs pattern 1 lt -1, \
>            '' using 4 fs pattern 2 lt -1
> 
> Data:
> 
> # Year, Red, Green, Blue
> 1990,   33,  45,    18
> 1991,   35,  42,    19
> 1992,   34,  44,    14
> 1993,   37,  43,    25
> 1994,   47,  15,    30
> 1995,   41,  14,    32
> 1996,   42,  20,    35
> 1997,   39,  21,    31
> 
> Is there a way to make the patterns look more like they do under postscript eps?
> 
> -- Eric Wayman
> 

Re: not_a_number for MinGW build (gcc-4.5.0)

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

Hello

Ooops!

> So I changed from
> #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) 
> to
> #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) || defined (__MinGW32__)
> but pr NaN gives 0.0.

I have just make a mistake in define MinGW.

The macro 'defined (__MinGW32__)' should be 'defined (__MINGW32__)'.

I have attached the patch. This makes 'pr NaN gives NaN.'.

Regards

Tatsuro
 
--- Tatsuro MATSUOKA wrote:

> Hello
> 
> For current windows binaries,
> gnuplot> pr NaN
> 0.0
> 
> This is not correct.
> 
> For the cygwin and the djgpp (modified recently) give 
> gnuplot> pr NaN
> NaN
> 
> I have googled NaN for the MinGW, I have not obtained good information yet.
> So I have written the test code the below
> 
> **************************************
> #include <stdio.h>
> #include <math.h>
> 
> 
> int main(void){
>     double dbl;
> 	unsigned long uldbl[2];
> 
>     printf("test 0.0/0.0\n");
>     dbl = 0.0/0.0;
>     *( double* )uldbl = dbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     printf("test 0xffffffff 0x7fffffff \n");
>     uldbl[0]=0xffffffff; uldbl[1]= 0x7fffffff;
>     dbl = *( double* )uldbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     printf("test atof(\"NaN\") \n");
>     dbl = atof("NaN");
>     *( double* )uldbl = dbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     printf("test atof(\"-1.#IND00\") \n");
>     dbl = atof("-1.#IND00");
>     *( double* )uldbl = dbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     printf("test atof(\"1.#QNAN0\") \n");
>     dbl = atof("1.#QNAN0");
>     *( double* )uldbl = dbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     printf("test 0 \n");
>     dbl = 0;
>     *( double* )uldbl = dbl;
>     printf("%f \n",dbl);
>     printf("isnan = %d \n",isnan(dbl));
>     printf("%x %x\n", uldbl[0], uldbl[1]);
>     printf("\n");
> 
>     return 0;
> }
> *************************
> The results are
> 
> $ ./nan
> test 0.0/0.0
> -1.#IND00
> isnan = 1
> 0 fff80000
> 
> test 0xffffffff 0x7fffffff
> 1.#QNAN0
> isnan = 1
> ffffffff 7fffffff
> 
> test atof("NaN")
> 2293504.000000
> isnan = 0
> 0 41417f80
> 
> test atof("-1.#IND00")
> 2293504.000000
> isnan = 0
> 0 41417f80
> 
> test atof("1.#QNAN0")
> 2293504.000000
> isnan = 0
> 0 41417f80
> 
> test 0
> 0.000000
> isnan = 0
> 0 0
> 
> #******************
> 
> >From above it seems to be
> 
> 	unsigned long lnan[2]={0xffffffff, 0x7fffffff};
>     return *( double* )lnan;
> 
> is applicable as for the MSC and djgpp.
> 
> So I changed from
> #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) 
> to
> #if defined (__MSC__) || defined (DJGPP) || defined(__DJGPP__) || defined (__MinGW32__)
> but pr NaN gives 0.0.
> 
> This is the current situation.
> 
> Any suggestions?
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Learn more about breast cancer - Pink Ribbon Campaign 2010
> http://yj.pn/JAy9L7
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Cross-hatching issue under pdfcairo in gnuplot 4.4 patchlevel 0

[Eric W. <way...@gm...>]

Hello,

When creating a rowstacked histogram in gnuplot 4.4 patchlevel 0 under
the pdfcairo terminal, I get a very ugly result compared to the
postscript eps terminal. Specifically, the cross-hatching patterns
look thick and ugly. I have attached the example output
"election.pdf."

Code:

set datafile separator ","
set out "election.pdf"
set term pdfcairo font "IPAMincho"
set title "日本語のフォントが使えます" font "IPAPMincho"
set xlabel "X軸" font "IPAPMincho"
set ylabel "Y軸" font "IPAPMincho"
set style histogram rowstacked
set style data histogram
plot 'election.csv' using 2 fs pattern 0 lt -1, \
           '' using 3 fs pattern 1 lt -1, \
           '' using 4 fs pattern 2 lt -1

Data:

# Year, Red, Green, Blue
1990,   33,  45,    18
1991,   35,  42,    19
1992,   34,  44,    14
1993,   37,  43,    25
1994,   47,  15,    30
1995,   41,  14,    32
1996,   42,  20,    35
1997,   39,  21,    31

Is there a way to make the patterns look more like they do under postscript eps?

-- Eric Wayman

Re: Excessive memory usage with the pdfcairo terminal?

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

On 08.10.2010 21:51, Allin Cottrell wrote:

> Isn't the best solution to down-sample the plot?

Not really.  Down-sampling a scatter plot defeats the purpose of the plot.

The best solution is "Don't do that, then".  Don't make million-point 
scatter plots in vector format if you're not prepared to accept the 
consequences (huge files, slow rendering times, possible rejection in 
print).

What one can do instead is down-sample and histogrammize the _data_, 
then make a different kind of plot of those.  E.g. a color-coded density 
plot.

Re: Excessive memory usage with the pdfcairo terminal?

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

On Fri, 8 Oct 2010, Ethan Merritt wrote:

> On Friday 08 October 2010 02:07:42 am Christoph Bersch wrote:
> > Ethan Merritt schrieb:
> > >
> > > The long-standing admonition still holds. Vector formats like PostScript,
> > > PDF, SVG are bad choices for creating a plot with a million points.
> > > A bitmap format like PNG does much better.  "Ah", you say,
> > > "but I asked cairo to produce a PNG file." Well yes, but that's not the way
> > > cairo works.  First it creates the requested graphic in a standard internal
> > > representation that maintains all the necessary information for vector output.
> > > Then when you are ready to dump it to a file, it converts the internal
> > > representation to the final output representation.
> > > Or at least that's how I understand it.
> > >
> > > Time to revisit the idea of a pdflatex terminal?
> >
> > How do you think would a pdflatex terminal solve this problem and what
> > configuration do you have in mind for a pdflatex terminal?
>
> I assume that the goal is to end up with a PDF file that contains
> a plot constructed from an unreasonably large number of
> points...

Isn't the best solution to down-sample the plot? Embedding a
bitmap in PDF output seems retrograde to me (although I do see how
it addresses the problem at hand). People often read PDFs
on-screen and then it's nice to have the non-text material in
vector form (resize at will).

Allin Cottrell

Re: Excessive memory usage with the pdfcairo terminal?

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

On Friday 08 October 2010 02:07:42 am Christoph Bersch wrote:
> Ethan Merritt schrieb:
> > 
> > The long-standing admonition still holds. Vector formats like PostScript,
> > PDF, SVG are bad choices for creating a plot with a million points.
> > A bitmap format like PNG does much better.  "Ah", you say, 
> > "but I asked cairo to produce a PNG file." Well yes, but that's not the way
> > cairo works.  First it creates the requested graphic in a standard internal
> > representation that maintains all the necessary information for vector output.
> > Then when you are ready to dump it to a file, it converts the internal
> > representation to the final output representation.
> > Or at least that's how I understand it.
> > 
> > Time to revisit the idea of a pdflatex terminal?
> 
> How do you think would a pdflatex terminal solve this problem and what 
> configuration do you have in mind for a pdflatex terminal?

I assume that the goal is to end up with a PDF file that contains
a plot constructed from an unreasonably large number of points.

This can be addressed by wrapping a bitmap image in a PDF file so that
the text is handled at full resolution while the bitmap image is handled
at a fixed maximum resolution that caps the total file size.

We already have a model for doing exactly this in gnuplot - the epslatex
terminal.  It splits the task into a text part and a non-text part, letting
latex handle the text and the postscript terminal handle the rest. 
I think it would be relatively easy to modify this so that the non-text
part is handled by the existing png driver and the latex part is tweaked
slightly for use with pdflatex rather than latex.

Obviously it is not strictly necessary to involve latex in this process.
I think the same split-and-recombine approach could be implemented by
importing a bitmap image generated by gd.trm into a complete document
created by pdfcairo.  But this would involve more work, as the code would
need to be written from scratch rather than being trivially modified from
the existing epslatex terminal driver. 

I can see arguments in favor of either path.
The argument in favor of png+pdflatex is that it could be supported
without requiring that gnuplot be built with the cairo libraries, and
the amount of new coding and debugging is expected to be small.
The arguments in favor of png+pdfcairo are that gnuplot itself would
emit the final pdf document rather than requiring a separate run of
pdflatex.

> In my eyes there are many different possibilities to realize a pdflatex 
> terminal, but I don't see any advantages of this compared to the cairo 
> terminals (apart from the mathematical typesetting).

Either way, someone has to code up the new terminal.   My estimate is
that basing it on the existing epslatex terminal would be relatively simple.
But if the hypothetical "someone" prefers to work with cairo and is willing
to take on the more complicated job, that's great also.

Either way there's already a patch on SourceForge that modifies gd.trm
so that it produces only the non-text portion of a plot.

	Ethan

 

Re: Excessive memory usage with the pdfcairo terminal?

[Christoph B. <us...@be...>]

Ethan Merritt schrieb:
> 
> The long-standing admonition still holds. Vector formats like PostScript,
> PDF, SVG are bad choices for creating a plot with a million points.
> A bitmap format like PNG does much better.  "Ah", you say, 
> "but I asked cairo to produce a PNG file." Well yes, but that's not the way
> cairo works.  First it creates the requested graphic in a standard internal
> representation that maintains all the necessary information for vector output.
> Then when you are ready to dump it to a file, it converts the internal
> representation to the final output representation.
> Or at least that's how I understand it.
> 
> Time to revisit the idea of a pdflatex terminal?

How do you think would a pdflatex terminal solve this problem and what 
configuration do you have in mind for a pdflatex terminal?

In my eyes there are many different possibilities to realize a pdflatex 
terminal, but I don't see any advantages of this compared to the cairo 
terminals (apart from the mathematical typesetting).

Christoph

Re: Excessive memory usage with the pdfcairo terminal?

[Peter J. <pet...@gm...>]

On Fri, Oct 8, 2010 at 2:32 AM, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Thursday 07 October 2010 01:07:28 pm Juhász Péter wrote:
>> Dear gnuplot developers,
>>
>> while doing some work on a large dataset, I've noticed that gnuplot uses
>> what could be construed as an excessive amount of memory if the terminal
>> is set to pdfcairo. (My machine actually ran out of physical memory and
>> began to thrash the swap, that's why I noticed).
>>
>> I've done some simple benchmarking with random data (k*1e5 pairs of
>> random numbers generated by perl, where k went from 1 to 10; then this
>> was plotted by:
>> gnuplot -e 'set term pdf;set out "r.pdf";plot "r.txt" w d').
>>
>> >From what I can see from the benchmark, the dependence of the memory
>> consumption on the dataset size is completely linear - this is expected
>> and understandable. What is not expected and hardly understandable is
>> the ratio: it needs about 872 bytes per point.
>
> How are you tracking memory usage?

Simply: ps ux | grep gnuplot. I generated ten datasets with k*1e5
points (k=1:10) and I saved the values of the VSZ and RSS columns of
the ps output for each dataset, then I fitted a line on the memory
data. So the precise statement is that memory usage grows by about 872
bytes per point.

Glancing at the source code, this may not be that mysterious at all.
It does a lot more that just drawing a dot, even if the plot style is
dots.

>
>> The pdfcairo terminal also takes a long time: about 27.9 s to plot 1
>> million points. (The time dependence is also linear.)
>
> One interesting thing is that less than half of this time is spent
> creating the cairo image internally; more of the time is spent
> converting it to pdf afterward.
>
> test file bigdata.dat was created by
>   for (i=0; i<1000000; i++) printf("%g %g\n",drand48(), drand48());
>
> [1] time gnuplot -e 'set term png; plot "bigdata.dat" using 1:2 with dots' > bigdata.png
> 0.883u 0.060s 0:01.00 94.0%     0+0k 0+24io 0pf+0w
> [2] time gnuplot -e 'set term pngcairo; plot "bigdata.dat" using 1:2 with dots' > bigdata.pngcairo
> 15.339u 0.044s 0:17.03 90.2%    0+0k 0+384io 0pf+0w
> [3] time gnuplot -e 'set term pdfcairo; plot "bigdata.dat" using 1:2 with dots' > bigdata.pdf
> 37.023u 0.533s 0:38.02 98.7%    0+0k 0+51520io 0pf+0w
>
> The long-standing admonition still holds. Vector formats like PostScript,
> PDF, SVG are bad choices for creating a plot with a million points.
> A bitmap format like PNG does much better.

I'm aware of this, the above example of one million points was only
for testing purposes.

"Ah", you say,
> "but I asked cairo to produce a PNG file." Well yes, but that's not the way
> cairo works.  First it creates the requested graphic in a standard internal
> representation that maintains all the necessary information for vector output.
> Then when you are ready to dump it to a file, it converts the internal
> representation to the final output representation.
> Or at least that's how I understand it.
>
> Time to revisit the idea of a pdflatex terminal?
>
>        Ethan
>
>> For comparison, the same data for the postscript terminal: little more
>> than 60 bytes per point (which is just what the plot->points array
>> needs) and just above one second of execution time for the same 1
>> million points.
>>
>> Now I haven't delved into the innards of the pdfcairo terminal driver,
>> and if you tell me that this is normal and expected, I'll believe you.
>> But I can't imagine why it needs over 800 bytes to store a single point.
>>
>> A not entirely unrelated question: how do I compile gnuplot with
>> profiling? I tried giving CFLAGS="-g -pg" to the configure script, but
>> the gmon.out file was not there after running gnuplot.
>>
>> Péter Juhász
>

Re: pm3d plot is brack for x11 terminal gnuplot

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

Hello

BTW, I have installed the xdpyinfo command into my cygwin system.

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> I have confirmed the change fixes the problem.
> 
> Thanks!!
> 
> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt  wrote:
> 
> > On Thursday 07 October 2010 03:59:39 pm Tatsuro MATSUOKA wrote:
> > > Hello
> > > 
> > > Thank you for your reply.
> > > 
> > > 
> > > --- "sfeam (Ethan Merritt)"  wrote:
> > > 
> > > > I think that change is probably not the source of the problem.
> > > > It is more likely this one:
> > > > 
> > > > 2010-10-05  Ethan A Merritt  <merritt@u.washington.edu>
> > > >         * src/getcolor.c (quantize_gray) src/getcolor.h src/gplt_x11.c:
> > > >         Continuation of defined palette revamp (2010-10-01). Break out the
> > > >         new code into a separate subroutine that can be shared with gnuplot_x11.
> > 
> > I have made one small change in gplt_x11.c this morning.  It should be in CVS by now.
> > I think it will fix your problem, but please confirm.
> > 
> > 	best regards,
> > 
> > 		Ethan
> > 
> > 
> > 
> > > > 
> > > > Is it possible that you can tell me the properties of your x11 display?
> > > > On linux the command is "xdpyinfo", but I do not know if the same command
> > > > exists in cygwin.  In particular I want to know if the x11 display uses
> > > > 24-bit RGB color or instead uses a color palette with a fixed number of
> > > > colors.
> > > > 
> > > 
> > > xdpyinfo
> > > does not work in my system.  I do not install full components of the cygwin.
> > > 
> > > Anyway I ask the way to know "if the x11 display uses
> > > 24-bit RGB color or instead uses a color palette with a fixed number of colors."
> > > 
> > > at the cygwin ML.
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > >  
> > > 
> > > 
> > > 
> > > --------------------------------------
> > > Learn more about breast cancer - Pink Ribbon Campaign 2010
> > > http://yj.pn/JAy9L7
> > > 
> > > ------------------------------------------------------------------------------
> > > Beautiful is writing same markup. Internet Explorer 9 supports
> > > standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> > > Spend less time writing and  rewriting code and more time creating great
> > > experiences on the web. Be a part of the beta today.
> > > http://p.sf.net/sfu/beautyoftheweb
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center,  K-428 Health Sciences Bldg
> > University of Washington, Seattle 98195-7742
> > 
> 
> 
> --------------------------------------
> Learn more about breast cancer - Pink Ribbon Campaign 2010
> http://yj.pn/JAy9L7
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: pm3d plot is brack for x11 terminal gnuplot

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

Hello

I have confirmed the change fixes the problem.

Thanks!!

Regards

Tatsuro

--- Ethan Merritt  wrote:

> On Thursday 07 October 2010 03:59:39 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Thank you for your reply.
> > 
> > 
> > --- "sfeam (Ethan Merritt)"  wrote:
> > 
> > > I think that change is probably not the source of the problem.
> > > It is more likely this one:
> > > 
> > > 2010-10-05  Ethan A Merritt  <merritt@u.washington.edu>
> > >         * src/getcolor.c (quantize_gray) src/getcolor.h src/gplt_x11.c:
> > >         Continuation of defined palette revamp (2010-10-01). Break out the
> > >         new code into a separate subroutine that can be shared with gnuplot_x11.
> 
> I have made one small change in gplt_x11.c this morning.  It should be in CVS by now.
> I think it will fix your problem, but please confirm.
> 
> 	best regards,
> 
> 		Ethan
> 
> 
> 
> > > 
> > > Is it possible that you can tell me the properties of your x11 display?
> > > On linux the command is "xdpyinfo", but I do not know if the same command
> > > exists in cygwin.  In particular I want to know if the x11 display uses
> > > 24-bit RGB color or instead uses a color palette with a fixed number of
> > > colors.
> > > 
> > 
> > xdpyinfo
> > does not work in my system.  I do not install full components of the cygwin.
> > 
> > Anyway I ask the way to know "if the x11 display uses
> > 24-bit RGB color or instead uses a color palette with a fixed number of colors."
> > 
> > at the cygwin ML.
> > 
> > Regards
> > 
> > Tatsuro
> >  
> > 
> > 
> > 
> > --------------------------------------
> > Learn more about breast cancer - Pink Ribbon Campaign 2010
> > http://yj.pn/JAy9L7
> > 
> > ------------------------------------------------------------------------------
> > Beautiful is writing same markup. Internet Explorer 9 supports
> > standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> > Spend less time writing and  rewriting code and more time creating great
> > experiences on the web. Be a part of the beta today.
> > http://p.sf.net/sfu/beautyoftheweb
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: pm3d plot is brack for x11 terminal gnuplot

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

Hello

I have confirmed the change fixes the problem.

Thanks!!

Regards

Tatsuro

--- Ethan Merritt  wrote:

> On Thursday 07 October 2010 03:59:39 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Thank you for your reply.
> > 
> > 
> > --- "sfeam (Ethan Merritt)"  wrote:
> > 
> > > I think that change is probably not the source of the problem.
> > > It is more likely this one:
> > > 
> > > 2010-10-05  Ethan A Merritt  <merritt@u.washington.edu>
> > >         * src/getcolor.c (quantize_gray) src/getcolor.h src/gplt_x11.c:
> > >         Continuation of defined palette revamp (2010-10-01). Break out the
> > >         new code into a separate subroutine that can be shared with gnuplot_x11.
> 
> I have made one small change in gplt_x11.c this morning.  It should be in CVS by now.
> I think it will fix your problem, but please confirm.
> 
> 	best regards,
> 
> 		Ethan
> 
> 
> 
> > > 
> > > Is it possible that you can tell me the properties of your x11 display?
> > > On linux the command is "xdpyinfo", but I do not know if the same command
> > > exists in cygwin.  In particular I want to know if the x11 display uses
> > > 24-bit RGB color or instead uses a color palette with a fixed number of
> > > colors.
> > > 
> > 
> > xdpyinfo
> > does not work in my system.  I do not install full components of the cygwin.
> > 
> > Anyway I ask the way to know "if the x11 display uses
> > 24-bit RGB color or instead uses a color palette with a fixed number of colors."
> > 
> > at the cygwin ML.
> > 
> > Regards
> > 
> > Tatsuro
> >  
> > 
> > 
> > 
> > --------------------------------------
> > Learn more about breast cancer - Pink Ribbon Campaign 2010
> > http://yj.pn/JAy9L7
> > 
> > ------------------------------------------------------------------------------
> > Beautiful is writing same markup. Internet Explorer 9 supports
> > standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> > Spend less time writing and  rewriting code and more time creating great
> > experiences on the web. Be a part of the beta today.
> > http://p.sf.net/sfu/beautyoftheweb
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: How to plot a 3D histogram ?

[Richard H. <Ric...@st...>]

On Wed, 2010-10-06 at 14:33 +0200, Le-Berre, Francois wrote:
> Hello,
> 
> I would like to know if it possible to plot a 3D histogram (GNUPLOT
> version 4.2, under windows). 
> 
> My need is the following : i want to plot in Z a signal level per CCD
> pixel, in X the X_pixel index, in Y the y_pixel index of the CCD
> sensor.
> 

did you get any inspiration from this page:

http://www.gnuplot.info/demo/surface1.html

?

richard,
-- 
Scanned by iCritical.

Re: Excessive memory usage with the pdfcairo terminal?

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

On Thursday 07 October 2010 01:07:28 pm Juhász Péter wrote:
> Dear gnuplot developers,
> 
> while doing some work on a large dataset, I've noticed that gnuplot uses
> what could be construed as an excessive amount of memory if the terminal
> is set to pdfcairo. (My machine actually ran out of physical memory and
> began to thrash the swap, that's why I noticed).
> 
> I've done some simple benchmarking with random data (k*1e5 pairs of
> random numbers generated by perl, where k went from 1 to 10; then this
> was plotted by:
> gnuplot -e 'set term pdf;set out "r.pdf";plot "r.txt" w d').
> 
> >From what I can see from the benchmark, the dependence of the memory
> consumption on the dataset size is completely linear - this is expected
> and understandable. What is not expected and hardly understandable is
> the ratio: it needs about 872 bytes per point.

How are you tracking memory usage?

> The pdfcairo terminal also takes a long time: about 27.9 s to plot 1
> million points. (The time dependence is also linear.)

One interesting thing is that less than half of this time is spent
creating the cairo image internally; more of the time is spent
converting it to pdf afterward.

test file bigdata.dat was created by
   for (i=0; i<1000000; i++) printf("%g %g\n",drand48(), drand48());

[1] time gnuplot -e 'set term png; plot "bigdata.dat" using 1:2 with dots' > bigdata.png
0.883u 0.060s 0:01.00 94.0%     0+0k 0+24io 0pf+0w
[2] time gnuplot -e 'set term pngcairo; plot "bigdata.dat" using 1:2 with dots' > bigdata.pngcairo
15.339u 0.044s 0:17.03 90.2%    0+0k 0+384io 0pf+0w
[3] time gnuplot -e 'set term pdfcairo; plot "bigdata.dat" using 1:2 with dots' > bigdata.pdf
37.023u 0.533s 0:38.02 98.7%    0+0k 0+51520io 0pf+0w

The long-standing admonition still holds. Vector formats like PostScript,
PDF, SVG are bad choices for creating a plot with a million points.
A bitmap format like PNG does much better.  "Ah", you say, 
"but I asked cairo to produce a PNG file." Well yes, but that's not the way
cairo works.  First it creates the requested graphic in a standard internal
representation that maintains all the necessary information for vector output.
Then when you are ready to dump it to a file, it converts the internal
representation to the final output representation.
Or at least that's how I understand it.

Time to revisit the idea of a pdflatex terminal?

	Ethan
 
> For comparison, the same data for the postscript terminal: little more
> than 60 bytes per point (which is just what the plot->points array
> needs) and just above one second of execution time for the same 1
> million points.
> 
> Now I haven't delved into the innards of the pdfcairo terminal driver,
> and if you tell me that this is normal and expected, I'll believe you.
> But I can't imagine why it needs over 800 bytes to store a single point.
> 
> A not entirely unrelated question: how do I compile gnuplot with
> profiling? I tried giving CFLAGS="-g -pg" to the configure script, but
> the gmon.out file was not there after running gnuplot.
> 
> Péter Juhász

Re: pm3d plot is brack for x11 terminal gnuplot

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

Hello

Thank you for your reply.


--- "sfeam (Ethan Merritt)"  wrote:

> I think that change is probably not the source of the problem.
> It is more likely this one:
> 
> 2010-10-05  Ethan A Merritt  <merritt@u.washington.edu>
>         * src/getcolor.c (quantize_gray) src/getcolor.h src/gplt_x11.c:
>         Continuation of defined palette revamp (2010-10-01). Break out the
>         new code into a separate subroutine that can be shared with gnuplot_x11.
> 
> Is it possible that you can tell me the properties of your x11 display?
> On linux the command is "xdpyinfo", but I do not know if the same command
> exists in cygwin.  In particular I want to know if the x11 display uses
> 24-bit RGB color or instead uses a color palette with a fixed number of
> colors.
> 

xdpyinfo
does not work in my system.  I do not install full components of the cygwin.

Anyway I ask the way to know "if the x11 display uses
24-bit RGB color or instead uses a color palette with a fixed number of colors."

at the cygwin ML.

Regards

Tatsuro
 



--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7

Re: Excessive memory usage with the pdfcairo terminal?

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

On 07.10.2010 22:07, Juhász Péter wrote:

> Now I haven't delved into the innards of the pdfcairo terminal driver,

... not to mention the innards of the cairo library, and the libraries 
used by that, etc.  This Cairo stuff carries around _way_ more code than 
traditional gnuplot terminal drivers did.

> A not entirely unrelated question: how do I compile gnuplot with
> profiling? I tried giving CFLAGS="-g -pg" to the configure script, but
> the gmon.out file was not there after running gnuplot.

You need to get the -pg into the LDFLAGS, too.  (And profiling without 
the usual -O2 would be a futile exercise...):

	make CFLAGS='-g -O2 -pg' CXXFLAGS='-g -pg'

(Ordinarily, the CFLAGS would be used in the link, too, but we use g++ 
to link, thus the CXXFLAGS).

Excessive memory usage with the pdfcairo terminal?

[Juhász P. <pet...@gm...>]

Dear gnuplot developers,

while doing some work on a large dataset, I've noticed that gnuplot uses
what could be construed as an excessive amount of memory if the terminal
is set to pdfcairo. (My machine actually ran out of physical memory and
began to thrash the swap, that's why I noticed).

I've done some simple benchmarking with random data (k*1e5 pairs of
random numbers generated by perl, where k went from 1 to 10; then this
was plotted by:
gnuplot -e 'set term pdf;set out "r.pdf";plot "r.txt" w d').

>From what I can see from the benchmark, the dependence of the memory
consumption on the dataset size is completely linear - this is expected
and understandable. What is not expected and hardly understandable is
the ratio: it needs about 872 bytes per point.

The pdfcairo terminal also takes a long time: about 27.9 s to plot 1
million points. (The time dependence is also linear.)

For comparison, the same data for the postscript terminal: little more
than 60 bytes per point (which is just what the plot->points array
needs) and just above one second of execution time for the same 1
million points.

Now I haven't delved into the innards of the pdfcairo terminal driver,
and if you tell me that this is normal and expected, I'll believe you.
But I can't imagine why it needs over 800 bytes to store a single point.

A not entirely unrelated question: how do I compile gnuplot with
profiling? I tried giving CFLAGS="-g -pg" to the configure script, but
the gmon.out file was not there after running gnuplot.

Péter Juhász

Re: pm3d plot is brack for x11 terminal gnuplot

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday 07 October 2010, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have built the cvs source(2010-10-06) and found that splot pm3d has given strange results for x11
> terminal on the cygwin.  
> 
> The snanshot is 
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0044
>  x11pm3d_20101006.png, 13,269 bytes, 2010-10-07
> 
> Is the above related below?
> 
> 2010-10-06  Ethan A Merritt  <merritt@u.washington.edu>
> 
> 	* src/color.c src/pm3d.c src/pm3d.h set.c show.c docs/gnuplot.doc:
> 	Simplify the syntax for "set pm3d hidden3d". A linestyle is no longer
> 	required.  If no linestyle is given, the line properties are taken from
> 	the plot command line.
> 	Bug #2997853

I think that change is probably not the source of the problem.
It is more likely this one:

2010-10-05  Ethan A Merritt  <merritt@u.washington.edu>
        * src/getcolor.c (quantize_gray) src/getcolor.h src/gplt_x11.c:
        Continuation of defined palette revamp (2010-10-01). Break out the
        new code into a separate subroutine that can be shared with gnuplot_x11.

Is it possible that you can tell me the properties of your x11 display?
On linux the command is "xdpyinfo", but I do not know if the same command
exists in cygwin.  In particular I want to know if the x11 display uses
24-bit RGB color or instead uses a color palette with a fixed number of
colors.

	thanks,

		Ethan

Re: not_a_number for MinGW build (gcc-4.5.0)

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

Hello

Thank you for your confirming the issue.
Your report reveals the issue genetic to the mingw platform.

Regards

Tatsuro


--- Allin Cottrell wrote:

> On Tue, 5 Oct 2010, Tatsuro MATSUOKA wrote:
> 
> > For current windows binaries,
> > gnuplot> pr NaN
> > 0.0
> >
> > This is not correct.
> 
> I can confirm that this is what I get running current CVS gnuplot
> for Windows on wine (my own build, using cross-mingw on Linux).
> 
> Allin Cottrell
> 


--------------------------------------
Learn more about breast cancer - Pink Ribbon Campaign 2010
http://yj.pn/JAy9L7