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

Re: Adding normalise to gnuplot

[Jon G. <jo...@th...>]

> > One feature I've been missing from gnuplot is the ability to normalise a
> > dataset; that is, scale all values so that they are in [0:1] by dividing
> > by the maximum value. The attached patch does so by introducing "smooth
> > normal".
> 
> The usual thing to do to "normalise" data would be subtract the mean and 
> divide by std dev.

The reason I want to divide by the max here is that I want to ensure the
plot will always fit within the range I specify. "Proper" normalization
wouldn't do that. In particular, this is useful for live plots where the
shape of the data may change drastically from one plot to the next.

> I think the design philosophy here has been that most data processing is 
> well catered for elsewhere and GP is not trying to be kitchensink, one 
> stop , DP and plotting tool.

I agree. I do feel that some commonly used functions should be included
though, to prevent the need for external tools for common tasks.
I admit normalization (or variations thereof) might not fall into that
category though.

> However, if you want to do this sort of thing it does not require a 
> patch to gnuplot, just use a function.
> 
> max(x) =(if (x>biggest)?biggest=max:(x))
> biggest=-1e-134; plot datafile 1:max($2)
> plot datafile 1:($2/biggest)

Ah, of course, why didn't I think of that?!
Thanks, I'll use this instead.

Jon

Re: Adding normalise to gnuplot

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

On 04/24/14 16:53, Jon Gjengset wrote:
> Hi all,
>
> One feature I've been missing from gnuplot is the ability to normalise a
> dataset; that is, scale all values so that they are in [0:1] by dividing
> by the maximum value. The attached patch does so by introducing "smooth
> normal".


The usual thing to do to "normalise" data would be subtract the mean and 
divide by std dev.

I think the design philosophy here has been that most data processing is 
well catered for elsewhere and GP is not trying to be kitchensink, one 
stop , DP and plotting tool.

However, if you want to do this sort of thing it does not require a 
patch to gnuplot, just use a function.

max(x) =(if (x>biggest)?biggest=max:(x))

biggest=-1e-134; plot datafile 1:max($2)

plot datafile 1:($2/biggest)


/Peter

Re: Adding normalise to gnuplot

[Jon G. <jo...@th...>]

Sorry, that should read "operate on r, not y". 

On April 24, 2014 3:53:48 PM GMT+01:00, Jon Gjengset <jo...@th...> wrote:
> Hi all,
> 
> One feature I've been missing from gnuplot is the ability to normalise
> a
> dataset; that is, scale all values so that they are in [0:1] by
> dividing
> by the maximum value. The attached patch does so by introducing
> "smooth
> normal".
> 
> There is (at least) one problem with the patch in its current form:
> Smoothing should operate on r, not t, when applied to polar plots.
> I'm not entirely sure how this should be implemented though?
> Any pointers would be welcome!
> 
> The patch does not merge cleanly against gnuplot-4.6.5, but by
> removing
> the documentation change and swapping 
>     void gen_interp_frequency __PROTO((struct curve_points *plot));
> and
>     void mcs_interp __PROTO((struct curve_points *plot));
> in the patch file under interpol.h.
> 
> Any feedback welcome,
> Jon
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Adding normalise to gnuplot

[Jon G. <jo...@th...>]

Hi all,

One feature I've been missing from gnuplot is the ability to normalise a
dataset; that is, scale all values so that they are in [0:1] by dividing
by the maximum value. The attached patch does so by introducing "smooth
normal".

There is (at least) one problem with the patch in its current form:
Smoothing should operate on r, not t, when applied to polar plots.
I'm not entirely sure how this should be implemented though?
Any pointers would be welcome!

The patch does not merge cleanly against gnuplot-4.6.5, but by removing
the documentation change and swapping 
    void gen_interp_frequency __PROTO((struct curve_points *plot));
and
    void mcs_interp __PROTO((struct curve_points *plot));
in the patch file under interpol.h.

Any feedback welcome,
Jon

Re: what is the use of "u" in tabulated output?

[<us...@be...>]

Zitat von pl...@pi...:

> On 04/23/14 20:47, Ethan A Merritt wrote:
>
> What is the most consistent with a terminal plot ?  Terminals produce no
> output for NaN points. Producing no output into the table would seem to
> be the best equivalent to me. That is the behaviour I was expecting , at
> least.
>
> There may be a case for outputting NaN in column 1 and the expression in
> col 2 but this could fail , for example , if I was doing the NaN trick
> to prevent evaluation of the expression in a range where it would fail.
>
> f(x)=1/x;
>   plot datafile using   (($1<0)?$1:NaN):(2 * f($1))
>
> so perhaps NaN NaN  ??
>
> I think no output is the most consistent with no point in a plot unless
>   someone can see something I've missed.

