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

Gnuplot crashing for "hidden3d undefined" ?

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

> Note that the plot command is such that
> there are values of the function outside
> the plot range (z-range).

> Is this a known problem?

See bug [ 1728063 ] hidden lines, scale assertion failure

The patch range checks and looks fine.  The consequence is that when all line segments get pushed off the edge of the screen it effectively outdoes any benefit quadtree gives because all the elements end up in the outermost bin of the division grid.  But why a user would want to push the plot too far off the screen I'm not sure.

Re: PNG term and anti-aliasing of lines

[Allin C. <cot...@wf...>]

On Thu, 15 Nov 2007, Ethan A Merritt wrote:

> On Thursday 15 November 2007 18:09, Allin Cottrell wrote:
> > Could anyone tell me, under what precise conditions do we get 
> > anti-aliasing of (width 1) lines in PNG plots?  (With the 
> > libgd-based driver, that is.)
> 
> Gnuplot asks for anti-aliased lines if and only if the linewidth 
> is 1. After that it's up to libgd.

OK, thanks, that's what I figured.  I'll try grubbing in the libgd 
code to see what's going on.

Allin Cottrell

Re: PNG term and anti-aliasing of lines

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

On Thursday 15 November 2007 18:09, Allin Cottrell wrote:
> Could anyone tell me, under what precise conditions do we get 
> anti-aliasing of (width 1) lines in PNG plots?  (With the 
> libgd-based driver, that is.)

Gnuplot asks for anti-aliased lines if and only if the linewidth is 1.
After that it's up to libgd.

The somewhat out-of-date libgd documentation says:
   Antialiased lines can be drawn on both truecolor and palette-based
   images. However, attempts to draw antialiased lines on highly complex
   palette-based backgrounds may not give satisfactory results, due to
   the limited number of colors available in the palette. Antialiased
   line-drawing on simple backgrounds should work well with palette-based
   images; otherwise create or fetch a truecolor image instead.

I can't think of any reason there would be a difference between
MSWin and linux, only between different versions of libgd.

		Ethan

 
> I ask because (a) on Linux I'm using reasonably current CVS 
> gnuplot with the latest libgd release, but I've never seen 
> anti-aliasing of lines in PNG output, while (b) with a similar 
> setup on Windows PNG output seems to be anti-aliased by default.
> 
> I've just recently twigged to the fact that you can get 
> anti-aliasing in PNG output on Linux if you add the "truecolor" 
> flag to the invocation of the png terminal.  Somehow, though, this 
> flag does not seem to be required to get anti-aliasing on Windows.  
> Is this a libgd quirk, perhaps?
> 
> The motivation for this question is, in part, that I'd like to be 
> able to choose between AA and non-AA PNG output in a 
> platform-independent manner.  Sometimes AA can be nice: it reduces 
> the artifacts you get on certain line segments when plotting "with 
> lines".  On the other hand, AA looks kinda funny when applied to 
> the straight lines that border a plot: they just become "fuzzy".
> So if a plot is mostly straight lines (e.g. "with impulses"), 
> having AA turned off would be preferable.
> 

-- 
Ethan A Merritt

PNG term and anti-aliasing of lines

[Allin C. <cot...@wf...>]

Could anyone tell me, under what precise conditions do we get 
anti-aliasing of (width 1) lines in PNG plots?  (With the 
libgd-based driver, that is.)

I ask because (a) on Linux I'm using reasonably current CVS 
gnuplot with the latest libgd release, but I've never seen 
anti-aliasing of lines in PNG output, while (b) with a similar 
setup on Windows PNG output seems to be anti-aliased by default.

I've just recently twigged to the fact that you can get 
anti-aliasing in PNG output on Linux if you add the "truecolor" 
flag to the invocation of the png terminal.  Somehow, though, this 
flag does not seem to be required to get anti-aliasing on Windows.  
Is this a libgd quirk, perhaps?

The motivation for this question is, in part, that I'd like to be 
able to choose between AA and non-AA PNG output in a 
platform-independent manner.  Sometimes AA can be nice: it reduces 
the artifacts you get on certain line segments when plotting "with 
lines".  On the other hand, AA looks kinda funny when applied to 
the straight lines that border a plot: they just become "fuzzy".
So if a plot is mostly straight lines (e.g. "with impulses"), 
having AA turned off would be preferable.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: table output oddity

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

