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

Re: [gnuplot]: set term size & ConTeXt

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

Ethan Merritt wrote:
> On Monday 19 June 2006 11:11 am, you wrote:
> 
>>As a part of the answer to "what special the ConTeXt terminal can do"
>>(not necessary to "what one would want to have there"), here's an
>>example that I wanted to show some time ago, but the support for such
>>trickery in ConTeXt was first introduced last week:
>>
>>    http://pub.mojca.org/gnuplot/sample/cow/gnuplot-cow.pdf
> 
> 
> [shrug] That kind of plot is possible in many of the terminals now,
> so long as you have a cow glyph to use in the first place.  See the
> stringvars demo.  
> 
> Even fancier variants of positioning glyphs/icons/pictures are possible
> using the "with image" plot mode, but no one has put together a demo
> for this [mis]use yet.  It will become more powerful if/when we add
> support for an alpha channel.  (cc'ed to Dan Sebald; maybe this will
> inspire him).

Nothing like cow plots to motivate someone from the dairy state.  (Actually, it just keeps slipping my mind.)  Well, to get started, I'm going to add IC_RGBA to the list, i.e.,

typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA }
	     t_imagecolor;

and adjust things accordingly to all the terminal drivers.   The advantage of this, as opposed to simply changing IC_RGB to IC_RGBA is data reduction across the pipe in the case of X11 and generally just data reduction whenever.  (I'm always for data reduction when 2D types of elements, e.g. surfaces, images, etc. are in play.)

Dan


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

possible bug in parsing of tics

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

Hi,

I just tried the following tics setting, leaving out <end>. My understanding
of the docs is that this should be valid, but isn't:
---------
set y2tics 0, 0.05 textcolor lt 3
                   ^
expecting comma to separate incr,end
---------
Am I mistaken or is this a bug?

Bastian

Re: thanks and rant

[<tim...@en...>]

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>  =20
>> Ethan Merritt wrote:
>>
>>    =20
>>> I'm sure glad someone around here understands the autotools,
>>> because I sure don't.
>>>
>>> Timoth=E9e, can you make a patch for this change and submit it
>>> to cvs after testing?
>>>
>>>     Ethan
>>>  =20
>>>      =20
>> Sure, I can. (I hope explaining the idea on the list was pedagogical ;=
-) )
>>    =20
>
> That depends on what it is you wanted us to learn.  :-)
>
> Dan
>  =20
You're right, the success is not guaranteed... :-)

TImoth=E9e

Re: thanks and rant

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

Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
>=20
>> I'm sure glad someone around here understands the autotools,
>> because I sure don't.
>>
>> Timoth=E9e, can you make a patch for this change and submit it
>> to cvs after testing?
>>
>>     Ethan
>>  =20
>=20
> Sure, I can. (I hope explaining the idea on the list was pedagogical ;-=
) )

That depends on what it is you wanted us to learn.  :-)

Dan

Re: thanks and rant

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

Timoth=E9e Lecomte wrote:

> True, GNUPLOT_PS_DIR is defined in ./configure.
>=20
> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
> defined (ie when not using ./configure), the best is to make sure that=20
> all custom makefile's do that properly (something else to do before 4.2=
=20
> I think).

You are much more knowledgeable on autotools than I.  In any case, I agre=
e this sounds like the right approach.

Dan

Re: thanks and rant

[<tim...@en...>]

Ethan Merritt wrote:
> I'm sure glad someone around here understands the autotools,
> because I sure don't.
>
> Timoth=E9e, can you make a patch for this change and submit it
> to cvs after testing?
>
> 	Ethan
>  =20
Sure, I can. (I hope explaining the idea on the list was pedagogical ;-) =
)

Best regards,

Timoth=E9e




