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

Re: cgm.trm [FILLEDBOXES && !PM3D] breaks

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

On Thursday 26 February 2004 04:39 am, Hans-Bernhard Broeker wrote:
>
> cgm.trm can't be built if FILLEDBOXES was turned on, but PM3D wasn't,
> because CGM_fillbox uses the PM3D type gpiPoint internally, and calls
> CGM_filled_polygon() to do the actual job.
>
> Who looks after this: Ethan? Jim?

I have only a limited ability to test the cgm code, via an old cgm emulation
package called ralcgm.  I added a few lines to the driver at some point by
working directly from the cgm spec to support colored text.
Then I added a few more fixes forwarded by (IIRC) Jim Bollinger.
But I am not really familiar with the code. 

If necessary I can probably hack at it to make it compile properly given
the various conditional compilation options, but I would need to have
someone else to confirm the validity of the output in each case.
If no one else steps forward, maybe ....

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

Re: 16-bit versions of gnuplot doomed?

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

Hans-Bernhard Broeker wrote:

>On Wed, 25 Feb 2004, Daniel J Sebald wrote:
>
>[PM3D stuff doesn't go through the 2D parts of gnuplot]
>
>  
>
>>In some sense it does.  I mean, it may not be set up that way, and that 
>>is why I say the two are diverging.  When it boils down to it, 3D is 
>>still just drawing lines, filled polygons, colorbox key, etc. 
>>    
>>
>
>It's exactly the filled polygons that don't really use any 2D stuff.
>
>The rest of the plot (largely) doesn't care whether a given dataset is
>output as pm3d, lines or points, but the actual surface plotting, where
>the real work is, does.  Note that the core data structure you pass
>to term->filled_polygon takes an at least optionally 3D data point for
>input: struct gpiPoint.
>
>  
>
>>give the illusion of 3D.  Do you agree with that?  
>>    
>>
>
>As long as we don't add an actual 3D terminal driver (OpenGL, VRML
>or whatever), yes.  But that's not something we have to worry about now.
>
>  
>
>>>>It should be just the core routines for graphics and then maybe a
>>>>"graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
>>>>right now it will undoubtedly mess up some of the patches currently on
>>>>SF.  
>>>>        
>>>>
>
>Well, the "core routines" are actually in term.c and the drivers, not in
>graphics.c.  The current graphics.c is esentially just that graph2D.c
>you're talking of.  It contains exactly those things that are specific to
>2D plotting: the implementations of 'with <style>' for 2D, and the 2D
>graph area positioning stuff, particularly the rather monstrous function
>boundary().
>
>A more natural split of graphics.c could therefore be along those lines.
>I.e. it might make sense to split out boundary() and its helpers into a
>new module layout2d.c.
>

Well, certainly that.  I think there was a discussion about better using 
the visual space in 3D plots.  Plus I think there is use for the 
colorbox key in 2D.  So here are some similar features that are handled 
differently depending upon the type of layout.  So there is that aspect.

What I was thinking of has to do with the image stuff I did.  However, 
now that I look more closely, it could be that the image case is 
slightly different from the other lines/points type of drawings.  What 
I'm seeing in graph3d.c are a number of routines (e.g., plot3d_lines) 
that aren't for plotting just one line, but for plotting a series of 
lines.  And plotting a line is fairly fundamental that it is easy to 
simply call a vector routine from the 3D routines.  However, in the case 
of drawing an image, which could be in 3D or 2D I certainly didn't want 
to have one for 2D and one for 3D.  So they are combined into one where 
there is a test inside of the image routine as to whether a 3D 
projection should be done.  Let's hold off this discussion.  There are 
too many issues surrounding this.

Dan

cgm.trm [FILLEDBOXES && !PM3D] breaks

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

Hello, everybody,

one other small gem I found during may forays into memory-starved
platform builds:

cgm.trm can't be built if FILLEDBOXES was turned on, but PM3D wasn't,
because CGM_fillbox uses the PM3D type gpiPoint internally, and calls
CGM_filled_polygon() to do the actual job.

