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

Re: unexpected behavior of "do for"

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

On 03/05/12 20:24, Ethan A Merritt wrote:
> Tait<gnu...@t4...>  wrote>
>>> So yes, there is an inconsistency.  There are currently three "for"
>>> constructs
>>>    do for
>>>    set for
>>>    plot for
>>>
>>> The first two of these always iterate at least once; the third one does not.
>>> The documentation is silent on the intended behavior.
>>> So which to change, "plot for" or both the others?
>>
>> Given that it's called "for" I'd say the principle of least surprise
>> dictate that it act consistently with "for" as used in most programming
>> languages (e.g. C).
>
> Well, C doesn't really have an automatic iterator of this form; you have to
> provide an explicit initialization, an explicit while condition, and an
> explicit iteration operation.
>
> It turns out to be surprisingly hard to determine what
> "most programming languages" do. Many require an explicit increment
> operation, like C.
>
> FWIW, here is what you get in R, whose syntax is close to that of gnuplot.
>
> R>   for (i in 4:1) { print(i) }
> [1] 4
> [1] 3
> [1] 2
> [1] 1
>
> So that's a third option to consider.
> It's not too late to consider adopting this behavior for gnuplot also:
>     for [i = start : end {: increment}]
> where increment defaults to -1 if (start>  end) and +1 otherwise.
>
> 	Ethan
>

Hi,

The R example is rather artificial. It is not the 'for' structure that 
automatically takes a negative increment. That is the result of the 
definition of the "range"  4:1 , which rightly defines a series 4 3 2 1 
, that is unique and unambiguous.

In this context the for-loop simply iterates a predetermined list , the 
loop increment is still +1 .


The idea that way the code is compiled varies dependant on the values of 
the data seems an aberration to me.  This sort of thing should be 
reserved for AI languages.

Perhaps someone could suggest how this would be advantageous.

If it is truly useful perhaps the idea of a range as a variable 
structure needs to implemented as in R. Though this would probably lead 
to an ambiguous syntax in for-loops which would have to have alternative 
code paths for conventional integer args and ranges.


Peter.

Re: unexpected behavior of "do for"

[Tait <gnu...@t4...>]

> > > So yes, there is an inconsistency.  There are currently three "for"
> > > constructs
> > >   do for
> > >   set for
> > >   plot for
> > >
> > > The first two of these always iterate at least once; the third one does not.
> > > The documentation is silent on the intended behavior.
> > > So which to change, "plot for" or both the others?
> >
> > Given that it's called "for" I'd say the principle of least surprise
> > dictate that it act consistently with "for" as used in most programming
> > languages (e.g. C).

Ethan:
> 
> It turns out to be surprisingly hard to determine what
> "most programming languages" do. Many require an explicit increment
> operation, like C.
>
> FWIW, here is what you get in R, whose syntax is close to that of gnuplot.
>
> R>  for (i in 4:1) { print(i) }
> [1] 4
> [1] 3
> [1] 2
> [1] 1
>
> So that's a third option to consider.

Arun:
> My preferred choice would be that you need to specify the -1 increment
> explicitly.
>
> If you leave it with an increment of +1 unless otherwise specified, I
> also would prefer if "do for [i=5:4] {" does no iterations at all.

Peter:
> I would advise against such "special" cases. It's confusing (unexpected)
> and as I said before makes producing predictable output complicated.

I was thinking in terms of for [a:b] implicitly meaning for [a:b:+1], in
which case there should be zero loops executed if a > b. For example...
Perl: 
    perl -e "print for 0..9"  => 0123456789
    perl -e "print for 9..0"  => 
Python:
    python -c "print range(0,9) => [0, 1, 2, 3, 4, 5, 6, 7, 8]
    python -c "print range(9,0) => []
Ruby:
    ruby -le 'print (0..9).to_a' => 0123456789
    ruby -le 'print (9..0).to_a' => 

But also R, as you mentioned, and...
PHP:
    php -r 'print implode(range(0,9))' => 0123456789
    php -r 'print implode(range(9,0))' => 9876543210
(...not that PHP should be a model for anything, in my personal opinion)

I do like and have often wished for R's behavior where [a:b] implies a
+1 increment if b>a and a -1 increment if a>b. I think gnuplot could
adopt this. But to address Arun and Peter's concern, for [i=9:0:1]
should do zero loops, to allow a mechansim for the author to say, "I
want Perl/Python/Ruby-like behavior, not R-like behavior." Having
for [i=9:0:1] do one loop can only be seen as broken.

Re: unexpected behavior of "do for"

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

