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

Plan to release 4.6.4 next week

[sfeam <sf...@us...>]

Hi all,

I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
Any last minute bug reports or other issues?
Here's the NEWS section for changes since 4.6.3:


 New features, changes and fixes since gnuplot version 4.6.3
===========================================================

* NEW Ctrl-Break interrupts fitting run in wgnuplot
* CHANGE treat empty fields in a csv file as "missing" rather than "bad"
* CHANGE allow reference to more than one column header in 'using' or 'title'
* CHANGE install-info is no longer a default "make install" target
* FIX svg and canvas terminal mousing of inverted axis coordinates
* FIX emf failed to initialize font correctly on some systems
* FIX timedata columns can now be referred to via column(N) and column("HEAD")
* FIX qt terminal toggling of enhanced text elements in plot with labels
* FIX color/pattern generated for key entries of columnstacked histograms
* FIX hitting ^C twice forces temination of wxt session hung by lost X-server
* FIX win terminal failed to properly adjust plot border after window resize
* FIX several conditions in which macros were not expanded during command input
* FIX promote a string containing only digits to INTGR rather than CMPLX
* FIX 'set grid front' caused failure to initialize location of axis zero point
* FIX very poor precision in mouse coords reported by x11 in -persist mode
* FIX parsing of $# (the number of arguments in a "call"). It's not a comment!
* FIX memory leak of cropped images using pngcairo terminal
* FIX "lc variable" now iterates over linetype colors (not styles) as documented
* FIX rtics were sometimes drawn with length 0

		Ethan Merritt (gnuplot development team)

Re: RFC: a proposed alternative solution to the "plotting columns from multiple files" problem

[<pl...@pi...>]

On 09/04/13 21:33, sfeam <Ethan A Merritt> wrote:
> The thing is, I don't think your proposal would actually work in practice
> for the "fit" part of this.  If every cycle of L-M fitting requres re-reading
> the original files through an intermediate layer of data presentation,
> my guess is that the throughput would become so awful as to be
> unusable.


It's true, iteratively doing plot and fit is going to be cumbersome 
whatever the details are.

Now, sorry if I'm mis-understanding the object of the task to be done 
here but isn't 'finding the best scaling' to match two files really 
regressing one ordinate series against the other one?

This raises the methodological issue of error/uncertainty in the mantissa.

Unless one is the controlled variable the resulting fit will be in 
error. (Eg. regressing a linear model will under-estimate the slope in 
the presence of x errors).

Assuming a fixed linear scaling is appropriate, doing the regression 
then inverting the data and fitting the other way around permits a first 
approximation (eg geometric average of the two slopes) but it really 
requires some added knowledge of the data. Non-trivial problem.

/Peter.

Does someone have a test script for the "call" command?

[sfeam <sf...@us...>]

Hi all,

I'm testing out a possible modifcation to the code supporting the "call" command
so that it can also apply to parameters passed on the shell command line.
The intent is to support a command of the form suggested by Shige Takeno
   http://sourceforge.net/p/gnuplot/patches/622/

It turns out that no file in our demo collection actually uses the "call" command.
Can someone contribute a script that demonstrates and exercises "call"?

	thanks,

		Ethan

Re: RFC: a proposed alternative solution to the "plotting columns from multiple files" problem

[<pl...@pi...>]

On 09/04/13 21:33, sfeam <Ethan A Merritt> wrote:
> The thing is, I don't think your proposal would actually work in practice
> for the "fit" part of this.  If every cycle of L-M fitting requres re-reading
> the original files through an intermediate layer of data presentation,
> my guess is that the throughput would become so awful as to be
> unusable.
>
> I suppose it's fair to answer that we won'e know the throughput limitations
> until an implementation exists.   I also suppose that I should spend more
> time exploring whether this task can be done in R or Octave.  Anyhow,
> thanks very much for the feedback.  I'll continue to ponder alternatives.
>
> 	Ethan


I started using R but it has a nasty habit of modifying the data to what 
someone "thinks" you need without even flagging it. eg changing the end 
date of a timeseries beyond the end of data in the file extended the 
data up to the nearest 128 points block length. I never bother to work 
out where it copied the extra points from since I really don't care 
where FALSE data comes from. I don't want it.

The worst part of this is that it is not even flagged.

I have had similar warnings from others.

AFAIAC, if I can't trust software not to do this kind of stupidity and 
have to start auditing everything I do to make sure it has not happened 
, it's not even worth starting.

Caveat emptor!

===


The idea of "fitting" one data file to another is something I've needed 
too.

  Since this sort of task implies some strict checking of continuity and 
compatibility of xdata intervals , it could be a bit of minefield to get 
into, though it would be nice to have.

Peter.

Re: RFC: a proposed alternative solution to the "plotting columns from multiple files" problem

[sfeam <E. A Merritt> <sf...@us...>]

