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

Re: string function: definition of a function

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

> > > The "pwd" command from the shell is needed in any case. It is only a matter
> > > of whether it is called directly or called via the internal routine pwd_command().
> > > I would do
> > >	a = system("pwd")
> > 
> > gnuplot> a=system("pwd")
> > 		 warning: system evaluation not supported by MS-Windows 32 bit
> 
> > gnuplot> pwd
> > C:\Program Files\gnuplot\bin
> > gnuplot>
> > 
> > So there is a need for something portable, and it's not system("pwd").
> 
> Huh. I did not know that.  
> So the windows code does not support the system() command?

Well, this depends on executable:
  wgnuplot.exe does not support pipes and system() and !command
  wgnuplot_pipes.exe supports them (but keeps an attached console window)

---
PM

Re: bug in GPFUN_ - Re: executable files of gnuplot generated from current cvs source trees are unstable

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

Hello

Thanks!! I have confirmed the fix. 

Regards

Tatsuro

--- Ethan A Merritt  wrote:

> On Sunday 01 February 2009, Petr Mikulik wrote:
> > > I have built windows binaries (bu mingw gcc-4.3.0-dw2-TDM), cygwin and djgpp.
> > > The exe files are unstable for all platforms.
> > 
> > The same for Linux and prob.dem, random.dem. It seems to be caused by the 
> > latest addition of GPFUN_*:
> 
> Yes. Fixed now.
> 
> -- 
> Ethan A Merritt
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

Re: Qt terminal

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

On Monday 02 February 2009, Philipp K. Janert wrote:
> 
> I think this is welcome! Thanks, Jerome!
> 
> I have not looked at the code for this patch, but 
> I have programmed Qt before, and I can say that it:
> - works really well
> - is incredibly well documented
> - has a very large set of useful widgets (although
> 	this does not do much for gnuplot right now).
> 
> 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. 
> 
> 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 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.  

	Ethan

> 
> Best,
> 
> 		Ph.
> 
> 
> On Monday 02 February 2009 12:28:26 pm Jérôme Lodewyck wrote:
> > Le lundi 2 février 2009, Ethan A Merritt a écrit :
> > > On Sunday 01 February 2009, Jérôme Lodewyck wrote:
> > > > Hi,
> > > >
> > > > 	I have written a Qt terminal for Gnuplot. My main motivation for doing
> > > > this is that Qt is going to be released under the LGPL, and I far as I
> > > > understood, this license is compatible with Gnuplot.
> > > > 	The terminal is mostly inspired from the wxWidgets terminal (thanks
> > > > Timothée for your hard work !). It is not yet optimized and there are
> > > > still some glitches here and there, but it is mostly feature complete.
> > > > 	If it is of interest for someone, I will be happy to propose a patch.
> > >
> > > Sure, go ahead and post a patch.
> > > It is hard to tell much about how it works by looking only at
> > > screenshots.
> >
> > Ok, the patch is submitted
> >
> > > Please describe more precisely what libraries or environment thie new
> > > terminal would require.
> > > Does it use the KDE libraries, or just Qt?
> > > If one built gnuplot with only the driver, would it be run on, say,
> > > the OpenMoko mobile phone platform?
> > > What about non-linux Qt platforms?
> >
> > It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my
> > experience, Qt applications usually work out of the box on any platform
> > supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE).
> > Only one pat of the terminal makes use of non-Qt functions: the Qt main
> > loop is implemented inside a pthread, which is a problem because
> > 1/ It doesn't work on non-UNIX platforms, but from what I understood from
> > the wx terminal, Windows support would only imply putting #ifdef's around
> > the pthread functions
> > 2/ Qt does not officially support running the main event loop inside a
> > thread; however, I did not experience any problem with this (except that Qt
> > functions should be used with care in the gnuplot thread)
> >
> > Jérôme
> >
> > > 	Ethan
> > >
> > > > Screenshots:
> > > >
> > > > http://lodewyck.free.fr/gp1.png
> > > > http://lodewyck.free.fr/gp2.png
> > > > http://lodewyck.free.fr/gp3.png
> > > >
> > > > Regards,
> > > >
> > > > Jérôme
> > > >
> > > > -----------------------------------------------------------------------
> > > >-- ----- This SF.net email is sponsored by:
> > > > SourcForge Community
> > > > SourceForge wants to tell your story.
> > > > http://p.sf.net/sfu/sf-spreadtheword
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> > ---------------------------------------------------------------------------
> >--- This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> 
> ------------------------------------------------------------------------------
> 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: Qt terminal

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

