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

Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

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

Hello

I have installed wgnuplot to the PC of one of students in my lab.
The OS is windows vista.  I found that old type help file used for wgnuplot is not supported on vista
:-(.  

Do any other persons see the same situation?

Anyway it will be nice help file will move to that of newer style by Microsoft HTML Help Workshop. 

I would like to commit it if possible but it will take a lot of time because my time and knowledge are
limited.

Any comments?

Regards

Tatsuro


--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: fitting functions with more independent variables

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

 Ethan Merritt <merritt@u.washington.edu> writes:
> On Saturday 31 January 2009 17:37:51 James R. Van Zandt wrote:
> > 
> > Currently gnuplot has these data formats for fitting functions with
> > one or two independent variables:
> > 
> >       y
> >       x:y
> >       x:y:s
> >       x:y:z:s
> > 
> > I propose to implement these additional data formats for fitting
> > functions with 3-5 independent variables:
> > 
> >       v:x:y:z:s
> >       u:v:x:y:z:s
> >       t:u:v:x:y:z:s

> I am not familiar with the "fit" subsystem, so I may be missing
> some essential point....
> but the above looks very strange  to me.  Why stick your additional
> dummy variables at the start rather than the end?  Surely it is
> more natural to have
>	   x
>	   x:y
>	   x:y:z
           x:y:z:t
           x:y:z:t:u
>	   x:y:z:t:u:v

Currently, the number of using specs determines the number of
independent variables.  If there are two independent variables, there
must be four using specs - one for each of those independent
variables, one for the dependent variable, and one for the error.

> > Linear regression would look like this:
> > 
> >   h(v,x,y) = a*v + b*x + c*y
> >   fit h(v,x,y) 'foo.dat' using 1:2:3:4:(1) via a,b,c
>
> Wouldn't it be far more natural to say
>     h(x,y,z) = a*x + b*y + c*z
>     fit h(x,y,z) 'foo.dat' using 1:2:3:4 via a,b,c

There are several issues here:

First, you have four specs, which would mean there are two independent
variables.  I would rather not not add some other mechanism to specify
the number of independent variables, so for three independent variables
we need to add a spec for the error.  E.g.:

    fit  <expression>  'foo.dat' using 1:2:3:4:(1) via a,b,c

Next we need to decide what to call the colums.  At present, we are
using Z for the dependent variable, S for the error, and X and Y for
independent variables.  It turns out that each column of data read
from a file must be associated with an axis (that's how the minimum
and maximum values are stored).  So for the rest of the independent
variables I chose the axes with names nearest X.

Third, we need to decide order of the columns read from the data file.
I am assuming the independent variables are first, then the dependent
variable, then the error.

Fourth, how to allocate dummy variable names to the columns.  I chose
alphabetical order.  We could instead say that the first two dummy
variables are always X and Y, and we add others in reverse
alphabetical order:

   x:z
   x:z:s
   x:y:z:s
   x:y:v:z:s
   x:y:v:u:z:s
   x:y:v:u:t:z:s

Or we could start with T and add in alphabetical order:

   x:z:s
   x:y:z:s
   x:y:t:z:s
   x:y:t:u:z:s
   x:y:t:u:v:z:s

I think these would be more awkward.

On the other hand, we could require the user to supply a range spec
with a dummy variable name for each independent variable.  That way he
could use whatever names he likes.  The only rules would be that the
first range spec corresponds to the first using spec, etc., and the
last two using specs would still be for the dependent variable and the
error.  E.g.:

  fit  [lat=*:*] [lon=0:pi] [alt=0:4000] a*sin(lat)+b*cos(lon)+c*alt  \
  'foo.dat' using 1:2:3:4:(1) via a,b,c

The data file might start like this:

  # lat   lon     alt   temp
  2.34    48.86   211   13
  5.37    43.31   820   22
  4.83    45.76   443   8
  1.45    43.62   411   23
  7.27    43.70   331   32
  -1.57   47.23   282   18

I think I would still need to store the min and max values in
axis_array entries.   I could add some extra entries, so I don't
interfere with the current axes.

BTW I'm still debugging.  So far the new code only works with one
independent variable...

         - Jim Van Zandt

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Thursday 05 February 2009 15:47:17 Petr Mikulik wrote:
> > > > Automatic varible
> > > > 	GPVAL_TERM_WINDOWID
> > > > could be filled after each "plot".
> > > > 
> > > > How can this be done? Could x11.trm read it? Or should this be obtained via 
> > > > gp_exec_event?
> > > 
> > > I think that it is best done by gnuplot_x11 at the time the plot window
> > > is first opened.  The information can be sent back to gnuplot proper by
> > > calling gp_exec_event().  
> > > 
> > > I do not know exactly what call into the X libraries would need to be
> > > added in gplt_x11.c, but there must be one.  On the receiving end, it
> > > just needs another case statement in mouse.c (do_event).  That part is
> > > trivial.
> 
> I've put a preliminary version of the patch here:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
> [ 2570385 ] GPVAL_X11_WINDOWID

I will have a look.

> It needs some further work:
> 
> 1. The number 12345 in gplt_x11.c should be replaced by the actual window 
>    id. This is a task for an X11 guru.
> 
> 2. The same for wxt terminal.

I think we should defer work on wxt, since Thimothée is in the process of
making that a separate process.  When he does, the event will come in via
the same pathway as the x11 event.

> 3. New global variable current_x11_windowid should be placed in an .h + .c 
>    file. Which one?

That will probably not work.  There can be multiple x11 windows open at the
same time, so there is no "current" one.  Since you can associate a window
number with each one, however, we might be able to do:
       set term x11 5
       print TERM_X11_WINDOW_5_ID 

> 4. Should it be called GPVAL_TERM_WINDOWID or GPVAL_X11_WINDOWID ? The wxt 
>    terminal can run not only under X11, but e.g. under windows as well. Is 
>    there something like window id?

       TERM_something

> 
> ---
> PM
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> > > Automatic varible
> > > 	GPVAL_TERM_WINDOWID
> > > could be filled after each "plot".
> > > 
> > > How can this be done? Could x11.trm read it? Or should this be obtained via 
> > > gp_exec_event?
> > 
> > I think that it is best done by gnuplot_x11 at the time the plot window
> > is first opened.  The information can be sent back to gnuplot proper by
> > calling gp_exec_event().  
> > 
> > I do not know exactly what call into the X libraries would need to be
> > added in gplt_x11.c, but there must be one.  On the receiving end, it
> > just needs another case statement in mouse.c (do_event).  That part is
> > trivial.

I've put a preliminary version of the patch here:

https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
[ 2570385 ] GPVAL_X11_WINDOWID

It needs some further work:

1. The number 12345 in gplt_x11.c should be replaced by the actual window 
   id. This is a task for an X11 guru.

2. The same for wxt terminal.

3. New global variable current_x11_windowid should be placed in an .h + .c 
   file. Which one?

4. Should it be called GPVAL_TERM_WINDOWID or GPVAL_X11_WINDOWID ? The wxt 
   terminal can run not only under X11, but e.g. under windows as well. Is 
   there something like window id?

---
PM

Re: Can I use the opaque point symbols only in postscript terminal?

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

Hello

--- Ethan Merritt  wrote:

> > The pt 70 is open but also opauque.  It has line a square edge and inside part of the circle
> is
> > painted with white.
> 
> Ah. I am sorry. I understand now.
> I tested by printing to a white background, so I missed this subtlety.
> I have a demo file somewhere that shows how to do this for all terminals.
> I will try to find it and post it tomorrow.

Thanks! I will wait for your post.

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: string function: definition of a function

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

> 
> Message: 1
> Date: Tue, 3 Feb 2009 15:21:30 -0800
> From: Ethan Merritt <merritt@u.washington.edu>
> Subject: Re: string function: definition of a function
> To: Petr Mikulik <mi...@ph...>
> Cc: gnu...@li..., "James R. Van Zandt"
> 	<jr...@co...>
> Message-ID: <200902031521.30590.merritt@u.washington.edu>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On Tuesday 03 February 2009 14:39:43 Petr Mikulik wrote:
> > > Gnuplot's strstrt() function is just a wrapper for the C 
> > library routine strstr().
> > > In C you could do:
> > > >     char *piece = "/some/long/path/name";
> > >     char *end;
> > > >     while (end = strstr( piece, "/" ))
> > >     do    {piece = end+1;}
> > > > Unfortunately, gnuplot doesn't support while/do so I think 
> > you are out of luck.
> >
> > We can add new function strstrtrev("piece", "/") that would 
> > return the last occurence of the substring.
> >
> > Would it be useful to have function for handling file names
> > 	strfileparts('/home/me/bla.dat',n)
> > which would return path (for n=1), name (n=2) and extension (n=3)?
> 
> These sound very specialized.  Why do we need such file-oriented string
> operations, that even the standard C library does not support?

If the desire is to have the ability to parse file names, why not 
implement "dirname" and "basename" equivalents?

Mike Sutton


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

Re: Can I use the opaque point symbols only in postscript terminal?

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

On Wednesday 04 February 2009 16:19:35 Tatsuro MATSUOKA wrote:
> Hello
> 
> > Perhaps you are using a modified postscript terminal?
> No
> 
>  
> > In the standard postscript terminal pt 70-75 are 
> >  open circle
> >  open square
> >  open up-triangle
> >  open down-triangle
> >  open diamond
> >  open pentagon
> 
> The pt 70 is open but also opauque.  It has line a square edge and inside part of the circle is
> painted with white.

Ah. I am sorry. I understand now.
I tested by printing to a white background, so I missed this subtlety.
I have a demo file somewhere that shows how to do this for all terminals.
I will try to find it and post it tomorrow.

	regards,

		Ethan



> 
> In the ps_symbols.ps, we can find #70-75 are opaque.
> 
> Please see 
> http://www.geocities.jp/tmgpltwin/Files/Files.html
> 
> 0013 sin64.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 64
> 0014 sin70.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 70
> 
> The differece is pt 64 is transparent squqre but pt 70 is not trasparent within the edge.
> Please see points near peaks.  The difference is clear.
> 
> I would like to use symbol black edge with with inside not being transparent like pt 70-75.
> 
> Perhaps such symbols exist in postscript terminal as far as I know.
> 
> Am I correct ?
> 
> Regards
> 
> Tatsuro
> 
> 
> 
> 
> 
> 
> 
>     
> 
> > The standard postscript terminal has opaque point symbols at
> > pt 5	solid square
> > pt 7	solid circle
> > pt 9	solid up-triangle
> > pt 11	solid down-triangle
> > pt 13	solid diamond
> > pt 15	solid pentagon
> > 
> > > My question is that I can use the opaque point symbols only in postscript terminal.
> > 
> > pt 5 7 9 11 13 are shared by most terminal types, including post, emf, cgm, and png. 
> > 
> > 
> > > When I used the origin, the open symbols were opaque.
> > > I would like to use it in the gnuplot.
> > > 
> > > If the opaque point symbols can be used in only post term, I will use 'pstoedit' and convert
> > to emf
> > > files.
> > > 
> > > Anyway I would like only to confirm my recognition.
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center
> > University of Washington, Seattle 98195-7742
> > 
> 
> 
> --------------------------------------
> Yahoo! JAPAN - Internet safety for children and parents.
> http://pr.mail.yahoo.co.jp/security/
> 



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

Re: Can I use the opaque point symbols only in postscript terminal?

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

Sorry I have forgotten to express appreciation to Ethan.
Thanks!

Tatsuro

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> > Perhaps you are using a modified postscript terminal?
> No
> 
>  
> > In the standard postscript terminal pt 70-75 are 
> >  open circle
> >  open square
> >  open up-triangle
> >  open down-triangle
> >  open diamond
> >  open pentagon
> 
> The pt 70 is open but also opauque.  It has line a square edge and inside part of the circle is
> painted with white.
> 
> In the ps_symbols.ps, we can find #70-75 are opaque.
> 
> Please see 
> http://www.geocities.jp/tmgpltwin/Files/Files.html
> 
> 0013 sin64.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 64
> 0014 sin70.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 70
> 
> The differece is pt 64 is transparent squqre but pt 70 is not trasparent within the edge.
> Please see points near peaks.  The difference is clear.
> 
> I would like to use symbol black edge with with inside not being transparent like pt 70-75.
> 
> Perhaps such symbols exist in postscript terminal as far as I know.
> 
> Am I correct ?
> 
> Regards
> 
> Tatsuro
> 
> 
> 
> 
> 
> 
> 
>     
> 
> > The standard postscript terminal has opaque point symbols at
> > pt 5	solid square
> > pt 7	solid circle
> > pt 9	solid up-triangle
> > pt 11	solid down-triangle
> > pt 13	solid diamond
> > pt 15	solid pentagon
> > 
> > > My question is that I can use the opaque point symbols only in postscript terminal.
> > 
> > pt 5 7 9 11 13 are shared by most terminal types, including post, emf, cgm, and png. 
> > 
> > 
> > > When I used the origin, the open symbols were opaque.
> > > I would like to use it in the gnuplot.
> > > 
> > > If the opaque point symbols can be used in only post term, I will use 'pstoedit' and convert
> > to emf
> > > files.
> > > 
> > > Anyway I would like only to confirm my recognition.
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center
> > University of Washington, Seattle 98195-7742
> > 
> 
> 
> --------------------------------------
> Yahoo! JAPAN - Internet safety for children and parents.
> http://pr.mail.yahoo.co.jp/security/
> 


--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: Can I use the opaque point symbols only in postscript terminal?

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

Hello

> Perhaps you are using a modified postscript terminal?
No

 
> In the standard postscript terminal pt 70-75 are 
>  open circle
>  open square
>  open up-triangle
>  open down-triangle
>  open diamond
>  open pentagon

The pt 70 is open but also opauque.  It has line a square edge and inside part of the circle is
painted with white.

In the ps_symbols.ps, we can find #70-75 are opaque.

Please see 
http://www.geocities.jp/tmgpltwin/Files/Files.html

0013 sin64.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 64
0014 sin70.eps.png set term post eps; set out 'sin64.eps; plot sin(x) w p ps 2 pt 70

The differece is pt 64 is transparent squqre but pt 70 is not trasparent within the edge.
Please see points near peaks.  The difference is clear.

I would like to use symbol black edge with with inside not being transparent like pt 70-75.

Perhaps such symbols exist in postscript terminal as far as I know.

Am I correct ?

Regards

Tatsuro







    

> The standard postscript terminal has opaque point symbols at
> pt 5	solid square
> pt 7	solid circle
> pt 9	solid up-triangle
> pt 11	solid down-triangle
> pt 13	solid diamond
> pt 15	solid pentagon
> 
> > My question is that I can use the opaque point symbols only in postscript terminal.
> 
> pt 5 7 9 11 13 are shared by most terminal types, including post, emf, cgm, and png. 
> 
> 
> > When I used the origin, the open symbols were opaque.
> > I would like to use it in the gnuplot.
> > 
> > If the opaque point symbols can be used in only post term, I will use 'pstoedit' and convert
> to emf
> > files.
> > 
> > Anyway I would like only to confirm my recognition.
> > 
> > Regards
> > 
> > Tatsuro
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: [manual] suggested addition to pcolor description

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

> | Using "interpolate 0,0" the result renders very rapidly.
> | 
> | Petr, Thanks for pointing out my err, the result looks very good to  
> | me. The corrected changeset is attached ... attributed to you of  
> | course ;-)
> 
> I applied it.