On 05/03/12 08:37, Tait wrote:
>> So yes, there is an inconsistency.  There are currently three "for"
>> constructs
>>    do for
>>    set for
>>    plot for
>>
>> The first two of these always iterate at least once; the third one does not.
>> The documentation is silent on the intended behavior.
>> So which to change, "plot for" or both the others?
>
> Given that it's called "for" I'd say the principle of least surprise
> dictate that it act consistently with "for" as used in most programming
> languages (e.g. C).
>

The illogical and inconsistent result of always executing once means 
that any situation where this is programmed to use variable values 
necessitates an additional test as the first thing within the 'for' 
structure, for it to be able to produce predictable output.

Since these syntactical tweaks to gnuplot commands do not allow complex, 
structured content, it would seem best to provide a behaviour which 
produces consistent behaviour irrespective of variable values, avoiding 
the need for further tests.

ie  for (i=2 ; i<=1)  does nothing.


Clearly it needs to be the same and thoroghly documented in all contexts.

Peter.

Re: unexpected behavior of "do for"

[Ethan A M. <sf...@us...>]

Tait <gnu...@t4...> wrote >
> > So yes, there is an inconsistency.  There are currently three "for"
> > constructs
> >   do for
> >   set for
> >   plot for
> > 
> > The first two of these always iterate at least once; the third one does not.
> > The documentation is silent on the intended behavior.
> > So which to change, "plot for" or both the others?
> 
> Given that it's called "for" I'd say the principle of least surprise
> dictate that it act consistently with "for" as used in most programming
> languages (e.g. C).

Well, C doesn't really have an automatic iterator of this form; you have to
provide an explicit initialization, an explicit while condition, and an
explicit iteration operation.

It turns out to be surprisingly hard to determine what 
"most programming languages" do. Many require an explicit increment
operation, like C.

FWIW, here is what you get in R, whose syntax is close to that of gnuplot.

R>  for (i in 4:1) { print(i) }
[1] 4
[1] 3
[1] 2
[1] 1

So that's a third option to consider.
It's not too late to consider adopting this behavior for gnuplot also:
   for [i = start : end {: increment}]
where increment defaults to -1 if (start > end) and +1 otherwise.

	Ethan

Re: unexpected behavior of "do for"

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

On 05/03/12 21:59, Arun Persaud wrote:
> An automatic switch to an increment of -1 would also be OK for me,
> although I wouldn't expect it;)
>
> Arun

I would advise against such "special" cases. It's confusing (unexpected) 
and as I said before makes producing predictable output complicated.

Arun's example case of the extra plot would be difficult to deal with in 
a general way and would probably require some testing of the values and 
conditional code before the "for" to stop things like that happening.


The automatic switch to negative increment would probably do something 
unhelpful like printing both "triangles" of his matrix of plots. Or 
something even more unexpected.

Peter.

Re: unexpected behavior of "do for"

[Arun P. <ape...@lb...>]

Hi

> R>  for (i in 4:1) { print(i) }
> [1] 4
> [1] 3
> [1] 2
> [1] 1
> 
> So that's a third option to consider.
> It's not too late to consider adopting this behavior for gnuplot also:
>    for [i = start : end {: increment}]
> where increment defaults to -1 if (start > end) and +1 otherwise.
> 
> 	Ethan

My preferred choice would be that you need to specify the -1 increment
explicitly.

If you leave it with an increment of +1 unless otherwise specified, I
also would prefer if "do for [i=5:4] {" does no iterations at all.

My application was that I had a data file with 33 columns and I wanted
to plot column i:j for the first 10 columns using

do for [i=:10] {
  do for[j=(i+1):10] {
    ...
  }
}

which plots something like an upper triangle matrix of plots, but with
an extra plot for 11:10, which I didn't expect. Can't really think of
other good examples where this would be relevant at the moment though.

An automatic switch to an increment of -1 would also be OK for me,
although I wouldn't expect it ;)

Arun

line position accuracy

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

Hi,

I'm looking at gnuplot svg output with a high zoom ratio that makes it 
easy to examine accuracy.  There are discrepancies.

http://i47.tinypic.com/1zcpjtc.png

this screen shot shows such a zoomed area and using mouse cursor feature 
to find the y coord of the grey line I get a reading of 0.49

In this case the textual dot that marks the current cursor readout is 
squarely on top of the grey line and of the same size as the line width. 
The next quantised cursor position puts the dot just under the grey line 
up against it. It shows a y value of 0.21; when above and touching is 0.76

As far as I can tell by eye it is the lower edge of the square textual 
dot that represents the value shown in the mouse cursor read out. This 
also seems close to the tip of the arrow shaped mouse cursor in Firefox 
that I am using to render the SVG.  I get very similar results on Opera.

This raises the question of whether the mouse readout is an accurate 
value for the position of the grey line.