I do also agree with you, that no output is more consistent.

Because you're talking about the NaN trick, I would like to raise a  
related discussion: I've been thinking about a new option which allows  
to treat NaN or 1/0 as missing instead of invalid data points. That  
would improve the possibilities to filter data in gnuplot and still  
being able to plot them with lines. I think that won't be much work,  
but how could such an option be called?

Christoph

Re: what is the use of "u" in tabulated output?

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

On 04/24/14 01:19, Ethan Merritt wrote:
>  > What is the most consistent with a terminal plot ?
>
> That may be the wrong way to look at it.


Hi,

Thanks for the extra detail. I was indeed missing the main intended use.

I tend to use this feature to dump out regression results from fit for 
external processing. I can use something like awk to filter out 'u' 
lines but it's just tiresome, not a major problem.

 > So there is a chance to keep more of the original data since it isn't 
filtered by the current axis ranges

This again raises the question of what happens if a range or a using ($1 
< .....)  is intended  to avoid a singularity or some other region where 
the ordinate is ill-defined.

Couldn't this potentially create a div_zero exception or an overflow, 
that had been specifically excluded by the user, that would crash the 
plot command ?

Peter

Re: what is the use of "u" in tabulated output?

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

On 04/23/14 20:47, Ethan A Merritt wrote:
>
> On Sunday, 20 April, 2014 10:48:10 pl...@pi... wrote:
>>    HI,
>>
>>
>> I often use conditional using clauses to plot part of a range of data
>>
>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
>>
>> I tried this when writing to a file specified with "set table"  and
>> instead of cutting off the output, it appends garbage data with a "u".
>>
>> help table tells me this means "undefined"
>>
>> I see two problems here. I did not ask for undefined output , I
>> specified NaN.
>>
>> Secondly , what is the possible use of "undefined" values in a data file?
>>
>> 1995.46  1.00914  i
>> 1995.54  1.10947  i
>> 1.98547e-81  4.74363e+170  u
>> 3.75845e+174  7.52884e-24  u
>> 0  2.122e-314  u
>> 0  0  u
>> 0  0  u
>> 1.9771e+161  1.44402e+214  u
>> -1.22337e-44  1.1735e-319  u
>> 1.01887e+189  7.49746e+247  u
>> 5.35166e+199  2.10124e+88  u
>
> I do not know what the original idea was,
> nor do I know if there are existing scripts that depend on the 'u'.
> It does seem pointless to write out total junk values as in your example.
>
> If it helps, version 5 has a new mode "with table" that does what you want.
>
> gnuplot> set samples 11
> gnuplot> set xrange [0:10]
> gnuplot> set table
> gnuplot> plot '+' using ((4<$1&&$1<8) ? NaN : $1) : ($1**2) with table
>   0 0
>   1 1
>   2 4
>   3 9
>   4 16
>   nan 25
>   nan 36
>   nan 49
>   8 64
>   9 81
>   10 100
> gnuplot>
>
> This is not ideal because it requires a separate plot style, which means
> you can't do
>      plot $foo;   set table;   replot
>
> Should tabular output of the regular plot styles be changes to match this?
> What, if anything, depends on the old behavior and would break?
>
> 	Ethan
>
>

Is it a safe bet that no one has a script that relies on meaningless junk?

This was presumably an oversight when NaN was added. Is anyone really 
using this "feature"?

It's more an inconsistency than a howler of a bug, so wouldn't v5 be a 
good opportunity to profit from the relaxation of b/c rules and fix it?

What is the most consistent with a terminal plot ?  Terminals produce no 
output for NaN points. Producing no output into the table would seem to 
be the best equivalent to me. That is the behaviour I was expecting , at 
least.

There may be a case for outputting NaN in column 1 and the expression in 
col 2 but this could fail , for example , if I was doing the NaN trick 
to prevent evaluation of the expression in a range where it would fail.

f(x)=1/x;
  plot datafile using   (($1<0)?$1:NaN):(2 * f($1))

so perhaps NaN NaN  ??

I think no output is the most consistent with no point in a plot unless 
  someone can see something I've missed.