I have also applied the gnuplot patch to its cvs. So "interp shading" should 
work nicely.

---
Petr Mikulik

Re: Can I use the opaque point symbols only in postscript terminal?

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

On Wednesday 04 February 2009, Tatsuro MATSUOKA wrote:
> Hello
> 
> The postscirpt terminal has the six opaque point symbols from pt 70-75.

Perhaps you are using a modified postscript terminal?

In the standard postscript terminal pt 70-75 are 
 open circle
 open square
 open up-triangle
 open down-triangle
 open diamond
 open pentagon


The standard postscript terminal has opaque point symbols at
pt 5	solid square
pt 7	solid circle
pt 9	solid up-triangle
pt 11	solid down-triangle
pt 13	solid diamond
pt 15	solid pentagon

> My question is that I can use the opaque point symbols only in postscript terminal.

pt 5 7 9 11 13 are shared by most terminal types, including post, emf, cgm, and png. 


> When I used the origin, the open symbols were opaque.
> I would like to use it in the gnuplot.
> 
> If the opaque point symbols can be used in only post term, I will use 'pstoedit' and convert to emf
> files.
> 
> Anyway I would like only to confirm my recognition.
> 
> Regards
> 
> Tatsuro

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

Re: [manual] suggested addition to pcolor description

[Ben A. <bpa...@ma...>]