>> This is a bug, but instead of fixing this bug by another hack with
>> the autotools, I propose to change the whole GNUPLOT_PS_DIR is
>> defined to make it more autotools-compliant :
>>
>> In configure.in, remove the following lines, because no path should
>> be determined at ./configure time (because you should still be able
>> to do 'make --prefix=3D...' or something like that later, and because
>> it needs an ugly hack when --prefix=3D... is not specified by the user=
)
>> :
>>
>>     dnl location of PostScript prolog and adjunct files
>>     GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
>>     eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
>>     AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
>>             [ Directory for PostScript prolog and associated files ])
>>
>> and remove also :
>>
>>     AC_SUBST(GNUPLOT_PS_DIR)
>>
>> In term/Makefile.am, remove the following lines :
>>
>>     # For Unix and MSDOS only
>>     install-data-local:
>>         $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
>>         $(INSTALL_DATA) $(srcdir)/PostScript/*.ps
>> $(DESTDIR)$(GNUPLOT_PS_DIR)
>>
>>     uninstall-local:
>>         @$(NORMAL_UNINSTALL)
>>         echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
>>         rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps
>>
>> In favor of the automake way of doing that :
>>
>>     postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
>>     postscript_DATA =3D 8859-15.ps 8859-1.ps\
>>         8859-2.ps cp1250.ps cp437.ps\
>>         cp850.ps cp852.ps koi8r.ps koi8u.ps\
>>         prologue.ps
>>
>> And finally, in src/Makefile.am, add to AM_CPPFLAGS :
>>       =20
>> -DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"
>>
>>
>> These changes will prevent any problem with the expansions as
>> Johannes experienced (in addition to a lower number of lines !).
>>
>> Best regards,
>>
>> Timoth=E9e
>>    =20

Re: thanks and rant

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

I'm sure glad someone around here understands the autotools,
because I sure don't.

Timoth=E9e, can you make a patch for this change and submit it
to cvs after testing?

	Ethan

On Monday 19 June 2006 11:36 am, Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
> > Dr. Johannes Zellner wrote:
> >> Hi,
> >>
> >> a big thanks for including the depth patch into gnuplot.
> >>
> >> But:
> >>
> >> in trm/post.trm there's a really ugly hardcoded path:
> >>
> >> #ifndef GNUPLOT_PS_DIR
> >> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
> >> #endif
> >
> > But that definition is only if GNUPLOT_PS_DIR is not defined, which
> > should probably have been done through the ./configure process.=20
> > (Although, maybe just complaining that GNUPLOT_PS_DIR is not
> > defined would be just as good.)  Something may have gone wrong with
> > your build.
>
> True, GNUPLOT_PS_DIR is defined in ./configure.
>
> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not
> defined (ie when not using ./configure), the best is to make sure
> that all custom makefile's do that properly (something else to do
> before 4.2 I think).
>
> > and in config.h:
> >
> > /* Directory for PostScript prolog and associated files */
> > #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
> >
> >
> > apparently, prefix should have been expanded there.
>
> This is a bug, but instead of fixing this bug by another hack with
> the autotools, I propose to change the whole GNUPLOT_PS_DIR is
> defined to make it more autotools-compliant :
>
> In configure.in, remove the following lines, because no path should
> be determined at ./configure time (because you should still be able
> to do 'make --prefix=3D...' or something like that later, and because
> it needs an ugly hack when --prefix=3D... is not specified by the user)
> :
>
>     dnl location of PostScript prolog and adjunct files
>     GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
>     eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
>     AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
>             [ Directory for PostScript prolog and associated files ])
>
> and remove also :
>
>     AC_SUBST(GNUPLOT_PS_DIR)
>
> In term/Makefile.am, remove the following lines :
>
>     # For Unix and MSDOS only
>     install-data-local:
>         $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
>         $(INSTALL_DATA) $(srcdir)/PostScript/*.ps
> $(DESTDIR)$(GNUPLOT_PS_DIR)
>
>     uninstall-local:
>         @$(NORMAL_UNINSTALL)
>         echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
>         rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps
>
> In favor of the automake way of doing that :
>
>     postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
>     postscript_DATA =3D 8859-15.ps 8859-1.ps\
>         8859-2.ps cp1250.ps cp437.ps\
>         cp850.ps cp852.ps koi8r.ps koi8u.ps\
>         prologue.ps
>
> And finally, in src/Makefile.am, add to AM_CPPFLAGS :
>       =20
> -DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"
>
>
> These changes will prevent any problem with the expansions as
> Johannes experienced (in addition to a lower number of lines !).
>
> Best regards,
>
> Timoth=E9e
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: thanks and rant

[<tim...@en...>]

Daniel J Sebald wrote:
> Dr. Johannes Zellner wrote:
>  =20
>> Hi,
>>
>> a big thanks for including the depth patch into gnuplot.
>>
>> But:
>>
>> in trm/post.trm there's a really ugly hardcoded path:
>>
>> #ifndef GNUPLOT_PS_DIR
>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>> #endif
>>    =20
>
> But that definition is only if GNUPLOT_PS_DIR is not defined, which sho=
uld probably have been done through the ./configure process.  (Although, =
maybe just complaining that GNUPLOT_PS_DIR is not defined would be just a=
s good.)  Something may have gone wrong with your build.
>
>  =20
True, GNUPLOT_PS_DIR is defined in ./configure.

I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
defined (ie when not using ./configure), the best is to make sure that=20
all custom makefile's do that properly (something else to do before 4.2=20
I think).


> and in config.h:
>
> /* Directory for PostScript prolog and associated files */
> #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
>
>
> apparently, prefix should have been expanded there.
>  =20