On Thursday 15 November 2007 13:58, pl...@pi... wrote:
> 
> # Curve 0 of 2, 3600 points
> # Curve title: "ch1"
> ...
> # Curve 1 of 2, 3600 points
> # Curve title: "ch2"
> 
> somewhat illogical and confusing using zero based counting unless there's  
> an overriding reason elsewhere.
> 
> You need to read elsewhre in the file to realise that "Curve 1 of 2" is in  
> fact the last one.

Indeed.

The tabular output code got a band-aid earlier this year,
but it needs more serious care.  See discussion on patch
#1707646    Print curve title in table output

Would you like to make a pass over it and submit a patch?

-- 
Ethan A Merritt

table output oddity

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

Hi,

just noticed a minor anomally in table output:

# Curve 0 of 2, 3600 points
# Curve title: "ch1"
...
# Curve 1 of 2, 3600 points
# Curve title: "ch2"

somewhat illogical and confusing using zero based counting unless there's  
an overriding reason elsewhere.

You need to read elsewhre in the file to realise that "Curve 1 of 2" is in  
fact the last one.

/Peter.

Re: status of alternatives to linetype/pointtype?

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

On Monday 12 November 2007 13:58, Ralf Juengling wrote:
> 
> On Mon, 12 Nov 2007, Ethan A Merritt wrote:
> 
> > As to lines and the choice of existing point types, it has been
> > fully supported since the release of version 4.2 early this year.
> >
> > See for instance:
> > 	http://gnuplot.sourceforge.net/demo_4.2/dashcolor.html
> > 	http://gnuplot.sourceforge.net/demo_4.2/rainbow.html
> >
> 
> Thanks. I have already discovered and used user defined line styles.
> What I was referring to, though, is the line or point pattern that
> is chosen per "linetype" or "pointtype", respectively. Even if one
> defines his own line style like in "dashcolor.dem",
> 
> set style line 1 lt 2 lc rgb "red" lw 3
> 
> this is not completely terminal independent because the meaning
> of "lt 2" is terminal dependent (I'm aware that also rgb is not
> supported by all terminals).

Color and width:
Obviously if the terminal cannot draw color, then nothing gnuplot
does will change that.  If you define a set of line styles with
explicit rgb colors, or simply "lt -1" (black), then they are 
terminal independent up to the point that the physical output
device supports it.

> > If you mean user definition of point types, please ask a more
> > specific question.
> 
> The same holds for point types, as far as I understand (applies
> to plotting styles 'points' or 'linespoints'). It would be nice
> if the interpretation of point types were terminal independent.

Points:
The first 8-10 point types are supposed to be the same up to the
limitations imposed by individual output hardware.  
I've just checked on post/pdf/cairo/png/emf/latex/x11/wxt/win 
They all look pretty much equivalent to me.
Do you have an example of an inconsistency?


Dashes:
I am not aware of any standard definition of dash patterns that
would be terminal-independent in the sense that RGB color is.
I am dubious that we can do any better than we already are.
The following terminals types have some hope of doing similar
things:

post, pdf  The patterns for PostScript and PDF output are defined
           equivalently in gnuplot; the various rendering programs may
           not produce the same output, however.   
cairo      We're still fiddling with the pattern definitions in the new
           support in the current cairo library is not satisfactory.
x11        Defined by your local X11 Resources file

So far as I know, we have little to no control over dash patterns on
other terminals.  If you know otherwise, please submit a patch 
demonstrating how this would work.
 


> > Some options are available there also.
> > See for example the 2nd to last plot of:
> > 	http://gnuplot.sourceforge.net/demo_4.2/stringvar.html
> 
> Thanks. I was not aware of the possibility of using symbols
> from a user-specified font. How is that implemented, though?
> If I create an eps, say, using symbols from user-defined fonts
> for some labels, do I need those fonts installed on the
> machine that I use for viewing/rendering the eps with?

If you simply refer to the font by name, then it must be installed
on the viewing machine or printer. However, you can use the
"fontfile" option to embed the font in the output file. Then there
is no need for a separately installed copy.

