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

Re: Request for comments: string variable patchset 2

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

> > 	N = N + 1
> > 	filename = "run_" . N . ".dat"
> > 	print filename
> > 		run_4.dat
> >
> > I am not aware of any problems introduced by either feature,
> > but comments are welcome.
>
> I'm not sure if this one is really needed.  I would rather like to
> have a builtin function "atof" to explicitly cast strings to
> numbers.

I like this, it is like in awk.


> I think the extra features patch can give parse errors.  Consider
>
>   x = "5"
>   set label x, 7

I think that these problems may arise only if there is a "default" option
expected for a given value (like "font" option for "set term post", where
just a string is OK). But this can always be avoided by a particular
keyword.


>  file = "input.dat"
>  value = `some-command @file`

I would propose to ignore macro expansion in `blabla1` and
!blabla2

but allow them in
system('blabla2')
and in
value = execute('blabla1');

Where the execute() is a new command. The user could use what he wants.


> set label sprintf("foo %f %f",var1,var2)

I really prefer the sprintf() way as it is a function like in C & friends.


>>   gnuplot> print sprintf("%i", 5.)
>>   0
>This example doesn't work in C either.

But it works in Octave and awk; I use it there to print an integer part of
the value. I would rather prefer an inteligent version that returns in the
above example 5.

> FOO = floor(FOO)
> "see man page for sprintf"

Well, "man floor" says that result of floor() and ceil() is also a double
value, so it does not help. Just in gnuplot it returns an integer.

---
PM

Re: A shameless plug for string variables

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

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

Re: A shameless plug for string variables

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

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

Re: A shameless plug for string variables

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

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

Re: A shameless plug for string variables

[Juergen W. <wie...@fr...>]

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

Re: Request for comments: string variable patchset 2

[Juergen W. <wie...@fr...>]

Am Mittwoch, 13. Oktober 2004 20:01 schrieb Ethan Merritt:
> > I was expecting more feedback, but maybe "no news = 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.
>
> The string variables "extra features" patch (#1043790)
> only contains two features right now:
>
> 1) String variables are auto-promoted to numbers if they are
>    encountered during evaluation of an arithmetic expression.
>    e.g:   (3 == "1" + "2")  evaluates to TRUE
>
> 2) Integers are auto-promoted to strings if they are encountered
>    during evaluation of a string expression.
>    e.g.:
> 	N = N + 1
> 	filename = "run_" . N . ".dat"
> 	print filename
> 		run_4.dat
>
> I am not aware of any problems introduced by either feature,
> but comments are welcome.


I'm not sure if this one is really needed.  I would rather like to
have a builtin function "atof" to explicitly cast strings to
numbers.  The other way round is done by sprintf.  This patch makes
the difference between numerical and string variables less clear.


Juergen

Re: A shameless plug for string variables

[Juergen W. <wie...@fr...>]

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

Re: Request for comments: command line macros

[Juergen W. <wie...@fr...>]

Am Mittwoch, 13. Oktober 2004 20:15 schrieb Ethan Merritt:
> > I was expecting more feedback, but maybe "no news = 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.
>
> This is a re-implementation of the "userstrings" patch I made
> quite a while back for version 3.8 and still available for 4.0.
> I know people are using this, because they send me Email.
>
> The only issue raised about the earlier patch was that it
> used the symbol "$" for a new purpose, possibly causing
> confusion with multiple existing uses.  So for this new version
> of the patch I have substituted the symbol "@", which is not
> currently accepted by the gnuplot parser at all.
>
> Syntax:
> 	myformat = " 1:2:($4-$5) with lines lt palette"
> 	plot "foo" using @myformat
>
> The parsing code performs a string substitution before
> interpreting the command line, yielding
> 	plot "foo" using  1:2:($4-$5) with lines lt palette
>
> Since @ was not previously legal at all, I can't think how
> this could break any existing scripts or usage.
> But as always, comments are welcome.

It can break scripts because macros are evaluated in "!"- and
backtic shell commands:

  gmx = "foo"
  print `echo us...@gm...`
  ! echo us...@gm...

While the latter doesn't seem to be useful (you can use the system
command instead) the macro expansion in backtics might have some
use.  Consider

  file = "input.dat"
  value = `some-command @file`