On Feb 4, 2009, at 4:03 AM, Petr Mikulik wrote:

>>> Yes, please try to patch both gnuplot and Octave and tell me  
>>> whether it
>>> gives the desired image.
>>>
>>> Note that
>>>  set pm3d interpolate 0,0
>>> can always be issued by Octave because current versions of gnuplot
>>> silently ignore non-positive numbers.
>>
>> Ok, I've made a local change to __go_draw_axes__.m and produce some  
>> images
>> with both Octave+Gnuplot as well as Matlab.
>>
>> Those interested can see them at the link below.
>>
>> 	http://www.picturehosting.com/gallery.php?u=bpabbott&g=pm3d
>>
>> Those who would like to exercise this functionality will need to  
>> apply Petr's
>> patch to the developer's sources for gnuplot, and apply the  
>> attached changeset
>> to the developers sources for Octave.
>
> The patch should be:
>    if (doing_interp_color)
>      interp_str = "interpolate 0,0";
>    else
>
> If you find this resolution being (very) different from Matlab, then  
> use
>      interp_str = "interpolate -300,-300";
> or some other negative numbers. Currently the default "0,0" is  
> equivalent to
> "-200,-200".

opps ... I should have been more thorough with my testing. I've  
updated the figures at the link to include those produced with (0,0)

	http://www.picturehosting.com/gallery.php?u=bpabbott&g=pm3d