On Sunday, 01 September, 2013 20:54:01 Juhász Péter wrote:
> Dear gnuplot developers,
> 
> Ethan has a patch on Sourceforge that aims to solve the old FAQ "how can
> I combine values from columns in multiple input files?"
> 
> http://sourceforge.net/p/gnuplot/patches/615/
> 
> First some observations to the patch and its description:
> 
> I don't like the name "merge" for this operation, because simply,
> merging is not what it does. If we were to go with it, I'd propose
> "store" or "stash" (the latter is inspired by "git stash")...
> 
> ...but I don't really like it as it is. I found the new command and its
> usage pattern quite hard to understand and the whole thing comes across
> as a hack.
> 
> So, I thought, if we wanted to solve the original FAQ problem, why not
> attack it directly, by extending the plot command to allow plotting from
> multiple files -- but I couldn't find an acceptable solution, with the
> plot command being quite complicated as it is, both in its user
> interface and its implementation.
> 
> Then a new idea struck: introduce a new concept called "datasource", in
> effect a layer that comes between low-level datafile reading and
> plotting. In this new mechanism, a datasource would be a kind of a
> "virtual file" that would define how the contents from one or more real
> data files are to be combined, transformed and filtered, and their
> output fed to the plot command. 
> 
> For example: 
> 
> set datasource $DATA1 "foo.txt" paste "bar.txt"
> plot $DATA1
> 
> This command would take the two files foo.txt and bar.txt and
> concatenate them line by line, like the Unix "paste" command, and let
> the plot command see the result of this combined file. 
> 
> Other combinations could be defined, for example "cat" which would just
> concatenate the files, one after the other (like the similarly named
> Unix command), or "transpose", which would act on just one file,
> transposing its contents. The usual "using", "every" etc. modifiers
> could be applied to the file names.
> 
> It is important that the "set datasource" command itself would not
> perform these operations, it would just prepare them. The data files
> would be read (and the specified transformations performed on them) only
> when the plot command is executed.
> 
> (The alternative is that the operations are performed by the set command
> itself and the results saved into a datablock. This would be simpler to
> implement, but the resulting datablocks could take up a lot of space, or
> the operation may not be possible at all if the input files are very
> large -- this is a problem with the original merge proposal as well).

True.  But if the data set is too large to hold in memory then the operations
I want to perform on it will be impractical in any case. 

> Note that I don't have any code to show yet, this RFC is just to poll
> the public opinion to see if the concept makes sense at all.

On the one hand I can see the advantage of agreeing on a desirable
user interface first and only then working on the implementation.

But on the other hand I'm not convinced that an implementation of this
particular interface is practical, or even possible.  Certainly it would
require a lot of new code.

> Also note that I personally have some reservations about the whole
> thing: it would potentially require rewriting / mucking up sensitive
> "here be dragons" parts of the code, with unclear benefit. It would also
> go against the Unix principle: we can run external commands and we have
> adequate text processing utilities outside gnuplot, so there is little
> need to make gnuplot into a text-processing-kitchen-sink-included
> utility. 

That too. If all it would accomplish is to internalize  cat, paste, grep,
and friends then I don't think it is worth starting down that path at all.

> Let me know what you think about all this.

I'm not sure that your proposal would address the actual use case
that motivated my "merge" patch.  If I knew how to handle this conveniently 
with some combination of paste/cat/grep/awk,  I probably would just do that
instead of working on a separate patch.  Possibly it would be better to
use R or Octave, but I understand gnuplot a whole lot better than either
of these, so...

Here is my application.  
There are a couple of dedicated programs that were written to deal exactly
with this class of experimental data, but  they offer limited hooks for
visualization.   As a die-hard gnuplot hacker, it seemed easier to me to
extend gnuplot's data-processing mechanism than to add general visualization
tools to existing dedicated processing programs, some of which are not
open source.

Experimental data is stored in many (tens to hundreds) of 
individual files.  Each consists of at least 3 columns of data:
  sample coordinate,   sample value,  error estimate

The task is to group and scale subsets of the files to agree with each
other, where it is unknown in advance 
1) which files will in fact agree with each other after scaling
2) what range of sample coordinates this agreement holds for
3) what scaling function is optimal

After identifying the optimal files, range and scaling, the corresponding
data is to be merged into a single output file for subsequent analysis. 

Using "paste" only works if the sample ranges and points
in the data files are identical. This is often true but is not guaranteed.
That's more or less what I was doing before the "merge" patch, but
it is rather cumbersome and requires separate checking in advance
that the sample points line up correctly.

If the scaling were already known, then plotting the data would be
easy even though it requires reading in multiple files.   But to optimize
the range and scaling you want to interactively select ranges of data,
the files for inclusion in the scaling, and the scaling function whose
parameters are to be optimized.     Alternating "fit" and "plot" commands
in gnuplot can do this, but only if the data is accessible all at once,
i.e. as if it were present in separate columns of a single input file.

The thing is, I don't think your proposal would actually work in practice
for the "fit" part of this.  If every cycle of L-M fitting requres re-reading
the original files through an intermediate layer of data presentation,
my guess is that the throughput would become so awful as to be
unusable.    

I suppose it's fair to answer that we won'e know the throughput limitations
until an implementation exists.   I also suppose that I should spend more
time exploring whether this task can be done in R or Octave.  Anyhow,
thanks very much for the feedback.  I'll continue to ponder alternatives.

	Ethan



