gnuplot-beta

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:

> Gnuplot has visualisation properties, which could be interpreted, and
> used by Octave by our package. But, there is always a but. We need to
> make duplicate copies of datasets, which are plotted in Gnuplot, since
> Gnuplot doesnt send it's dataset of visualisation back.

I don't think I see what that "dataset of visualization" you're talking
about is.

Anyway: is this about 3D or 2D plots?  Or colour maps?

> This is the curve/surface data, such as X, Y and Z.

How would these differ from the data sent from octave to gnuplot?

> 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:

> I know Octave can get some parameters from gnuplot using gshow, which 
> will run show in Gnuplot.

But that's not exactly the easiest possible way.  "show" is meant for
consumption by humans, not computers.  The "save" command's output would 
be a lot better for that, I guess.  This writes out a complete script to 
generate the current plot (with the exception of multiplot stuff).

Note that some parameters actually used in the plot are neither in 'save'
nor in 'show' output.  The major examples are the margin sizes, legend
positioning and, most prominently, the actual axis range.  Unless mousing
is in use or you explicitly requested the "writeback" feature, the axis
range endpoints are not kept anywhere after the plot has been done.

> The question is whether Gnuplot is doing some housekeeping of curve-data 
> (2D & 3D), and this is retrievable in an easy way.

Not after the fact.  gnuplot does not generally keep plotted data in
memory after the plot has been drawn, so it can't report them back to
octave, either.  This kind of data copying would have to be done at the
octave end of the connection instead.  There's, again, an exception to 
this, but it only applies to mouse-enabled versions, and then only to 3D 
plots, IIRC.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

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

On Friday 20 February 2004 02:54 pm, Hans-Bernhard Broeker wrote:
>
> Not after the fact.  gnuplot does not generally keep plotted data in
> memory after the plot has been drawn, so it can't report them back to
> octave, either.  This kind of data copying would have to be done at the
> octave end of the connection instead.  There's, again, an exception to
> this, but it only applies to mouse-enabled versions, and then only to 3D
> plots, IIRC.

Only 2D I think you mean?  The x11 mousing code stores the axis
info so that it can translate mouse clicks into plot coordinates.
But it only does such translation for 2D plots.

The outboard x11 driver, gplt_x11, stores most of the plot information
implicitly. It needs this anyway in order to continuously display plots,
even old plots, on the screen. There is a code stub in
gplt_x11.c just waiting to pass mousing events from prior windows
back to external applications. But as of now it is commented out
because we have no such interface defined.

If some interested parties on both the gnuplot and octave side work
to define such an interface, I believe it would not be a tremendous
amount of work to export data on demand from gnuplot_x11 to an
octave session.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Gnuplot and Octave.

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

Ethan Merritt wrote:

>On Friday 20 February 2004 02:54 pm, Hans-Bernhard Broeker wrote:
>  
>
>>Not after the fact.  gnuplot does not generally keep plotted data in
>>memory after the plot has been drawn, so it can't report them back to
>>octave, either.  This kind of data copying would have to be done at the
>>octave end of the connection instead.  There's, again, an exception to
>>this, but it only applies to mouse-enabled versions, and then only to 3D
>>plots, IIRC.
>>    
>>
>
>Only 2D I think you mean?  The x11 mousing code stores the axis
>info so that it can translate mouse clicks into plot coordinates.
>But it only does such translation for 2D plots.
>
>The outboard x11 driver, gplt_x11, stores most of the plot information
>implicitly. It needs this anyway in order to continuously display plots,
>even old plots, on the screen. There is a code stub in
>gplt_x11.c just waiting to pass mousing events from prior windows
>back to external applications. But as of now it is commented out
>because we have no such interface defined.
>
>If some interested parties on both the gnuplot and octave side work
>to define such an interface, I believe it would not be a tremendous
>amount of work to export data on demand from gnuplot_x11 to an
>octave session.
>

One small drawback though is that when the data reaches the point of 
gnuplot_x11 it has been translated to a new coordinate system.  I 
suppose the translation can be reversed, but there will be some 
precision discrepancies.

Dan

Re: Gnuplot and Octave.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 20 Feb 2004, Daniel J Sebald wrote:

[...]
> One small drawback though is that when the data reaches the point of 
> gnuplot_x11 it has been translated to a new coordinate system. 

Not just translated, but projected, too.  I.e. the coordinates known
to gnuplot_x11 are always 2D.  There's no way at all it could give
back 3D data.