I think this is welcome! Thanks, Jerome!

I have not looked at the code for this patch, but 
I have programmed Qt before, and I can say that it:
- works really well
- is incredibly well documented
- has a very large set of useful widgets (although
	this does not do much for gnuplot right now).

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. 

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?

Best,

		Ph.


On Monday 02 February 2009 12:28:26 pm Jérôme Lodewyck wrote:
> Le lundi 2 février 2009, Ethan A Merritt a écrit :
> > On Sunday 01 February 2009, Jérôme Lodewyck wrote:
> > > Hi,
> > >
> > > 	I have written a Qt terminal for Gnuplot. My main motivation for doing
> > > this is that Qt is going to be released under the LGPL, and I far as I
> > > understood, this license is compatible with Gnuplot.
> > > 	The terminal is mostly inspired from the wxWidgets terminal (thanks
> > > Timothée for your hard work !). It is not yet optimized and there are
> > > still some glitches here and there, but it is mostly feature complete.
> > > 	If it is of interest for someone, I will be happy to propose a patch.
> >
> > Sure, go ahead and post a patch.
> > It is hard to tell much about how it works by looking only at
> > screenshots.
>
> Ok, the patch is submitted
>
> > Please describe more precisely what libraries or environment thie new
> > terminal would require.
> > Does it use the KDE libraries, or just Qt?
> > If one built gnuplot with only the driver, would it be run on, say,
> > the OpenMoko mobile phone platform?
> > What about non-linux Qt platforms?
>
> It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my
> experience, Qt applications usually work out of the box on any platform
> supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE).
> Only one pat of the terminal makes use of non-Qt functions: the Qt main
> loop is implemented inside a pthread, which is a problem because
> 1/ It doesn't work on non-UNIX platforms, but from what I understood from
> the wx terminal, Windows support would only imply putting #ifdef's around
> the pthread functions
> 2/ Qt does not officially support running the main event loop inside a
> thread; however, I did not experience any problem with this (except that Qt
> functions should be used with care in the gnuplot thread)
>
> Jérôme
>
> > 	Ethan
> >
> > > Screenshots:
> > >
> > > http://lodewyck.free.fr/gp1.png
> > > http://lodewyck.free.fr/gp2.png
> > > http://lodewyck.free.fr/gp3.png
> > >
> > > Regards,
> > >
> > > Jérôme
> > >
> > > -----------------------------------------------------------------------
> > >-- ----- This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: string function: definition of a function

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

On Monday 02 February 2009 16:50:55 Tait wrote:
> > > Further I have noticed `pwd` command from shell is needed to set a variable
> > > for the current working directory because
> > >	gnuplot> pwd
> > > just prints it to screen, but I cannot do
> > >	a=pwd
> > > or	a=eval pwd
> >
> > The "pwd" command from the shell is needed in any case. It is only a matter
> > of whether it is called directly or called via the internal routine pwd_command().
> > I would do
> >	a = system("pwd")
> 
> gnuplot> a=system("pwd")
> 		 warning: system evaluation not supported by MS-Windows 32 bit

> gnuplot> pwd
> C:\Program Files\gnuplot\bin
> gnuplot>
> 
> So there is a need for something portable, and it's not system("pwd").

Huh. I did not know that.  
So the windows code does not support the system() command?
Can that be fixed?
It seems to me that's a more serious issue than the details
of how best to query the current working directory.

> > I don't know.  I don't think that the concept of "current working directory"
> > is universally portable even apart from how you would issue the command.
> > In VMS, for example, the current directory name and the current disk are
> > separate things. Just asking for the current directory would not tell you
> > what disk you would be writing to.
> 
> In Windows, the drive is given as part of pwd, so it would make sense,
> I think, to emulate the same behavior in VMS and return the full path,
> diskname$foo:[path.to.dir]. 