>> 	surf(peaks)
>> 	colormap(jet(200))
>> 	shading interp
>>
>> After  an unpleasant delay a nice image was produced. Checking my  
>> Mac OSX
>> activity monitor it appears that gnuplot requires 750MB of real  
>> memory and
>> 2.5GB of virtual memory to produce this image. It is due to the  
>> excessive
>> time and memory requiried that I decided to limit the levels of  
>> interpolation
>> that occur across a particular quadrangle.
>
> I don't wonder if the current changeset produced something like
> 	interpolate 90,90
> i.e. drawing image with (200*90)^2 = 18000^2 points.

Using "interpolate 0,0" the result renders very rapidly.

Petr, Thanks for pointing out my err, the result looks very good to  
me. The corrected changeset is attached ... attributed to you of  
course ;-)

I don't have a copy of an old gnuplot available. Petr are your running  
Octave built from the developer's sources? If so, can you verify that  
this change does not break anything?

Ben

Re: string function: definition of a function

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

> > > Would an automatic variable GPVAL_PWD be the only chance for a portable 
> > > solution?
> > 
> > I have added it.
> 
> 2009-02-03  Petr Mikulik  <mi...@ph...>
> 
>         * src/eval.c (update_gpval_variables) src/command.c (changedir_command)
>         New automatic variable GPVAL_PWD for current working directory.
>                                      ^^^     ^       ^       ^
> 
> Wouldn't that better be GPVAL_cwd or GPVAL_CWD?