I would really appreciate this functionality.  But it is some kind
of inconsistent that

  value = `some-command "@file"`

wouldn't work.  You would have to kludge

  backticcommand = '`some-command "' . file . '"`'
  value = @backticcommand

On the other hand, if you really need the "@" in the backtic
command, you would have to count the quotes.  This isn't really
intuitive.

That said, I think this patch is a small change which clearly
extends the power of gnuplot.


Juergen


PS: Just curious: Is there a reason that string_expand isn't called
from within scanner just like substitute?

Re: A shameless plug for string variables

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

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?

Re: Timeframe for 4.1 release?

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

Petr Mikulik wrote:

> Is there the fix for the "white line" bug in the combination of
> postscript + pm3d + gs8.x + antialiasing? That would be worth it.

Since we only know how to trigger it, but never quite found out *why* it
happens, I don't see any way of fixing that one.  Maybe someone should
file a ghostscript bug for that one?

Re: Timeframe for 4.1 release?

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

> But I do think it is worth putting out a 4.0.2 bugfix release.
>
> It's been 6  months, and we've gotten several real-world
> bug reports for things that had already been fixed in the
> branch-4-0-stable cvs tree.

I think so too.

Is there the fix for the "white line" bug in the combination of postscript +
pm3d + gs8.x + antialiasing? That would be worth it.

--
PM

Re: Timeframe for 4.1 release?

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

On Wednesday 13 October 2004 03:53 am, Per Persson wrote:
> Hi,
> is there a estimated ETA for gnuplot 4.1?

Heh.  Not likely.

But I do think it is worth putting out a 4.0.2 bugfix release.

It's been 6  months, and we've gotten several real-world  
bug reports for things that had already been fixed in the 
branch-4-0-stable cvs tree.

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

Request for comments: command line macros

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

 > On Tuesday 12 October 2004 11:37 pm, Petr Mikulik wrote:
>> 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 = 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.

This is a re-implementation of the "userstrings" patch I made 
quite a while back for version 3.8 and still available for 4.0.
I know people are using this, because they send me Email.

The only issue raised about the earlier patch was that it
used the symbol "$" for a new purpose, possibly causing
confusion with multiple existing uses.  So for this new version
of the patch I have substituted the symbol "@", which is not
currently accepted by the gnuplot parser at all.

Syntax:
	myformat = " 1:2:($4-$5) with lines lt palette"
	plot "foo" using @myformat

The parsing code performs a string substitution before
interpreting the command line, yielding
	plot "foo" using  1:2:($4-$5) with lines lt palette

Since @ was not previously legal at all, I can't think how
this could break any existing scripts or usage.
But as always, comments are welcome.

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

Request for comments: string variable patchset 2

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

> On Tuesday 12 October 2004 11:37 pm, Petr Mikulik wrote:
>> 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 = 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.

The string variables "extra features" patch (#1043790)
only contains two features right now:

1) String variables are auto-promoted to numbers if they are
   encountered during evaluation of an arithmetic expression.
   e.g:   (3 == "1" + "2")  evaluates to TRUE

2) Integers are auto-promoted to strings if they are encountered
   during evaluation of a string expression.
   e.g.:   
	N = N + 1
	filename = "run_" . N . ".dat"
	print filename
		run_4.dat

I am not aware of any problems introduced by either feature,
but comments are welcome.


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

Re: A shameless plug for string variables

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

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

Re: Timeframe for 4.1 release?

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

Per Persson wrote:

> is there a estimated ETA for gnuplot 4.1?

No.  gnuplot has esentially never used time as a planning instrument 
outside those phases when releases were actively being put together.

In other words, the ETA is "whenever we think it's ready".

Timeframe for 4.1 release?

[Per P. <per...@ma...>]

Hi,
is there a estimated ETA for gnuplot 4.1?
I'm working on enhanced text support for aquaterm and I'd like to have 
it well tested by then...

/Per

Re: A shameless plug for string variables

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

> 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

Re: Files BUGS and README.1ST

[Harald H. <h.h...@tu...>]

On Tue, 12 Oct 2004, Hans-Bernhard Broeker wrote:

> On Mon, 11 Oct 2004, Harald Harders wrote:
>
> > I think a mixture of Ethan's and your answer is correct. For arrows within
> > plots,
>
> What exactly would an "array within a plot" be?  What would distinguish
> it from a different type of arrow?