/Peter

Re: what is the use of "u" in tabulated output?

[Ethan M. <eam...@gm...>]

> Is it a safe bet that no one has a script that relies on meaningless junk?

Not the junk values themselves.  But there may be scripts that depend on a
1-to-1 agreement between number of lines in and number of lines out.   This
is the case, for instance, when dumping a matrix or image array.  If you
skip a line just because it contains an undefined or NaN entry then the
whole array grid alignment fails.

> This was presumably an oversight when NaN was added. Is anyone really
using this "feature"?

The 'u' flag was already in the code when it was imported into CVS back in
1999. So no, it doesn't have anything to do with NaN.

That said, I really don't know whether anyone uses it.

> What is the most consistent with a terminal plot ?

That may be the wrong way to look at it.   To the extent that "set table"
is used to produce intermediate data for reading back in later, it is more
important to ask for consistency with the input format.  That's why the
"set table" output writes 1 or 2 blank lines between curves and data
blocks, and why it writes out both INRANGE and OUTRANGE values.  The idea
is not to duplicate that plot that would have produced using the current
axis range, but to save the data so that it can be plotted later perhaps
with different ranges.

===

Let me back up one step and explain why I think it made sense to add the
"plot ... with table" option for version 5.  Previously when you said "set
table", or before that when you said "set terminal table", a [s]plot
command would cause the program to (1) read in whatever data it needed for
the plot, filtering through axis range limits, style-specific
transformations,  etc as it went and then (2) instead of actually plotting
the data it would write to the table file instead.   This 2-step process is
significant because if the program sees a NaN (old style 1/0) in step 1 it
does not store any data values internally - just a flag that the point was
undefined.  So in step 2 there are no values available to write out.  I'm
not sure but I think originally it would have written all zeros rather than
the current bug's random garbage, but either way the only correct item on
the output line is the 'u'.

The new "with table" mode is different.  It kicks in earlier and does the
whole table generation process in a single step.  So there is a chance to
keep more of the original data since it isn't filtered by the current axis
ranges, plot style-specific filtering, and so on.  While the reason it was
proposed in the first place was simply that it can handle more columns than
any "real" plot style, I think these other differences are equally
important.

Re: what is the use of "u" in tabulated output?

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

On Wednesday, 23 April, 2014 21:54:56 pl...@pi... wrote:
> On 04/23/14 21:05, Ethan A Merritt wrote:
> >
> > On Wednesday, 23 April, 2014 20:50:18 pl...@pi... wrote:
> >> On 04/23/14 20:30, Ethan A Merritt wrote:
> >>>
> >>> On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
> >>>> On 04/20/14 10:48, pl...@pi... wrote:
> >>>>>
> >>>>> I often use conditional using clauses to plot part of a range of data
> >>>>>
> >>>>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
> >>>
> >>> [defer discussion of tabular output to a separate reply]
> >>>
> >>>> I've just found out the if I used "NaN" as a string instead of NaN in
> >>>> the using clause I get the result I expected: the data cuts off at the
> >>>> required date.
> >>>>
> >>>> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))
> >>>
> >>> I think that's because you gave a string where a number was expected.
> >>> The fact that the string contained "NaN" rather than, say, "foo" is not
> >>> relevant.
> >>>
> >>>> It seems there is an inconsistency in the way this is being handled.
> >>>
> >>> I agree. This is a bug.  If the program finds a string where a number
> >>> was expected, the numerical value returned to get_data() should be
> >>> NaN rather than some random or left-over value from an earlier line.
> >>> This should get a fix for both 4.6 and 5.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> I would have expected the parser the throw this out since it is
> >> illegitimate input in this context.
> >>
> >> I only tried this to see what would happen when the correct syntax
> >> produced garbage output.
> >>
> >> Why didn't the parser reject it ?
> >
> > It's fine at the level of parsing.  There's nothing intrinsically wrong
> > with reading in a data string rather than a number.  The problem
> > only comes later if you try to use that for something that really does
> > require a numerical value.   The bug is that there is still an old
> > numerical value hanging around from an earlier read operation that
> > is used instead.  That shouldn't happen.
> >
> > 	Ethan
> >
> >
> >
> 
> 
> OK, I was forgetting that a string can be valid as a 'using' specifier 
> for named columns. 

