Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-10 01:19:01
|
So there I was... thinking about two recent requests for gnuplot features. One is now listed as RFE #1040597 "user-definable point symbols" The other one, from comp.graphics.apps.gnuplot, asked how to make a plot where the coordinate pair itself was printed at the appropriate point on the graph. I suddenly realized you can do both of these using the core functionality of the string variable code (now split out as patchset #1043784). Sample plots can be viewed at http://www.bmsc.washington.edu/people/merritt/gnuplot/stringvariables.html User-specific point symbols ------------------------------------- Simple example (equivalent to plot with points using "A" as a point style) plot "foo" using 1:2:"A" with labels Snazzier example plot "foo" using 1:2:( ($2>$3) ? "J" : "D" ) with labels \ font "WingDings" This one plots a smily-face at each point where col 2 is greater than col 3, and a thumbs-down wherever col 2 is less than col 3. Write coord pair on graph ----------------------------------- format = "[%.0f, %.0f]" coords(x,y) = sprintf( format, x, y ) plot "foo" using 1:2:( coords($1,$2) ) with labels |
|
From: Petr M. <mi...@ph...> - 2004-10-13 06:38:59
|
> So there I was... thinking about two recent requests for > gnuplot features. > > One is now listed as RFE #1040597 "user-definable point symbols" > The other one, from comp.graphics.apps.gnuplot, asked how to > make a plot where the coordinate pair itself was printed at the > appropriate point on the graph. > > I suddenly realized you can do both of these using the > core functionality of the string variable code (now split out > as patchset #1043784). > > Sample plots can be viewed at > http://www.bmsc.washington.edu/people/merritt/gnuplot/stringvariables.html The string patch is cool, and looks like complete -- is there still some functionality missing? Should we think to put it to cvs soon? -- Petr |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-13 17:39:27
|
On Tuesday 12 October 2004 11:37 pm, Petr Mikulik wrote:
>=20
> The string patch is cool, and looks like complete -- is there still some
> functionality missing? Should we think to put it to cvs soon?
I was expecting more feedback, but maybe "no news =3D good news".
Yes, the core code can probably go into cvs. The add-ons should
get more discussion. I'll start separate threads for each.
Issues that have been raised regarding the core code (#1043784)
=2D The pre-defined function sprintf() requires some familiarity with=20
C language formats. Harald doesn't like this. I see it as a feature,
since the documentation is basically "see man page for sprintf"
=2D This new code supersedes the current special case hack for
formatting labels:
old: set label "foo %f %f",var1,var2
new: set label sprintf("foo %f %f",var1,var2)
If backwards-compatibilty for this specific case is required,
that may be a problem. Right now the old syntax can cause
parsing errors, so I disabled it.
=2D J=FCrgen Wieferink has pointed out that there may be problems
if a user defines a string variable that duplicates a gnuplot
keyword:
lt =3D "foo"
plot sin(x) with lines lt 3
The intention is that keyword parsing always happens first,
and certainly in this simple case it does and there is no problem.
But it wouldn't surprise me if there are some pathological cases.
I think we can just fix them as they are reported, or tell people
"don't redefine 'with' and expect anything reasonable to happen".
=2D Daniel and Petr pointed out that currently "plot ...007" actually
plots something because it is parsed as "plot 0.0 lt 0 pt 0.007".
After this patch, "plot ...007" will return some error message
about improper operands for string concatenation. I doubt that
this will affect any real world cases.
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Juergen W. <wie...@fr...> - 2004-10-14 19:30:30
|
Am Mittwoch, 13. Oktober 2004 19:39 schrieb Ethan Merritt:
> Issues that have been raised regarding the core code (#1043784)
>
> - The pre-defined function sprintf() requires some familiarity
> with C language formats. Harald doesn't like this. I see it as a
> feature, since the documentation is basically "see man page for
> sprintf"
I tried
gnuplot> print sprintf("%i", 5)
5
gnuplot> print sprintf("%i", 5.)
0
gnuplot> print sprintf("%f", 5.)
5.000000
gnuplot> print sprintf("%f", 5)
0.000000
Are the second and the fourth example meant not to work? In this
short example, this would not be a problem; it's simply the fault of
the user. But is there a way to find out if a variable is an int or
a double/complex (apart from "show var")? I'd prefer not to have to
trigger what type my variable is -- at least as long as I know it is
numerical.
How difficult would it be to get gnuplot to do casts implicitly?
> - This new code supersedes the current special case hack for
> formatting labels:
> old: set label "foo %f %f",var1,var2
> new: set label sprintf("foo %f %f",var1,var2)
> If backwards-compatibilty for this specific case is required,
> that may be a problem. Right now the old syntax can cause
> parsing errors, so I disabled it.
>
> - J=FCrgen Wieferink has pointed out that there may be problems
> if a user defines a string variable that duplicates a gnuplot
> keyword:
> lt =3D "foo"
> plot sin(x) with lines lt 3
> The intention is that keyword parsing always happens first,
> and certainly in this simple case it does and there is no
> problem. But it wouldn't surprise me if there are some
> pathological cases. I think we can just fix them as they are
> reported, or tell people "don't redefine 'with' and expect
> anything reasonable to happen".
You're probably right. I think your idea
gnuplot> tc =3D "label"
gnuplot> set label n tc at 1, 1
warning: ignoring user-defined variable tc=20
because it is also a keyword
^
textcolor colorspec not recognized
is a good one.
Once more: I really like this patch. Apart from the minor issues
above, I think it's really a great thing. Eventually, I'll be able
to use dynamic filenames! And the design seems to be quite mature.
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-14 20:01:08
|
On Thursday 14 October 2004 12:29 pm, Juergen Wieferink wrote:
> Am Mittwoch, 13. Oktober 2004 19:39 schrieb Ethan Merritt:
> > Issues that have been raised regarding the core code (#1043784)
> >
> > - The pre-defined function sprintf() requires some familiarity
> > with C language formats. Harald doesn't like this. I see it as a
> > feature, since the documentation is basically "see man page for
> > sprintf"
>
> I tried
>
> gnuplot> print sprintf("%i", 5)
> 5
> gnuplot> print sprintf("%i", 5.)
> 0
> gnuplot> print sprintf("%f", 5.)
> 5.000000
> gnuplot> print sprintf("%f", 5)
> 0.000000
>
> Are the second and the fourth example meant not to work?
The 2nd example doesn't work in C either.
"see man page for sprintf" :-) :-)
> But is there a way to find out if a variable is an int or
> a double/complex (apart from "show var")? I'd prefer not to have to
> trigger what type my variable is -- at least as long as I know it is
> numerical.
gnuplot already has the standard functions floor(x) and ceil(x),
which will force an integer value. If you are not sure whether FOO
is currently an int, you can do
FOO = floor(FOO)
> How difficult would it be to get gnuplot to do casts implicitly?
The existing code in internal.c maps all arithmetic operations onto
C language statements, so the normal C rules for promoting
ints to doubles apply.
Are you asking if it would be possible to catch mis-matched
format statements at runtime? I suppose so, although this goes
beyond what most languages do.
The string variable code already does a little of that, since
otherwise an attempt to print a number with %s would segfault
immediately.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-14 07:36:59
|
Ethan Merritt wrote:
> Issues that have been raised regarding the core code (#1043784)
> - The pre-defined function sprintf() requires some familiarity with
> C language formats. Harald doesn't like this. I see it as a feature,
> since the documentation is basically "see man page for sprintf"
>
> - This new code supersedes the current special case hack for
> formatting labels:
> old: set label "foo %f %f",var1,var2
Not quite. It was
set label "foo %f", var1, " %f", var2
I.e. only one variable per format string, because that way it can use
gprintf(), and support the gnuplot extension formats like %L/%l, which
use two format strings to print the same number.
> new: set label sprintf("foo %f %f",var1,var2)
> If backwards-compatibilty for this specific case is required,
> that may be a problem. Right now the old syntax can cause
> parsing errors, so I disabled it.
Given that this format has been available for only one officially
released gnuplot version, I have mixed feelings about throwing it out
again immediately. On one hand, it's not some time-honoured thing that
people would be mad at us for breaking deliberately, on the other, it
*is* a brand new feature for some of them, so it's hard to tell how they
will react if we take it away again so soon. What parse errors would
that be, anyway?
|
|
From: Juergen W. <wie...@fr...> - 2004-10-14 18:46:47
|
Am Donnerstag, 14. Oktober 2004 09:36 schrieb Hans-Bernhard Broeker:
> > - This new code supersedes the current special case hack for
> > formatting labels:
> > old: set label "foo %f %f",var1,var2
>
> Not quite. It was
>
> set label "foo %f", var1, " %f", var2
>
> I.e. only one variable per format string, because that way it can
> use gprintf(), and support the gnuplot extension formats like
> %L/%l, which use two format strings to print the same number.
>
> > new: set label sprintf("foo %f %f",var1,var2)
> > If backwards-compatibilty for this specific case is
> > required, that may be a problem. Right now the old syntax can
> > cause parsing errors, so I disabled it.
>
> Given that this format has been available for only one officially
> released gnuplot version, I have mixed feelings about throwing it
> out again immediately. On one hand, it's not some time-honoured
> thing that people would be mad at us for breaking deliberately,
> on the other, it *is* a brand new feature for some of them, so
> it's hard to tell how they will react if we take it away again so
> soon. What parse errors would that be, anyway?
I think the extra features patch can give parse errors. Consider
x = "5"
set label x, 7
You could parse x for "%", but would it be worth it?
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-14 19:40:01
|
On Thursday 14 October 2004 11:46 am, Juergen Wieferink wrote: > > I think the extra features patch can give parse errors. Consider > > x = "5" > set label x, 7 If you are thinking that "5" will be treated as a number in this context, that is not correct. In the case of "set label foo", the parser must explicitly check whether foo is a string variable or an integer variable. Otherwise it is ambiguous whether you are setting a property of label 5, or setting the current label to have text string "5". -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-14 19:34:55
|
On Thursday 14 October 2004 12:36 am, Hans-Bernhard Broeker wrote:
> Not quite. It was
> set label "foo %f", var1, " %f", var2
>
> > new: set label sprintf("foo %f %f",var1,var2)
> > If backwards-compatibilty for this specific case is required,
> > that may be a problem. Right now the old syntax can cause
> > parsing errors, so I disabled it.
> What parse errors would that be, anyway?
I added the old syntax back to the current incarnation of the code
and it seems to work in a quick test. So whatever problem I had
originally during development must have been fixed as a result of
the code evolution.
So it seems not to be a problem after all.
Sorry for the false alarm.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