I can see that the configuration tool does set HAVE_GETCWD for VMS, but
I don't currently have a VMS system to check on what exactly it returns.

-- 
Ethan A Merritt

Re: string function: definition of a function

[Tait <gnu...@t4...>]

> > Further I have noticed `pwd` command from shell is needed to set a variable
> > for the current working directory because
> >	gnuplot> pwd
> > just prints it to screen, but I cannot do
> >	a=pwd
> > or	a=eval pwd
>
> The "pwd" command from the shell is needed in any case. It is only a matter
> of whether it is called directly or called via the internal routine pwd_command().
> I would do
>	a = system("pwd")

gnuplot> a=system("pwd")
		 warning: system evaluation not supported by MS-Windows 32 bit
gnuplot> pwd
C:\Program Files\gnuplot\bin
gnuplot>

So there is a need for something portable, and it's not system("pwd").

> I don't know.  I don't think that the concept of "current working directory"
> is universally portable even apart from how you would issue the command.
> In VMS, for example, the current directory name and the current disk are
> separate things. Just asking for the current directory would not tell you
> what disk you would be writing to.

In Windows, the drive is given as part of pwd, so it would make sense,
I think, to emulate the same behavior in VMS and return the full path,
diskname$foo:[path.to.dir]. 

Tait

Re: [manual] suggested addition to pcolor description

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

On Feb 2, 2009, at 6:06 PM, Petr Mikulik wrote:

>>>> | On caveat is that gnuplot's method of interpolation is different
>>>> | than that of Matlab's. As Francesco points out the commercial
>>>> | variant splits rectangles into a pair of triangles and performs a
>>>> | linear interpolation of the color across the triangle. Although  
>>>> I do
>>>> | not know what algorithm is used, gnuplot does not work the same  
>>>> way.
>>>>
>>>> Is this something that Octave should do, rather than relying on
>>>> gnuplot?  If so, where does this code belong?  Maybe we should  
>>>> provide
>>>> a function (accessible from C++ and the scripting language?) that  
>>>> does
>>>> the interpolation, so that all backends can do things consistently.
>>>
>>> In 2007, I noticed that even matlab behaves differently depending on
>>> platform (linux, windows) and renderer (OpenGL, ...) when plotting
>>> polygons. But I have not verified if its still true. Also, OpenGL  
>>> does
>>> this interpolation with hardware acceleration, so we would waste a  
>>> lot
>>> of graphic performance in this case.
>>
>> I studied the situation more closely and noticed that gnuplot  
>> appears (to me)
>> to interpolate colors by increasing the density of the facets by  
>> four. The
>> color of facets appear to snap to the nearest color in the colormap.
>>
>> If anyone is running a copy of gnuplot with the patch for  
>> interpolating color
>> as a 4th dimension, you can examine this by
>>
>> 	[x,y,z] = peaks(10);
>> 	pcolor([x,y,z])
>> 	shading interp
>> 	shading faceted
>
> I think a better comparison would be
> 	shading flat
> 	shading interp
>
>> In any event, I agree with Kai. The backend should handle this.  
>> Regarding
>> Octave's gnuplot backend, I don't see anything that Octave should do
>> differently.
>>
>> I've copied Petr in the event my inference regarding the gnuplot
>> implementation is in error ... or in the event he has some insight  
>> as to the
>> possibility of modifying the behavior of gnuplot.
>
> 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":
>
>
> figure(1)
> pcolor([1 2; 3 3])
> shading interp
> drawnow ('x11', '/dev/null', false, '1.gp')
>
> figure(2)
> pcolor([1 2; 3 3])
> shading flat
> drawnow ('x11', '/dev/null', false, '2.gp')
>
> system('sed "s/depthorder /depthorder interpolate 100,100 /" <2.gp  
> >2a.gp');
> system('sed "s/depthorder /           interpolate 100,100 /" <2.gp  
> >2b.gp');
>
> % The two images are identical for the very fresh gnuplot compiled  
> from cvs,
> % otherwise look to results from 2b.gp:
>
> system('gnuplot -persist 2a.gp');
> system('gnuplot -persist 2b.gp');
>
>
> The implementation of "shading interp" requires the backend to smooth
> colours with the resolution comparable with the output device. There  
> was an
> attempt for this functionality (see EXTENDED_COLOR_SPECS in gnuplot  
> sources
> - however, I think it was working only for the vgagl terminal). So  
> this
> feature is currently not working.
>
>
> 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
> Does it look OK?
>
> ---
> Petr Mikulik

Petr,

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.

Ben

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.

Yes, it should work this way. Maybe the window ID is hidden somewhere in 
the X11 structure? 

---
PM

Re: [manual] suggested addition to pcolor description

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

> > > | On caveat is that gnuplot's method of interpolation is different
> > > | than that of Matlab's. As Francesco points out the commercial
> > > | variant splits rectangles into a pair of triangles and performs a
> > > | linear interpolation of the color across the triangle. Although I do
> > > | not know what algorithm is used, gnuplot does not work the same way.
> > >
> > >Is this something that Octave should do, rather than relying on
> > >gnuplot?  If so, where does this code belong?  Maybe we should provide
> > >a function (accessible from C++ and the scripting language?) that does
> > >the interpolation, so that all backends can do things consistently.
> >
> >In 2007, I noticed that even matlab behaves differently depending on
> >platform (linux, windows) and renderer (OpenGL, ...) when plotting
> >polygons. But I have not verified if its still true. Also, OpenGL does
> >this interpolation with hardware acceleration, so we would waste a lot
> >of graphic performance in this case.
> 
> I studied the situation more closely and noticed that gnuplot appears (to me)
> to interpolate colors by increasing the density of the facets by four. The
> color of facets appear to snap to the nearest color in the colormap.
> 
> If anyone is running a copy of gnuplot with the patch for interpolating color
> as a 4th dimension, you can examine this by
> 
> 	[x,y,z] = peaks(10);
> 	pcolor([x,y,z])
> 	shading interp
> 	shading faceted

I think a better comparison would be
	shading flat
	shading interp

> In any event, I agree with Kai. The backend should handle this. Regarding
> Octave's gnuplot backend, I don't see anything that Octave should do
> differently.
> 
> I've copied Petr in the event my inference regarding the gnuplot
> implementation is in error ... or in the event he has some insight as to the
> possibility of modifying the behavior of gnuplot.

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":


figure(1)
pcolor([1 2; 3 3])
shading interp
drawnow ('x11', '/dev/null', false, '1.gp')

figure(2)
pcolor([1 2; 3 3])
shading flat
drawnow ('x11', '/dev/null', false, '2.gp')

system('sed "s/depthorder /depthorder interpolate 100,100 /" <2.gp >2a.gp');
system('sed "s/depthorder /           interpolate 100,100 /" <2.gp >2b.gp');

% The two images are identical for the very fresh gnuplot compiled from cvs,
% otherwise look to results from 2b.gp:

system('gnuplot -persist 2a.gp');
system('gnuplot -persist 2b.gp');


The implementation of "shading interp" requires the backend to smooth 
colours with the resolution comparable with the output device. There was an 
attempt for this functionality (see EXTENDED_COLOR_SPECS in gnuplot sources 
- however, I think it was working only for the vgagl terminal). So this 
feature is currently not working.


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
Does it look OK?

---
Petr Mikulik

Re: string function: definition of a function

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

> > seems we don't have "string index" or "string split" functions.
> 
> We do. It is called strstrt(haystack,needle):
> 
> gnuplot> show var GPFUN
>         GPFUN_f = "f(a,b) = a**2 + sqrt(b*a)"
> 
> gnuplot> print strstrt(GPFUN_f,"=")
> 	8
> gnuplot> print GPFUN_f[ strstrt(GPFUN_f,"=") : * ]

Interesting, I have never used this.

How can I get the "reversed" version of it? Just today I needed to extract 
the last part of the directory, e.g. from
	/tmp/bla/now
I needed to get "now". Finally I've got it by calling shall's `basename` but 
the reversed version of "strstrt" would help a lot.

Further I have noticed `pwd` command from shell is needed to set a variable 
for the current working directory because
	gnuplot> pwd
just prints it to screen, but I cannot do
	a=pwd
or	a=eval pwd

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

---
PM

Re: string function: definition of a function

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

On Monday 02 February 2009 13:52:18 you wrote:
> > > seems we don't have "string index" or "string split" functions.
> > 
> > We do. It is called strstrt(haystack,needle):
> > 
> > gnuplot> show var GPFUN
> >         GPFUN_f = "f(a,b) = a**2 + sqrt(b*a)"
> > 
> > gnuplot> print strstrt(GPFUN_f,"=")
> > 	8
> > gnuplot> print GPFUN_f[ strstrt(GPFUN_f,"=") : * ]
> 
> Interesting, I have never used this.
> 
> How can I get the "reversed" version of it? Just today I needed to extract 
> the last part of the directory, e.g. from
> 	/tmp/bla/now
> I needed to get "now". Finally I've got it by calling shall's `basename` but 
> the reversed version of "strstrt" would help a lot.

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.

> Further I have noticed `pwd` command from shell is needed to set a variable 
> for the current working directory because
> 	gnuplot> pwd
> just prints it to screen, but I cannot do
> 	a=pwd
> or	a=eval pwd

The "pwd" command from the shell is needed in any case. It is only a matter
of whether it is called directly or called via the internal routine pwd_command().
I would do
	a = system("pwd") 

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

I don't know.  I don't think that the concept of "current working directory"
is universally portable even apart from how you would issue the command.
In VMS, for example, the current directory name and the current disk are
separate things. Just asking for the current directory would not tell you
what disk you would be writing to.

-- 
Ethan A Merritt

Re: bug in depthorder?

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

Petr Mikulik wrote:

> I was wondering which point(s) of the rectangle is/are used for the depth 
> ordering. 

It may seem like this should be an important detail.  But it's not. 
It's completely irrelevant which number you sort by.  It just moves the 
problem into different regions, but does nothing at all to solve it.

The heart of the matter is that depth sorting does not work.  It's quite 
easy to prove by counter-example.

You have to do more than just sort polygons to get a correct rendering. 
  The sort itself can't be done by comparing a single "characteristic" 
number.  You have to compare entire polygons, using basically all their 
geometric data.  And sometimes the answer still is "undecidable", in 
which case you have to split one of them.  For the gory details, look up 
the Newell-Newell-Sancha algorithm, or consult the literature on BSP 
trees and their usage to do hidden-surface removal.

Re: Qt terminal

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

Le lundi 2 février 2009, Ethan A Merritt a écrit :
> On Sunday 01 February 2009, Jérôme Lodewyck wrote:
> > Hi,
> >
> > 	I have written a Qt terminal for Gnuplot. My main motivation for doing
> > this is that Qt is going to be released under the LGPL, and I far as I
> > understood, this license is compatible with Gnuplot.
> > 	The terminal is mostly inspired from the wxWidgets terminal (thanks
> > Timothée for your hard work !). It is not yet optimized and there are
> > still some glitches here and there, but it is mostly feature complete.
> > 	If it is of interest for someone, I will be happy to propose a patch.
>
> Sure, go ahead and post a patch.
> It is hard to tell much about how it works by looking only at screenshots.

Ok, the patch is submitted

> Please describe more precisely what libraries or environment thie new
> terminal would require.
> Does it use the KDE libraries, or just Qt?
> If one built gnuplot with only the driver, would it be run on, say,
> the OpenMoko mobile phone platform?
> What about non-linux Qt platforms?

It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my 
experience, Qt applications usually work out of the box on any platform 
supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE). Only 
one pat of the terminal makes use of non-Qt functions: the Qt main loop is 
implemented inside a pthread, which is a problem because
1/ It doesn't work on non-UNIX platforms, but from what I understood from the 
wx terminal, Windows support would only imply putting #ifdef's around the 
pthread functions
2/ Qt does not officially support running the main event loop inside a thread; 
however, I did not experience any problem with this (except that Qt functions 
should be used with care in the gnuplot thread)

Jérôme

> 	Ethan
>
> > Screenshots:
> >
> > http://lodewyck.free.fr/gp1.png
> > http://lodewyck.free.fr/gp2.png
> > http://lodewyck.free.fr/gp3.png
> >
> > Regards,
> >
> > Jérôme
> >
> > -------------------------------------------------------------------------
> >----- This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: wrong position of colorbox

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

On Saturday 31 January 2009 02:19:32 Petr Mikulik wrote:
> It seems that the patch
> 
> 2008-12-26  Ethan Merritt  <merritt@u.washington.edu>
> * src/graphics.c (boundary):
>   Clean up border placement code, fix colorbox bug.
> 
> added a new bug: you can see "too much space on right", try
> 
> 	 plot 'demo.edf' binary filetype=edf with image
> 
> in gnuplot 4.2 and current gnuplot-cvs.

Should be fixed now.

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

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

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

On Sunday 01 February 2009 15:41:16 Petr Mikulik wrote:
> > Could the size and position of the x11 plot window be determined in a  
> > similar manner (on the gnuplot end)? Of course, no pause would be  
> > required, but I assume some gnuplot command would be needed.
> > 
> > Either that or could another internally-maintained variable be created  
> > to hold a window's x11 id? ... if so would this work for wxt as well?
> 
> 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.

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

Re: fitting functions with more independent variables

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

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:u:v

> For example, if there are five columns:
> 
>   The first column inherits its data range and time/date flag from the
>   V axis unless a specific data range is given, and has the dummy
>   variable 'v' unless a different name is given in a range or "set
>   dummy v" statement.  The first range spec in a fit command would
>   affect this variable.
> 
>   The second column inherits its data range and time/date flag from
>   the first X axis unless a specific data range is given, and has the
>   dummy variable 'x' unless a different name is given in a range or
>   "set dummy x" statement.  The second range spec in a fit command
>   would affect this variable.
> 
>   The third column inherits its data range and time/date flag from the
>   first Y axis unless a specific data range is given, and has the
>   dummy variable 'y' unless a different name is given in a range or
>   "set dummy y" statement.
> 
>   The fourth column has the dependent variable, and inherits from the
>   Z axis.
> 
>   The last column gives the error standard deviation.
> 
> 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

As I say, I am not familiar with the 'fit' subsystem, but that's
what I would expect it to behave like, and I suspect other naive
users would expect the same.

	Ethan

>   fit [q=-8:8] [r=*:*] [s=*:*] [t=0:10] a*q+b*r+c*s+d*t \
>       'foo.dat' using 1:2:3:4:5:(1) via a,  b,  c,  d
> 
> I think I see how to do this.  
> 
> Comments?
> 
>          - Jim Van Zandt

-- 
Ethan A Merritt

Re: string function: definition of a function

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

On Saturday 31 January 2009 02:15:49 Petr Mikulik wrote:
> > I propose the patch below, which adds a function that returns the
> > string that defines a specified user defined function.
> 
> I see it gives the following:
>         GPFUN_f = "f(x,y)=x+y+20"
>         GPFUN_g = "g(x,y)=x*y"
> 
> I wonder how I can get the definition part only, i.e. "x+y+20" or "x*y".
> Maybe you could add another variable
> 	GPFUN__f = "x+y+20"
> ?
> 
> I though there are some "string" functions that could allow this, but it 
> seems we don't have "string index" or "string split" functions.

We do. It is called strstrt(haystack,needle):

gnuplot> show var GPFUN
        GPFUN_f = "f(a,b) = a**2 + sqrt(b*a)"

gnuplot> print strstrt(GPFUN_f,"=")
	8
gnuplot> print GPFUN_f[ strstrt(GPFUN_f,"=") : * ]
	= a**2 + sqrt(b*a)
gnuplot> print GPFUN_f[ strstrt(GPFUN_f,"=")+1 : * ]
	 a**2 + sqrt(b*a)
gnuplot> body = GPFUN_f[strstrt(GPFUN_f,"=")+1:*]
gnuplot> print body
	 a**2 + sqrt(b*a)






> 
> Maybe it would be also useful to have
> 	strindex("hello world", "llo")  => 3
> 	strsplit("hello=world", "=", 0) => "hello"
> 	strsplit("hello=world", "=", 1) => "="
> 	strsplit("hello=world", "=", 2) => "world"
> 
> ---
> PM
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> 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: bug in depthorder?

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

Petr Mikulik wrote:
>>>The enclosed script using the "pm3d depthorder" gives wrong ordering of
>>>faces on gnuplot-cvs, and sometimes wrong and sometimes good ordering on
>>>gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen?
>>
>>Petr,
>>
>>depthorder is a very much an approximation to true hidden surface features.  I
>>think there was some discussion a couple years ago about this.  If I'm
>>remembering correctly, I wrote a patch for determining the depth which I
>>thought was a bit more robust.  But after discussions with Ethan, I thought it
>>would be more worthwhile putting effort into actual hidden surface, if one had
>>time.  (A generalization of the hidden lines code where a hidden surface is
>>broken into smaller parts.)
>>
>>The problem in your example is that the surfaces are too big relative to the
>>resolution such that in 3D space their depths overlap.  Furthermore, this
>>example is probably undersampling anyway because the peaks aren't visible.
> 
> 
> I was wondering which point(s) of the rectangle is/are used for the depth 
> ordering. Is it min(all 4 corners) or center-of-rectangle or all of them? It 
> seems to me that this is producing this bug: the two problematic rectangles 
> touch in one edge (2 corners), but their other 2 corners have different 
> depth.

You've found the right issue.  It is min or max, I can't recall which.  I think I'd written a patch that used average or something.  All choices have their particular problem scenarios.

Dan

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

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

On Feb 2, 2009, at 4:41 AM, Petr Mikulik wrote:

>>>> Could the size and position of the x11 plot window be determined  
>>>> in a
>>>> similar manner (on the gnuplot end)? Of course, no pause would be
>>>> required, but I assume some gnuplot command would be needed.
>>>>
>>>> Either that or could another internally-maintained variable be  
>>>> created
>>>> to hold a window's x11 id? ... if so would this work for wxt as  
>>>> well?
>>>
>>> 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'm not familiar with x11.trm or what "gp_exec_event" is.
>
> That's the command in gplt_x11.c sources which sends information  
> (events)
> from X11's graph to gnuplot.

Ok, I understand. This is  a question for the gnuplot developers.

>> Would the gnuplot command "print GPVAL_TERM_WINDOWID" print the  
>> id? ... or
>> perhaps, I should ask what is an automatic variable?
>
> The automatic variables are all those GPVAL_ and MOUSE_ which are
> automatically filled by gnuplot, some of them being updated after  
> plot or
> mouse clicks (see "show var all"). In Octave, MOUSE_ are read by  
> ginput.m,
> for example. You could read GPVAL_TERM_WINDOWID in the same way.

That should work nicely for what I understand is needed by Octave.

Ben

Re: bug in depthorder?

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

> > The enclosed script using the "pm3d depthorder" gives wrong ordering of
> > faces on gnuplot-cvs, and sometimes wrong and sometimes good ordering on
> > gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen?
> 
> Petr,
> 
> depthorder is a very much an approximation to true hidden surface features.  I
> think there was some discussion a couple years ago about this.  If I'm
> remembering correctly, I wrote a patch for determining the depth which I
> thought was a bit more robust.  But after discussions with Ethan, I thought it
> would be more worthwhile putting effort into actual hidden surface, if one had
> time.  (A generalization of the hidden lines code where a hidden surface is
> broken into smaller parts.)
> 
> The problem in your example is that the surfaces are too big relative to the
> resolution such that in 3D space their depths overlap.  Furthermore, this
> example is probably undersampling anyway because the peaks aren't visible.

I was wondering which point(s) of the rectangle is/are used for the depth 
ordering. Is it min(all 4 corners) or center-of-rectangle or all of them? It 
seems to me that this is producing this bug: the two problematic rectangles 
touch in one edge (2 corners), but their other 2 corners have different 
depth.

---
PM

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

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

> > >Could the size and position of the x11 plot window be determined in a
> > >similar manner (on the gnuplot end)? Of course, no pause would be
> > >required, but I assume some gnuplot command would be needed.
> > >
> > >Either that or could another internally-maintained variable be created
> > >to hold a window's x11 id? ... if so would this work for wxt as well?
> >
> >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'm not familiar with x11.trm or what "gp_exec_event" is.

That's the command in gplt_x11.c sources which sends information (events) 
from X11's graph to gnuplot.

> Would the gnuplot command "print GPVAL_TERM_WINDOWID" print the id? ... or
> perhaps, I should ask what is an automatic variable?

The automatic variables are all those GPVAL_ and MOUSE_ which are 
automatically filled by gnuplot, some of them being updated after plot or 
mouse clicks (see "show var all"). In Octave, MOUSE_ are read by ginput.m, 
for example. You could read GPVAL_TERM_WINDOWID in the same way.

---
PM

Re: Qt terminal

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

On Sunday 01 February 2009, Jérôme Lodewyck wrote:
> Hi,
> 
> 	I have written a Qt terminal for Gnuplot. My main motivation for doing this 
> is that Qt is going to be released under the LGPL, and I far as I understood, 
> this license is compatible with Gnuplot.
> 	The terminal is mostly inspired from the wxWidgets terminal (thanks Timothée 
> for your hard work !). It is not yet optimized and there are still some 
> glitches here and there, but it is mostly feature complete.
> 	If it is of interest for someone, I will be happy to propose a patch.

Sure, go ahead and post a patch.
It is hard to tell much about how it works by looking only at screenshots.

Please describe more precisely what libraries or environment thie new terminal
would require.  
Does it use the KDE libraries, or just Qt?
If one built gnuplot with only the driver, would it be run on, say,
the OpenMoko mobile phone platform?  
What about non-linux Qt platforms?

	Ethan

> 
> Screenshots:
> 
> http://lodewyck.free.fr/gp1.png
> http://lodewyck.free.fr/gp2.png
> http://lodewyck.free.fr/gp3.png
> 
> Regards,
> 
> Jérôme
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> 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: bug in GPFUN_ - Re: executable files of gnuplot generated from current cvs source trees are unstable

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

On Sunday 01 February 2009, Petr Mikulik wrote:
> > I have built windows binaries (bu mingw gcc-4.3.0-dw2-TDM), cygwin and djgpp.
> > The exe files are unstable for all platforms.
> 
> The same for Linux and prob.dem, random.dem. It seems to be caused by the 
> latest addition of GPFUN_*:

Yes. Fixed now.

-- 
Ethan A Merritt

Qt terminal

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

Hi,

	I have written a Qt terminal for Gnuplot. My main motivation for doing this 
is that Qt is going to be released under the LGPL, and I far as I understood, 
this license is compatible with Gnuplot.
	The terminal is mostly inspired from the wxWidgets terminal (thanks Timothée 
for your hard work !). It is not yet optimized and there are still some 
glitches here and there, but it is mostly feature complete.
	If it is of interest for someone, I will be happy to propose a patch.

Screenshots:

http://lodewyck.free.fr/gp1.png
http://lodewyck.free.fr/gp2.png
http://lodewyck.free.fr/gp3.png

Regards,

Jérôme

Re: bug in depthorder?

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

Petr Mikulik wrote:
> The enclosed script using the "pm3d depthorder" gives wrong ordering of 
> faces on gnuplot-cvs, and sometimes wrong and sometimes good ordering on 
> gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen?

Petr,

depthorder is a very much an approximation to true hidden surface features.  I think there was some discussion a couple years ago about this.  If I'm remembering correctly, I wrote a patch for determining the depth which I thought was a bit more robust.  But after discussions with Ethan, I thought it would be more worthwhile putting effort into actual hidden surface, if one had time.  (A generalization of the hidden lines code where a hidden surface is broken into smaller parts.)

The problem in your example is that the surfaces are too big relative to the resolution such that in 3D space their depths overlap.  Furthermore, this example is probably undersampling anyway because the peaks aren't visible.

Try

set dgrid3d 100,100
replot

and you should get improvement in the behavior of both.  (But there are still hidden surface flaws.)

Dan


> 
> ***
> 
> f(x,y)=sin(x*y*pi/180)/(x*y*pi/180)
> 
> if (1)  set xrange [-720:720]; set yrange [-720:720]; \
>         set sample 10; set isosamples 10; set table 'a.dat'; splot f(x,y); 
> unset table; reset
> 
> set auto fix
> #set xrange [0:10]; set yrange [0:10]
> set xlabel "x axis"; set ylabel "y axis"
> set xyplane at 0
> 
> set pm3d
> 
> set pm3d depthorder
> 
> set view 64, 287
> splot 'a.dat' with pm3d
> 
> pause 1
> 
> set view 64, 286; replot
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com