> 
> Peter Juhasz
> 
> 

Re: x11 palette inaccuracy?

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

On 09/01/2013 03:04 PM, Ethan Merritt wrote:
>
>     >  I don't know which terminals other than x11 are affected by this.
>     Shouldn't it be effecting all terminals in the same way if the
>     problem lies in the core?  Why is the Qt terminal not showing this?
>     Dan
>
>
> The demo actually uses a palette of functions, not gradients. Most
> terminals calculate a pixel color directly from the functions.  But
> there is no way to pass the function definitions to gnuplot_x11, so
> instead the code in x11.trm pre-calculates a gradient by sampling the
> functions, and passes the gradient to gnuplot_x11.   I haven't looked to
> see if any other terminals do this also.

Ah...  It appears to be only the gnuplot_x11 terminal requiring the use 
of color function interpolation as:

#ifndef GPLT_X11_MODE
     case SMPAL_COLOR_MODE_FUNCTIONS:
	calculate_color_from_formulae(gray, color);
	break;
#endif /* !GPLT_X11_MODE */

I wonder if in this function:

calculate_color_from_formulae(double gray, rgb_color *color)

where the three components are computed whether the type of 
interpolation, linear or angular, can be controlled.

I'm still not sure that will work (it might).  The functions have to be 
retained post interpolation.  Once the function values are computed, 
doing interpolation has no assurance of selecting the user's desired 
result.  We can only assume that the user wants the interpolation with 
lowest frequency.  That is, perhaps the user gave commands to create the 
snow effect and that was his desired result.

Dan

Re: x11 palette inaccuracy?

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

On 09/01/2013 01:32 PM, sfeam (Ethan Merritt) wrote:
> On Saturday, 31 August 2013, Daniel J Sebald wrote:
>> On 08/31/2013 04:19 PM, Juhász Péter wrote:
>>> Dear gnuplot list,
>>>
>>> continuing my recent series "exposing possible bugs by fun, useless
>>> scripts", here is a nice plasma effect:
>>>
>>>
>>> set term x11
>>> set sa 50
>>> set isosa 50
>>> set pm3d
>>> unset surface
>>> set view map
>>>
>>> plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
>>> pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
>>> frac(x)= x-int(x)
>>> t = 0
>>> while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}
>>>
>>>
>>> With the x11 terminal I notice that there is "snowing" on the picture,
>>> that is, some of the pm3d rectangles have incorrect color in certain
>>> frames. Rounding or accuracy effect?
>>>
>>> I don't know if this is significant at all, but it doesn't show with the
>>> wxt or qt terminals.
>>
>> The snow effect appears to happen when the color of the "pixel" is
>> predominantly red.  Assuming the order of the triplet is RGB with red
>> being most significant, it could be that the upper-most palette is
>> incorrect, the index is pointing outside the palatte, or there is some
>> time of sign/unsigned issue unaccounted for, or all of the above.  I'd
>> have to guess it is an end-of-palette issue because otherwise I suspect
>> we'd have seen this issue show up in some other way.
>
> The x11 terminal approximates the color functions by constructing
> a gradient palette and passing that to gnuplot_x11.
> It is screwing up because this palette is in HSV space rather than RGB.
> Here is a typical palette gradient that it sends:
>
>   frac      HSV    frac      HSV    ...
>   0.0000 0f80ff 0.9400 ff80ff 0.9410 0080ff 1.0000 0f80ff 1.0000 0f80ff
>
> S is always 80, V is always ff.   H varies from 00 to ff.
> Extracting only the Hue from that gradent we get:
>
> Fraction Hue
> ---------------------
> 0.0000  0f
> 0.9400  ff
> 0.9410  00
> 1.0000  0f
> 1.0000  0f
>
> The problem is that between 0.940 and 0.941 it tries to interpolate
> from Hue = FF to Hue = 00.   Now in HSV space these represent the same hue,
> but the interpolated values between them are very definitely different hues.

I think I follow what you are saying, i.e., the approximate_palette 
routine does interpolation with the assumption of Cartesian coordinates, 
not cylindrical coordinates.  That very last "jump" looks like a 
significant change and when linear interpolation is used the algorithm 
picks some colors with hue values way in between "red" and "red" in the 
angular color space.  That sort of explains why the sparkling snow 
effect has a fairly fixed number of colors (blue, yellow) and not some 
random colors.


> The problem lies in the routine getcolor.c (approximate_palette).
> It wasn't designed to handle HSV color space.
>
> For the palettes that are generated by this demo, it is obvious to the
> eye that gradient break-point at the wrap-around point to be identically
> the same rather than  frac - (frac+0.001) would fix the problem.
> But it's not obvious to me what that means in terms of changing the
> code in approximate_palette().
>
> Maybe it would be possible to add a post-processing step that is only
> called if we are working in HSV space?

Would there be some way to do the arithmetic in greater than 8 bit and 
truncate?  That is, the table is really something like this:

Fraction Hue
---------------------
0.0000   0f
0.9400   ff
0.9410  100
1.0000  10f
1.0000  10f

for which linear interpolation will still work.  I've got a feeling that 
might not be possible though because that approximate_palette() comes 
after the palette definition.  Is that correct?