I hesitated as well, but then I tried bash:

set | grep -i pwd

where I can see variables
	PWD
	OLDPWD
	MC_PWD
	MC_PWD_FILE
and thus I have decided for GPVAL_PWD as well.

---
PM

Re: [manual] suggested addition to pcolor description

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

> >Yes, please try to patch both gnuplot and Octave and tell me whether it
> >gives the desired image.
> >
> >Note that
> >   set pm3d interpolate 0,0
> >can always be issued by Octave because current versions of gnuplot
> >silently ignore non-positive numbers.
> 
> Ok, I've made a local change to __go_draw_axes__.m and produce some images
> with both Octave+Gnuplot as well as Matlab.
> 
> Those interested can see them at the link below.
> 
> 	http://www.picturehosting.com/gallery.php?u=bpabbott&g=pm3d
> 
> Those who would like to exercise this functionality will need to apply Petr's
> patch to the developer's sources for gnuplot, and apply the attached changeset
> to the developers sources for Octave.

The patch should be:
    if (doing_interp_color)
      interp_str = "interpolate 0,0";
    else

If you find this resolution being (very) different from Matlab, then use
      interp_str = "interpolate -300,-300"; 
or some other negative numbers. Currently the default "0,0" is equivalent to 
"-200,-200".

> 	surf(peaks)
> 	colormap(jet(200))
> 	shading interp
> 
> After  an unpleasant delay a nice image was produced. Checking my Mac OSX
> activity monitor it appears that gnuplot requires 750MB of real memory and
> 2.5GB of virtual memory to produce this image. It is due to the excessive
> time and memory requiried that I decided to limit the levels of interpolation
> that occur across a particular quadrangle.

I don't wonder if the current changeset produced something like
	interpolate 90,90
i.e. drawing image with (200*90)^2 = 18000^2 points.

---
Petr Mikulik

Can I use the opaque point symbols only in postscript terminal?

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

Hello

The postscirpt terminal has the six opaque point symbols from pt 70-75.

My question is that I can use the opaque point symbols only in postscript terminal.

When I used the origin, the open symbols were opaque.
I would like to use it in the gnuplot.

If the opaque point symbols can be used in only post term, I will use 'pstoedit' and convert to emf
files.

Anyway I would like only to confirm my recognition.

Regards

Tatsuro
 



--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: [manual] suggested addition to pcolor description

[Ben A. <bpa...@ma...>]

On Feb 3, 2009, at 7:25 AM, Petr Mikulik wrote:

>>>>> pcolor([1 2; 3 3])
>>>>> shading interp
>>>>> shading flat
>>>>>
>>>>> Therefore, I've written the following patch:
>>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2558565&group_id=2055&atid=302055
>>>>> [ 2558565 ] pm3d interpolate 0,0
>>>>> The animated demo there shows color surface transformations;  
>>>>> Octave would
>>>>> use for its "shading interp" the option
>>>>> set pm3d interpolate 0,0
>>>>
>>>> I think the attached files look good ... but can you describe  
>>>> what has been
>>>> changed.  The results (in your email) look very similar to what  
>>>> the current
>>>> gnuplot sources produce.
>>>
>>> It is desired to achieve higher resolution plot with an  
>>> alternative "pm3d
>>> interpolate" option. Let us suppose that "continuous" colour  
>>> gradient on the
>>> map/surface would need edge size of at least 200 pixels on screen  
>>> window.
>>> Then
>>> a=hilb(4);
>>> pcolor(a);
>>> would need
>>> 	set pm3d interpolate 50,50
>>> while
>>> a=hilb(100);
>>> pcolor(a);
>>> would need
>>> set pm3d interpolate 2,2
>>>
>>> With the new patch, you can set
>>> 	set pm3d interpolate -200,-200
>>> and gnuplot will ensure at least 200 points in both cases, i.e.  
>>> Octave
>>> passes the sampling to the drawing backend.
>>>
>>> Currently,
>>> 	set pm3d interpolate 0,0
>>> is equivalent to 200 points.
>>
>> Ok, thanks for explaining.
>>
>> I'll patch my gnuplot sources and work on a patch for Octave.
>>
>> Are you looking for some of us to test drive your gnuplot patch, as  
>> well?
>
> Yes, please try to patch both gnuplot and Octave and tell me whether  
> it
> gives the desired image.
>
> Note that
>    set pm3d interpolate 0,0
> can always be issued by Octave because current versions of gnuplot
> silently ignore non-positive numbers.
>
> ---
> PM

Ok, I've made a local change to __go_draw_axes__.m and produce some  
images with both Octave+Gnuplot as well as Matlab.

Those interested can see them at the link below.

	http://www.picturehosting.com/gallery.php?u=bpabbott&g=pm3d

Those who would like to exercise this functionality will need to apply  
Petr's patch to the developer's sources for gnuplot, and apply the  
attached changeset to the developers sources for Octave.

Notice that I've attempted to modulate the levels of interpolation to  
correspond to the levels in the colormap.

Petr, can you comment on my changeset. Specifically, it is not clear  
to me if this would not work without out your patch.

I tried the following example as well

	surf(peaks)
	colormap(jet(200))
	shading interp

After  an unpleasant delay a nice image was produced. Checking my Mac  
OSX activity monitor it appears that gnuplot requires 750MB of real  
memory and 2.5GB of virtual memory to produce this image.  It is due  
to the excessive time and memory requiried that I decided to limit the  
levels of interpolation that occur across a particular quadrangle.

Ben

Re: string function: definition of a function

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

On Tuesday 03 February 2009 14:39:43 Petr Mikulik wrote:
> 
> > Would an automatic variable GPVAL_PWD be the only chance for a portable 
> > solution?
> 
> I have added it.

2009-02-03  Petr Mikulik  <mi...@ph...>

        * src/eval.c (update_gpval_variables) src/command.c (changedir_command)
        New automatic variable GPVAL_PWD for current working directory.
                                     ^^^     ^       ^       ^

Wouldn't that better be GPVAL_cwd or GPVAL_CWD?


-- 
Ethan A Merritt

Re: string function: definition of a function

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

On Tuesday 03 February 2009 14:39:43 Petr Mikulik wrote:
> > Gnuplot's strstrt() function is just a wrapper for the C library routine strstr().
> > In C you could do:
> > 
> >     char *piece = "/some/long/path/name";
> >     char *end;
> > 
> >     while (end = strstr( piece, "/" ))
> >     do    {piece = end+1;}
> > 
> > Unfortunately, gnuplot doesn't support while/do so I think you are out of luck.
> 
> We can add new function strstrtrev("piece", "/") that would return the last 
> occurence of the substring.
> 
> Would it be useful to have function for handling file names
> 	strfileparts('/home/me/bla.dat',n)
> which would return path (for n=1), name (n=2) and extension (n=3)?

These sound very specialized.  Why do we need such file-oriented string
operations, that even the standard C library does not support?

I think I'd rather go ahead and add support for a 'while' statement.
It would be limited to a single line, just as the current 'if' statement,
but it should be possible to do. 