Embedding an entire font makes for a large output file, however.
For this purpose it would be better to use symbols from a small font
containing only the symbols you want.  You may be able to use the
"-L" option to the program "ttf2pt1" to create such a minimal font.
I'm still learning to use it myself, so I can't offer more detailed
instructions.


-- 
Ethan A Merritt

Re: status of alternatives to linetype/pointtype?

[Ralf J. <jue...@cs...>]

On Mon, 12 Nov 2007, Ethan A Merritt wrote:

> As to lines and the choice of existing point types, it has been
> fully supported since the release of version 4.2 early this year.
>
> See for instance:
> 	http://gnuplot.sourceforge.net/demo_4.2/dashcolor.html
> 	http://gnuplot.sourceforge.net/demo_4.2/rainbow.html
>

Thanks. I have already discovered and used user defined line styles.
What I was referring to, though, is the line or point pattern that
is chosen per "linetype" or "pointtype", respectively. Even if one
defines his own line style like in "dashcolor.dem",

set style line 1 lt 2 lc rgb "red" lw 3

this is not completely terminal independent because the meaning
of "lt 2" is terminal dependent (I'm aware that also rgb is not
supported by all terminals).


> If you mean user definition of point types, please ask a more
> specific question.

The same holds for point types, as far as I understand (applies
to plotting styles 'points' or 'linespoints'). It would be nice
if the interpretation of point types were terminal independent.


> Some options are available there also.
> See for example the 2nd to last plot of:
> 	http://gnuplot.sourceforge.net/demo_4.2/stringvar.html

Thanks. I was not aware of the possibility of using symbols
from a user-specified font. How is that implemented, though?
If I create an eps, say, using symbols from user-defined fonts
for some labels, do I need those fonts installed on the
machine that I use for viewing/rendering the eps with?

Thanks,
Ralf

Re: status of alternatives to linetype/pointtype?

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

On Monday 12 November 2007 12:34, Ralf Juengling wrote:
> 
> I'm sure this issue has been raised frequently
> in the past: It would be desirable to control
> the appearance of lines and points in a terminal-
> independent way.
> 
> Are there any proposals out there for how to realize this?

As to lines and the choice of existing point types, it has been
fully supported since the release of version 4.2 early this year.

See for instance:
	http://gnuplot.sourceforge.net/demo_4.2/dashcolor.html
	http://gnuplot.sourceforge.net/demo_4.2/rainbow.html

Furthermore, there is a new command
	set style increment user

that tells gnuplot to always choose user-defined line styles
in preference to the default line types (NB: 'style' vs. 'type').
This means that if you load a set of user-defined line styles as
a preface, all your old scripts should still work as before except
that they use the user-defined line styles.

There were a few corner cases in the original release where the
user-defined styles were not used  (3D contours, back-surfaces
of hidden3d plots)  but these have been fixed in 4.2.2

If you mean user definition of point types, please ask a more
specific question.  Some options are available there also.
See for example the 2nd to last plot of:
	http://gnuplot.sourceforge.net/demo_4.2/stringvar.html

-- 
Ethan A Merritt

status of alternatives to linetype/pointtype?

[Ralf J. <jue...@cs...>]

Hi,

I'm sure this issue has been raised frequently
in the past: It would be desirable to control
the appearance of lines and points in a terminal-
independent way.

Are there any proposals out there for how to
realize this?

Thanks,
Ralf

Re: a patch of docs/Makefile.in for cairo.trm

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

On Monday 12 November 2007 01:31, Shigeharu TAKENO wrote:
> shige 11/12 2007
> ----------------
> 
> I think docs/Makefile.in lacks the entry of new terminal driver 
> cairo.trm.

Added to CVS.

	thanks.