I ment the difference between arrows produced by 'plot' or 'splot' and
arrows produced by 'set arrow'. The first should be clipped to the plot
boundaries while the second should be clipped to the screen boundaries.

> I think the BUGS entry is quite accurate as it is: arrows aren't clipped
> at all, and that's clearly wrong.  The discussion what would be right
> has just proven to be too involved to be written into BUGS.

You are right. We should just keep in mind what is ment.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Files BUGS and README.1ST

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

On Mon, 11 Oct 2004, Harald Harders wrote:

> I think a mixture of Ethan's and your answer is correct. For arrows within
> plots, 

What exactly would an "array within a plot" be?  What would distinguish
it from a different type of arrow?

I think the BUGS entry is quite accurate as it is: arrows aren't clipped
at all, and that's clearly wrong.  The discussion what would be right
has just proven to be too involved to be written into BUGS.

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

Re: Files BUGS and README.1ST

[Harald H. <h.h...@tu...>]

On Mon, 11 Oct 2004, Hans-Bernhard Broeker wrote:

> On Sat, 9 Oct 2004, Harald Harders wrote:
>
> > In the file BUGS, one thing is listed that I don't see as a bug:
> >
> >  *) Arrows and labels are not clipped (2D and 3D).
> >
> > I often use labels and arrows with the intention to generate things
> > outside the plot margins, for example special axis labels (according to
> > the DIN style for diagrams). If they were clipped I would not be able to
> > do so anymore. Thus, I think it is not a bug and should be removed from
> > BUGS.
>
> I think you're misunderstanding what "clipped" means, here.  The thing
> they should be clipped against is the page boundary, not that of the plot.
> Try a
>
> 	set arrow from screen -1, screen -1 to screen 3, screen 3
>
> on various terminals, and I think  you'll see what I mean.

I think a mixture of Ethan's and your answer is correct. For arrows within
plots, a clipping to the plot boundaries should be added while for all
other arrows, the screen boundaries should be used. But shouldn't that be
written to BUGS that way?

Yours
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Files BUGS and README.1ST

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

Petr Mikulik wrote:

>I find this bug also quite boring: I draw a curve with 3 peaks, put arrows
>towards peak maxima, then zoom around one peak -- and there is a garbage of
>the out-of-screen lines.
>
>Would it be possible to clip them?
>

If I recall this discussion correctly, there was an issue about a 
coordinate value cast to an unsigned number.  However, this occurred 
throughout the software and there was no one or two line fix.

Dan

Re: Files BUGS and README.1ST

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

> >  *) Arrows and labels are not clipped (2D and 3D).
> >
> > I often use labels and arrows with the intention to generate things
> > outside the plot margins, for example special axis labels (according to
> > the DIN style for diagrams). If they were clipped I would not be able to
> > do so anymore. Thus, I think it is not a bug and should be removed from
> > BUGS.
>
> That is a good point.  But the bug is real.  If you use zoom on a plot
> containing vectors you will see all sorts of garbage on the screen as the
> individual vectors span the plot margins.  Perhaps the rule should be to
> clip auto-generated arrows (i.e. 'plot with vectors') but not arrows
> requested individually by the user.

I find this bug also quite boring: I draw a curve with 3 peaks, put arrows
towards peak maxima, then zoom around one peak -- and there is a garbage of
the out-of-screen lines.

Would it be possible to clip them?

---
PM

Re: Files BUGS and README.1ST

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

On Sat, 9 Oct 2004, Harald Harders wrote:

> 
> In the file BUGS, one thing is listed that I don't see as a bug:
> 
>  *) Arrows and labels are not clipped (2D and 3D).
> 
> I often use labels and arrows with the intention to generate things
> outside the plot margins, for example special axis labels (according to
> the DIN style for diagrams). If they were clipped I would not be able to
> do so anymore. Thus, I think it is not a bug and should be removed from
> BUGS.

I think you're misunderstanding what "clipped" means, here.  The thing
they should be clipped against is the page boundary, not that of the plot.
Try a

	set arrow from screen -1, screen -1 to screen 3, screen 3

on various terminals, and I think  you'll see what I mean.

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

A shameless plug for string variables

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

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