> That would be quite handy especially in the "plot for" loop.

Could you give an example showing why this would be useful?

-- 
Ethan A Merritt

Re: string function: definition of a function

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

> Gnuplot's strstrt() function is just a wrapper for the C library routine strstr().
> In C you could do:
> 
>     char *piece = "/some/long/path/name";
>     char *end;
> 
>     while (end = strstr( piece, "/" ))
>     do    {piece = end+1;}
> 
> Unfortunately, gnuplot doesn't support while/do so I think you are out of luck.

We can add new function strstrtrev("piece", "/") that would return the last 
occurence of the substring.

Would it be useful to have function for handling file names
	strfileparts('/home/me/bla.dat',n)
which would return path (for n=1), name (n=2) and extension (n=3)?
That would be quite handy especially in the "plot for" loop.

> Would an automatic variable GPVAL_PWD be the only chance for a portable 
> solution?

I have added it.

---
PM

Re: Qt terminal

[Nigel N. <nn...@gm...>]

On 2/3/09, Ethan A Merritt <merritt@u.washington.edu> wrote:


> I haven't tried this new driver yet, but if I understood the earlier
> description correctly, it probably suffers from exactly the same
> problem as wxt on Mac.  The event loop is in a thread,
> and OSX does not like that.  But we'll see.



Sorry for not getting around to submitting our wx alternative.
By building gnuplot as a library and exposing two functions,

  int init_gnuplot(int bInteract);
  int lib_do_line(const char *gp_cmd);

we can plug gnuplot into any application. If we just want ps or
pdf results, we pass lines to gnuplot by calling lib_do_line(...);

  lib_do_line("set term post");
  lib_do_line("set grid");
  lib_do_line("plot 'results.dat' with lines");

A current project uses a wxPanel as a rendering canvas, and a
modified wxTextBox for a gui command line.  Essentially HBB's
win.trm adjusted for wx. Simple, robust, and no threads.

Nigel

Re: Qt terminal

[Jérôme L. <jer...@al...>]

Le mardi 3 février 2009, Ethan A Merritt a écrit :
> I haven't tried this new driver yet, but if I understood the earlier
> description correctly, it probably suffers from exactly the same
> problem as wxt on Mac.  The event loop is in a thread,
> and OSX does not like that.  But we'll see.

You are most probably right. However, this thread business was just a 
quick and dirty way to have the terminal working. Internally, all 
comunications between gnuplot core and the terminal itself are event 
based, so forking and using an IPC should be easy to implement.

Jérôme

Re: Qt terminal

[Jérôme L. <jer...@al...>]

Philipp K. Janert a écrit :
> What would make this really, really cool is if it
> could truly leverage Qt's cross-platform capabilities,
> such that it would become easier to build and install
> gnuplot on Win and the Mac. 

I think it should be rather straightforward to port the terminal on any 
platform supported by Qt.

> By the same token, if it does NOT offer this
> cross-platform capability, then I need to understand
> better what this patch does that wxt is not doing
> already. Could you speak to that?

I seems to me that wxt is also aiming at cross-platform capability...

Here are a few arguments in favor of developing this terminal:
- The more terminals, the better. A new terminal adds opportunities but 
doesn't harm, so in any case, it is worth considering.
- As it is using Qt, it looks more at home in Qt based environments, 
such as KDE. It also introduces no memory overhead if Qt libraries are 
already in use.
- I chose a modular design for this terminal, the aim being to be able 
to embed a plotting widget in any Qt application, as the x11 terminal is 
able to embed the plotting area in existing x11 windows.
- The plot rendering is done using the Qt GraphicsScene framework that 
registers each graph element as independent items, which means that 
advanced user interaction (e.g. modifying a label directly on he plot, 
moving a line...) can be envisioned.

Jérôme

Re: [manual] suggested addition to pcolor description

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