But now that I look at the sources, it seems the 3D data are actually kept 
around until the next 'plot', i.e. the only calls to the relevant routine
sp_free() are in eval3d_plot() and when you change the 'samples' settings
(for whatever that is supposed to achieve...)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Gnuplot and Octave.

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

Hans-Bernhard Broeker wrote:

>On Fri, 20 Feb 2004, Daniel J Sebald wrote:
>
>[...]
>  
>
>>One small drawback though is that when the data reaches the point of 
>>gnuplot_x11 it has been translated to a new coordinate system. 
>>    
>>
>
>Not just translated, but projected, too.  I.e. the coordinates known
>to gnuplot_x11 are always 2D.  There's no way at all it could give
>back 3D data.
>

Oh yeah.  That too.

>But now that I look at the sources, it seems the 3D data are actually kept 
>around until the next 'plot', i.e. the only calls to the relevant routine
>sp_free() are in eval3d_plot() and when you change the 'samples' settings
>(for whatever that is supposed to achieve...)
>

My guess would be that sampling pertains to the sampling intervals of a 
internal math function so that if the user changes that it is assumed 
that the data inherently changes.

Dan

Re: Gnuplot and Octave.

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

Hans-Bernhard Broeker wrote:

>On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:
>
>  
>
>>Gnuplot has visualisation properties, which could be interpreted, and
>>used by Octave by our package. But, there is always a but. We need to
>>make duplicate copies of datasets, which are plotted in Gnuplot, since
>>Gnuplot doesnt send it's dataset of visualisation back.
>>    
>>
>
>I don't think I see what that "dataset of visualization" you're talking
>about is.
>
>Anyway: is this about 3D or 2D plots?  Or colour maps?
>
>  
>
>>This is the curve/surface data, such as X, Y and Z.
>>    
>>
>
>How would these differ from the data sent from octave to gnuplot?
>

Probably most on this list are familiar with Matlab's handle graphics 
objects, but just in case I'll summarize.  Matlab extends the concept of 
matrices to the plot realm by associating elements of a plot to an 
elements in a vector.  Think of these elements as "handles".  Using 
"get" will get the vector of handles associated with a particular 
figure.  For example, here is a short segment of code to change the line 
width of a plot:

  H = get(get(gcf,'Children'),'Children');
  set(H(1),'LineWidth',2.0);

You'll notice to use of "get" twice.  The reason is that there is a 
hierarchy of plot elements.  For example, an axis will be an element, 
and then under that will be other elements for the axis like text. 
 "get" alone without assignment will display all the information about a 
handle object such as the actual text, the font type, the size of the 
font, etc.  The sub-objects are called children.

Naturally, this requires a storing of all information about the plot 
elements.  Or, it requires some way of inquiring such information from 
Gnuplot, if Gnuplot keeps a record of such things.  A plot line is also 
an object and part of its characteristics is all the data points 
associated with it.  So, this is what the original question is about. 
 Is it possible to get back the (x,y,z) information that Petr is 
referring to from Gnuplot.

A few things:

1)  This would mean that somehow information about plot data would need 
to be sent back to Octave through the pipe so that Octave could 
interpret it and use it in a handle graphics fashion.  I'm not sure if 
Gnuplot is set up to do such a thing.

2)  It would then seem that to do this would require the strategy that, 
I think it was, Hans has mentioned about each Gnuplot plot storing all 
information so that it can be retrieved.  (I assume same goes for all 
other elements like labels, etc.)  From Gnuplot's perspective, this was 
for allowing the mouse to zoom on not only the most recent plot, but all 
plots in X11.  But here would be an example of another use.

3)  I don't know what Ole has in mind, but I assume that this concept 
has to be extended to all other graph objects, i.e., labels and so on. 
 That is, either Gnuplot is the one to keep track of all the retrievable 
information, or Octave is the one.

You may be wondering, how does one know what the hierarchy is Matlab? 
 That is, how did I know to use "get" twice in the above script example 
and then select element H(1) from the array of handle objects?  Well, 
one has to simply display the information, following the hierarchy of 
children down to the object of interest.  It isn't the most apparent 
logic as to how things are grouped, but perhaps once you get used to it, 
things become easier.