Is the plotted line draw equidistant from the data value (ie data value 
is at the centre of the draw line - as one would probably assume) or is 
the data value at the lower extremity of the plotted line?

In this example the line would seem to be closer to 0.75 but cursor read 
out is 0.49

If I try to get a readout on the x axis, the closest I get to zero is 
-0.03 when the bottom of the mouse cursor is near the centre of the line 
drawn as the x axis.

Taken together, this would suggest that the plot line is drawn on and 
above the data value , not centred on it.  These lines are default line 
width.

The result is that the plotted line appears to higher than the actual 
data value and placing the cursor at a position on the graph gives a 
coord readout larger than the data value unless on realises that it is 
the lower edge of the marker dot that should be used to indicate the 
position.


The "dot" referred to here is the first character of cursor readout 
text, presumably this is a period (or full-stop) character.

Regards, Peter.

Re: unexpected behavior of "do for"

[Tait <gnu...@t4...>]

> So yes, there is an inconsistency.  There are currently three "for"
> constructs
>   do for
>   set for
>   plot for
> 
> The first two of these always iterate at least once; the third one does not.
> The documentation is silent on the intended behavior.
> So which to change, "plot for" or both the others?

Given that it's called "for" I'd say the principle of least surprise
dictate that it act consistently with "for" as used in most programming
languages (e.g. C).

Re: Want to contribute in gnuplot

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

On Wednesday, May 02, 2012 02:18:45 pm Aman (neshu) Agarwal wrote:
> Hi Sorry for bugging you guys again.
> 
> can some one please give me task, I want to contribute in it.

Re: your svg patch (remove trailing whitespace in output)
	patch applied to 4.7 CVS

Re: your quantize_normal_tics patch
	I already sent Email commenting on this one.
    Could you please provide a test case showing what was bad before,
    and how it is better after your patch?

Re: other possible projects

    - See recent requests to have "set timefmt" accept a string variable.
	This would involve calling try_to_get_string() rather than quote_str(),
	with suitable garbage collection.

	- Add a linewidth option for the lua terminal, as in
        set term tikz size BIGX,BIGY linewidth 2.0
	This would require modifying the lua code in 
	.../term/lua/gnuplot-tikz.lua

	- Rewrite the X11 terminal so that the coordinate system matches the
	current X11 display window.  I.e., if the plot is displayed in a
	window that is 700x500 pixels, the terminal coordinates should run
	from 0 to 700*SCALE on x, and 0 to 500*SCALE on y.  In the current
	code the coordinates always run from 0 to 4096 regardless of the 
	actual size or aspect ratio of the window.  This breaks all commands
	that try to set a particular aspect ratio, e.g.  "set size square"
	or "set size ratio 1.5"

	- The X11 terminal does not yet support toggling individual plots
	on/off by clicking on the key sample.  Of the terminals that 
	currently support this, I think wxt or canvas would be the best to
	use as a model for how to do this. But the wxt code is C++ and the
	canvas code is javascript, so it's not going to be exactly the same.  

	- Support mousing in multiplot mode.  This will have to be tackled
	one terminal at a time, and some will be easier than others.

	- The script "gpsavediff" is very useful.  You can download a copy
	from the contributed scripts section of the web site:
         http://gnuplot.sourceforge.net/scripts/files/gpsavediff
	Basically it compares the output of the "save" command from your
	current session to the output of "save" on program initialization,
	keeping only the settings that have changed.  So
             save "| gpsavediff > thisplot.gp"
	creates a file contains only those commands needed to reproduce
	the current state in gnuplot.  This is so useful that it would be
	nice to have it be a built-in function rather than an external
	script.  I'm not sure exactly how best to do this, but one idea
	would be to add an option to the existing "save" command. If the
	option is selected, then each line that writes out a setting is
	executed only if that setting is different from the program default.

	- Have a look through the Feature Requests tracker.
	Many of the requests are not so reasonable, but these are among
	the ones that look OK to me:
	  3376559 3087960 995040 3066642 3468942

	- Find a type of plot used in your own field or some other scientific
	field that gnuplot doesn't yet know how to produce.  Write a set of
	routines to support it in gnuplot.  This works better if it's a kind
	of plot you use yourself, since then you already know what are its
	important features.  One possible example:
		Barycentric plots: http://rgm2.lab.nig.ac.jp/RGM2/func.php?rd_id=klaR:triplot


			have fun,

				Ethan