Well yes, but that's not what's happening here.
You are not asking it to read a value from a column named "NaN".
You are asking it to evaluate a value from an in-line expression rather
than from a column, and that in-line expression happens to be the
string constant "NaN".

That's fine if you are going to do something string-like with the value,
but it doesn't work if you actually needed a numerical value.
The bug is that it doesn't fill in a numerical value _at_ _all_.
It just returns the string and leaves the numerical slot full of
whatever was there before - maybe garbage, maybe never initialize,
maybe a previous data value.


> However, here's another oddity:
> 
> gnuplot> plot "-" u ("foo"):2
> input data ('e' ends) > 1 2
> input data ('e' ends) > e
> Warning: empty x range [1.58805e-314:1.58805e-314], adjusting to 
> [1.57217e-314:1.60393e-314]
> Warning: empty y range [2:2], adjusting to [1.98:2.02]
> 
> Why is the string "foo" being evaluated as something close to zero?

Same bug.  The numerical value is meaningless;   you get whatever
contents were there before the data was read from the file.

Basically it's a failure to initialize the return value.
If the program successfully parses a number from the input line
then it's fine.  This is returned.  But if it doesn't successfully
parse a number it returns the uninitialized placeholder.
Very bad, but only triggered by an incorrect plot command.

Fixed now in CVS for both 4.6 and 5.

	Ethan

Re: what is the use of "u" in tabulated output?

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

On 04/23/14 21:05, Ethan A Merritt wrote:
>
> On Wednesday, 23 April, 2014 20:50:18 pl...@pi... wrote:
>> On 04/23/14 20:30, Ethan A Merritt wrote:
>>>
>>> On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
>>>> On 04/20/14 10:48, pl...@pi... wrote:
>>>>>
>>>>> I often use conditional using clauses to plot part of a range of data
>>>>>
>>>>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
>>>
>>> [defer discussion of tabular output to a separate reply]
>>>
>>>> I've just found out the if I used "NaN" as a string instead of NaN in
>>>> the using clause I get the result I expected: the data cuts off at the
>>>> required date.
>>>>
>>>> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))
>>>
>>> I think that's because you gave a string where a number was expected.
>>> The fact that the string contained "NaN" rather than, say, "foo" is not
>>> relevant.
>>>
>>>> It seems there is an inconsistency in the way this is being handled.
>>>
>>> I agree. This is a bug.  If the program finds a string where a number
>>> was expected, the numerical value returned to get_data() should be
>>> NaN rather than some random or left-over value from an earlier line.
>>> This should get a fix for both 4.6 and 5.
>>>
>>> 	Ethan
>>>
>>
>> I would have expected the parser the throw this out since it is
>> illegitimate input in this context.
>>
>> I only tried this to see what would happen when the correct syntax
>> produced garbage output.
>>
>> Why didn't the parser reject it ?
>
> It's fine at the level of parsing.  There's nothing intrinsically wrong
> with reading in a data string rather than a number.  The problem
> only comes later if you try to use that for something that really does
> require a numerical value.   The bug is that there is still an old
> numerical value hanging around from an earlier read operation that
> is used instead.  That shouldn't happen.
>
> 	Ethan
>
>
>


OK, I was forgetting that a string can be valid as a 'using' specifier 
for named columns. You are correct ( as often happens ;) ).


However, here's another oddity:

gnuplot> plot "-" u ("foo"):2
input data ('e' ends) > 1 2
input data ('e' ends) > e
Warning: empty x range [1.58805e-314:1.58805e-314], adjusting to 
[1.57217e-314:1.60393e-314]
Warning: empty y range [2:2], adjusting to [1.98:2.02]


Why is the string "foo" being evaluated as something close to zero? If I 
try addition it does not get interpreted as zero, it gets kicked out:

  x=1+"foo"
          Non-numeric string found where a numeric expression was expected


Here's another bug:

gnuplot> plot "-" u ("foo"):2
input data ('e' ends) > 1 2
input data ('e' ends) > 3 4
input data ('e' ends) > e

This produces two '+'  marks at the extreme left of the wxt window: 
outside the plot area !

There is no x-axis labelling nor grid, though I do get y axis and grid 
lines.


Unless you see any mistakes here, maybe these should be split to 
separate messages too.


/Peter.

Re: what is the use of "u" in tabulated output?

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