> > > >pcolor([1 2; 3 3])
> > > >shading interp
> > > >shading flat
> > > >
> > > >Therefore, I've written the following patch:
> > > >https://sourceforge.net/tracker/index.php?func=detail&aid=2558565&group_id=2055&atid=302055
> > > >[ 2558565 ] pm3d interpolate 0,0
> > > >The animated demo there shows color surface transformations; Octave would
> > > >use for its "shading interp" the option
> > > > set pm3d interpolate 0,0
> > >
> > >I think the attached files look good ... but can you describe what has been
> > >changed.  The results (in your email) look very similar to what the current
> > >gnuplot sources produce.
> >
> >It is desired to achieve higher resolution plot with an alternative "pm3d
> >interpolate" option. Let us suppose that "continuous" colour gradient on the
> >map/surface would need edge size of at least 200 pixels on screen window.
> >Then
> > a=hilb(4);
> > pcolor(a);
> >would need
> >	set pm3d interpolate 50,50
> >while
> > a=hilb(100);
> > pcolor(a);
> >would need
> > set pm3d interpolate 2,2
> >
> >With the new patch, you can set
> >	set pm3d interpolate -200,-200
> >and gnuplot will ensure at least 200 points in both cases, i.e. Octave
> >passes the sampling to the drawing backend.
> >
> >Currently,
> >	set pm3d interpolate 0,0
> >is equivalent to 200 points.
> 
> Ok, thanks for explaining.
> 
> I'll patch my gnuplot sources and work on a patch for Octave.
> 
> Are you looking for some of us to test drive your gnuplot patch, as well?

Yes, please try to patch both gnuplot and Octave and tell me whether it 
gives the desired image.

Note that
    set pm3d interpolate 0,0
can always be issued by Octave because current versions of gnuplot 
silently ignore non-positive numbers.

---
PM

Re: [manual] suggested addition to pcolor description

[Ben A. <bpa...@ma...>]

On Feb 3, 2009, at 3:32 AM, Petr Mikulik wrote:

>>> Gnuplot does interpolation in pm3d by splitting each quadrangle  
>>> into smaller
>>> quadrangles. You can try the following example that demonstrates
>>> "shading flat" and "shading interp":
>>>
>>> pcolor([1 2; 3 3])
>>> shading interp
>>> shading flat
>>>
>>> Therefore, I've written the following patch:
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2558565&group_id=2055&atid=302055
>>> [ 2558565 ] pm3d interpolate 0,0
>>> The animated demo there shows color surface transformations;  
>>> Octave would
>>> use for its "shading interp" the option
>>> 	set pm3d interpolate 0,0
>>
>> I think the attached files look good ... but can you describe what  
>> has been
>> changed.  The results (in your email) look very similar to what the  
>> current
>> gnuplot sources produce.
>
> It is desired to achieve higher resolution plot with an alternative  
> "pm3d
> interpolate" option. Let us suppose that "continuous" colour  
> gradient on the
> map/surface would need edge size of at least 200 pixels on screen  
> window.
> Then
> 	a=hilb(4);
> 	pcolor(a);
> would need
> 	set pm3d interpolate 50,50
> while
> 	a=hilb(100);
> 	pcolor(a);
> would need
> 	set pm3d interpolate 2,2
>
> With the new patch, you can set
> 	set pm3d interpolate -200,-200
> and gnuplot will ensure at least 200 points in both cases, i.e. Octave
> passes the sampling to the drawing backend.
>
> Currently,
> 	set pm3d interpolate 0,0
> is equivalent to 200 points.

Ok, thanks for explaining.

  I'll patch my gnuplot sources and work on a patch for Octave.

Are you looking for some of us to test drive your gnuplot patch, as  
well?

Ben

Re: [manual] suggested addition to pcolor description

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

> >Gnuplot does interpolation in pm3d by splitting each quadrangle into smaller
> >quadrangles. You can try the following example that demonstrates
> >"shading flat" and "shading interp":
> >
> >pcolor([1 2; 3 3])
> >shading interp
> >shading flat
> >
> >Therefore, I've written the following patch:
> >https://sourceforge.net/tracker/index.php?func=detail&aid=2558565&group_id=2055&atid=302055
> >[ 2558565 ] pm3d interpolate 0,0
> >The animated demo there shows color surface transformations; Octave would
> >use for its "shading interp" the option
> >	set pm3d interpolate 0,0
> 
> I think the attached files look good ... but can you describe what has been
> changed.  The results (in your email) look very similar to what the current
> gnuplot sources produce.

It is desired to achieve higher resolution plot with an alternative "pm3d 
interpolate" option. Let us suppose that "continuous" colour gradient on the 
map/surface would need edge size of at least 200 pixels on screen window. 
Then
	a=hilb(4);
	pcolor(a);
would need
	set pm3d interpolate 50,50
while
	a=hilb(100);
	pcolor(a);
would need
	set pm3d interpolate 2,2

With the new patch, you can set
	set pm3d interpolate -200,-200
and gnuplot will ensure at least 200 points in both cases, i.e. Octave 
passes the sampling to the drawing backend.

Currently,
	set pm3d interpolate 0,0
is equivalent to 200 points.

---
Petr Mikulik