> I don't know which terminals other than x11 are affected by this.

Shouldn't it be effecting all terminals in the same way if the problem 
lies in the core?  Why is the Qt terminal not showing this?

Dan

RFC: a proposed alternative solution to the "plotting columns from multiple files" problem

[Juhász P. <pet...@gm...>]

Dear gnuplot developers,

Ethan has a patch on Sourceforge that aims to solve the old FAQ "how can
I combine values from columns in multiple input files?"

http://sourceforge.net/p/gnuplot/patches/615/

First some observations to the patch and its description:

I don't like the name "merge" for this operation, because simply,
merging is not what it does. If we were to go with it, I'd propose
"store" or "stash" (the latter is inspired by "git stash")...

...but I don't really like it as it is. I found the new command and its
usage pattern quite hard to understand and the whole thing comes across
as a hack.

So, I thought, if we wanted to solve the original FAQ problem, why not
attack it directly, by extending the plot command to allow plotting from
multiple files -- but I couldn't find an acceptable solution, with the
plot command being quite complicated as it is, both in its user
interface and its implementation.

Then a new idea struck: introduce a new concept called "datasource", in
effect a layer that comes between low-level datafile reading and
plotting. In this new mechanism, a datasource would be a kind of a
"virtual file" that would define how the contents from one or more real
data files are to be combined, transformed and filtered, and their
output fed to the plot command. 

For example: 

set datasource $DATA1 "foo.txt" paste "bar.txt"
plot $DATA1

This command would take the two files foo.txt and bar.txt and
concatenate them line by line, like the Unix "paste" command, and let
the plot command see the result of this combined file. 

Other combinations could be defined, for example "cat" which would just
concatenate the files, one after the other (like the similarly named
Unix command), or "transpose", which would act on just one file,
transposing its contents. The usual "using", "every" etc. modifiers
could be applied to the file names.

It is important that the "set datasource" command itself would not
perform these operations, it would just prepare them. The data files
would be read (and the specified transformations performed on them) only
when the plot command is executed.

(The alternative is that the operations are performed by the set command
itself and the results saved into a datablock. This would be simpler to
implement, but the resulting datablocks could take up a lot of space, or
the operation may not be possible at all if the input files are very
large -- this is a problem with the original merge proposal as well).


Note that I don't have any code to show yet, this RFC is just to poll
the public opinion to see if the concept makes sense at all.

Also note that I personally have some reservations about the whole
thing: it would potentially require rewriting / mucking up sensitive
"here be dragons" parts of the code, with unclear benefit. It would also
go against the Unix principle: we can run external commands and we have
adequate text processing utilities outside gnuplot, so there is little
need to make gnuplot into a text-processing-kitchen-sink-included
utility. 


Let me know what you think about all this.

Peter Juhasz

Re: x11 palette inaccuracy?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 31 August 2013, Daniel J Sebald wrote:
> On 08/31/2013 04:19 PM, Juhász Péter wrote:
> > Dear gnuplot list,
> >
> > continuing my recent series "exposing possible bugs by fun, useless
> > scripts", here is a nice plasma effect:
> >
> >
> > set term x11
> > set sa 50
> > set isosa 50
> > set pm3d
> > unset surface
> > set view map
> >
> > plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
> > pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
> > frac(x)= x-int(x)
> > t = 0
> > while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}
> >
> >
> > With the x11 terminal I notice that there is "snowing" on the picture,
> > that is, some of the pm3d rectangles have incorrect color in certain
> > frames. Rounding or accuracy effect?
> >
> > I don't know if this is significant at all, but it doesn't show with the
> > wxt or qt terminals.
> 
> The snow effect appears to happen when the color of the "pixel" is 
> predominantly red.  Assuming the order of the triplet is RGB with red 
> being most significant, it could be that the upper-most palette is 
> incorrect, the index is pointing outside the palatte, or there is some 
> time of sign/unsigned issue unaccounted for, or all of the above.  I'd 
> have to guess it is an end-of-palette issue because otherwise I suspect 
> we'd have seen this issue show up in some other way.

The x11 terminal approximates the color functions by constructing 
a gradient palette and passing that to gnuplot_x11.  
It is screwing up because this palette is in HSV space rather than RGB.
Here is a typical palette gradient that it sends:

 frac      HSV    frac      HSV    ...
 0.0000 0f80ff 0.9400 ff80ff 0.9410 0080ff 1.0000 0f80ff 1.0000 0f80ff

S is always 80, V is always ff.   H varies from 00 to ff.
Extracting only the Hue from that gradent we get:

Fraction Hue
---------------------
0.0000  0f 
0.9400  ff 
0.9410  00 
1.0000  0f 
1.0000  0f

The problem is that between 0.940 and 0.941 it tries to interpolate
from Hue = FF to Hue = 00.   Now in HSV space these represent the same hue,
but the interpolated values between them are very definitely different hues.

The problem lies in the routine getcolor.c (approximate_palette).
It wasn't designed to handle HSV color space.