On Wednesday, 23 April, 2014 20:50:18 pl...@pi... wrote:
> On 04/23/14 20:30, Ethan A Merritt wrote:
> >
> > On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
> >> On 04/20/14 10:48, pl...@pi... wrote:
> >>>
> >>> I often use conditional using clauses to plot part of a range of data
> >>>
> >>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
> >
> > [defer discussion of tabular output to a separate reply]
> >
> >> I've just found out the if I used "NaN" as a string instead of NaN in
> >> the using clause I get the result I expected: the data cuts off at the
> >> required date.
> >>
> >> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))
> >
> > I think that's because you gave a string where a number was expected.
> > The fact that the string contained "NaN" rather than, say, "foo" is not
> > relevant.
> >
> >> It seems there is an inconsistency in the way this is being handled.
> >
> > I agree. This is a bug.  If the program finds a string where a number
> > was expected, the numerical value returned to get_data() should be
> > NaN rather than some random or left-over value from an earlier line.
> > This should get a fix for both 4.6 and 5.
> >
> > 	Ethan
> >
> 
> I would have expected the parser the throw this out since it is 
> illegitimate input in this context.
> 
> I only tried this to see what would happen when the correct syntax 
> produced garbage output.
> 
> Why didn't the parser reject it ?

It's fine at the level of parsing.  There's nothing intrinsically wrong
with reading in a data string rather than a number.  The problem
only comes later if you try to use that for something that really does
require a numerical value.   The bug is that there is still an old
numerical value hanging around from an earlier read operation that
is used instead.  That shouldn't happen.

	Ethan

Re: what is the use of "u" in tabulated output?

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

On 04/23/14 20:30, Ethan A Merritt wrote:
>
> On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
>> On 04/20/14 10:48, pl...@pi... wrote:
>>>
>>> I often use conditional using clauses to plot part of a range of data
>>>
>>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
>
> [defer discussion of tabular output to a separate reply]
>
>> I've just found out the if I used "NaN" as a string instead of NaN in
>> the using clause I get the result I expected: the data cuts off at the
>> required date.
>>
>> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))
>
> I think that's because you gave a string where a number was expected.
> The fact that the string contained "NaN" rather than, say, "foo" is not
> relevant.
>
>> It seems there is an inconsistency in the way this is being handled.
>
> I agree. This is a bug.  If the program finds a string where a number
> was expected, the numerical value returned to get_data() should be
> NaN rather than some random or left-over value from an earlier line.
> This should get a fix for both 4.6 and 5.
>
> 	Ethan
>

I would have expected the parser the throw this out since it is 
illegitimate input in this context.

I only tried this to see what would happen when the correct syntax 
produced garbage output.

Why didn't the parser reject it ?

Peter.

Re: what is the use of "u" in tabulated output?

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

On Sunday, 20 April, 2014 10:48:10 pl...@pi... wrote:
>   HI,
> 
> 
> I often use conditional using clauses to plot part of a range of data
> 
> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
> 
> I tried this when writing to a file specified with "set table"  and 
> instead of cutting off the output, it appends garbage data with a "u".
> 
> help table tells me this means "undefined"
> 
> I see two problems here. I did not ask for undefined output , I 
> specified NaN.
> 
> Secondly , what is the possible use of "undefined" values in a data file?
> 
> 1995.46  1.00914  i
> 1995.54  1.10947  i
> 1.98547e-81  4.74363e+170  u
> 3.75845e+174  7.52884e-24  u
> 0  2.122e-314  u
> 0  0  u
> 0  0  u
> 1.9771e+161  1.44402e+214  u
> -1.22337e-44  1.1735e-319  u
> 1.01887e+189  7.49746e+247  u
> 5.35166e+199  2.10124e+88  u

I do not know what the original idea was,
nor do I know if there are existing scripts that depend on the 'u'.
It does seem pointless to write out total junk values as in your example.

If it helps, version 5 has a new mode "with table" that does what you want.

gnuplot> set samples 11
gnuplot> set xrange [0:10]
gnuplot> set table
gnuplot> plot '+' using ((4<$1&&$1<8) ? NaN : $1) : ($1**2) with table
 0 0
 1 1
 2 4
 3 9
 4 16
 nan 25
 nan 36
 nan 49
 8 64
 9 81
 10 100
gnuplot> 

This is not ideal because it requires a separate plot style, which means
you can't do
    plot $foo;   set table;   replot

Should tabular output of the regular plot styles be changes to match this?
What, if anything, depends on the old behavior and would break?

	Ethan

Re: what is the use of "u" in tabulated output?

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