> 
> ----- From here -----
> --- gnuplot/docs/Makefile.in.ORG	Mon Nov 12 17:29:27 2007
> +++ gnuplot/docs/Makefile.in	Mon Nov 12 17:28:08 2007
> @@ -111,7 +111,9 @@
>  
>  T = $(top_srcdir)/term/
>  CORETERM = $(T)aed.trm $(T)ai.trm $(T)amiga.trm $(T)apollo.trm \
> -$(T)aquaterm.trm $(T)atariaes.trm $(T)atarivdi.trm $(T)be.trm $(T)cgi.trm \
> +$(T)aquaterm.trm $(T)atariaes.trm $(T)atarivdi.trm $(T)be.trm \
> +$(T)cairo.trm \
> +$(T)cgi.trm \
>  $(T)cgm.trm $(T)corel.trm $(T)debug.trm $(T)djsvga.trm $(T)dumb.trm \
>  $(T)dxf.trm $(T)dxy.trm $(T)eepic.trm $(T)emf.trm $(T)emxvga.trm \
>  $(T)epson.trm $(T)excl.trm $(T)fg.trm $(T)fig.trm $(T)gd.trm \
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

a patch of docs/Makefile.in for cairo.trm

[Shigeharu T. <sh...@ie...>]

shige 11/12 2007
----------------

I think docs/Makefile.in lacks the entry of new terminal driver 
cairo.trm.

----- From here -----
--- gnuplot/docs/Makefile.in.ORG	Mon Nov 12 17:29:27 2007
+++ gnuplot/docs/Makefile.in	Mon Nov 12 17:28:08 2007
@@ -111,7 +111,9 @@
 
 T = $(top_srcdir)/term/
 CORETERM = $(T)aed.trm $(T)ai.trm $(T)amiga.trm $(T)apollo.trm \
-$(T)aquaterm.trm $(T)atariaes.trm $(T)atarivdi.trm $(T)be.trm $(T)cgi.trm \
+$(T)aquaterm.trm $(T)atariaes.trm $(T)atarivdi.trm $(T)be.trm \
+$(T)cairo.trm \
+$(T)cgi.trm \
 $(T)cgm.trm $(T)corel.trm $(T)debug.trm $(T)djsvga.trm $(T)dumb.trm \
 $(T)dxf.trm $(T)dxy.trm $(T)eepic.trm $(T)emf.trm $(T)emxvga.trm \
 $(T)epson.trm $(T)excl.trm $(T)fg.trm $(T)fig.trm $(T)gd.trm \
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Bug? show palette palette does now write to file

[Philipp K. J. <ja...@ie...>]

Thanks. That's helpful!

On Sunday 11 November 2007 12:07, you wrote:
> On Sunday 11 November 2007 11:25, Philipp K. Janert wrote:
> > According to the documentation, I can
> > export a palette to file, but this does not
> > seem to work:
> >
> > set palette defined ( 0 'red', 1 'yellow' )
> > set output "foo"
> > show palette palette 3
> >
> > creates an empty file "foo", but prints the
> > palette values only to the screen.
>
> The command
>   set output "foo"
> controls where the output from the next 'plot' or 'splot' will go,
> not printed output.
>
> What you want is
>   set print "baz"
> which controls where to send the output of subsequent 'print' commands.
>
> Yes, this seems to be an error in the docs.
>
>
> 	Ethan

Re: Bug? show palette palette does now write to file

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

On Sunday 11 November 2007 11:25, Philipp K. Janert wrote:
> 
> According to the documentation, I can
> export a palette to file, but this does not
> seem to work:
> 
> set palette defined ( 0 'red', 1 'yellow' )
> set output "foo"
> show palette palette 3
> 
> creates an empty file "foo", but prints the
> palette values only to the screen.

The command
  set output "foo"
controls where the output from the next 'plot' or 'splot' will go,
not printed output.

What you want is
  set print "baz"
which controls where to send the output of subsequent 'print' commands.

Yes, this seems to be an error in the docs.


	Ethan

-- 
Ethan A Merritt

Bug? show palette palette does now write to file

[Philipp K. J. <ja...@ie...>]

According to the documentation, I can
export a palette to file, but this does not
seem to work:

set palette defined ( 0 'red', 1 'yellow' )
set output "foo"
show palette palette 3

creates an empty file "foo", but prints the
palette values only to the screen.

Version info below.

Best,

		Ph.




gnuplot> show version long

        G N U P L O T
        Version 4.2 patchlevel 2
        last modified 31 Aug 2007
        System: Linux 2.6.18.2-34-default

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from http://www.gnuplot.info/faq/

        Send bug reports and suggestions to