As a minimal fix, the relevant #if's in cgm.trm would have to be changed
from

	#ifdef USE_ULIG_FILLEDBOXES

to
	
	#if defined(USE_ULIG_FILLEDBOXES) && defined(PM3D)

Who looks after this: Ethan? Jim?

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

Re: 16-bit versions of gnuplot doomed?

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

On Wed, 25 Feb 2004, Daniel J Sebald wrote:

[PM3D stuff doesn't go through the 2D parts of gnuplot]

> In some sense it does.  I mean, it may not be set up that way, and that 
> is why I say the two are diverging.  When it boils down to it, 3D is 
> still just drawing lines, filled polygons, colorbox key, etc. 

It's exactly the filled polygons that don't really use any 2D stuff.

The rest of the plot (largely) doesn't care whether a given dataset is
output as pm3d, lines or points, but the actual surface plotting, where
the real work is, does.  Note that the core data structure you pass
to term->filled_polygon takes an at least optionally 3D data point for
input: struct gpiPoint.

> give the illusion of 3D.  Do you agree with that?  

As long as we don't add an actual 3D terminal driver (OpenGL, VRML
or whatever), yes.  But that's not something we have to worry about now.

> >>It should be just the core routines for graphics and then maybe a
> >>"graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
> >>right now it will undoubtedly mess up some of the patches currently on
> >>SF.  

Well, the "core routines" are actually in term.c and the drivers, not in
graphics.c.  The current graphics.c is esentially just that graph2D.c
you're talking of.  It contains exactly those things that are specific to
2D plotting: the implementations of 'with <style>' for 2D, and the 2D
graph area positioning stuff, particularly the rather monstrous function
boundary().

A more natural split of graphics.c could therefore be along those lines.
I.e. it might make sense to split out boundary() and its helpers into a
new module layout2d.c.

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

Re: 16-bit versions of gnuplot doomed?

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

Hans-Bernhard Broeker wrote:

>On Wed, 25 Feb 2004, Daniel J Sebald wrote:
>
>  
>
>>I think "graphics.c" is the file I argued should be restructured because 
>>2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
>>ends up being plotted in 2D.)  
>>    
>>
>
>Not everything, strictly.  PM3D stuff doesn't.
>

In some sense it does.  I mean, it may not be set up that way, and that 
is why I say the two are diverging.  When it boils down to it, 3D is 
still just drawing lines, filled polygons, colorbox key, etc.  It's just 
that they are transformed into slightly different way and positioned to 
give the illusion of 3D.  Do you agree with that?  It just seemed like 
better code reuse could have been done there.

>>It should be just the core routines for graphics and then maybe a
>>"graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
>>right now it will undoubtedly mess up some of the patches currently on
>>SF.  
>>    
>>
>
>Not necessarily.  I think I can pull it off while only adding
>#ifdef's to graphics.c.  I'll effectively compile the same file
>twice, but select different parts of it to actually be compiled.
>That's a bit hairy, but if patch compatibility is a major concern,
>it can be done.
>

Some strategically placed #ifdefs is not a problem.  The patch program 
usually can figure that kind of thing out with enough offset.  However, 
breaking the file into two chunks would probably cause problems.

>>make work in the time span of making a release.  Maybe it would be best
>>to not rock the 16-bit boat until 4.1. 
>>    
>>
>
>Which will be even bigger, and thus harder to port to 16-bitters. Not to
>mention there's not even a *hint* of a plan when a 4.1 might happen.  
>Averaging over the history of releases since 3.5, that may take 2
>years....
>

Can't argue with that point.

Dan

Re: multiple X11 term in 3.8k

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

Your expectation is not correct.

There is no such thing as "going back to" a previous plot and
adding something to it.

This has nothing to do with x11; it is just the way gnuplot works.
You can choose a previous output device for a new plot,
but the new plot simply replaces the old plot.  It does not
"add to" it.