On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
> On 04/20/14 10:48, pl...@pi... wrote:
> >
> > I often use conditional using clauses to plot part of a range of data
> >
> > plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))

[defer discussion of tabular output to a separate reply]

> I've just found out the if I used "NaN" as a string instead of NaN in 
> the using clause I get the result I expected: the data cuts off at the 
> required date.
> 
> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))

I think that's because you gave a string where a number was expected.
The fact that the string contained "NaN" rather than, say, "foo" is not
relevant.

> It seems there is an inconsistency in the way this is being handled. 

I agree. This is a bug.  If the program finds a string where a number
was expected, the numerical value returned to get_data() should be
NaN rather than some random or left-over value from an earlier line.
This should get a fix for both 4.6 and 5.

	Ethan

Re: Plans for gnuplot version 5 [per-line ranges]

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

On Tuesday, 22 April, 2014 22:57:01 Karl-Friedrich Ratzsch wrote:
> On 22.04.2014 08:13, Tait wrote:
> > In the current versions (4.6p3 or p5), the initial []-enclosed values
> > are taken as the overall x- and y- range.
> >   plot [5:11][3:12] x, x/2+4
> > is equivalent to
> >   set xrange [5:11]; set yrange [3:12]; plot x, x/2+4
> > and a range like [7:9] before the x/2+4 is a syntax error.
> > 
> > Changing this as outlined above (and apparently as-implemented in
> > CVS?) is incompatible because now the [3:12] above would be a syntax
> > error* and the [5:11] would apply only to the x and not to the x/2+4
> > line, and the overall plot x-range is still presumably at its previous
> > setting, or default [-10:10].
> 
> As far as i can see, the behaviour in 50 ist absolutely identical
> from the point of 4.6, also with your example.
> 
> But the new syntax with the "sample" keyword looks rather sketchy to me:
> 
>  plot sample [-1:0] -x, [0:1] x
> 
> Wouldn´t backward compatibility also be achieved by adding a keyword
> to "set xrange", e.g. "set xrange [0:1] axislength", meaning that
> the sampling is to be done per-line, and the axis length be taken
> from xrange?

The "sample [min:max]", as its name suggests, controls the axis being
sampled (usually t or x).  This is particularly relevant for parametric plots,
but does apply to function plots as well.  If you need to distinguish between
the sampled axis (t) and the x axis you can provide separate ranges for
each.   See "help plot sampling" 

> Oh, and i noted that replot still doesn´t accept an explicit range,
> even in "per-line" mode. Would that be possible?

Why would you ever need this?
Wouldn't "set xrange [min:max]; replot" do the same thing?
That's what zoom/unzoom does.

	Ethan

Re: Plans for gnuplot version 5 [per-line ranges]

[Karl-Friedrich R. <mai...@gm...>]

On 22.04.2014 08:13, Tait wrote:
> In the current versions (4.6p3 or p5), the initial []-enclosed values
> are taken as the overall x- and y- range.
>   plot [5:11][3:12] x, x/2+4
> is equivalent to
>   set xrange [5:11]; set yrange [3:12]; plot x, x/2+4
> and a range like [7:9] before the x/2+4 is a syntax error.
> 
> Changing this as outlined above (and apparently as-implemented in
> CVS?) is incompatible because now the [3:12] above would be a syntax
> error* and the [5:11] would apply only to the x and not to the x/2+4
> line, and the overall plot x-range is still presumably at its previous
> setting, or default [-10:10].

As far as i can see, the behaviour in 50 ist absolutely identical
from the point of 4.6, also with your example.

But the new syntax with the "sample" keyword looks rather sketchy to me:

 plot sample [-1:0] -x, [0:1] x

Wouldn´t backward compatibility also be achieved by adding a keyword
to "set xrange", e.g. "set xrange [0:1] axislength", meaning that
the sampling is to be done per-line, and the axis length be taken
from xrange?

Oh, and i noted that replot still doesn´t accept an explicit range,
even in "per-line" mode. Would that be possible?

  Karl

Re: Plans for gnuplot version 5 [per-line ranges]

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

