Perl - Gnuplot Topics

Perl - Gnuplot Topics

Post by E.D.G » Sat, 02 Aug 2008 19:19:03


f you have a response that contains information for both Perl and Gnuplot
users then you might post to both groups. Otherwise you should probably
post responses to just one group or the other.

1. Using Perl And Gnuplot With Windows XP And Windows Vista
2. Perl And Gnuplot Recommendations
A. A Formal Perl - Gnuplot Interface
B. A Real Time Version Of Gnuplot
3. Perl .exe Program Assistance Needed

1. USING PERL AND GNUPLOT WITH WINDOWS XP AND WINDOWS VISTA

Gnuplot can be a powerful graphics program when used by itself or with Perl
and probably any of a number of other programming languages. One of the
advantages of using them together is that both are actively supported. When
new versions of Perl are developed, older graphics modules might work and
they might not. But once a Perl - Gnuplot interface is developed, Gnuplot
programs should work with any Perl updates.

Perl is great for fast, complex calculations and data array management.
Gnuplot produces high quality graphics and appears to use relatively little
computer memory.

Using them together can be tricky. It probably took me a year of trying one
thing or another to determine how to get the two programs to work together
effectively with both Windows XP and Vista. The main problem is with
starting Gnuplot from a Perl program and then having the Perl program
continue running. That is necessary because after my Gnuplot program starts
the Perl program monitors keyboard keys and instructs the Gnuplot program to
draw different types of charts etc. in response. For example, with an arrow
key press a cursor will move a small distance left or right on the display
screen.

When the Perl system and exec commands are used Gnuplot starts running and
the Perl program usually pauses until Gnuplot is stopped. That appears to
be a problem that is somewhat unique with Gnuplot.

The following routines should allow Perl to continue running in the
background.

A Windows shortcut link such as Plot.gnu.lnk has to be created for the
Gnuplot program. And instead of directly accessing the Gnuplot program the
link has to be accessed in the following manner with Perl commands.

system 'c:\programs\Plot.gnu.lnk';# For Windows XP
system 'start c:\programs\Plot.gnu.lnk';# For Windows Vista

Windows "Run" commands can also be used to start a Gnuplot program. But
that is more complicated. And the programs can get confused if they loose
track of which Windows screen is active.

So far I have not had much success with passing information from the Perl
program to Gnuplot through a pipe. Instead I have been storing data and
commands in files which Gnuplot then reads. If that is done some
handshaking is necessary so that Perl does not try to store data in a file
at the same time Gnuplot is trying to read it. When that happens the Perl
program keeps running and the Gnuplot program crashes, probably because the
Perl program is compiled and the Gnuplot program interprets one command line
at a time.

2. PERL AND GNUPLOT RECOMMENDATIONS

A. A Formal Perl Gnuplot Interface

This combination of programs can be so useful for researchers that it would
be helpful if program developers created some type of interface that made it
possible for the two programs to work together in a seamless manner.

A special Perl command could be created that would start Gnuplot and allow
Perl to continue running in the background. For example,

star
 
 
 

Perl - Gnuplot Topics

Post by merrit » Sun, 03 Aug 2008 00:33:48

In article < XXXX@XXXXX.COM >,


I think the operative word there is "Windows". Coordinating perl + gnuplot
is trivially easy on any unix-like system.


That is indeed the problem with Windows. Gnuplot is designed to
communicate via pipes, and Windows doesn't support this model well.


All versions of gnuplot for at least the last 10 years have supported this
to some extent. The current development version goes substantially further
in this direction.



Gnuplot natively supports mouse/cursor interactions in the display window,
even when driven by an external script. Pressing 'r' in the plot window
toggles a large cross-hair that can be dragged along the plot, for example.
The mouse position in terms of plot coordinates are tracked in real time
and echoed to the bottom of the plot window. None of this requires any
special code on the perl side.

--
Ethan A Merritt

 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Sun, 03 Aug 2008 03:45:12

Thanks for the response.





There is unfortunately no way to avoid using Perl, Gnuplot, and Windows with
this application as it is the operating system used by virtually all of the
scientists, government officials and researchers around the world who would
be using my main Perl program. As I said, I can get it to work sufficiently
well that it does what it needs to do and provides fast, versatile, and
valuable graphics features. But the combination of Perl, Gnuplot, and
Windows is not a perfect match.


I thought that I had checked on this before and had no success. The Replot
command won't work here as far as I can see because the Gnuplot program does
not automatically redraw what was erased by the last Replot command.

--