On Wednesday 25 February 2004 12:05 pm, Dmitri A. Sergatskov wrote:
> I played with new this feature of X11 terminal and the behavior was not
> what I expected.
> Perhaps this is a "feature" rather than the bug, but I'd like to hear
> confirmation one way or another.
>
> gnuplot> set term x11 0
> Terminal type set to 'x11'
> Options are '0'
> gnuplot> plot sin(x)
> (Plot sin(x) in window "0")
> gnuplot> set term x11 1
> Terminal type set to 'x11'
> Options are '1'
> gnuplot> plot sin(2*x)
> (This opens the second window and plot sin(2*x), so far so good.
> Now I want to go back to window 0 and _add_ cos(x) to the plot)
> gnuplot> set term x11 0
> Terminal type set to 'x11'
> Options are '0'
> gnuplot> replot cos(x)
> (sin(x) plot is gone and I have sin(2*x) and cos(x) in windows "0")
>
> Is it what suppose to happen?
>
> Sincerely,
>
> Dmitri.
>
>
> -------------------------------------------------------
> 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

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

Re: 16-bit versions of gnuplot doomed?

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

On Wed, 25 Feb 2004, Daniel J Sebald wrote:

> I think "graphics.c" is the file I argued should be restructured because 
> 2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
> ends up being plotted in 2D.)  

Not everything, strictly.  PM3D stuff doesn't.

> It should be just the core routines for graphics and then maybe a
> "graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
> right now it will undoubtedly mess up some of the patches currently on
> SF.  

Not necessarily.  I think I can pull it off while only adding
#ifdef's to graphics.c.  I'll effectively compile the same file
twice, but select different parts of it to actually be compiled.
That's a bit hairy, but if patch compatibility is a major concern,
it can be done.

> make work in the time span of making a release.  Maybe it would be best
> to not rock the 16-bit boat until 4.1. 

Which will be even bigger, and thus harder to port to 16-bitters. Not to
mention there's not even a *hint* of a plan when a 4.1 might happen.  
Averaging over the history of releases since 3.5, that may take 2
years....


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

multiple X11 term in 3.8k

[Dmitri A. S. <dm...@un...>]

I played with new this feature of X11 terminal and the behavior was not what
I expected.
Perhaps this is a "feature" rather than the bug, but I'd like to hear confirmation one
way or another.

gnuplot> set term x11 0
Terminal type set to 'x11'
Options are '0'
gnuplot> plot sin(x)
(Plot sin(x) in window "0")
gnuplot> set term x11 1
Terminal type set to 'x11'
Options are '1'
gnuplot> plot sin(2*x)
(This opens the second window and plot sin(2*x), so far so good.
Now I want to go back to window 0 and _add_ cos(x) to the plot)
gnuplot> set term x11 0
Terminal type set to 'x11'
Options are '0'
gnuplot> replot cos(x)
(sin(x) plot is gone and I have sin(2*x) and cos(x) in windows "0")

Is it what suppose to happen?

Sincerely,

Dmitri.

Re: 16-bit versions of gnuplot doomed?

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

On Wed, 25 Feb 2004, Ethan Merritt wrote:

> But is it not sufficient to support these machines under linux?

No.  Some of the boxes we're talking about here couldn't run Linux even if
their operators' lives depended on it.  An actual need for a 16-bit DOS
version means real DOS on a 286-class or even smaller machine.  An actual
IBM PC/AT or PS/2 model 30, roughly 10 years old or older. Such boxes
won't even run the 32-bit DOS binary, like the DJGPP one which I'll
certainly prepare and package a release of.

A need for 16-bit Windows versions can arise even on a 486 box, _if_ it's
still running Win3.x, without the "Win32s" add-on installed.

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

Re: 16-bit versions of gnuplot doomed?

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

I propose to let gnuplot 3.7.3 to be the last one supporting 16bit machines.
This may change only if there is a strong feedback, as you say in your
posting. You could add this announcement to the new web page too, section
"Development".