> 
> Thanks
> 
> On Sun, Apr 29, 2012 at 3:30 PM, Aman (neshu) Agarwal <
> nes...@gm...> wrote:
> 
> > Hi,
> >
> > I create a patch again.
> > sorry to bug you again. should I need to remove full quantize_normal_tics
> > ?
> >
> > PFA to see I am on right track or not.
> >
> > Thanks for everything
> >
> >
> >
> > On Mon, Apr 23, 2012 at 1:21 AM, Marek Peca <ma...@du...> wrote:
> >
> >> Hello,
> >>
> >>
> >>  PFA, check the patch for the tic function.
> >>>
> >>
> >> I think it should be done the clean way, i.e. to remove old, bypassed
> >> function etc. Please consult it with Gnuplot core developers.
> >>
> >> Thank you,
> >> Marek
> >>
> >
> >
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: Want to contribute in gnuplot

[Aman (n. A. <nes...@gm...>]

Hi Sorry for bugging you guys again.

can some one please give me task, I want to contribute in it.

Thanks

On Sun, Apr 29, 2012 at 3:30 PM, Aman (neshu) Agarwal <
nes...@gm...> wrote:

> Hi,
>
> I create a patch again.
> sorry to bug you again. should I need to remove full quantize_normal_tics
> ?
>
> PFA to see I am on right track or not.
>
> Thanks for everything
>
>
>
> On Mon, Apr 23, 2012 at 1:21 AM, Marek Peca <ma...@du...> wrote:
>
>> Hello,
>>
>>
>>  PFA, check the patch for the tic function.
>>>
>>
>> I think it should be done the clean way, i.e. to remove old, bypassed
>> function etc. Please consult it with Gnuplot core developers.
>>
>> Thank you,
>> Marek
>>
>
>

Re: unexpected behavior of "do for"

[Ethan A M. <sf...@us...>]

On Monday, April 30, 2012 03:21:36 pm Arun Persaud wrote:
> Hi
> 
> I just ran across the following problem:
> 
> do for [i=5:1] {
>   print i
> }
> 
> prints "5" instead of doing nothing. Is this the intended behavior?
> 
> This seems due to the use of a "do {} while" structure in
> src/command.c:do_command, instead of perhaps a while or for.
> 
> Other places in gnuplot where "for" is used, don't seem to do this:
> 
> plot for [i=5:1] sin(i*x)

  set for [i=5:1] label i "Foo"
  show label
        label 5 "Foo" at (0, 0, 0) left not rotated back  nopoint

So yes, there is an inconsistency.  There are currently three "for"
constructs
  do for
  set for
  plot for

The first two of these always iterate at least once; the third one does not.
The documentation is silent on the intended behavior.
So which to change, "plot for" or both the others?

Re: bugs - set timefmt and xrange

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

On 05/01/12 21:27, Petr Mikulik wrote:
> I think I have found two places where time settings accept string but not
> string variable or string functions:
>
> 1. Here "set timefmt" does not accept string variable:
>
> set xdata time
> set timefmt "[%Y/%m/%d %H:%M:%S]"
> show timefmt
>
> myfmt = "%Y/%m/%d %H:%M:%S"
> set timefmt myfmt
>
> gnuplot>  set timefmt myfmt
>                       ^
>           "bug1.gp", line 8: time format string expected
>
>
> 2. "set xrange" accepts string variables but not string functions:
>

Agreed, also noted this short-coming recently wanting to use a variable 
to set timefmt, had to use string literals in two places and maintain 
each versions of the string.

IMO, allowing variable substitution in this context would be an advantage.

Peter. (with two e's ;) )



> reset
>
> set xdata time
> set timefmt "%Y/%m/%d %H:%M:%S"
>
> set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ]
> show xrange
>
> s1="2012/01/20 14:00:00"; s2="2012/01/20 18:00:00"
> set xrange [ s1 : s2 ]
> show xrange
>
> set xrange [sprintf("2012/01/20 14:00:00") : sprintf("2012/01/20 18:00:00")]
> show xrange
>
> myfmt = "%Y/%m/%d %H:%M:%S"
> x1=strptime(myfmt, "2012/01/20 14:00:00")
> x2=strptime(myfmt, "2012/01/20 18:00:00")
>
> set xrange [ strftime(myfmt, x1) : strftime(myfmt, x2) ]
> show xrange
>
> =>
>
>          set xdata time
>          set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ]
>
>          set xdata time
>          set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ]
>
>          set xdata time
>          set xrange [ "2000/01/01 00:33:32" : "2000/01/01 00:33:32" ]
>
>          set xdata time
>          set xrange [ "2000/01/01 00:33:32" : "2000/01/01 00:33:32" ]
>
> ... the first two outputs are correct.
>
> ---
> Petr
>

bugs - set timefmt and xrange

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

I think I have found two places where time settings accept string but not 
string variable or string functions:

1. Here "set timefmt" does not accept string variable:

set xdata time
set timefmt "[%Y/%m/%d %H:%M:%S]"
show timefmt

myfmt = "%Y/%m/%d %H:%M:%S"
set timefmt myfmt

gnuplot> set timefmt myfmt
                     ^
         "bug1.gp", line 8: time format string expected


2. "set xrange" accepts string variables but not string functions:

reset

set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"

set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ]
show xrange

s1="2012/01/20 14:00:00"; s2="2012/01/20 18:00:00"
set xrange [ s1 : s2 ] 
show xrange

set xrange [sprintf("2012/01/20 14:00:00") : sprintf("2012/01/20 18:00:00")]
show xrange

myfmt = "%Y/%m/%d %H:%M:%S"
x1=strptime(myfmt, "2012/01/20 14:00:00")
x2=strptime(myfmt, "2012/01/20 18:00:00")

set xrange [ strftime(myfmt, x1) : strftime(myfmt, x2) ]
show xrange

=>

        set xdata time
        set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ] 

        set xdata time
        set xrange [ "2012/01/20 14:00:00" : "2012/01/20 18:00:00" ] 

        set xdata time
        set xrange [ "2000/01/01 00:33:32" : "2000/01/01 00:33:32" ] 

        set xdata time
        set xrange [ "2000/01/01 00:33:32" : "2000/01/01 00:33:32" ] 

... the first two outputs are correct.

---
Petr

Re: [Patch] removing trailing whitespace from svg-output

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

On 05/01/12 01:32, Arun Persaud wrote:
> Hi
>
> attached is a patch that removes some whitespace from svg-output. It
> replaces the function SVG_PathLimit that was used called after each M or
> L command to wrap long lines with another functions that either adds the
> newline or adds a space and the trailing space is removed from the
> commands M and L.
>
> It also removes a few traling whitespaces from the svg-header.
>
> Works for me, but I don't use any extras that seem to be available in
> the header.
>
> cheers
>
> Arun
>
>

Hi,

I was also wondering about reducing the footprint of variable names as well.

The long names are nice and explicitly and are eminently readable.  This 
is great for compiled source code but can have a heavy impact on 
interpreted code like js and svg.

I was looking in particular at the gnuplot svg javascript code there are 
two variables which seem to occur in every other line in the code.


gnuplot_svg plotcoord

replacing these two alone with a one or two letter variable name would 
likely reduce the js footprint by about half.

Since I run "standalone" option this gets included in each file and it 
would be nice to reduce it somewhat.

I was intending to do this locally , but since the subject came up, I 
thought I'd post the suggestion.

Best regards, Peter.

make install prefix=... fails for TEXDIR

[Mojca M. <moj...@gm...>]

Dear gnuplot developers,

for some unknown reason macports has always used
    make install prefix=$destdir
for installing gnuplot (= creating a package) as opposed to
    make install DESTDIR=$destdir

If you try to use
    ./configure --prefix=/tmp/configureprefix
    make
    make install prefix=/tmp/makeprefix
you'll end up with all the gnuplot files in /tmp/configureprefix
except for the four tex files (= TEXDIR) in /tmp/makeprefix. Using
    make install DESTDIR=$destdir
works properly.

My question is: would it make sense to fix the behaviour? Below are the patches:


--- a/configure.in
+++ b/configure.in
@@ -120,14 +120,14 @@ if test "$with_latex" = yes; then
   dnl texdir has priority
   if test "$TEXDIR" = "no"; then
     if test "x$prefix" != "xNONE"; then
-      TEXDIR=${prefix}/share/texmf
+      TEXDIR='${prefix}/share/texmf'
     else
       TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
       if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
-        TEXDIR=${ac_default_prefix}/share/texmf
+        TEXDIR='${prefix}/share/texmf'
       fi
     fi
-    TEXDIR=${TEXDIR}/tex/latex/gnuplot
+    TEXDIR="${TEXDIR}/tex/latex/gnuplot"
   fi
 fi

(I'm not exactly sure why ${ac_default_prefix} was there, so I'm not
100% sure about correctness of the replacement for that line, but
double braces in third line don't hurt and single brackets in the
first line are absolutely needed in order to prevent too early
expansion.)

Actually even more correct would be:

--- a/configure.in
+++ b/configure.in
@@ -120,14 +120,18 @@ if test "$with_latex" = yes; then
   dnl texdir has priority
   if test "$TEXDIR" = "no"; then
     if test "x$prefix" != "xNONE"; then
-      TEXDIR=${prefix}/share/texmf
+      TEXDIR='${prefix}/share/texmf'
     else
       TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
       if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