However, I'm going to give my experience about this, and keep in mind 
that this is opinion.  (Repeat OPINION!)  I was exposed to Matlab before 
Octave so the handle object approach is what I first used to customize 
plots.  I never found it easy to use; quite arduous actually.  The 
searching through children of children of children part is what gets to 
one after while.  Switching over to Octave, I found that using "gset" 
and the Gnuplot customizing commands a bit easier to use.  The handle 
graphics approach is to create the graphics objects and then go back and 
modify them (going through the handle hierarchy in the process).  The 
Gnuplot approach is to set the object property at the same time the 
object is created, and be done with it.  In Gnuplot, setting a default 
property is often very easy as well.

I could say more here, but I will leave it open for further comment from 
others.

Dan

Re: Gnuplot and Octave.

[Ole J. H. <wat...@ya...>]

Hi, again.

I know Octave can get some parameters from gnuplot using gshow, which 
will run show in Gnuplot.
And a lot of types, parameters and properties related to current plot is 
available here.
All these could be collected from Octave.

There is a lot of builtin functionality inside gnuplot to be used within 
Octave, and could be interpreted as handle graphics.
Remark that gnuplot doesn't have to support a core handle graphics. 
Handle graphics of Matlab is very restrictive,
and should be interpreted as some sort of Mathworks attempt to 
generalize properties of a visualisation.

Gnuplot should continue in it's development regardless of handle graphics.

The question is whether Gnuplot is doing some housekeeping of curve-data 
(2D & 3D), and this is retrievable in an easy way.

It would be nice to be able to retrieve the curve_data which is 
visualised. That would be perfect.

I know that Octave is able to use a gshow, which will list out 
properties as in show.  
I believe I can get labels, ticks, colour and format, but not the 
curve_data, which could be quite useful....


Cheers

Ole J.




Daniel J Sebald wrote:

>
>
> Hans-Bernhard Broeker wrote:
>
>> On Fri, 20 Feb 2004, Ole Jacob Hagen wrote:
>>
>>  
>>
>>> Gnuplot has visualisation properties, which could be interpreted, and
>>> used by Octave by our package. But, there is always a but. We need to
>>> make duplicate copies of datasets, which are plotted in Gnuplot, since
>>> Gnuplot doesnt send it's dataset of visualisation back.
>>>   
>>
>>
>> I don't think I see what that "dataset of visualization" you're talking
>> about is.
>>
>> Anyway: is this about 3D or 2D plots?  Or colour maps?
>>
>>  
>>
>>> This is the curve/surface data, such as X, Y and Z.
>>>   
>>
>>
>> How would these differ from the data sent from octave to gnuplot?
>>
>
> Probably most on this list are familiar with Matlab's handle graphics 
> objects, but just in case I'll summarize.  Matlab extends the concept 
> of matrices to the plot realm by associating elements of a plot to an 
> elements in a vector.  Think of these elements as "handles".  Using 
> "get" will get the vector of handles associated with a particular 
> figure.  For example, here is a short segment of code to change the 
> line width of a plot:
>
>  H = get(get(gcf,'Children'),'Children');
>  set(H(1),'LineWidth',2.0);
>
> You'll notice to use of "get" twice.  The reason is that there is a 
> hierarchy of plot elements.  For example, an axis will be an element, 
> and then under that will be other elements for the axis like text. 
> "get" alone without assignment will display all the information about 
> a handle object such as the actual text, the font type, the size of 
> the font, etc.  The sub-objects are called children.
>
> Naturally, this requires a storing of all information about the plot 
> elements.  Or, it requires some way of inquiring such information from 
> Gnuplot, if Gnuplot keeps a record of such things.  A plot line is 
> also an object and part of its characteristics is all the data points 
> associated with it.  So, this is what the original question is about. 
> Is it possible to get back the (x,y,z) information that Petr is 
> referring to from Gnuplot.
>
> A few things:
>
> 1)  This would mean that somehow information about plot data would 
> need to be sent back to Octave through the pipe so that Octave could 
> interpret it and use it in a handle graphics fashion.  I'm not sure if 
> Gnuplot is set up to do such a thing.
>
> 2)  It would then seem that to do this would require the strategy 
> that, I think it was, Hans has mentioned about each Gnuplot plot 
> storing all information so that it can be retrieved.  (I assume same 
> goes for all other elements like labels, etc.)  From Gnuplot's 
> perspective, this was for allowing the mouse to zoom on not only the 
> most recent plot, but all plots in X11.  But here would be an example 
> of another use.
>
> 3)  I don't know what Ole has in mind, but I assume that this concept 
> has to be extended to all other graph objects, i.e., labels and so on. 
> That is, either Gnuplot is the one to keep track of all the 
> retrievable information, or Octave is the one.
>
> You may be wondering, how does one know what the hierarchy is Matlab? 
> That is, how did I know to use "get" twice in the above script example 
> and then select element H(1) from the array of handle objects?  Well, 
> one has to simply display the information, following the hierarchy of 
> children down to the object of interest.  It isn't the most apparent 
> logic as to how things are grouped, but perhaps once you get used to 
> it, things become easier.
>
> However, I'm going to give my experience about this, and keep in mind 
> that this is opinion.  (Repeat OPINION!)  I was exposed to Matlab 
> before Octave so the handle object approach is what I first used to 
> customize plots.  I never found it easy to use; quite arduous 
> actually.  The searching through children of children of children part 
> is what gets to one after while.  Switching over to Octave, I found 
> that using "gset" and the Gnuplot customizing commands a bit easier to 
> use.  The handle graphics approach is to create the graphics objects 
> and then go back and modify them (going through the handle hierarchy 
> in the process).  The Gnuplot approach is to set the object property 
> at the same time the object is created, and be done with it.  In 
> Gnuplot, setting a default property is often very easy as well.
>
> I could say more here, but I will leave it open for further comment 
> from others.
>
> Dan
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Gnuplot and Octave.

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