<http://sourceforge.net/projects/gnuplot>

Compile options:
-READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE

DRIVER_DIR
= "/home/janert/Gnuplot/Build/Release-4.2.2/build/libexec/gnuplot/4.2"
GNUPLOT_PS_DIR
=
 "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/PostScript
" HELPFILE
=
 "/home/janert/Gnuplot/Build/Release-4.2.2/build/share/gnuplot/4.2/gnuplot.gi
h"

Re: html code in gnuplot.doc

[Thomas S. <t.s...@fz...>]

a remark regarding the html-version of gnuplot.doc:

calling latex2html with following options

latex2html -html_version=3.2,math -no_math gnuplot.tex

gives nice > and < signs instead of 6#6 and 5#5
(but has maybe other side effects?)
-- 
View this message in context: http://www.nabble.com/html-code-in-gnuplot.doc-tf4766390.html#a13669190
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: html code in gnuplot.doc

[Thomas S. <t.s...@fz...>]

if you don't want to introduce problems when converting to the other
documentation output formats, the only way i can see is:
surround these text passages with meaningful text,
e.g. 'See the ...'
like in the 'seeking-assistance' section:

 Before seeking help, please check the

^  http://www.gnuplot.info/faq/ 
           FAQ (Frequently Asked Questions) list.
^  

which is converted to

 Before seeking help, please check the
 FAQ (Frequently Asked Questions) list.

in the help file.

suppressing the text between the html-tags doesn't
seem to be work (example from the 'index' section):

^ See also web page
^  http://www.gnuplot.info/demo/multimsh.html 
^ splot with indices demo.
^  

is converted to nothing in the help-file (which would be fine),
but results in an empty (=useless) hypertext reference in
e.g. the latex-file (produced with 'make gnuplot.dvi').


Petr Mikulik wrote:
> 
> There is a "strange" text printed on screen for "help xxx" if the section 
> "xxx" contains the hypertext. For example, try:
> 
> 
> help filledcurves:
> 
>  Example of filling the area between two input curves.
>  fill between curves demo.
> 
> 
> help uniq:
> 
>  resulting points are then connected by straight line segments.
>  demos
> 
> 
> help boxerrorbars:
> 
>  See also
>  errorbar demo.
> 
> 
> Does somebody have an idea how to make the output more "beutiful"?
> 
> ---
> PM
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/html-code-in-gnuplot.doc-tf4766390.html#a13667024
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: simple feature request for fit

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

Hi,

quite a while ago Thomas Mattison posted patch
"[ 1445064 ] Gnuplot fitting improvements"
on sourceforge. Amongst many other things it
includes

 > 7. New one-line progress-report,
 > revert by FIT_CLASSIC_PROGRESS = 1
 >
 > 8. New final fit parameter report format,
 > revert by FIT_CLASSIC_RESULT = 1

It's a large patch which changes quite a lot
of things, which in my opinion kept it from
being included. Also the control variables
it introduces should be converted to options
to 'set fit'.
I started to split the patch into smaller
pieces, which could be included more easily.
Due to lack of time I haven't been able to
finish it though.

Bastian


pl...@pi... schrieb:
> Hi,
> 
> fit is one of the best features of gnuplot but its rather verbose output  
> spamming the console can be annoying.
> 
> I frequently have useful output from print statements in a gnuplot file  
> that I need to see. Having to scoll back several pages and parse  
> screenfuls of junk to read two consecutive lines of output is obstructive.
> 
> Clearly the fit output can be very relevant and useful but if we dont need  
> to see the dirty details of every iteration every time it runs, an option  
> to for a silent run would be nice.
> 
> printing the final parameter values would probably suffice much of the  
> time.
> 
> regards, Peter.
> 

simple feature request for fit

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

Hi,

fit is one of the best features of gnuplot but its rather verbose output  
spamming the console can be annoying.

I frequently have useful output from print statements in a gnuplot file  
that I need to see. Having to scoll back several pages and parse  
screenfuls of junk to read two consecutive lines of output is obstructive.

Clearly the fit output can be very relevant and useful but if we dont need  
to see the dirty details of every iteration every time it runs, an option  
to for a silent run would be nice.