On DOS 386 machine, people can use compiles by emx (or djgpp) -- anyway, I
haven't heard long time about any such compile, but as emx is used to
compile the OS/2 version, it should work too "in principle" (another
terminals).

Machines with 286 and Win3.1 -- obviously not the production machines of
today, but still can be used in labs for running experiments -- I guess
people are happy with gnuplot plotting nice curves as 3.7.3 does, with the
memory requirements gnuplot <3.7.3 has, and don't need those features for
which gnuplot 4.0 has been extended.

---
Petr Mikulik

Re: 16-bit versions of gnuplot doomed?

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

Hans-Bernhard Broeker wrote:

>Hello, all,
>
>I've got round to trying to build 16-bit binaries of gnuplot for DOS and
>Windows and the news, so far, is bad.
>
>Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
>itself directly on startup.  I may be blowing the stack or something ---
>investigating that is a nightmare without at least a Win9x machine.
>
>DOS-16bit works, sort of.  But that's after I disabled most of the bit
>optional features (filled boxes, PM3D) *and* removed pretty much all
>terminal drivers besides dospc (the interactive graphics driver), table
>and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
>post.trm had to go is the PS_header[] string array.  This is simply too
>large, and the way it's constructed (array of many short strings) means
>that Borland's compiler, which is otherwise quite clever at squeezing a
>lot of code into those 640KB, fails to move the bulk of it into a separate
>segment.  As is, term.obj with post.trm in it costs 26000 of the total of
>64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
>though.
>
>The other major challenge is graphics.c, and it affects both 16-bit
>platforms: that module is plain and simply too large.  BCC chokes already
>on compiling that source file because it contains more than 64KB of code.  
>Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
>has only 52KB...), but for the time being, I decided to tentatively split
>graphics.c into two files: I copied all the "steps" plotting style handler
>(plot_{f,hi,}steps) and their helper functions to a separate source file
>and #ifdef'ed out their implementations in graphics.c.  The new files
>steps2d.[ch] currently contain copies of the relevant parts of
>graphics.[ch], but those may be replaced by #include'ing graphics.c if I
>put even more #ifdef's into the latter.
>
>I will leave the CVS version free of these complications for now, until
>the following question is settled: Is support for 16-bit machines (think:
>old lab PCs, "poor pupils", under-developed countries...) important enough
>to warrant changes as deep as these before the release?
>
>I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
>get some additional feedback.
>

I think "graphics.c" is the file I argued should be restructured because 
2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
ends up being plotted in 2D.)  It should be just the core routines for 
graphics and then maybe a "graph2D.c" and "graph3D.c".  If a major 
change is made to graphics.c right now it will undoubtedly mess up some 
of the patches currently on SF.  Supporting 16-bit would probably be 
nice, but a conscious decision needs to be done on how to make that 
happen, i.e., how should software be organized, what features will be 
included.  That will be difficult to make work in the time span of 
making a release.  Maybe it would be best to not rock the 16-bit boat 
until 4.1.  That is, don't make an untested upgrade for 16-bit. 
 Otherwise the 16-bit world will upgrade and probably end up wrecking 
their current, workable set up.  I don't look back fondly on software 
upgrades in the 16-bit days.

Dan

Re: 16-bit versions of gnuplot doomed?

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

On Wednesday 25 February 2004 01:03 am, Hans-Bernhard Broeker wrote:
> The new files steps2d.[ch] currently contain copies of the
> relevant parts of  graphics.[ch], but those may be replaced by
> #include'ing graphics.c if I  put even more #ifdef's into the latter.

That sounds ugly.  If it must be split, I hope we can make it a 
clean split.

> I will leave the CVS version free of these complications for now, until
> the following question is settled: Is support for 16-bit machines
> (think: old lab PCs, "poor pupils", under-developed countries...)
> important enough to warrant changes as deep as these before the release?