For the palettes that are generated by this demo, it is obvious to the
eye that gradient break-point at the wrap-around point to be identically
the same rather than  frac - (frac+0.001) would fix the problem.
But it's not obvious to me what that means in terms of changing the
code in approximate_palette().   

Maybe it would be possible to add a post-processing step that is only
called if we are working in HSV space?

I don't know which terminals other than x11 are affected by this.

	Ethan

Re: plasma demo, was: x11 palette inaccuracy?

[Bastian M. <bma...@we...>]

Am 31.08.2013 23:19, schrieb Juhász Péter:
> Dear gnuplot list,
>
> continuing my recent series "exposing possible bugs by fun, useless
> scripts", here is a nice plasma effect:
>

Nice one!  To improve the animation speed, I checked wether using "with 
image" instead of pm3d would help.  Tests were done without the colorbox 
and key using the wxt terminal on Windows 8.  Here are my results:

   pm3d:  28 fps
   with image:  40 fps
   with image + refresh:  162 fps

Using the pseudofile '++', we can actually reuse the plot data with 
"refresh".  You can find the updated script below.

   Bastian


----
reset
set sa 50
set isosa 50
set xrange [-10:10]
set yrange [-10:10]
unset colorbox
unset key

bind "Escape"      "t = 10"

plasma(x,y) = sin(x / .8) + sin(y / 1.6) + sin((x + y) / 1.9)
pal(t)  = sprintf("set pal model HSV functions frac(gray+%f),0.5,1",t)
frac(x) = x - int(x)
t = 0
start = time(0.)
eval pal(t)
plot '++' using 1:2:(plasma($1,$2)) with image
while(t < 3){
	eval pal(t)
	t = t + 0.01
	pr t
	refresh
}

print sprintf("%.2f frames/second", t/0.01 / (time(0.) - start))
reset bind
----



>
> set term x11
> set sa 50
> set isosa 50
> set pm3d
> unset surface
> set view map
>
> plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
> pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
> frac(x)= x-int(x)
> t = 0
> while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}
>
>
> With the x11 terminal I notice that there is "snowing" on the picture,
> that is, some of the pm3d rectangles have incorrect color in certain
> frames. Rounding or accuracy effect?
>
> I don't know if this is significant at all, but it doesn't show with the
> wxt or qt terminals.
>
> Peter
>

game demos

[Juhász P. <pet...@gm...>]

Dear gnuplot list,

by popular demand ;), I've added the game demos discussed earlier to the
CVS.

Fixes: 
- up key now disabled
- key events are now handled after the pause so they don't mess up the
internal state
- label size chosen according to terminal

Standing issues: 
- with the wxt terminal, keypad + and - appears to keep their default
functions, even though they are rebound explicitly by the script

Please waste time by playing them^W^W^W^W^Wtest them thoroughly!

Peter

Re: x11 palette inaccuracy?

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

On 08/31/2013 04:52 PM, Daniel J Sebald wrote:

> The snow effect appears to happen when the color of the "pixel" is
> predominantly red.  Assuming the order of the triplet is RGB with red
> being most significant, it could be that the upper-most palette is
> incorrect, the index is pointing outside the palatte, or there is some
> time of sign/unsigned issue unaccounted for, or all of the above.  I'd
> have to guess it is an end-of-palette issue because otherwise I suspect
> we'd have seen this issue show up in some other way.

I conflated a couple concepts there: RRGGBB wouldn't be a palette lookup 
sort of thing.  This is palette-based so I'm going to guess indexing 
outside the palette, i.e., some rounding effect puts the palette index 
one past the last value and a range check is missing.

The best place to watch is the colorbar.  It is always the same color 
that has the incorrect shade.

Dan

Re: x11 palette inaccuracy?

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

On 08/31/2013 04:19 PM, Juhász Péter wrote:
> Dear gnuplot list,
>
> continuing my recent series "exposing possible bugs by fun, useless
> scripts", here is a nice plasma effect:
>
>
> set term x11
> set sa 50
> set isosa 50
> set pm3d
> unset surface
> set view map
>
> plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
> pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
> frac(x)= x-int(x)
> t = 0
> while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}
>
>
> With the x11 terminal I notice that there is "snowing" on the picture,
> that is, some of the pm3d rectangles have incorrect color in certain
> frames. Rounding or accuracy effect?
>
> I don't know if this is significant at all, but it doesn't show with the
> wxt or qt terminals.

OK, I finally broke out of the hypnotic trance...

The snow effect appears to happen when the color of the "pixel" is 
predominantly red.  Assuming the order of the triplet is RGB with red 
being most significant, it could be that the upper-most palette is 
incorrect, the index is pointing outside the palatte, or there is some 
time of sign/unsigned issue unaccounted for, or all of the above.  I'd 
have to guess it is an end-of-palette issue because otherwise I suspect 
we'd have seen this issue show up in some other way.

Dan

x11 palette inaccuracy?

[Juhász P. <pet...@gm...>]

Dear gnuplot list,

continuing my recent series "exposing possible bugs by fun, useless
scripts", here is a nice plasma effect:


set term x11
set sa 50
set isosa 50
set pm3d
unset surface
set view map