-        TEXDIR=${ac_default_prefix}/share/texmf
+        TEXDIR='${prefix}/share/texmf'
+      elif
+        TEXDIR='${prefix}'"${TEXDIR}"
       fi
     fi
-    TEXDIR=${TEXDIR}/tex/latex/gnuplot
+    TEXDIR="${TEXDIR}/tex/latex/gnuplot"
+  elif
+    TEXDIR='${prefix}'"${TEXDIR}"
   fi
 fi

For MacPorts this can easily be fixed by using DESTDIR instead of
prefix and I was told that DESTDIR is the right way to go anyway, but
I thought that it might nevertheless make sense to fix some quoting
"errors" in gnuplot sources. I didn't check yet how --with-lispdir
behaves.

My preference would actually be to rather switch to
    --with-texmfdir=
instead, so that something like
    --with-texmfdir=/usr/local/texlive/texmf-local
would end up with
    /usr/local/texlive/texmf-local/tex/context/third/gnuplot-lua-tikz/t-gnuplot-lua-tikz.tex
    /usr/local/texlive/texmf-local/tex/generic/gnuplot-lua-tikz/gnuplot-lua-tikz-common.tex
    /usr/local/texlive/texmf-local/tex/latex/gnuplot-lua-tikz/gnuplot-lua-tikz.sty
    /usr/local/texlive/texmf-local/tex/latex/gnuplot/gnuplot.cfg
    /usr/local/texlive/texmf-local/tex/plain/gnuplot-lua-tikz/gnuplot-lua-tikz.tex