printing the final parameter values would probably suffice much of the  
time.

regards, Peter.

Re: Heavy weight deps (was y scaling error)

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

On Thu, 08 Nov 2007 02:16:22 +0100, Allin Cottrell <cot...@wf...>  =

wrote:

> On Thu, 8 Nov 2007, pl...@pi... quoted:
>
>> >> It's a pity that enable/disable and with/without aren't treated
>> >> as synonyms.  How is anyone supposed to remember which one goes
>> >> with which option?
>> >
>> > Not at all.  Just like nobody is supposed to remember the list of
>> > available --enable/--disable/--with{,out} options.  That's what
>> > ./configure --help is for (./configure --help=3Dshort if you alread=
y  =

>> know
>> > the generic configure options).
>
> and wrote:
>>
>> So no-one is likely to remember the whole list, but accepting we
>> can remember a few we need to include/exclude it would be nice
>> not add to the burden with apparently arbitary on/off option
>> names. Is there a feature here we are missing the point of?
>
> I'm not sure this is totally compelling, but I think the
> traditional distinction in the autoconf context is
>
> * enable/disable is a simple binary feature toggle
>
> * with/without implies inclusion or not of functionality provided
>   by a third-party library or app, and implies an optional
>   parameter to "with", namely the path to the third-party
>   something, as in
>
>   --with-ssl=3D/opt/openssl
>
> Allin Cottrell
>

Thanks for that explaination, that does go someway to explaining the  =

difference but does not seem to apply generally to gnuplot since several=
  =

"with" options are not due to external deps.

non exhaustive list:

   --with-cwdrc            check current directory for .gnuplot file,
                           normally disabled for security reasons
   --with-row-help         format help and subtopic tables by row (defau=
lt)
   --without-row-help      format help and subtopic tables by column

It may help to remember some cases though.

Thx.

Re: Heavy weight deps (was y scaling error)

[Allin C. <cot...@wf...>]

On Thu, 8 Nov 2007, pl...@pi... quoted:

> >> It's a pity that enable/disable and with/without aren't treated
> >> as synonyms.  How is anyone supposed to remember which one goes
> >> with which option?
> >
> > Not at all.  Just like nobody is supposed to remember the list of
> > available --enable/--disable/--with{,out} options.  That's what
> > ./configure --help is for (./configure --help=short if you already know
> > the generic configure options).

and wrote:
> 
> So no-one is likely to remember the whole list, but accepting we 
> can remember a few we need to include/exclude it would be nice 
> not add to the burden with apparently arbitary on/off option 
> names. Is there a feature here we are missing the point of?

I'm not sure this is totally compelling, but I think the 
traditional distinction in the autoconf context is

* enable/disable is a simple binary feature toggle

* with/without implies inclusion or not of functionality provided
  by a third-party library or app, and implies an optional 
  parameter to "with", namely the path to the third-party
  something, as in

  --with-ssl=/opt/openssl

Allin Cottrell

Re: Heavy weight deps (was y scaling error)

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

On Wed, 07 Nov 2007 21:03:04 +0100, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> Ethan A Merritt wrote:
>> On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
>>> For instance, doing
>>>   ./configure --disable-wxwidgets --disable-cairo
>>> nevertheless detects and links against the cairo and pango libraries,  
>>> even
>>> though it doesn't actually build the wxt or cairo terminals.
>>
>> False alarm.  It should have been
>>     ./configure --disable-wxwidgets --without-cairo
>>
>> It's a pity that enable/disable and with/without aren't treated
>> as synonyms.  How is anyone supposed to remember which one goes
>> with which option?
>
> Not at all.  Just like nobody is supposed to remember the list of
> available --enable/--disable/--with{,out} options.  That's what
> ./configure --help is for (./configure --help=short if you already know
> the generic configure options).
>

So no-one is likely to remember the whole list, but accepting we can  
remember a few we need to include/exclude it would be nice not add to the  
burden with apparently arbitary on/off option names. Is there a feature  
here we are missing the point of?

Is there a good reason they are not synonymous?

thx.



> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Heavy weight deps (was y scaling error)

[<HBB...@t-...>]