> > I think I remember some discussion a while back about changing plot's
> > syntax to specify a per-line range for plots. Something akin to:
> >   set xrange [-10:10]
> >   plot [0:10] sqrt(x), [-10:0] -log(-x+1)
> > 
> > ... as a substitute for the current approach:
> >   rangefunc(x,min,max,func)=(x>min)&&(x<=max) ? func : 1/0
> >   plot rangefunc(x,0,10,sqrt(x)), rangefunc(x,-10,0,-log(-x+1))
> > 
> > Did that idea ever go anywhere? 
> 
> A variant of this went into CVS more than a year ago.
> 
>    http://gnuplot.sourceforge.net/demo_cvs/piecewise.html

Okay sorry, I forgot that and didn't find it within the archives I
still have handy.

> > Since it's backward-incompatible with the current plot [] syntax, it would
> > probably have to be a major version change.
> 
> In what way is it incompatible? 
> I don't recall seeing any reports of breakage.

In the current versions (4.6p3 or p5), the initial []-enclosed values
are taken as the overall x- and y- range.
  plot [5:11][3:12] x, x/2+4
is equivalent to
  set xrange [5:11]; set yrange [3:12]; plot x, x/2+4
and a range like [7:9] before the x/2+4 is a syntax error.

Changing this as outlined above (and apparently as-implemented in
CVS?) is incompatible because now the [3:12] above would be a syntax
error* and the [5:11] would apply only to the x and not to the x/2+4
line, and the overall plot x-range is still presumably at its previous
setting, or default [-10:10].


* maybe? I suppose gnuplot could implement a per-line y-range by
calculating the point it would draw, then not drawing it if it falls
outside the y-range given for that line.

Re: Plans for gnuplot version 5 [per-line ranges]

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

On Monday, 21 April, 2014 23:57:29 Tait wrote:
> 
> I think I remember some discussion a while back about changing plot's
> syntax to specify a per-line range for plots. Something akin to:
>   set xrange [-10:10]
>   plot [0:10] sqrt(x), [-10:0] -log(-x+1)
> 
> ... as a substitute for the current approach:
>   rangefunc(x,min,max,func)=(x>min)&&(x<=max) ? func : 1/0
>   plot rangefunc(x,0,10,sqrt(x)), rangefunc(x,-10,0,-log(-x+1))
> 
> Did that idea ever go anywhere? 

A variant of this went into CVS more than a year ago.

   http://gnuplot.sourceforge.net/demo_cvs/piecewise.html

> Since it's backward-incompatible with the current plot [] syntax, it would
> probably have to be a major version change.

In what way is it incompatible? 
I don't recall seeing any reports of breakage.

	Ethan

Re: Plans for gnuplot version 5 [per-line ranges]

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

I think I remember some discussion a while back about changing plot's
syntax to specify a per-line range for plots. Something akin to:
  set xrange [-10:10]
  plot [0:10] sqrt(x), [-10:0] -log(-x+1)

... as a substitute for the current approach:
  rangefunc(x,min,max,func)=(x>min)&&(x<=max) ? func : 1/0
  plot rangefunc(x,0,10,sqrt(x)), rangefunc(x,-10,0,-log(-x+1))

Did that idea ever go anywhere? Since it's backward-incompatible with
the current plot [] syntax, it would probably have to be a major
version change.

Re: what is the use of "u" in tabulated output?

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

On 04/20/14 10:48, pl...@pi... wrote:
>
>    HI,
>
>
> I often use conditional using clauses to plot part of a range of data
>
> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
>
> I tried this when writing to a file specified with "set table"  and
> instead of cutting off the output, it appends garbage data with a "u".
>
> help table tells me this means "undefined"
>
> I see two problems here. I did not ask for undefined output , I
> specified NaN.
>
> Secondly , what is the possible use of "undefined" values in a data file?
>
> 1995.46  1.00914  i
> 1995.54  1.10947  i
> 1.98547e-81  4.74363e+170  u
> 3.75845e+174  7.52884e-24  u
> 0  2.122e-314  u
> 0  0  u
> 0  0  u
> 1.9771e+161  1.44402e+214  u
> -1.22337e-44  1.1735e-319  u
> 1.01887e+189  7.49746e+247  u
> 5.35166e+199  2.10124e+88  u
>
>
>   From my using clause I would expect either
>
> NaN [ correct value of 2*fcos($1) ] o
> NaN [ correct value of 2*fcos($1) ] i
>
> or preferable nothing at all , as would reflect the usual terminal
> output for NaN points.
>
>    Version 4.7 patchlevel 0    last modified 2012-10-16
>           Build System: Linux i686
>
>
>
> Thanks , Peter
>