in contrast to current behaviour that simply puts plain TeX and
ConTeXt files to LaTeX directory where they are completely useless
(kpathsea won't find them).

Mojca

[Patch] removing trailing whitespace from svg-output

[Arun P. <ape...@lb...>]

Hi

attached is a patch that removes some whitespace from svg-output. It
replaces the function SVG_PathLimit that was used called after each M or
L command to wrap long lines with another functions that either adds the
newline or adds a space and the trailing space is removed from the
commands M and L.

It also removes a few traling whitespaces from the svg-header.

Works for me, but I don't use any extras that seem to be available in
the header.

cheers

Arun

unexpected behavior of "do for"

[Arun P. <ape...@lb...>]

Hi

I just ran across the following problem:

do for [i=5:1] {
  print i
}

prints "5" instead of doing nothing. Is this the intended behavior?

This seems due to the use of a "do {} while" structure in
src/command.c:do_command, instead of perhaps a while or for.

Other places in gnuplot where "for" is used, don't seem to do this:

plot for [i=5:1] sin(i*x)

=> nothing is plotted.

system: linux (openSUSE Tumbleweed)
gnuplot version: from 2012-04-30 (ff262a693106d from
https://github.com/gnuplot/gnuplot.git)

just FYI:
I came across this using the following
do for [i=1:N] {
  do for [j=(i+1):N] { # (i+1 will be N+1 during the last i-iteration)
    print "doing ".i." ".j
  }
}

ARUN

Re: possible bug: svg and multiplot

[Arun P. <ape...@lb...>]

Hi

>> I just ran into the following error when trying to open a svg file
>> created by gnuplot:
>>
>> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
>> Bytes: 0x80 0x22 0x20 0x3E"
> 
> You have indeed found a real bug, which I have just now fixed in the CVS
> source code.  The subplots in a multiplot are labeled internally as 'a'-'z'.
> The bug was an incorrect check to prevent letters beyond 'z' from being 
> generated.  So it triggered whenever the number of subplots exceeded 30.

Thanks for the bugfix... tested it and everything works great!

> [...]

> set term svg  size 2400,1800  fsize (10. * SCALE)  lw  (1. * SCALE)

also thanks for helping with the script... fsize and lw in "set term"
was what I was missing.

cheers

Arun

Re: error in CVS

[Mojca M. <moj...@gm...>]

On Fri, Apr 27, 2012 at 14:48,  <pl...@pi...> wrote:
> Hi,
>
> just updated from cvs and it fails to compile version.h
>
> looks like a patching error:
>
>
> const char gnuplot_version[] = "4.7";
> const char gnuplot_patchlevel[] = "0";
> <<<<<<< version.c
> const char gnuplot_date[] = "2012-02-08 ";
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004,
> 2007-2011";
> =======
> const char gnuplot_date[] = "2012-03-02 ";
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004,
> 2007-2012";
>  >>>>>>> 1.104

My guess is that while you were building gnuplot your local copy was
changed. In the meantime it was also changed in CVS and when you tried
to update, CVS had problems with merging the changes (it wasn't able
to decide whether to obey your local modifications or to take the one
from CVS).

It probably helps to simply delete this file and update again.

Mojca

Re: possible bug: svg and multiplot

[Ethan A M. <sf...@us...>]

On Friday, April 27, 2012 01:48:32 pm Arun Persaud wrote:
> Hi
> 
> I just ran into the following error when trying to open a svg file
> created by gnuplot:
> 
> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0x80 0x22 0x20 0x3E"

You have indeed found a real bug, which I have just now fixed in the CVS
source code.  The subplots in a multiplot are labeled internally as 'a'-'z'.
The bug was an incorrect check to prevent letters beyond 'z' from being 
generated.  So it triggered whenever the number of subplots exceeded 30.


However, your script will not work as it is even after the bug fix.
See comments below.

> --------------
> reset
> N=30
> 
> set term svg
> set out "test.svg"
> 
> set size N,N

	Don't do this.  "set size" should never use values greater than 1.
   
> set multiplot
> 
> set size 1,1
>
> do for [i=1:N] {
>   do for [j=i:N] {
> 
>   set title "x: ".i." y: ".j
>   set origin ((i-1)),((j-1))
> 
>   plot sin(i*j*x)
>   }
> }
> 
> unset multiplot
> set out
> --------------

I think the revised script below does what you want.
You don't necessarily have to make the nominal x and y size bigger,
but if you don't then cramming in 900 subplots may run into the precision
issue that Peter brought up yesterday - that the coordinates written to the
output file only use 1 decimal place.


========================
XSIZE = 2400       # The default size is 600 x 480
YSIZE = 1800       # so this is roughly 4 times bigger
SCALE = 600./XSIZE
N = 30

set term svg  size 2400,1800  fsize (10. * SCALE)  lw  (1. * SCALE)
set out "newversion.svg"

set multiplot layout N,N
do for [i=1:N] {
  do for [j=i:N] {
    set title "x: ".i." y: ".j
    plot sin(i*j*x)
  }
}

unset multiplot
=======================


 
> The script works OK for small N, e.g. N=3.
> 
> Not sure if this is a problem with gnuplot or my lib that reads svg...
> can someone reproduce this?
> 
> I'm running the latest gnuplot cvs version (updated a few hours ago) on
> openSUSE Tumbleweed. Compiled cvs using "./prepare; configure; make".
> 
> As a side question: in the above script how do I get to size the output
> of the svg to the N,N size? Or if I use set size 1,1 outside multiplot
> and set size 1.0/N,1.0/N inside multiplot, how to I get gnuplot to scale
> the whole plot including fonts, tics, etc.

The revised script above shows how you can apply explicit scaling.

The CVS version has partial support for more generic scaling commands
but these are not yet implemented for the svg terminal.

	Ethan


> 
> thanks
> 
> Arun

Re: possible bug: svg and multiplot

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

On 04/27/12 22:48, Arun Persaud wrote:
> Hi
>
> I just ran into the following error when trying to open a svg file
> created by gnuplot:
>
> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0x80 0x22 0x20 0x3E"
>
> and I can't open the svg (tried inkscape and eog).
>
> Here is the script that produced the svg:
>
> --------------
> reset
> N=30
>
> set term svg
> set out "test.svg"
>
> set size N,N
>
> set multiplot
>
> set size 1,1
>
> do for [i=1:N] {
>    do for [j=i:N] {
>
>    set title "x: ".i." y: ".j
>    set origin ((i-1)),((j-1))
>
>    plot sin(i*j*x)
>    }
> }
>
> unset multiplot
> set out
> --------------
>
> The script works OK for small N, e.g. N=3.
>
> Not sure if this is a problem with gnuplot or my lib that reads svg...
> can someone reproduce this?
>
> I'm running the latest gnuplot cvs version (updated a few hours ago) on
> openSUSE Tumbleweed. Compiled cvs using "./prepare; configure; make".
>
> As a side question: in the above script how do I get to size the output
> of the svg to the N,N size? Or if I use set size 1,1 outside multiplot
> and set size 1.0/N,1.0/N inside multiplot, how to I get gnuplot to scale
> the whole plot including fonts, tics, etc.
>
> thanks
>
> Arun
>
> --------------------------------------

confirmed, I ran your script and this is what firefox reported when 
opening it.

XML Parsing Error: not well-formed
Location: file:///back/coredata/test.svg
Line Number 898, Column 23:	<g id="gnuplot_plot_1\uffff" 
 ><title>gnuplot_plot_1\uffff</title>


HTH

possible bug: svg and multiplot

[Arun P. <ape...@lb...>]

Hi

I just ran into the following error when trying to open a svg file
created by gnuplot:

"test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0x80 0x22 0x20 0x3E"

and I can't open the svg (tried inkscape and eog).

Here is the script that produced the svg:

--------------
reset
N=30

set term svg
set out "test.svg"

set size N,N

set multiplot

set size 1,1

do for [i=1:N] {
  do for [j=i:N] {

  set title "x: ".i." y: ".j
  set origin ((i-1)),((j-1))

  plot sin(i*j*x)
  }
}

unset multiplot
set out
--------------

The script works OK for small N, e.g. N=3.

Not sure if this is a problem with gnuplot or my lib that reads svg...
can someone reproduce this?

I'm running the latest gnuplot cvs version (updated a few hours ago) on
openSUSE Tumbleweed. Compiled cvs using "./prepare; configure; make".

As a side question: in the above script how do I get to size the output
of the svg to the N,N size? Or if I use set size 1,1 outside multiplot
and set size 1.0/N,1.0/N inside multiplot, how to I get gnuplot to scale
the whole plot including fonts, tics, etc.

thanks

Arun

error in CVS

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

Hi,

just updated from cvs and it fails to compile version.h

looks like a patching error:


const char gnuplot_version[] = "4.7";
const char gnuplot_patchlevel[] = "0";
<<<<<<< version.c
const char gnuplot_date[] = "2012-02-08 ";
const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2011";
=======
const char gnuplot_date[] = "2012-03-02 ";
const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2012";
 >>>>>>> 1.104

Re: granularity in xml terminals

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

On 04/27/12 04:15, sfeam (Ethan Merritt) wrote:
>> >  What difference should I see ?  I thought this was supposed to add and
>> >  extra d.p. to the x,y coords.
> Yeah, I noticed that right after I posted my previous suggestion.
> I fixed it in CVS yesterday, but you probably haven't updated since
> then.
>
> 	Ethan
>
>

ah, thanks.  I've been buggering around with this all afternoon, 
wondering if I was making some dumb mistake.

I'll get a fresh pull in a day or two.

regards.

Re: granularity in xml terminals

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 26 April 2012, pl...@pi... wrote:
> Hi,
> 
> I just tried a build with  CANVAS_OVERSAMPLE aka SVG_SCALE=100
> 
> Good news is nothing too bad happens but I'm not sure what I get for my 
> money.
> 
> 
> 
> 	<path  d='M489.2,197.0 L484.7,197.0 M489.2,193.3 L484.7,193.3 
> M489.2,189.6 L484.7,189.6 M489.2,186.0 L484.7,186.0
> 		M489.2,182.3 L484.7,182.3 M489.2,178.6 L484.7,178.6 M489.2,175.0 
> L484.7,175.0 M489.2,171.3 L484.7,171.3
> 		M489.2,167.7 L484.7,167.7 M489.2,164.0 L480.2,164.0  h0.01'/>
> 
> 
> What difference should I see ?  I thought this was supposed to add and 
> extra d.p. to the x,y coords.

Yeah, I noticed that right after I posted my previous suggestion.
I fixed it in CVS yesterday, but you probably haven't updated since
then.

	Ethan


> 
>  From the source, it just looks like it changes the preset variables it 
> prints for the js mouse code.
> 
> 
> <script type="text/javascript"><![CDATA[
> // plot boundaries and axis scaling information for mousing
> gnuplot_svg.plot_term_xmax = 60;
> gnuplot_svg.plot_term_ymax = 48;
> gnuplot_svg.plot_xmin = 6.4;
> gnuplot_svg.plot_xmax = 48.9;
> gnuplot_svg.plot_ybot = 40.2;
> gnuplot_svg.plot_ytop = 5.4;
> gnuplot_svg.plot_width = 42.6;
> gnuplot_svg.plot_height = 34.8;
> gnuplot_svg.plot_axis_xmin = 0;
> gnuplot_svg.plot_axis_xmax = 1980;
> gnuplot_svg.plot_axis_ymin = -5;
> gnuplot_svg.plot_axis_ymax = 90;
> gnuplot_svg.polar_mode = false;
> gnuplot_svg.plot_axis_x2min = "none"
> gnuplot_svg.plot_axis_y2min = -50;
> gnuplot_svg.plot_axis_y2max = 900;
> gnuplot_svg.plot_logaxis_x = 0;
> gnuplot_svg.plot_logaxis_y = 0;
> gnuplot_svg.plot_timeaxis_x = "Time";
> ]]>
> </script>
> 
> 
> 
> 
> also mouse coords gets a  bit confused though I don't understand how.
> 
> y mouse coord is upside down , x TIME coord gets 24h in several times 
> across the plot that is just a daily plot.
> 
> 
> x=00:30 reads 05:53 ; y1=30 reads -640 !?
> 
> 
> Needs a fix.
> 
> 
> 
> Thx, Peter
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>