Ole Jacob Hagen wrote:

> Hi, again.
>
> I know Octave can get some parameters from gnuplot using gshow, which 
> will run show in Gnuplot.
> And a lot of types, parameters and properties related to current plot 
> is available here.
> All these could be collected from Octave.
>
> There is a lot of builtin functionality inside gnuplot to be used 
> within Octave, and could be interpreted as handle graphics.
> Remark that gnuplot doesn't have to support a core handle graphics. 
> Handle graphics of Matlab is very restrictive,
> and should be interpreted as some sort of Mathworks attempt to 
> generalize properties of a visualisation. 


I will agree with that.

> Gnuplot should continue in it's development regardless of handle 
> graphics.
>
> The question is whether Gnuplot is doing some housekeeping of 
> curve-data (2D & 3D), and this is retrievable in an easy way.
>
> It would be nice to be able to retrieve the curve_data which is 
> visualised. That would be perfect.
>
> I know that Octave is able to use a gshow, which will list out 
> properties as in show.  I believe I can get labels, ticks, colour and 
> format, but not the curve_data, which could be quite useful.... 


(Brainstorming questions, not proposals:)

So that would perhaps mean a set/show combination?  Hmm.  "show" used to 
display the data (i.e., transfer back to Octave) would mean putting 
things in ASCII floating point or something.  Some datasets for plots 
can get very large.

There isn't anyway to create a special terminal type that would send the 
data back to Octave somehow, is there?

In any case, from Octave's perspective it would still be better if 
Gnuplot had an internal record of _each_ plot rather than just the 
current plot, right?

Dan

Re: Gnuplot and Octave.

[Arun P. <ape...@lb...>]

Hi,

Ole Jacob Hagen wrote:
> The question is whether Gnuplot is doing some housekeeping of curve-data 
> (2D & 3D), and this is retrievable in an easy way.
> 
> It would be nice to be able to retrieve the curve_data which is 
> visualised. That would be perfect.

not sure if gnuplot can do it already or if I misunderstood the question 
;), but it seams to me that all you need is a terminal that will output 
plot and splot data in text format (e.g. x/y/z values)... wouldn't 
"terminal table" work? Octave could parse the output and you would get 
the data back into octave...

HTH

Arun

Re: Gnuplot and Octave.

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

> The question is whether Gnuplot is doing some housekeeping of curve-data
> (2D & 3D), and this is retrievable in an easy way.

I think gnuplot does some proprocessing on reading the data (especially if
you use "set log", or smoothing (?)), so the data may not be always
reproducible.

> It would be nice to be able to retrieve the curve_data which is
> visualised. That would be perfect.
>
> I know that Octave is able to use a gshow, which will list out properties
> as in show.  I believe I can get labels, ticks, colour and format, but not
> the curve_data, which could be quite useful....

You can get this functionality outside of gnuplot. Just after each plot from
your front-end, do "save 'plot1.gp'" -- and there you have access to all
properties of this plot, including the "plot" command listing the datafiles.
You just have to parse the file -- I think that's how Octave's "gshow"
currently works.

Maybe using mkfifo you don't need to touch the filesystem and keep all these
options as a string list in memory of your front-end.

---
PM