This is a bug, but instead of fixing this bug by another hack with the=20
autotools, I propose to change the whole GNUPLOT_PS_DIR is defined to=20
make it more autotools-compliant :

In configure.in, remove the following lines, because no path should be=20
determined at ./configure time (because you should still be able to do=20
'make --prefix=3D...' or something like that later, and because it needs=20
an ugly hack when --prefix=3D... is not specified by the user) :

    dnl location of PostScript prolog and adjunct files
    GNUPLOT_PS_DIR=3D"$pkgdatadir/$VERSION_MAJOR/PostScript"
    eval GNUPLOT_PS_DIR=3D${GNUPLOT_PS_DIR}
    AC_DEFINE_UNQUOTED(GNUPLOT_PS_DIR,"${GNUPLOT_PS_DIR}",
            [ Directory for PostScript prolog and associated files ])

and remove also :

    AC_SUBST(GNUPLOT_PS_DIR)

In term/Makefile.am, remove the following lines :

    # For Unix and MSDOS only
    install-data-local:
        $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
        $(INSTALL_DATA) $(srcdir)/PostScript/*.ps=20
$(DESTDIR)$(GNUPLOT_PS_DIR)

    uninstall-local:
        @$(NORMAL_UNINSTALL)
        echo " rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps"
        rm -f $(DESTDIR)$(GNUPLOT_PS_DIR)/*.ps

In favor of the automake way of doing that :

    postscriptdir =3D $(pkgdatadir)/$(VERSION_MAJOR)/PostScript
    postscript_DATA =3D 8859-15.ps 8859-1.ps\
        8859-2.ps cp1250.ps cp437.ps\
        cp850.ps cp852.ps koi8r.ps koi8u.ps\
        prologue.ps

And finally, in src/Makefile.am, add to AM_CPPFLAGS :
        -DGNUPLOT_PS_DIR=3D\"$(pkgdatadir)/$(VERSION_MAJOR)/PostScript\"


These changes will prevent any problem with the expansions as Johannes=20
experienced (in addition to a lower number of lines !).

Best regards,

Timoth=E9e

Re: Build problem

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

> I suggest you check for extra copies of autoconf or automake, which
> may be hiding the versions you mention.  E.g.
>
>   type -a autoconf
>   type -a automake

Good idea.  But I've checked them using

  autoconf --version
  automake --version

so I should be save.
  
Juergen
  

Re: thanks and rant

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

Dr. Johannes Zellner wrote:
> Hi,
> 
> a big thanks for including the depth patch into gnuplot.
> 
> But:
> 
> in trm/post.trm there's a really ugly hardcoded path:
> 
> #ifndef GNUPLOT_PS_DIR
> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
> #endif

But that definition is only if GNUPLOT_PS_DIR is not defined, which should probably have been done through the ./configure process.  (Although, maybe just complaining that GNUPLOT_PS_DIR is not defined would be just as good.)  Something may have gone wrong with your build.


> this fails when installing gnuplot to any another prefix than /usr/local.

Did you use the installation process?  Or build and then move the executable somewhere?


> 
> and in config.h:
> 
> /* Directory for PostScript prolog and associated files */
> #define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"
> 
> 
> apparently, prefix should have been expanded there.