The goal of supporting old (cheap) machines is a laudable one.
But is it not sufficient to support these machines under linux?
It sounds like the problems you found are more an issue of the
inadequacies of Win3.1 than of the hardware per se.

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

Re: 16-bit versions of gnuplot doomed?

[Lars H. <lhe...@us...>]

 
> I will leave the CVS version free of these complications for now, until
> the following question is settled: Is support for 16-bit machines (think:
> old lab PCs, "poor pupils", under-developed countries...) important enough
> to warrant changes as deep as these before the release?
> 
> I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
> get some additional feedback.

 That would need to be done.

 I remember receiving email from a user (Nobel laureate in physics ...)
 a few years back, mentioning that he is using both DOS and Linux versions.

16-bit versions of gnuplot doomed?

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

Hello, all,

I've got round to trying to build 16-bit binaries of gnuplot for DOS and
Windows and the news, so far, is bad.

Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
itself directly on startup.  I may be blowing the stack or something ---
investigating that is a nightmare without at least a Win9x machine.

DOS-16bit works, sort of.  But that's after I disabled most of the bit
optional features (filled boxes, PM3D) *and* removed pretty much all
terminal drivers besides dospc (the interactive graphics driver), table
and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
post.trm had to go is the PS_header[] string array.  This is simply too
large, and the way it's constructed (array of many short strings) means
that Borland's compiler, which is otherwise quite clever at squeezing a
lot of code into those 640KB, fails to move the bulk of it into a separate
segment.  As is, term.obj with post.trm in it costs 26000 of the total of
64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
though.

The other major challenge is graphics.c, and it affects both 16-bit
platforms: that module is plain and simply too large.  BCC chokes already
on compiling that source file because it contains more than 64KB of code.  
Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
has only 52KB...), but for the time being, I decided to tentatively split
graphics.c into two files: I copied all the "steps" plotting style handler
(plot_{f,hi,}steps) and their helper functions to a separate source file
and #ifdef'ed out their implementations in graphics.c.  The new files
steps2d.[ch] currently contain copies of the relevant parts of
graphics.[ch], but those may be replaced by #include'ing graphics.c if I
put even more #ifdef's into the latter.

I will leave the CVS version free of these complications for now, until
the following question is settled: Is support for 16-bit machines (think:
old lab PCs, "poor pupils", under-developed countries...) important enough
to warrant changes as deep as these before the release?

I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
get some additional feedback.

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

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> I was hoping for a more general solution, or rather a solution
> that would help all redrawing of all x11 plot windows.  The bigger
> problem is that the window is redrawn repeatedly during and
> after resizing. Having the individual redraws a bit slow is less of
> a concern than the fact that it may redraw 10 times when only
> 1 or 2 were really necessary.
>

Doesn't this depend on the window manager configuration ?

If the user has set the window manager to continuous redraws during resize,
then that's exactly what they want the behaviour to be. So the redraws
are not unnecessary.

 I seem to be setup to use rubber-banding during resizing, so I wouldn't expect
to get any intermediate redraws. (But maybe I misunderstood the problem.)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

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

Re: splot can it do

[Andre R. <ar...@gw...>]

On Mon, 23 Feb 2004, kemal asad wrote:

> I am looking for a plotting application or library for 2D and 3D, data
> and function  representation.
> in my selection process i have establish that i want the application or
> library to have the ability  to do the following kind of graphs.
> z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y)).
> So the question is can gnuplot do this? yes yes how?
> thanks
> Kemal
>
>
yes, yes, yes, gnuplot can do this, ... .
just type:
z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y))
splot z(x,y)

regards and rtfm

Andre

splot can it do

[kemal a. <as...@cl...>]

I am looking for a plotting application or library for 2D and 3D, data
and function  representation.
in my selection process i have establish that i want the application or
library to have the ability  to do the following kind of graphs. 
z(x,y)=  5*cos(2*sqrt(x*x+y*y))*exp(-0.3*sqrt(x*x+y*y)).  
So the question is can gnuplot do this? yes yes how?
thanks
Kemal