plasma(x,y) = sin(x/.8)+sin(y/1.6)+sin((x+y)/1.9)
pal(t) = sprintf("set pal model HSV functions frac(gray+%f),0.5,1", t)
frac(x)= x-int(x)
t = 0
while(t<10){eval pal(t); t= t+0.01; pr t; splot plasma(x,y)}


With the x11 terminal I notice that there is "snowing" on the picture,
that is, some of the pm3d rectangles have incorrect color in certain
frames. Rounding or accuracy effect?

I don't know if this is significant at all, but it doesn't show with the
wxt or qt terminals.

Peter

Re: prev/next scaling history

[<pl...@pi...>]

On 08/31/13 04:07, sfeam (Ethan Merritt) wrote:
> It's clearer in the sense that you really do want a scaling history.
> But the program doesn't currently keep anything of the sort,
> so it would be a major change.  About the same difficulty as
> the recurring request for zoomable multiplots, and for much
> the same reason.  The necessary information is not available.
>
> 	Ethan

Sorry if the example did not reproduce what I meant it to.

Basically I work in wxt most of the time. There would appear to be a 
"history" in what you refer to as the zoom stack.

All I am suggesting would be helpful is that the initial autoscale state 
could be included in this "stack"  in a way that is accessible to the 
"p" hotkey or the "previous" button on wxt.

If I manually select a zoom with the mouse , then autoscale button, then 
a different manual selection, I would like all three states to be in the 
stack , not just two.

I'll stop the description there is the hope of not further confusing the 
issue.

regards, Peter.

Re: prev/next scaling history

[sfeam (E. Merritt) <eam...@gm...>]

On Friday, 30 August 2013, pl...@pi... wrote:
> On 08/31/13 01:47, sfeam <Ethan A Merritt> wrote:
> > On Friday, 30 August, 2013 21:45:50 pl...@pi... wrote:
> >> Hi,
> >>
> >> this is only a niggle but a niggle that bugs me every day and every time
> >> I use gnuplot.
> >>
> >> Why isn't "auto-scale" included in the history of scaling values stored
> >> for the previous/next scale feature.
> >>
> >> eg
> >>
> >> reset
> >> plot datafile w l
> >> set xr [1:10]; replot
> >>
> >> now in an interactive terminal (eg wxt) I hit "p" but instead of it
> >> returning to autoscale it jumps to some scaling I used yesterday on a
> >> different plot. ie , the last NON autoscale setting of xr.
> >>
> >> Equally, if I explicitly set 'auto' and then zoom to some other setting,
> >>    it does not get counted next time I do 'previous'.
> >>
> >> Is there a problem with including auto as a value in the scaling history?
> >
> > Could it be that you are looking for the "u" hot key?
> >
> > 	Ethan
> >
> >
> 
> Thanks but no.
> 
>   p              `builtin-zoom-previous` go to previous zoom in the zoom 
> stack
>   u              `builtin-unzoom`
> 
> I'm talking about the unzoomed (autoscaled) state being included in the 
> zoom stack.
> ie first plot would put "auto" onto the zoom stack as would reset; replot

But "auto" is not a zoom state at all.
I don't see how it fits in with n/p.

> 
> eg
> 
> reset
> set xr [1:50]
> plot datafile w l
> set auto; replot
> set xr [1:10]; replot

Gnuplot keeps no history of previous plots.
Once you say "set xr [1:10]; plot", that's it, boom, all the
previous states are gone.  
The [1:50] resulting plot is not there any more;
the autoscaled resulting plot is not there any more either.

All that n/p/u can do is work with the base state of the
current plot.


> then pressing p hotkey would take me to the unzoomed state not [1:50] as 
> it currently does.

Um.  Are you sure that's what it currently does? 
The sequence of commands you give above does not
act that way when I try it here.
I don't recall ever seeing anything like you describe.


> a second "p" would then take me to [1:50]
> 
> Although set auto is the "unzoomed" state it is a finite scaling option 
> that has been viewed and likely explicitly set.
> 
> The special treatment of this scaling is disrouting and frequently 
> rather inconvenient.
> 
> I hope that's clearer.

It's clearer in the sense that you really do want a scaling history.
But the program doesn't currently keep anything of the sort,
so it would be a major change.  About the same difficulty as
the recurring request for zoomable multiplots, and for much
the same reason.  The necessary information is not available.

	Ethan

Re: prev/next scaling history

[<pl...@pi...>]

On 08/31/13 01:47, sfeam <Ethan A Merritt> wrote:
> On Friday, 30 August, 2013 21:45:50 pl...@pi... wrote:
>> Hi,
>>
>> this is only a niggle but a niggle that bugs me every day and every time
>> I use gnuplot.
>>
>> Why isn't "auto-scale" included in the history of scaling values stored
>> for the previous/next scale feature.
>>
>> eg
>>
>> reset
>> plot datafile w l
>> set xr [1:10]; replot
>>
>> now in an interactive terminal (eg wxt) I hit "p" but instead of it
>> returning to autoscale it jumps to some scaling I used yesterday on a
>> different plot. ie , the last NON autoscale setting of xr.
>>
>> Equally, if I explicitly set 'auto' and then zoom to some other setting,
>>    it does not get counted next time I do 'previous'.
>>
>> Is there a problem with including auto as a value in the scaling history?
>
> Could it be that you are looking for the "u" hot key?
>
> 	Ethan
>
>