Or perhaps--as I'm assuming you are using ./prepare prior to ./configure because you must have gotten the latest CVS if you are using the depth patch--it is a problem in your "configure" file.  What are your "ac_default_prefix", "exec_prefix", "prefix" and "program_prefix" defined as?

Dan

thanks and rant

[Dr. J. Z. <joh...@ze...>]

Hi,

a big thanks for including the depth patch into gnuplot.

But:

in trm/post.trm there's a really ugly hardcoded path:

#ifndef GNUPLOT_PS_DIR
#define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
#endif

this fails when installing gnuplot to any another prefix than /usr/local.

and in config.h:

/* Directory for PostScript prolog and associated files */
#define GNUPLOT_PS_DIR "${prefix}/share/gnuplot/4.1/PostScript"


apparently, prefix should have been expanded there.

Best regards,

-- 
Johannes

Re: MISSING and UNDEFINED

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

Just brainstorming here:

> I propose there should be two types of classification strings
> 
> set datafile missing ""
> set datafile undefined ""

 Syntax:
       set datafile missing {"<string>"} {ignore | increment}
                            {connect | break}
       show datafile missing
       unset datafile

where "ignore" means to ignore any point containing the string "<string>", "inc" means to increment any datum fields (useful for leaving spaces in histograms); "connect" means to draw over the point for continuous styles as though the point wasn't present connecting points on either side(s), "break" means to not connect any points present on either side(s) (useful for placing discontinuities in lines).  The default for "missing" is ignore/connect.

The syntax for "undefined" would be similar except the default would be increment/break.

You've probably noticed that there is no difference here other than titles "missing" and "undefined"; we'd just be providing two flags for the user to control.  So really, an alternative would simply be to have a general "flag", e.g., "set datafile flag "NaN" increment break" for which there could be multiple flags.  But, in some sense I kind of like the missing/datafile in that it provides the flexibility but provides just a tad of assumptions (the defaults) to help the user.

Dan

Re: MISSING and UNDEFINED

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

Daniel J Sebald wrote:

> I still am wondering if there is a purpose to having both a datafile 
> missing string and datafile undefined string.  Somehow it seems to me 
> the user could have both such items at the same time and want there to 
> be different behavior based upon type.

As I looked at the right side graphs in the PNGs of a couple emails back, I began to wonder even about the behavior of passing a DF_MISSING point through an action table script.  Why should a point go from type DF_MISSING to DF_UNDEFINED just because it goes through a function first?  I doubt anyone desires or expects that.  I hear the compatibility argument, but sometimes improving what looks to have been consequential behavior is rather tempting.

I propose there should be two types of classification strings

set datafile missing ""
set datafile undefined ""

If the df_readascii() routine finds a missing data string such as "NA", return DF_MISSING.  If it finds an undefined string such as NaN, return DF_UNDEFINED.  If the data point is valid but passed through the using function and then becomes undefined then return, what?, DF_UNDEFINED or DF_BAD?

These definitions all depend on meaningful interpretation on gnuplot's part.  If there are meaningful actions to take based upon whether the data is missing or undefined (and both can be present in the same dataset) then that should be the driving factor.  I can't think of any good examples right now, but somehow I think there is meaningful distinction that there could be missing and undefined data points at the same time.

I think that then there might be good reason to eventually have some options for how to utilize the classification in the plots.  This will sound strange, but maybe there should be a way to configure missing points as undefined OR undefined points as missing (but not interchange both because one could simply redefine to achieve that).  That would be in addition to specifications of how to utilize such points in the graph... well, on second thought, if the two classes can be configure in similar ways there really is no need then to have "treat missing as undefined", etc.

Anyway, my feeling is that the behavior of the data can be made much more useful without too much pain and should be before 4.2.  I can see a missing.dem demo with all kinds of plots illustrating nice handling of missing and undefined data.  I really do think that complaints will be few when changing behavior that looks like it wasn't so much planned as it was simply explained.  Useful, controllable plotting will assuage any complaints.

Dan

Re: MISSING and UNDEFINED

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

Daniel J Sebald wrote:

> I still am wondering if there is a purpose to having both a datafile 
> missing string and datafile undefined string.  Somehow it seems to me 
> the user could have both such items at the same time and want there to 
> be different behavior based upon type.

Oh yeah, that question and also, if you look at the PNG's of the previous email, there is the question of a the line number (or datum) being incremented even when the data point is missing.  Are there some situation where that is undesirable?  For example, if you look at some of the histogram examples in all.dem, you might imagine a table like

"day of week"  "number of coots on lake"
"Monday"  127
"Tuesday"   N/A
"Wednesday"   35
"Thursday"  42
"Friday"  73

where the user may not want an empty blank space between the first and second histogram element.  (In some sense this illustrates the reason for df_readascii() to always return something if it finds a data point rather than ignoring DF_MISSING.  So the higher level routines can have alternative behavior in the future.)

Dan

Re: MISSING and UNDEFINED

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

Daniel J Sebald wrote:

> I just about have one.  I think it is worthwhile to get a discussion going and will serve as a tutorial to the user so we can prevent such bug reports in the future.  Ten minutes...

I placed the patch on S.F. under a new patch entry.

I like these sorts of patches because they are tutorial and a good check some times for when bugs are introduced.  We've caught several that way in the past.

I still am wondering if there is a purpose to having both a datafile missing string and datafile undefined string.  Somehow it seems to me the user could have both such items at the same time and want there to be different behavior based upon type.

Anyway, attached are the PNG images for those not tuned in to the discussion (AFTER THE PATCH).  We can see what Ethan is talking about for the example where the line dips down to (3,2) in the two column data case.

I'd like to add an example or two for the 3D case so we can modify and test proper behavior, but don't want to have so many data points inside the demo file.

Dan

Re: MISSING and UNDEFINED

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

Ethan A Merritt wrote:
> On Sunday 18 June 2006 12:28 pm, you wrote:
> 
>>My feeling is that good programming practice would be to always go 
>>back to the calling routine with some indication of whether this is 
>>a DF_MISSING, DF_UNDEFINED or DF_BAD point and let the calling 
>>routine handle it.
> 
> 
> MISSING and UNDEFINED are indeed returned to the caller, but so far
> the callers treat them the same way (plot2d.cline 446, plot3d.c line 688).

Yes and no.  Yes, currently treated the same way.  (I'm arguing they shouldn't be.)  No, in some instances df_readascii() will decide "this is missing data, so I'm going to go back to the top and read another line of data".  It does this via "line_okay".  I say it should always return something if a non-comment is found.


>>will treat the third point as (2,3) whether "missing" is properly 
>>set or not.
> 
> 
> I consider that a bug.

I'm in agreement with you.


> But it's been documented as behaving like that
> since forever, so I suppose we may be stuck with it.