The applications I have developed are too complex and require keyboard
monitoring by Perl which then sends instructions to Gnuplot. For example,
after pressing "n," the up and down arrow keys can be used to increase or
decrease the number of line plots displayed on the monitor. "p" combined
with up and down arrow keys causes the all of the line plot displays to
scroll up and down. There are presently many other commands no built into
the program combination. And new commands are quite easy to add.

What results are very powerful Real Time control features that make it look
like Gnuplot is one of those advanced graphics programs used for aircraft
flight simulation for example. The Gnuplot programs themselves are quite
simple. Perl does all of the data manipulation. Gnuplot largely uses its
line, point, and label features to convert Perl data into boarders with tics
on them etc. It is easier to do it that way than try to use Gnuplot's
advanced automatic axis features.

After some investigation I discovered that ActiveState has a Perl
development kit for several hundred dollars that looks like it will create
.exe programs. That would be in my affordability range if it works with
Windows etc. and no problems.
 
 
 

Perl - Gnuplot Topics

Post by merrit » Sun, 03 Aug 2008 04:26:02

n article < XXXX@XXXXX.COM >,
E.D.G. < XXXX@XXXXX.COM > wrote:

If you have not looked at Octave, you probably should. It manages to drive
gnuplot even under Windows, and whatever tricks they used may be directly
relevant to your application as well.


Sorry, I don't follow what you mean by that. In particular I don't follow
what you mean "erased by the last replot command".
Replot does exactly what it sounds like; it re-executes the previous plot
command. You may have changed something in between (view angle, labels,
axis range, position on the canvas, etc). If so, the new plot may overlap
the old one, or sit beside it, or whatever. If you want the lines from the
previous plot to remain, the you tell gnuplot to use "multiplot" mode.

The recent change is to offer an alternative "refresh" command, which does the
same thing but without re-reading the underlying data. This allows it to work
through a pipe, and is needed by recent versions of Octave. It is also
relevant if you are plotting realtime data, where the data may have changed
since the previous plot command. "replot" would use the new data, since
reading from the data source was inherent in the previous command;
"refresh" instead skips this part and re-uses the old data.
[yeah, that may sounds backwards, but the behaviour of "replot" was already
established].



OK, but that could still be programmed in gnuplot itself using the
"bind" command to reassign the meaning of keypress events. I don't know
whether that would result in faster response than doing it at the perl
layer, but you might want to experiment.


I don't know about "easier", since I don't know in detail what your
application needs to do. But you also mentioned a constraint on speed,
and I rather suspect it's faster to use gnuplot built-in operations when
they are available rather than emulating them in the perl layer.



--
Ethan A Merritt
 
 
 

Perl - Gnuplot Topics

Post by Raoul Flec » Sun, 03 Aug 2008 04:27:46


in my (admittedly controversial) opinion any scientist that makes
intimate use of microsoft products is not doing good science for the
simple reason that they are by business design black-boxes whose
functional details cannot be published, hence cannot be replicated, and
is subject to stealthly change without warning. thus by making use of
two excellent open-source projects whose use in science is properly
celebrated with a closed operating system you bring down the
respectability of your application to one only an MBA foolishly
appreciates. that being said, you'll probably make more money in doing
so. but while you count your money, consider sending some of it in
support of those software tools you from which you benefitted
--
r
 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Sun, 03 Aug 2008 09:37:14


There is no profit or even money of any sort involved with this effort that
I am aware of. The disaster mitigation program being developed is presently
intended to be given for free use to governments, researchers, and any other
interested parties around the world. The goal is to hopefully save some
lives.

To get started with, Windows has to be used simply because it is being used
by all of the people who would likely be testing the program. However, I
believe that with a few minor software adjustments the Perl - Gnuplot
combination would probably run fine on Unix computers etc.

If governments etc. decide that they like the way the program works then I
expect that their professional computer programmers will almost immediately
start rewriting it in some other language and also greatly expand its
capabilities. Then I can move on to another project.
But, we have to get started somewhere.
 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Sun, 03 Aug 2008 10:11:51


That sounds like a good idea. And I will take a look at Octave. However,
the Gnuplot programs I presently have running are working and are doing a
great job of producing graphics. They are making it possible to do a lot of
data analysis that it was impossible to do just a year ago because it
required so much time and energy. So, the basic goal has been achieved.
But there is always room for improvement.


My program draws world maps for example. And they can have a vertical line
representing longitude that moves to the right or left based on pressing the
appropriate arrow key. Each time the line is moved one longitude degree
Gnuplot has to redraw the entire world map.