Thanks but no.

  p              `builtin-zoom-previous` go to previous zoom in the zoom 
stack
  u              `builtin-unzoom`

I'm talking about the unzoomed (autoscaled) state being included in the 
zoom stack.
ie first plot would put "auto" onto the zoom stack as would reset; replot

eg

reset
set xr [1:50]
plot datafile w l
set auto; replot
set xr [1:10]; replot


then pressing p hotkey would take me to the unzoomed state not [1:50] as 
it currently does.
a second "p" would then take me to [1:50]

Although set auto is the "unzoomed" state it is a finite scaling option 
that has been viewed and likely explicitly set.

The special treatment of this scaling is disrouting and frequently 
rather inconvenient.

I hope that's clearer.



regards, Peter.

Re: prev/next scaling history

[sfeam <E. A Merritt> <sf...@us...>]

On Friday, 30 August, 2013 21:45:50 pl...@pi... wrote:
> Hi,
> 
> this is only a niggle but a niggle that bugs me every day and every time
> I use gnuplot.
> 
> Why isn't "auto-scale" included in the history of scaling values stored
> for the previous/next scale feature.
> 
> eg
> 
> reset
> plot datafile w l
> set xr [1:10]; replot
> 
> now in an interactive terminal (eg wxt) I hit "p" but instead of it
> returning to autoscale it jumps to some scaling I used yesterday on a
> different plot. ie , the last NON autoscale setting of xr.
> 
> Equally, if I explicitly set 'auto' and then zoom to some other setting,
>   it does not get counted next time I do 'previous'.
> 
> Is there a problem with including auto as a value in the scaling history?

Could it be that you are looking for the "u" hot key?

	Ethan


> 
> 
> regards, Peter.
> 
> 
> 
> ----------------------------------------------------------------------------
> -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

prev/next scaling history

[<pl...@pi...>]

Hi,

this is only a niggle but a niggle that bugs me every day and every time 
I use gnuplot.

Why isn't "auto-scale" included in the history of scaling values stored 
for the previous/next scale feature.

eg

reset
plot datafile w l
set xr [1:10]; replot

now in an interactive terminal (eg wxt) I hit "p" but instead of it 
returning to autoscale it jumps to some scaling I used yesterday on a 
different plot. ie , the last NON autoscale setting of xr.

Equally, if I explicitly set 'auto' and then zoom to some other setting, 
  it does not get counted next time I do 'previous'.

Is there a problem with including auto as a value in the scaling history?


regards, Peter.

Re: interactive game demo for gnuplot

[Ethan A M. <sf...@us...>]

On Monday, August 26, 2013 11:52:47 am Juhász Péter wrote:
> On Sun, 2013-08-25 at 16:51 -0700, sfeam (Ethan Merritt) wrote:
> > On Sunday, 25 August 2013, Juhász Péter wrote:
> 
> [snip]
> 
> > The only thing I find surprising or unexpected here is that
> > qt is faster than both wxt and x11. 
> > X11 with no pause is slightly faster than in earlier versions, 
> > but I think that is likely due to Dima Kogan's speed optimizations.
> 
> About those, see the next attachment.
> 
> ./metaball1.sh > foo; gnuplot foo
> 
> With earlier versions the animation is quite smooth. With the current
> cvs it's glacial. So those optimizations may backfire in some cases.

It's glacial because your demo puts it in a poll/wait loop
where each poll has the 1 msec timeout that I mentioned earlier.
If I reset that timeout to zero, then the timing for current cvs
is comparable to earlier versions:

$ time gnuplot_4.4.4 foo
  3.156u 0.506s 0:04.37 83.5% 
$ time gnuplot_4.6.3 foo
  4.525u 0.517s 0:05.16 97.4% 
$ time ~/cvs/gnuplot-cvs/src/gnuplot foo
  3.440u 0.721s 0:04.39 94.7%   

It seems the 1 msec delay was a bad idea.
I'll make it a defined constant in term_api.h, set it to 0 by default,
and update CVS so you can test it.
 
> Interestingly, the more obvious ./metaball1.sh | gnuplot - is uselessly
> slow in all cases, because gnuplot echoes all commands to the terminal,
> but even with redirecting the output to /dev/null it is slower than in
> the file-reading case.

Perhaps we should add a command line option  -noprompt
or something like that to suppress the echo if it is not wanted.