It is, but as far as being stuck with it.  I think the documentation was one of describing how it just happens to work because it was dealt with specifically.  I see no use to the way that behaves so why have such behavior?  (I know I'm a bit more willing to toss precedent to the wind than others.)


>  To me it makes
> no sense to interpret the different lines of input as having different
> formats. I.e. if you read 2 values, X and Y, from lines 1 and 2 then
> it's crazy to suddenly switch modes and interpret line 3 as having
> an implicit X value and Y in column 1.   But this is a digression.

Exactly.  I don't think it is a digression.


>>But how about for a single column?
>>
>>gnuplot> plot '-'
>>input data ('e' ends) > 10
>>input data ('e' ends) > 20
>>input data ('e' ends) > ?
>>              ^
>>         Bad data on line 3
>>
>>Ooop, that happens when missing is not defined AND when it is defined.
> 
> 
> It works properly here.  Are you sure you correctly set missing?

In the patch I had an extra unnecessary test condition.


>>Should I put together a demo?
> 
> 
> I'm less interested in a demo than in a re-written section for the
> docs.  Once we have agreed on a statement of what is supposed to 
> happen, then we can do any required bug fixing or demo-writing.

I just about have one.  I think it is worthwhile to get a discussion going and will serve as a tutorial to the user so we can prevent such bug reports in the future.  Ten minutes...

Dan

Re: MISSING and UNDEFINED

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

On Sunday 18 June 2006 12:28 pm, you wrote:
> My feeling is that good programming practice would be to always go 
> back to the calling routine with some indication of whether this is 
> a DF_MISSING, DF_UNDEFINED or DF_BAD point and let the calling 
> routine handle it.

MISSING and UNDEFINED are indeed returned to the caller, but so far
the callers treat them the same way (plot2d.cline 446, plot3d.c line 688).

> Here is how it is for the patch in 2D
> 
> plot '-'
> 1 10
> 2 20
> 3 ?
> 4 40
> 5 50
> e
> 
> will treat the third point as (2,3) whether "missing" is properly 
> set or not.

I consider that a bug. But it's been documented as behaving like that
since forever, so I suppose we may be stuck with it.  To me it makes
no sense to interpret the different lines of input as having different
formats. I.e. if you read 2 values, X and Y, from lines 1 and 2 then
it's crazy to suddenly switch modes and interpret line 3 as having
an implicit X value and Y in column 1.   But this is a digression.

> But how about for a single column?
> 
> gnuplot> plot '-'
> input data ('e' ends) > 10
> input data ('e' ends) > 20
> input data ('e' ends) > ?
>               ^
>          Bad data on line 3
> 
> Ooop, that happens when missing is not defined AND when it is defined.

It works properly here.  Are you sure you correctly set missing?

> I would say that it should be ignored in the case of missing being defined... 
> so there is a bug right there even with the patch in my mind.  

Um. I see no bug. It works exactly as you say it should.

> Should I put together a demo?

I'm less interested in a demo than in a re-written section for the
docs.  Once we have agreed on a statement of what is supposed to 
happen, then we can do any required bug fixing or demo-writing.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: MISSING and UNDEFINED

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

Ethan A Merritt wrote:
> On Sunday 18 June 2006 11:19 am, Daniel J Sebald wrote:
> 
>>There are about four bug reports related to handling of 
>>MISSING and/or UNDEFINED data points in a file.
> 
> 
> This was explicitly listed in my original summary of 
> "What's left for a 4.2 release?".
> 
> 
>>I think the patch I sent yesterday is close to a solution.
> 
> 
> The main problem is that there is no clear agreement on
> what the behavior is *supposed* to be.  Without such a 
> statement, it's pointless to produce patches.

I agree with that, and that's why I clarified the way I configured the patch.  Defining what the behavior should be is the big issue, so let's have the list do that in the next day or two.

Currently the documentation does not specify all conditions, I think.

> 
> Version 4.0 does not behave as the docs state.
> Is this a bug in the code, or in the docs?
> Which do we want to fix?
> 
> Disregarding what the docs say, is the handling of
> missing/undefined/garbage data consistent in all code paths?
> 
> FWIW, my own feeling is that a data line containing a field marked
> MISSING  (i.e. it matches the string set by `set datafile missing "X"`)
> should be treated as if the entire line were not there at all, 

You mean "line", as in line of ascii text in the file, I assume.

> save maybe for incrementing the line count.

Hmm, good question, because there is the issue of using the datum number as one of the plotting variables.  In some cases this is desirable (e.g., the geographic statistics on population or somethere simply where there might be a city where information is not available) in others not (e.g., a function relationship).

>  This is not necessarily
> the same as treating it as "undefined" or "garbage in the input field".
> In other words, I think the description in the docs should be changed.
> That is not to say that the code is bug-free, however. 

I don't think it is bug free.  It looks pretty likely that plot3d.c does not behave the same as plot2d.c.

(***) I think one conceptual or philosophical thing we should decide is whether datafile.c can simply toss out an ascii line that is data (i.e., not comment line, or blank line, etc.; those it can ignore in my opinion) or whether it should always go back to the calling code and indicate either DF_MISSING, DF_UNDEFINED or DF_BAD (which looks like something you've added at some point).

My feeling is that good programming practice would be to always go back to the calling routine with some indication of whether this is a DF_MISSING, DF_UNDEFINED or DF_BAD point and let the calling routine handle it.  Now, this is a philosophical issue of having to repeat code vs. the flexibility to have the calling routine behave accordingly if it needs to.  I'm going to go with more flexibility on this one, for no good reason I guess other than future modifications.

...

Perhaps we need more than one character definition.  Maybe we need

set datafile missing "NA"
set datafile undefined "NaN"

Could the difference between these two be that in the case of finding the missing string the line count is not incremented?  In the case of an undefined string it is?  The two can't be the same, of course.

...

Here is how it is for the patch in 2D

plot '-'
1 10
2 20
3 ?
4 40
5 50
e

will treat the third point as (2,3) whether "missing" is properly set or not.  This line count is used as one variable.

But how about for a single column?

gnuplot> plot '-'
input data ('e' ends) > 10
input data ('e' ends) > 20
input data ('e' ends) > ?
              ^
         Bad data on line 3

Ooop, that happens when missing is not defined AND when it is defined.  I would say that it should be ignored in the case of missing being defined... so there is a bug right there even with the patch in my mind.

Let me stop here.  I think the two column behavior with MISSING works in a logical way, but with there being issues I haven't accounted for already for single column data I can see that the approach of discussing the whole thing first isn't going to be the best approach.

How about we do the following?  Let's have a discussion on the topic (***) above about whether we should always return to the calling code as opposed to using the "line_okay" continue method for data.

And let's put together a demo illustrating how MISSING and UNDEFINED works for all the various situations.  We'll move that demo into CVS right away and then people on the list can download, compile and THEN get into a discussion about what behavior should be.  The demo will be plotted examples with "linespoints" set illustrating side-by-side when missing is properly defined and not.  One column and two column data for 2D plots, multiple column data for 3D plots.

Should I put together a demo?

Dan

Re: MISSING and UNDEFINED

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

On Sunday 18 June 2006 11:19 am, Daniel J Sebald wrote:
> There are about four bug reports related to handling of 
> MISSING and/or UNDEFINED data points in a file.

This was explicitly listed in my original summary of 
"What's left for a 4.2 release?".

> I think the patch I sent yesterday is close to a solution.

The main problem is that there is no clear agreement on
what the behavior is *supposed* to be.  Without such a 
statement, it's pointless to produce patches.

Version 4.0 does not behave as the docs state.
Is this a bug in the code, or in the docs?
Which do we want to fix?

Disregarding what the docs say, is the handling of
missing/undefined/garbage data consistent in all code paths?

FWIW, my own feeling is that a data line containing a field marked
MISSING  (i.e. it matches the string set by `set datafile missing "X"`)
should be treated as if the entire line were not there at all, 
save maybe for incrementing the line count.  This is not necessarily
the same as treating it as "undefined" or "garbage in the input field".
In other words, I think the description in the docs should be changed.
That is not to say that the code is bug-free, however. 

> Ethan, could you please have a look at that and maybe 
> we can clear out several bug reports with one patch.    

That has been the idea since the beginning.
But first I'd like to see if the "one patch" can be a
patch to gnuplot.doc, or whether we need to patch the
code anyway.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

MISSING and UNDEFINED

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

There are about four bug reports related to handling of MISSING and/or UNDEFINED data points in a file.  I think the patch I sent yesterday is close to a solution.  Ethan, could you please have a look at that and maybe we can clear out several bug reports with one patch.

Dan

Re: Build problem

[James R. V. Z. <jr...@co...>]

Juergen Wieferink <wie...@fr...> wrote:

>  ./prepare gives me the following error message:
>
>  ===========================================================================
>  configure.in:243: error: possibly undefined macro: AC_MSG_WARN
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
..
> I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
> versions available.  

I suggest you check for extra copies of autoconf or automake, which
may be hiding the versions you mention.  E.g.
  
  type -a autoconf
  type -a automake

               - Jim Van Zandt

[ 969322 ] Set Missing problem with gnuplot 4.0

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

I put a patch on

[ 969322 ] Set Missing problem with gnuplot 4.0

to address this bug.  Probably the best person to look at this is Ethan because he is familiar with that section of datafile code and could tell in a second if it is the correct thing to do.

Be sure to try behavior for with and without "?" set as the missing character for data files.  (See the text associated with the bug report.)  I've made it work the way that seems logical to me, e.g., if the user specifies a using field AND the missing character is not specified then it is treated as DF_UNDEFINED as opposed to simply ignoring the data point.

Really, there is the flexibility with DF_UNDEFINED and DF_MISSING, etc. to program it fairly easily to be any behavior.

I'll attach the patch here as well because I can't attach it to someone elses bug report and don't want to create another that references it.

There is the issue of what to do with 3D data, but let's address that after 2D.

Dan

Re: 'make distcheck' has problems with the wxt files

[<tim...@en...>]

Ethan A Merritt wrote:
> Do you have any comments on Bastian's recent patches for Windows?
>  1505275  	  wgnuplot: scrollwheel support for text window
>  1505261  	  wgnuplot: open file-open-dialog in current dir
>
> The first one sounds obviously good. The second sounds like a UI
> change, but since I'm not a Windows user I can't judge whether it's
> good, bad, or indifferent.
>  =20
I plan to reboot to Windows in a few hours. I will try those if I have ti=
me.
> One more thing:
>
> Even though we have deferred moving 'q' and '<space>' keystroke
> processing back into the core code, I still very much want some way
> to prevent those keystrokes from being trapped by the wxt terminal.
> Can you provide a command line option with similar effect to the
> "gnuplot*ctrlq: on" resource for x11?  Something like
> 	set term wxt ctrlq ...
I can either make an option in the configuration dialog and/or (or is=20
simpler) a command line option. What do you prefer ?

On my side, I have one bug to fix about the way the modifier keys are=20
handled by the wxt terminal (unreliable regarding sequences like ctrl-F1=20
which are caught by KDE to change the virtual desktop, and gnuplot ends=20
up believing that ctrl is still pressed - I will try to solve that in=20
the next few hours). Apart from that, I think the wxt terminal is ready.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Saturday 17 June 2006 10:04 pm, Timoth=E9e Lecomte wrote:
> >
> >     bind icon "paintbox.png" \
> > 	action "load 'linestyles'; set style incr user; replot"
> >  =20
> Yes, yes, it is on my TODO list for post-4.2, and the move to embedded=20
> PNGs for the default icons should not prevent any future extension of=20
> the system.=20

Great!
It's good to have a post-4.2 list also.

But let's wrap up 4.2 first.

Do you have any comments on Bastian's recent patches for Windows?
 1505275  	  wgnuplot: scrollwheel support for text window
 1505261  	  wgnuplot: open file-open-dialog in current dir

The first one sounds obviously good. The second sounds like a UI
change, but since I'm not a Windows user I can't judge whether it's
good, bad, or indifferent.



One more thing:

Even though we have deferred moving 'q' and '<space>' keystroke
processing back into the core code, I still very much want some way
to prevent those keystrokes from being trapped by the wxt terminal.
Can you provide a command line option with similar effect to the
"gnuplot*ctrlq: on" resource for x11?  Something like
	set term wxt ctrlq ...

I want this because I am working on a utility script to allow
interactive placement of labels.  It should not require any changes
to the core code other than a mechanism to allow all keystrokes=20
to be passed back to the user script.  Otherwise we'll have an
interactive labelling script that works for all labels that=20
don't contain a 'q' or a space ;-)

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: 'make distcheck' has problems with the wxt files

[<tim...@en...>]

Ethan A Merritt wrote:
> On Saturday 17 June 2006 09:47 pm, Timoth=E9e Lecomte wrote:
>  =20
>> You can embed a PNG file in the source code after having converted to =
a=20
>> C array. Thus you profit from the compression of the PNG format=20
>> (compared to including XPM files) and you don't have to care about the=
=20
>> paths as the files are included at compile time.
>>    =20
>
> OK by me. =20
>
> But in the abstract, I'd still like to leave open the  possibility
> of users adding their own custom menu icons with bound actions.=20
> As I envision it, the system would work similarly to the
> existing 'bind' command.  E.g. instead of binding to a key, you'd
> be binding to a menu button:
>
>     bind icon "paintbox.png" \
> 	action "load 'linestyles'; set style incr user; replot"
>
> (that doesn't quite work for other reasons, but you get the idea)
>  =20
Yes, yes, it is on my TODO list for post-4.2, and the move to embedded=20
PNGs for the default icons should not prevent any future extension of=20
the system. For custom icons, it seems reasonable to me to ask the user=20
for the full path.

Timoth=E9e