Ethan A Merritt wrote:
> On Tuesday 06 November 2007 21:53, Ethan A Merritt wrote:
>> For instance, doing
>>   ./configure --disable-wxwidgets --disable-cairo
>> nevertheless detects and links against the cairo and pango libraries, even
>> though it doesn't actually build the wxt or cairo terminals.
> 
> False alarm.  It should have been
>     ./configure --disable-wxwidgets --without-cairo
> 
> It's a pity that enable/disable and with/without aren't treated
> as synonyms.  How is anyone supposed to remember which one goes
> with which option?

Not at all.  Just like nobody is supposed to remember the list of 
available --enable/--disable/--with{,out} options.  That's what 
./configure --help is for (./configure --help=short if you already know 
the generic configure options).

Re: Suggestion for dgrid3d

[Philipp K. J. <ja...@ie...>]

I just submitted a patch for dgrid3d to sourceforge.

Features:

- Fully backward compatible with the current version.
- "Thin Plate Splines" can now be chosen as run-time 
	option: 'set dgrid3d 30,30 splines'
- Five new smoothing kernels (gauss, cauchy, exp, 
	box, hann) which can be selected as part 
	of 'set dgrid3d'. For these kernels, the smoothing
	"radius" can be selected as part of the 
	"set dgrid3d" command.

The patch also includes updates to gnuplot.doc.

Let me know what you think.

Best,

		Ph.




On Sunday 21 October 2007 08:46, Philipp K. Janert wrote:
> I was just playing with dgrid3d, and had some
> difficulties getting rather "smooth" input data
> to come out "just right". So I looked into the
> implementation for dgrid3d and wanted to make
> a suggestion.
>
> Context:
> ======
> dgrid3d evaluates (possibly ungridded) input data
> and calculates a smooth approximation to it on a
> regular grid. The values assigned to each grid point
> are essentially weighted averages:
> 	sum_{all points} w_i * data_i
> The sum runs over all input data points, and the
> weight function w is essentially an inverse power
> of the distance between each data point and the
> current grid point:
> 	w = 1/dist**p      for some integer p
>
> Problem:
> ======
> This particular choice of weight function has a few
> disadvantages:
> 1) for dist==0, it is undefined (requiring treatment
> 	as special case)
> 2) for dist > 0 but small, the weight can become
> 	arbitrarily large
> 3) for large p, each individual data point totally
> 	dominates all grid points within dist < 1, but
> 	is irrelevant once dist > 1, with an abrupt
> 	change in behaviour at dist=1 if p gets large.
> 4) no way to control the "radius of influence" or
> 	catchment area for data points
>
> Suggestion:
> ========
> I think it would be desirable to have a weight function
> with the following properties:
> 1) bounded
> 2) w( d=0 ) = 1
> 3) falling smoothly as d -> infty
> 4) have a parameter which smoothly controls the
> 	size of the "catchment radius".
>
> A Gaussian is the first thing that comes to mind.
>
> I have tried it and quite like the results. I have
> posted some example images comparing Gaussian
> weighting vs the power law weighting at:
> 	www.philipp-janert.com/gnuplot
>
> Optional:
> ======
> I have hijacked the "norm" parameter to
> control the width of the Gaussian. This is
> not ideal - a better solution would be to
> extend the dgrid3d option in such a way
> that it can take two float values (instead
> of an int), which can be used to scale the
> x- and y-distances independently.
>
> Attached, you will find a patch file (against
> CVS head) containing the changes to use
> a Gaussian instead of a power law. They
> do not include the "optional" feature
> mentioned above.
>
> Please let me know what you think. I have
> not prepared a patch to the documentation
> yet - I'd like to hear opinions on this
> suggestion first.
>
> Best,
>
> 		Ph.

html code in gnuplot.doc

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

There is a "strange" text printed on screen for "help xxx" if the section 
"xxx" contains the hypertext. For example, try:


help filledcurves:

 Example of filling the area between two input curves.
 fill between curves demo.


help uniq:

 resulting points are then connected by straight line segments.
 demos


help boxerrorbars:

 See also
 errorbar demo.


Does somebody have an idea how to make the output more "beutiful"?

---
PM