> (about this demo: it's adapted from a demo a colleague of mine wrote for
> his project called animator, http://repo.hu/projects/animator/ )

  nice!

> 
> Peter


	Ethan

Re: interactive game demo for gnuplot

[Juhász P. <pet...@gm...>]

On Sun, 2013-08-25 at 16:51 -0700, sfeam (Ethan Merritt) wrote:
> On Sunday, 25 August 2013, Juhász Péter wrote:

[snip]

> The only thing I find surprising or unexpected here is that
> qt is faster than both wxt and x11. 
> X11 with no pause is slightly faster than in earlier versions, 
> but I think that is likely due to Dima Kogan's speed optimizations.

About those, see the next attachment.

./metaball1.sh > foo; gnuplot foo

With earlier versions the animation is quite smooth. With the current
cvs it's glacial. So those optimizations may backfire in some cases.

Interestingly, the more obvious ./metaball1.sh | gnuplot - is uselessly
slow in all cases, because gnuplot echoes all commands to the terminal,
but even with redirecting the output to /dev/null it is slower than in
the file-reading case.

(about this demo: it's adapted from a demo a colleague of mine wrote for
his project called animator, http://repo.hu/projects/animator/ )

Peter

Re: interactive game demo for gnuplot

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

>>   For example, the up-arrow seems to move all the blocks
>> downward out of the window, but I don't see that the up-arrow is
>> "binded" to anything in the xixit.plt code.
>
> Isn't that the expected plot scrolling action?

yes, it's scrolling, thus this default action needs to be bind to "nothing".

--
Petr

Re: interactive game demo for gnuplot

[<pl...@pi...>]

On 08/26/13 07:34, Daniel J Sebald wrote:
>   For example, the up-arrow seems to move all the blocks
> downward out of the window, but I don't see that the up-arrow is
> "binded" to anything in the xixit.plt code.

Isn't that the expected plot scrolling action?

/Peter

Re: interactive game demo for gnuplot

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

>> Looking forward to Tetris in gnuplot!
> I couldn't resist the challenge...
>
> It's not "real" Tetris but a variant called Xixit that I used to play a
> lot on my 486.

Fantastic!!!

Now it runs slightly better on qt than on x11.

In the setup, I propose
- bind the up arrow to nothing 
- bind also normal +/- to faster/slower
- unset mouse

> (I decided against Tetris because I had doubts about the legal status of a 
> reimplementation.)

I don't think there are any nowadays; there is also tetris as a vim plugin.

> I also have doubts whether it should be included in the demo suite: the
> game logic is sufficiently complex that it begins to strain the limits
> of gnuplot. Well, theoretically, we have conditional execution,
> variables and eval in gnuplot, so it can do anything, but the point is
> whether it is sensible to do so - and if someone said this example is
> not sensible, I'd have to agree.

I think there can be a subdirectory games/ in the demo directory. And on web 
page as well.

---
PM

Re: interactive game demo for gnuplot

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

On 08/25/2013 06:20 PM, sfeam (Ethan Merritt) wrote:
> On Sunday, 25 August 2013, Daniel J Sebald wrote:
>> As for the demo, updating gnuplot_x11 via the install makes things
>> worse.  xixit.plt doesn't create any type of plot (gnuplot_x11 doesn't
>> appear).
>
> Oops. Sorry.
> There was a line missing from x11.trm in yesterday's cvs version.
> It would hang waiting for terminal input if the input was from a
> file but the terminal was x11.  Not good.
> Fixed in CVS as of a minute ago.
>
>> Huh, after running some demos, gnuplot now behaves like normal at the
>> shell command line...but it still has the super fast redrawing.
>
> I have not yet seen any case of "super fast redrawing".
> Could you explain in more detail?
>
> 	thanks for testing!
>
> 		Ethan

OK, with the latest code the shell command line is working properly 
again.  Thanks Ethan.

As for the redrawing, it is simply that the position coordinates at the 
bottom of the page are redrawn superfast and similarly the cursor icon 
flickers between the cross and the busy symbol.

Looking more closely at the xixit.plt file, it looks like there are some 
bugs to work out yet.  The reason this is being refreshed so quickly is 
that a redraw is forced every time through the loop.  When I comment 
that out:

	iter = iter + 1
#	do_redraw = 1

	# and finally show the new state if needed
	if (do_redraw) {
		eval redraw
		do_redraw = 0
		replot
	}

things behave more nicely.  I've also come across the situation where I 
get this error:

gnuplot> block_7_-1 = tc

because

		"j = ymin;".\

and

block(i, j) = sprintf("block_%d_%d", int(i), int(j))

so if ymin becomes negative, that creates a syntax problem.  I'm not 
sure how ymin is becoming negative, but I think there are a lot of key 
bindings that do something to move the plot around.  If those keys 
aren't bound to some bogus function that does nothing, they might cause 
problems.  For example, the up-arrow seems to move all the blocks 
downward out of the window, but I don't see that the up-arrow is 
"binded" to anything in the xixit.plt code.

Pressing and holding down the down-arrow can make the blocks drop past 
the end of the screen and the game seems to get stuck as a consequence, 
but I'm not 100% sure what it is supposed to do to move the stack downward.

I think that the pause can be much longer than 0.005.  If I understand 
the program correctly, the redraw isn't supposed to happen until the 
blocks move, and that seems to be the case when commenting out 
"do_redraw = 1" as above.  The user's keypad action can initiate a 
change in the plot, but I'd think there is no way someone playing the 
game could type keys faster than, say, 1/10 of a second.  I changed 
"pause" to 0.1 and "wait" to 5 and the games seems to run fairly fast. 
(I'd think one would want it to run fast by default and make it 
challenging for the user.)

Dan