I've just found out the if I used "NaN" as a string instead of NaN in 
the using clause I get the result I expected: the data cuts off at the 
required date.

plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))

It seems there is an inconsistency in the way this is being handled. 
Clearly I should not need two different versions of the plot command.

Peter.

what is the use of "u" in tabulated output?

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

  HI,


I often use conditional using clauses to plot part of a range of data

plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))

I tried this when writing to a file specified with "set table"  and 
instead of cutting off the output, it appends garbage data with a "u".

help table tells me this means "undefined"

I see two problems here. I did not ask for undefined output , I 
specified NaN.

Secondly , what is the possible use of "undefined" values in a data file?

1995.46  1.00914  i
1995.54  1.10947  i
1.98547e-81  4.74363e+170  u
3.75845e+174  7.52884e-24  u
0  2.122e-314  u
0  0  u
0  0  u
1.9771e+161  1.44402e+214  u
-1.22337e-44  1.1735e-319  u
1.01887e+189  7.49746e+247  u
5.35166e+199  2.10124e+88  u


 From my using clause I would expect either

NaN [ correct value of 2*fcos($1) ] o
NaN [ correct value of 2*fcos($1) ] i

or preferable nothing at all , as would reflect the usual terminal 
output for NaN points.

  Version 4.7 patchlevel 0    last modified 2012-10-16
         Build System: Linux i686



Thanks , Peter

Gnuplot-wxt Error on Cygwin_x86

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

Hello

I build cvs version of gnuplot (ChangeLog 2014-04-18 ) with wxt terminal.
The wxGTK-2.8.12 is used.

gnuplot> plot sin(x)

The plot is successful but an error dialog appears and says:

Cannot convert from the charset 'Unknown encoding (-1)'!

The dialog is attached.

Any suggestions?

Regards

Tatsuro

Re: caca terminal for gnuplot.exe

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

--- On Sat, 2014/4/19, Bastian Märkisch  wrote:

> Am 18.04.2014 23:38, schrieb Tatsuro MATSUOKA:
> > Hello
> > For caca terminal on gnuplot.exe (windows console binary),  plot command leads to closing  a command line console and opening a graph windows (actually it is another windows console.) Of course, pressings 'q'  or 'Q' key closes the plot window and recover the command line console.
> >
> > However, for example on the linux, plot command leads to opening a new graph windows.
> > On linux gnuplot works on the terminal, while gnuplot.exe on windows works on the windows console.  I feel that the behaviors on the linux and on the  windows are not consistent.
> >
> 
> Shrug. The behaviour really depends on the libcaca driver. On Linux, 
> 'gl' and 'x11' open a new window, whereas 'slang' and 'ncurses' don't. 
> Windows console mode gnuplot just uses the console window which is 
> already available.
> 
>    Bastian
> 
> > For gnuplot.exe, cannot a another console be opened to represent a plot?

Thanks for the reply.
Regards
Tatsuro

Re: caca terminal for gnuplot.exe

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

Am 18.04.2014 23:38, schrieb Tatsuro MATSUOKA:
> Hello
> For caca terminal on gnuplot.exe (windows console binary),  plot command leads to closing  a command line console and opening a graph windows (actually it is another windows console.) Of course, pressings 'q'  or 'Q' key closes the plot window and recover the command line console.
>
> However, for example on the linux, plot command leads to opening a new graph windows.
> On linux gnuplot works on the terminal, while gnuplot.exe on windows works on the windows console.  I feel that the behaviors on the linux and on the  windows are not consistent.
>

Shrug. The behaviour really depends on the libcaca driver. On Linux, 
'gl' and 'x11' open a new window, whereas 'slang' and 'ncurses' don't. 
Windows console mode gnuplot just uses the console window which is 
already available.

   Bastian

> For gnuplot.exe, cannot a another console be opened to represent a plot?
>



> Regards
>
> Tatsuro
>

caca terminal for gnuplot.exe

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

Hello
For caca terminal on gnuplot.exe (windows console binary),  plot command leads to closing  a command line console and opening a graph windows (actually it is another windows console.) Of course, pressings 'q'  or 'Q' key closes the plot window and recover the command line console.

However, for example on the linux, plot command leads to opening a new graph windows.
On linux gnuplot works on the terminal, while gnuplot.exe on windows works on the windows console.  I feel that the behaviors on the linux and on the  windows are not consistent.

For gnuplot.exe, cannot a another console be opened to represent a plot?

Regards

Tatsuro