Re: new Gnuplot web site

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

> Sorry, I missed the beginning of this thread.  Would you like this work
> to be integrated with the official http://www.gnuplot.info/ site

I propose the date when gnuplot 4.0 gets released, both webs should be
unified (redirect?).

Or maybe we can even do it now to get more attraction? May not be so bad
idea. Is it only index.html what's there? Then, it should become
index373.html to be saved for future.

> we spoke about it, we agreed that we would be happy if someone would
> take this up.  Alex Woo had done work long ago, but I don't think he has
> worked on the web page in a long time.

I think I took all the relevant info from gnuplot.info, so that site is no
longer needed.

---
Petr Mikulik

Re: Going over bugs before release...

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

On Monday 23 February 2004 05:48 am, Dave Denholm wrote:
> > With the patch applied there is no problem with colors, but any
> > x11 plot containing rotated text is refreshed very much slower.
> > This is in particular noticeable when you resize the plot window.
> > But speeding up window resizing is certainly not release-critical,
> > so we can address it later.
>
> what's the change, and why does it cause a slowdown ?

The previous code assumed that text/background pixel area could
be represented by a 1-bit deep array.  The array was rotated, and
then the entire rotated array was ORer back onto the original image
in one (relatively fast) operation.  The problem is that ORing the
background color is only harmless if it is represented by all zeros.
If it is anything else then the OR operation perturbs the existing
colors.

The new code explicitly tests for pixels in the rotated text box that
are non-background, and substitutes them back into the original
image one by one.  That is relatively slow.

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

Re: Going over bugs before release...

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Monday 23 February 2004 05:48 am, Dave Denholm wrote:
>> > With the patch applied there is no problem with colors, but any
>> > x11 plot containing rotated text is refreshed very much slower.
>> > This is in particular noticeable when you resize the plot window.
>> > But speeding up window resizing is certainly not release-critical,
>> > so we can address it later.
>>
>> what's the change, and why does it cause a slowdown ?
>
> The previous code assumed that text/background pixel area could
> be represented by a 1-bit deep array.  The array was rotated, and
> then the entire rotated array was ORer back onto the original image
> in one (relatively fast) operation.  The problem is that ORing the
> background color is only harmless if it is represented by all zeros.
> If it is anything else then the OR operation perturbs the existing
> colors.
>
> The new code explicitly tests for pixels in the rotated text box that
> are non-background, and substitutes them back into the original
> image one by one.  That is relatively slow.
>


Yes, that's what I feared...

isn't the standard trick here to

first AND with bg = ~0, fg = reqd colour
then   OR with bg =  0, fg = reqd colour


true there may be an intermediate frame with the wrong foreground colour,
but it's usually not noticable.

dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: new Gnuplot web site

[Clark G. <ga...@di...>]

Petr Mikulik wrote:
>>Petr - Do you want to be the point person for changes to the web site,
>>or should it proceed by shared access as with the CVS tree itself?
> 
> Anyone can modify these new gnuplot's web pages, I hapilly claim no
> copyright for it (especially if it means less work for me!).

Sorry, I missed the beginning of this thread.  Would you like this work 
to be integrated with the official http://www.gnuplot.info/ site or are 
you working with Lars in that matter?  I can easily point the mirror 
elsewhere or we can update the master which Lars maintains.  Last time 
we spoke about it, we agreed that we would be happy if someone would 
take this up.  Alex Woo had done work long ago, but I don't think he has 
worked on the web page in a long time.

--ckg

Re: file permissions - Re: release plane for 4.0

[Lars H. <lhe...@us...>]

> >From some strange reasons, I cannot touch files in subdirectories. I don't
> see what's wrong in file permissions... only in "demo/" directory I can
> write a file.
> 
> Can you please fix it?
> 
> If you are there, please move scr-new-petr/index.html into
> screenshots/index.html, and remove this directory.
 
 Done.

 Petr, you too need to take care that all files and directories you
 create are group-writable!