Menu
▾
▴
gnuplot-beta
|
From: Tait <gnu...@t4...> - 2014-04-17 20:30:05
|
The root question is, what do gnuplot's users expect? The example of Python just illustrates one point in the landscape of tools that are used for data analysis, graphing, and numerical computation. My sense is that Python is one of gnuplot's "peers" in this respect, and probably among the most-frequently-used alternatives to gnuplot. I don't think most gnuplot users are familiar with C, so while gnuplot's mannerisms mirror C*, that's meaningless to many users. Users expect division to promote-to-float as necessary because all the other tools they are familiar with do it that way, from their paper and pencil to their calculator to WolframAlpha to R. If gnuplot were were not an anomaly, there would be no surprise and confusion at its current behavior, but there is. If you don't agree with the users-expect argument, consider consistency. Imagine you have: f(x) = (x/2)**2 - x + 3 The return value f(x) will be different depending on x's type. That is not C-like (where functions can have only a single return type) and it makes it difficult to work with f(x), because f(1) is different from f(1.0). (To make f(x) predictable, one must use: f(x) = (1.0*x/2)**2 - 1.0*x + 3.) Currently, function inputs tend to be floats because $1,$2,... return a float, but if gnuplot gains array support it will less commonly true that inputs are already float and so predictability of function output will become more important. Further, gnuplot built-in functions don't exhibit this same ambiguity. For example log10() returns a float, even when it could return an int: log10(100) => 2.0; real() always returns float, even with int arguments: real(1) => 1.0. Users might be misled into expecting the same consistency from user-defined functions. * It's not even true that gnuplot's mannerisms mirror C. C is a statically-typed language. Variables and arguments have a known and unchanging type at the time of their declaration. Gnuplot has no such facilities; types are undeclared and inferred dynamically, which is all the more reason to expect dynamic, rather than static, typing behaviors throughout. > [shrug] > Most of gnuplot's math syntax follows C, and the distinction between > (int) and (float) also follows C. > I don't think that pulling in examples from python is relevant; > languages all have their quirks and even a kitchen-sink tool like > perl cannot simultaneous mimic all of them. |
|
From: Jonathan T. <jt...@as...> - 2014-04-17 21:18:19
|
On Thu, Apr 17, 2014 at 08:29:56PM +0000, Tait wrote:
> The root question is, what do gnuplot's users expect?
[[...]]
> I don't think most gnuplot users are familiar with C, so while
> gnuplot's mannerisms mirror C*, that's meaningless to many users.
> Users expect division to promote-to-float as necessary because all the
> other tools they are familiar with do it that way, from their paper
> and pencil to their calculator to WolframAlpha to R.
The problem is that we don't have any *data* on what "most gnuplot
users" expect, nor on "all the other tools they are familiar with".
We only have conjecture.
For some people "all the other tools" are software environments
(e.g., C, C++, Java, Perl, Python, Fortran, Pascal, PL/I, ...) where
integer division truncates. For some (other) people "all the other
tools" are software environments (e.g., APL, R, pocket calculators,
spreadsheets) where integer division promotes the arguments to float.
The problem is that we don't know the relative sizes of these different
sets of gnuplot users. Nor do we know what fraction of them have
existing scripts which would break if we changed the default.
This topic has been argued for a long time. I think it might be useful
to revive an old suggestion from Dave Denholm:
> Date: Thu, 05 Aug 2004 17:50:43 +0100
> From: Dave Denholm <dde...@es...>
> Reply-To: gnu...@li...
> To: gnu...@li...
> Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
>
> I wonder if it is worth putting in special
> code to detect division of two integer constants, and warn once per
> session. (every evaluation would obviously be too often)
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
|
|
From: <pl...@pi...> - 2014-04-18 08:56:36
|
On 04/17/14 22:29, Tait wrote: > * It's not even true that gnuplot's mannerisms mirror C. C is a > statically-typed language. Variables and arguments have a known and > unchanging type at the time of their declaration. Gnuplot has no such > facilities; types are undeclared and inferred dynamically, which is > all the more reason to expect dynamic, rather than static, typing > behaviors throughout. Indeed, I was going to reply in a similar vein yesterday but did not have time. The problem is that gnuplot us a fuzzy typed language, so it's inappropriate to say it follows C conventions. Clearly having functions that can deliver different results *depending on the data* is a serious flaw. The need for integer division is fairly marginal and is better treated with int() when required. There is an efficiency gain to int. dev. and in a language like C that is intended for writing operating systems every bit counts, but in the sea of fp calcs needed to plot a graph this is a bit irrelevant. (Even in the case of non FPU hardware like earlier ARM platforms.) It seems it should either go one way or the other. Statically typed or full automatic promotion. An unholy mix of the two leads to unacceptable ambiguities, like function results depending on the data. Peter. |
|
From: Philipp K. J. <ja...@ie...> - 2014-04-18 01:25:40
|
> [shrug] > Most of gnuplot's math syntax follows C, and the distinction between > (int) and (float) also follows C. > I don't think that pulling in examples from python is relevant; > languages all have their quirks and even a kitchen-sink tool like > perl cannot simultaneous mimic all of them. > I think this is the point: gnuplot does what C does. 10, even 5 years ago, this reasonably represented users expectations. I am willing to acknowledge that times have moved on. Which brings us to two questions: 1) how much of a problem is this (really)? 2) how difficult would it be to change it (and what weird, unexpected fall-out might it cause)? Regarding 1), I can offer this as "hard" data: on my public gnuplot forum (over at Manning), there have been 166 user questions over the last few years, and as far as I recall, this issue has NOT come up. (Not a huge data set to be sure, but it does not support an urgent need for action.) Personally, it does bite me occasionally, and like Peter, by habit I always append a dot to denominators, and I'd be happy if I didn't have to do that anymore. At the same time, I can think of far fewer situations, where I actually WANTED the integer arithmetic. I have no way of assessing the effort (item 2). However, speaking of Python again, I find it unsettling if a mature program changes some of its fundamental behavior (as Python did/does). I am not convinced this issues is urgent enough. Best, Ph. |
|
From: Tait <gnu...@t4...> - 2014-04-17 23:36:23
|
> > I don't think most gnuplot users ... > > The problem is that we don't have any *data* on what "most gnuplot > users" expect, nor on "all the other tools they are familiar with". > We only have conjecture. Indeed; I speak from my experience. Is your experience different? > For some people "all the other tools" are software environments > (e.g., C, C++, Java, Perl, Python, Fortran, Pascal, PL/I, ...) where > integer division truncates. C, C++, Java, Fortran, and Pascal are statically-typed languages where the types of variables and inputs are fixed. I think it is natural in such languages for operations on integers to produce integers, because it's well-established whether an input is an integer or not, and what type is the output. Perl and Python are dynamic (like gnuplot) and do auto-promote. PL/I, I'll have to plead ignorance about. > This topic has been argued for a long time. I think it might be useful > to revive an old suggestion from Dave Denholm: > > > Date: Thu, 05 Aug 2004 17:50:43 +0100 > > From: Dave Denholm <dde...@es...> > > > > I wonder if it is worth putting in special > > code to detect division of two integer constants, and warn once per > > session. (every evaluation would obviously be too often) I like this idea if we choose not to auto-promote. For those already aware, the warning would get annoying. There should be a way to suppress the warning (by using int()?), and for that matter probably a way to suppress all warnings. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2014-04-18 00:04:38
|
On Thursday, 17 April, 2014 23:36:13 Tait wrote: > > This topic has been argued for a long time. I think it might be useful > > to revive an old suggestion from Dave Denholm: > > > > > Date: Thu, 05 Aug 2004 17:50:43 +0100 > > > From: Dave Denholm <dde...@es...> > > > > > > I wonder if it is worth putting in special > > > code to detect division of two integer constants, and warn once per > > > session. (every evaluation would obviously be too often) Limiting this to integer constants would be tricky. By the time the evaluation code sees the division operation, the two operands have already been evaluated. I don't think there is any way to tell at that point whether these were "constants" or "result of integer expression" or "extracted from a user variable". > I like this idea if we choose not to auto-promote. > > For those already aware, the warning would get annoying. There should > be a way to suppress the warning (by using int()?), and for that matter > probably a way to suppress all warnings. |
|
From: Jonathan T. <jt...@as...> - 2014-04-18 01:50:29
|
Tait wrote:
> I don't think most gnuplot users ...
I replied:
| The problem is that we don't have any *data* on what "most gnuplot
| users" expect, nor on "all the other tools they are familiar with".
| We only have conjecture.
Tait then asked:
> Indeed; I speak from my experience. Is your experience different?
Yes, my experience is different: all the gnuplot users I know come
from C/C++/Fortran backgrounds, where integer division truncates.
But I don't know the background of the "median gnuplot user".
A different point:
I suggested reviving an old suggestion of Dave Denholm:
: Date: Thu, 05 Aug 2004 17:50:43 +0100
: From: Dave Denholm <dde...@es...>
: Reply-To: gnu...@li...
: To: gnu...@li...
: Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
:
: I wonder if it is worth putting in special
: code to detect division of two integer constants, and warn once per
: session. (every evaluation would obviously be too often)
Ethan Merritt pointed out a difficulty with this:
> Limiting this to integer constants would be tricky.
> By the time the evaluation code sees the division operation,
> the two operands have already been evaluated. I don't think there
> is any way to tell at that point whether these were "constants" or
> "result of integer expression" or "extracted from a user variable".
Dave Denholm's original message went on to say:
: Just a quick scan over the action table after parsing, to detect the
: sequence (puchc int), (pushc int), div
:
: gnuplot> show at x/3.0 + 10/3
:
: push x
: pushc 3.0
: div
: pushc 10
: pushc 3
: div
: plus
:
:
: Or even - when appending the 'div' action, peek back at the previous
: two entries.
:
: This isn't going to catch the sequence
:
: x=13
: print x/3
:
: but it might stop the user scratching their head for too long if they
: then resort to typing in things like
:
: print 13/3
Another alternative would be to warn the first time an integer division
yields a result which
(a) is not an integer or very close to an integer,
[We could use the "set zero" value as a tolerance to
define "very close to an integer", i.e.,
very_close_to_integer(x)
:= ( abs(x-nearest_integer_to_x) <= tolerance*max(1,abs(x)) )
(This definition is borrowed from APL; the "max(1,"
is to properly handle values close to zero.)]
AND
(b) is *not* immediately passed to floor(), ceil(), or int()
[these seem to be the only builtin functions which
convert a real number to an integer.]
Implementing (b) would require the division operator to look back down
in the evaluation stack. This is a kludge. But it would warn on
x = 4
y = 5
print x/y
If we did such a warning then probably the warning should mention that
taking int(), floor(), or ceil() of the integer-division-result would
silence the warning. And having a separate control to disable the
warning altogether might also be useful.
But having said all this, my preference is to either
(a) leave the current behavior unchanged, or
(b) introduce a new global mode
set integer_division [ truncates | promotes ]
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
|
|
From: sfeam <sf...@us...> - 2014-04-18 06:19:11
|
On Thursday, 17 April 2014 09:50:14 PM Jonathan Thornburg wrote:
>
> A different point:
>
> I suggested reviving an old suggestion of Dave Denholm:
>
> : Date: Thu, 05 Aug 2004 17:50:43 +0100
> : From: Dave Denholm <dde...@es...>
> : Reply-To: gnu...@li...
> : To: gnu...@li...
> : Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
> :
> : I wonder if it is worth putting in special
> : code to detect division of two integer constants, and warn once per
> : session. (every evaluation would obviously be too often)
>
> Ethan Merritt pointed out a difficulty with this:
>
> > Limiting this to integer constants would be tricky.
> > By the time the evaluation code sees the division operation,
> > the two operands have already been evaluated. I don't think there
> > is any way to tell at that point whether these were "constants" or
> > "result of integer expression" or "extracted from a user variable".
>
> Dave Denholm's original message went on to say:
>
> : Just a quick scan over the action table after parsing, to detect the
> : sequence (puchc int), (pushc int), div
> :
> : gnuplot> show at x/3.0 + 10/3
> :
> : push x
> : pushc 3.0
> : div
> : pushc 10
> : pushc 3
> : div
> : plus
> :
> :
> : Or even - when appending the 'div' action, peek back at the previous
> : two entries.
Ugh. Seriously? That amounts to examining every partial expression
in the stack on the off chance that one of them matches a known pattern.
And it would still fail on the logically equivalent case
gnuplot> show at 10/(1+2)
pushc 10
pushc 1
pushc 2
plus
div
> : This isn't going to catch the sequence
> :
> : x=13
> : print x/3
> :
> : but it might stop the user scratching their head for too long if they
> : then resort to typing in things like print 13/3
Heh. It would probably just add to any confusion.
"Given A=10; B=3; Why does A/B not equal 10/3?"
> Another alternative would be to warn the first time an integer division
> yields a result which
> (a) is not an integer or very close to an integer,
> [We could use the "set zero" value as a tolerance to
> define "very close to an integer", i.e.,
> very_close_to_integer(x)
> := ( abs(x-nearest_integer_to_x) <= tolerance*max(1,abs(x)) )
> (This definition is borrowed from APL; the "max(1,"
> is to properly handle values close to zero.)]
> AND
> (b) is *not* immediately passed to floor(), ceil(), or int()
> [these seem to be the only builtin functions which
> convert a real number to an integer.]
>
> Implementing (b) would require the division operator to look back down
> in the evaluation stack. This is a kludge. But it would warn on
> x = 4
> y = 5
> print x/y
>
> If we did such a warning then probably the warning should mention that
> taking int(), floor(), or ceil() of the integer-division-result would
> silence the warning. And having a separate control to disable the
> warning altogether might also be useful.
>
>
>
> But having said all this, my preference is to either
> (a) leave the current behavior unchanged, or
> (b) introduce a new global mode
> set integer_division [ truncates | promotes ]
>From the perspective of designing a well-behaved syntax,
I'd rather introduce a new operator:
10 / 4 = 2
10 ➗ 4 = 2.5
Of course that has several serious downsides.
- The same people who didn't understand why 10/4 == 2 won't
understand when/why they need to use a different operator.
- It would be more conventional to flip the meanings,
since ➗ is normally taught in the context of integer arithmetic.
- Most people don't have their keyboard set up to type ➗ easily.
Ethan
|
|
From: <pl...@pi...> - 2014-04-18 14:06:20
|
On 04/18/14 08:19, sfeam wrote: > - Most people don't have their keyboard set up to type ➗ easily. > > Ethan Any my default character set does not even display it ! Looks like a rectangle of grey spots. While I too would prefer a Pascal like 'div' as a separate operator ( in fact Pascal's strong variable typing makes it one of the fastest languages to write and debug reliable code , but I digress ), changing the usual fp division to anything other than slash is likely to cause more confusion than anything else. > - The same people who didn't understand why 10/4 == 2 won't > understand when/why they need to use a different operator. The people who do not understand *don't need* a new operator. ;) I really don't see the need for anything more complex than the use of slash as always f.p. division and int() where int.div. is required. Someone may like to scratch their head about byte counting how inefficient it is to do an fp div then a fn call but, as I said before, in the sea of f.p. needed by 'plot' I'm not sure there is a strong argument for a separate operator. (Not that I see any objection to a new op for integer. div.). Peter. |
|
From: Karl-Friedrich R. <mai...@gm...> - 2014-04-18 11:24:45
|
As gnuplot is not a programming language, i think changing the integer division behaviour is well permissible for a major version. And for those who, like myself, misuse gp for general data evaluation and programming, i´d just say "Suck it up!" ;-) One should however set up a few extra warnings (probably in the gp startup messages?), so everybody will catch up on it. I would like to have an explicit integer division symbol, like e.g. pascal "div". It´d be faster, could be overloaded to also accept a real divided/divisor, and just be syntactically clear. (btw., would it be possible to overload modulo "%" to also accept reals?) >>> I wonder if it is worth putting in special >>> code to detect division of two integer constants, and warn once per >>> session. (every evaluation would obviously be too often) > > I like this idea if we choose not to auto-promote. > > For those already aware, the warning would get annoying. There should > be a way to suppress the warning (by using int()?), and for that matter > probably a way to suppress all warnings. > The problem then persist: Most everybody sometimes forgets the dot after a number that is supposed to be a real, and then spends half an hour searching for the bug. Karl |
|
From: Tait <gnu...@t4...> - 2014-04-21 23:57:37
|
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. |
|
From: Ethan A M. <sf...@us...> - 2014-04-22 00:16:52
|
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 |
|
From: Tait <gnu...@t4...> - 2014-04-22 06:13:45
|
> > 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. |
|
From: Karl-Friedrich R. <mai...@gm...> - 2014-04-22 20:56:55
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2014-04-22 21:36:32
|
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 |
|
From: Tait <gnu...@t4...> - 2015-12-11 00:04:35
|
> <1>. Multiple keys
> ...
> set key 1 top right
> set key 2 bottom left
> plot 'data' key 1, '' key 1, '' key 2, '' key 2
>
> Thus, if I have many legends and there's no space to put them together,
> I can divide them into two groups
> "key 1" and "key 2" and put them at different places.
Don't labels (as in, "help set label") offer a more flexible and
comprehensive solution to this problem?
> <2>. Multiple files
>
> Columns from different files can be calculated together. e.g. I have two
> files that have the same format, say, 100 row of (x, y) data, named
> 'file1' and 'file2'. Now I want to plot the different between y columns
> from the two files.
>
> plot 'file1' using 1:($2-column('file2',2)) with lp
There's more that goes into selecting data from a file than merely a
filename and column. Consider "every" and "using", for example,
which are tied with a line, not with a file. This request would
almost seem to demand a cached "virtual column" data structure that
could be populated with arbitrary combinations of
file(s)/every/using/timefmt/etc. and then be given to plot as a
source.
On the other hand, facilities already exist outside of gnuplot to
combine columns from multiple files (e.g. paste, col, or even awk,
bash, perl/python/etc). Small, separate tools are free from the
constraints of gnuplot's syntax and data structures. Languages have
the power to implement any transformation possible, not just a small
handful of pre-imagined example scenarios. And gnuplot can even
invoke these outside utilities, inline, with the plot command via
the "plot '<command'" syntax. I can't see a way to combine multiple
files into a single line without syntactic complexity, hard-to-test
(and hard-to-maintain) combinations of keywords, and backward-
compatibility-breaking changes. Especially when there's
already an existing solution, it doesn't seem worth it.
|
|
From: Liu G. <goo...@gm...> - 2016-07-13 10:56:30
|
I still expect the support for multiple keys.
Using labels is too complicated and inconvenient.
Label is only suitable for adding text, but incapable of adding lines,
points, linepoints, histograms, etc.
For example, I don't know how to use label to mimic the key in the
following plot statement:
plot 'data1' t 'test1' w p pt 7 ps 2, \
'data2' t 'test2' w l lw 2 lt 3,\
'data3' t 'test3' w lp lt 1 lw 2 pt 6 ps 2,\
'data4' t 'test4' w histograms
在 2015-12-11 7:43, Tait 写道:
>> <1>. Multiple keys
>> ...
>> set key 1 top right
>> set key 2 bottom left
>> plot 'data' key 1, '' key 1, '' key 2, '' key 2
>>
>> Thus, if I have many legends and there's no space to put them together,
>> I can divide them into two groups
>> "key 1" and "key 2" and put them at different places.
> Don't labels (as in, "help set label") offer a more flexible and
> comprehensive solution to this problem?
>
|
|
From: Ethan A M. <sf...@us...> - 2016-07-13 17:12:19
|
On Wednesday, 13 July, 2016 18:49:41 Liu Guibin wrote: > I still expect the support for multiple keys. > > Using labels is too complicated and inconvenient. > Label is only suitable for adding text, but incapable of adding lines, > points, linepoints, histograms, etc. > For example, I don't know how to use label to mimic the key in the > following plot statement: > > plot 'data1' t 'test1' w p pt 7 ps 2, \ > 'data2' t 'test2' w l lw 2 lt 3,\ > 'data3' t 'test3' w lp lt 1 lw 2 pt 6 ps 2,\ > 'data4' t 'test4' w histograms > > > 在 2015-12-11 7:43, Tait 写道: > >> <1>. Multiple keys > >> ... > >> set key 1 top right > >> set key 2 bottom left > >> plot 'data' key 1, '' key 1, '' key 2, '' key 2 > >> > >> Thus, if I have many legends and there's no space to put them together, > >> I can divide them into two groups > >> "key 1" and "key 2" and put them at different places. > > Don't labels (as in, "help set label") offer a more flexible and > > comprehensive solution to this problem? Current cvs (version 5.1) supports individual placement of key items. Demo is here: http://gnuplot.sourceforge.net/demo_cvs/custom_key.html Help text is here: gnuplot> help plot title By default each plot is listed in the key by the corresponding function or file name. You can give an explicit plot title instead using the `title` option. Syntax: title <text> | notitle [<ignored text>] title columnheader | title columnheader(N) {at {beginning|end}} {{no}enhanced} [...] The `at` keyword allows you to place the plot title somewhere outside the auto-generated key box. The title can be placed immediately before or after the line in the graph itself by using `at {beginning|end}`. This option may be useful when plotting `with lines` but makes little sense for most other styles. To place the plot title at an arbitrary location on the page, use the form `at <x-position>,<y-position>`. By default the position is interpreted in screen coordinates; e.g. `at 0.5, 0.5` is always the middle of the screen regardless of plot axis scales or borders. The format of titles placed in this way is still affected by key options. See `set key`. Ethan |