It sounds like a newer version of Gnuplot might have a command that can let
you get around that need to redraw everything when you make changes in just
one area. So I will check on that and see if it helps. There was nothing
like that in the version I am using. And I read all of the documentation
several times. Multiplot was tried and did not appear to offer any help.
Only one plot is being used at a time.


Initially I compared results using the "bind" command versus Perl's
"IsKeyPressed" command. And I decided to go with the Perl keyboard monitor
because most of the programming is being done with Perl. So it is easier to
quickly change what task the arrow keys etc. are assigned to do.


I went with Perl for deciding how to draw borders and axes etc. because of
the need to quickly move them around and expand them and contract them. It
is a little easier to do that by storing all of the data in arrays and then
just multiplying the arrays by some variable factor to expand or contract
the axes etc. The adjusted data from the arrays are then stored in data
files that Gnuplot reads and plots several times a second when necessary.

Once more, the primary goal here is to just get something working that will
convince governments etc. that they should be developing this type of
disaster management resource. And they need to see some data to believe it.
They won't at first care how the programs work or even what programs are
being used. Once they have accepted that this is a worthwhile type of
effort they will probably just redo all of the computer programming. That's
fine with me.
 
 
 

Perl - Gnuplot Topics

Post by Hans-Bernh » Mon, 04 Aug 2008 05:59:55


_Every_ program for 3D views on a 2D screen has to do that. The only
open question is whether the computations for that redraw are performed
by some hardware 3D graphics processor, or by the main CPU.
 
 
 

Perl - Gnuplot Topics

Post by sln » Mon, 04 Aug 2008 07:12:00


Why would any sane person go for this logic given anything removed from
C/C++/Assembly is purely a HOG. Most all matrix conversions are done on
the graphics chip. What are you selling here??


This is simply not true. Where did you get this from??????


<snip> the rest of the BS.......
 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Mon, 04 Aug 2008 08:30:32


The following is a little more detail regarding that concept. "plot" is an
already existing Gnuplot command. "tmplot" and "unplot" are only being
proposed in this posting.

plot 'world.map'
That command would plot the entire file which could be fairly complex.

tmplot 'line.map'
temporary plot - That command would draw the line or whatever defined in
line.map on top of the world.map screen. But Gnuplot would remember the
screen content that was covered by the new line.

unplot 'line.map'
unplot or erase a temporary plot - That command would tell Gnuplot to
erase the new line and replace it with the original data from world.map.

What would be saved by using those proposed new commands is some plotting
time if world.map had generated a fairly complex screen. To draw temporary
lines etc. like that Gnuplot would have to have some way of determining what
was being drawn over and storing that data. It is possible that something
like that would be too complicated.
 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Mon, 04 Aug 2008 08:37:44


Quite a bit of programming that I did in the past involved versions of Basic
that interpreted one line of code at a time. In comparison, Perl is a
racehorse.
 
 
 

Perl - Gnuplot Topics

Post by merrit » Mon, 04 Aug 2008 09:09:34

In article < XXXX@XXXXX.COM >,




As I told you before, this functionality is built in to gnuplot's
interactive terminals already. The 'r' key toggles a line or crosshair
that behaves exactly as you describe.
It is at best inefficient to emulate this at a higher level.


As it stands, there is no command-line trigger for the builtin-toggle-ruler
function, since it is intended to be triggered from the plot window.
But there has been a recent suggestion to provide command-line
equivalents for all of the builtin mousing functions. Would that help
your application?


--
Ethan A Merritt
 
 
 

Perl - Gnuplot Topics

Post by Jgen Exne » Mon, 04 Aug 2008 10:38:45


I guess when all you know are bicycles then a sedan must appear to be
magic to you.
But that doesn't make the sedan a formula one race car in the outside
world at all.

jue
 
 
 

Perl - Gnuplot Topics

Post by E.D.G » Mon, 04 Aug 2008 12:40:56


As I said in one of the other posts, my present setup with Perl sending
Gnuplot data and commands through data files and with Gnuplot replotting all
of the data each time is sufficiently fast for my application. The concept
of having the Gnuplot program have a reversible plot command was largely
something that I thought might be of interest to the program developers. I
believe that it would make Gnuplot more powerful. But it might not be worth
the trouble. I don't know what would be involved with creating a screen
memory that would enable the program to recall just a small area of the
screen.

In case people are interested in that concept, two additional commands might
be:

setscreen
That command would make the present screen including all of the temporary
plots the permanent reference screen.

retscreen
return screen - That command would refresh the screen to the one created
after the latest plot, replot, or setscreen command.

See also my "Success - Thanks" posting.