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

Re: Qt terminal and dashed lines

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

On Thursday, 20 December 2012, sfeam (Ethan Merritt) wrote:
> On Thursday, 20 December 2012, Daniel J Sebald wrote:
> > Related to the dashed lines issue, someone noticed that {solid|dashed} 
> > is not listed in the documentation for the Qt terminal even though these 
> > terms are accepted and appear to do something relevant.  
> 
> True.  The {dashed|solid} options seem to be missing from the terminal's
> help output.  Perhaps the idea was to hold off advertising it until
> dashlength could be implemented?  
> 
> > The user 
> > appears to not be able to get the proper dashed setting with a 
> > combination of "termoption" and "term", even though inside gnuplot the 
> > test page seems to function in a sensible way.  
> 
> That's not much of a description to work from.
> Have any more information?
> Is it just that the terminal doesn't offer the "dashlength" option?
> 
> > I'd say hold off on that 
> > other than perhaps adding {solid|dashed} to the Qt terminal 
> > documentation.  Fixing the x11 term is higher priority.
> 
> See other message.  I don't think there's anything wrong with the x11
> terminal.  You could make a case that the way x11 itself works is a 
> problem, but X has been that way for 25 years now.
> 
> echo "  gnuplot*dashed:       on
>   gnuplot*borderDashes:   0
>   gnuplot*axisDashes:    16
>   gnuplot*line1Dashes:    0
>   gnuplot*line2Dashes:   42
>   gnuplot*line3Dashes:   13
>   gnuplot*line4Dashes:   44
>   gnuplot*line5Dashes:   15
>   gnuplot*line6Dashes: 4441
>   gnuplot*line7Dashes:   42
>   gnuplot*line8Dashes:   13"  > xrdb -merge

Darn those fingers!  That should be a pipe of course.
echo "..." | xrdb -merge

Re: X11 terminal: dashes and test page

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

On 12/20/2012 10:08 PM, sfeam (Ethan Merritt) wrote:
> On Thursday, 20 December 2012, Daniel J Sebald wrote:
>> Hi Folks,
>>
>> Someone on the Octave list brought up an issue with requiring "set
>> termoption dashed" to get dashed lines.  The conclusion was that most
>> terminals appear to work except X11.  I thought Ethan had added dashed
>> line support to X11 terminal some time ago.
>
> The problem is that x11 line types are controlled through the
> XResource mechanism rather than from the command line.
> You can do "set term x11 dash", but it only produces the
> expected result if you have defined the dashed line types
> in .XDefaults or another resource file.  This is all documented
> extensively.

Sounds familiar.  No luck so far, but where exactly these resource files 
are supposed to go is always tricky.


>> Well, that got me to checking into the X11 terminal with the latest
>> gnuplot CVS code.  I found that the "test" screen is failing.  As far
>> back as September 26:
>>
>> cvs -z3
>> -d:pserver:ano...@gn...:/cvsroot/gnuplot co -D
>> 2012-09-26 -P gnuplot
>>
>> things are beginning to not look correct.  On that date the height of
>> the test page is not correct within the X11 window.  By October 04:
>
> That was around the time that Dima Kogan's updates to x11 started
> to go in.  They introduce changes in the protocol used between gnuplot
> and gnuplot_x11.  I suspect that what has happened is that you upgraded
> gnuplot but did not replace an outdated installation of gnuplot_x11.
> Easy test:
>     cd .../src
>     setenv GNUPLOT_DRIVER_DIR .
>     ./gnuplot
>     set term x11; test

Ah yes.  I should have just installed.  Setting the variable works.

Thanks,

Dan

Re: Qt terminal and dashed lines

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

On Thursday, 20 December 2012, Daniel J Sebald wrote:
> Related to the dashed lines issue, someone noticed that {solid|dashed} 
> is not listed in the documentation for the Qt terminal even though these 
> terms are accepted and appear to do something relevant.  

True.  The {dashed|solid} options seem to be missing from the terminal's
help output.  Perhaps the idea was to hold off advertising it until
dashlength could be implemented?  

> The user 
> appears to not be able to get the proper dashed setting with a 
> combination of "termoption" and "term", even though inside gnuplot the 
> test page seems to function in a sensible way.  

That's not much of a description to work from.
Have any more information?
Is it just that the terminal doesn't offer the "dashlength" option?

> I'd say hold off on that 
> other than perhaps adding {solid|dashed} to the Qt terminal 
> documentation.  Fixing the x11 term is higher priority.

See other message.  I don't think there's anything wrong with the x11
terminal.  You could make a case that the way x11 itself works is a 
problem, but X has been that way for 25 years now.

echo "  gnuplot*dashed:       on
  gnuplot*borderDashes:   0
  gnuplot*axisDashes:    16
  gnuplot*line1Dashes:    0
  gnuplot*line2Dashes:   42
  gnuplot*line3Dashes:   13
  gnuplot*line4Dashes:   44
  gnuplot*line5Dashes:   15
  gnuplot*line6Dashes: 4441
  gnuplot*line7Dashes:   42
  gnuplot*line8Dashes:   13"  > xrdb -merge

gnuplot
  set term x11 dash
  test

	Ethan

> Dan
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: X11 terminal: dashes and test page

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

On Thursday, 20 December 2012, Daniel J Sebald wrote:
> Hi Folks,
> 
> Someone on the Octave list brought up an issue with requiring "set 
> termoption dashed" to get dashed lines.  The conclusion was that most 
> terminals appear to work except X11.  I thought Ethan had added dashed 
> line support to X11 terminal some time ago.

The problem is that x11 line types are controlled through the
XResource mechanism rather than from the command line.
You can do "set term x11 dash", but it only produces the 
expected result if you have defined the dashed line types
in .XDefaults or another resource file.  This is all documented
extensively.

> Well, that got me to checking into the X11 terminal with the latest 
> gnuplot CVS code.  I found that the "test" screen is failing.  As far 
> back as September 26:
> 
> cvs -z3 
> -d:pserver:ano...@gn...:/cvsroot/gnuplot co -D 
> 2012-09-26 -P gnuplot
> 
> things are beginning to not look correct.  On that date the height of 
> the test page is not correct within the X11 window.  By October 04:

That was around the time that Dima Kogan's updates to x11 started
to go in.  They introduce changes in the protocol used between gnuplot
and gnuplot_x11.  I suspect that what has happened is that you upgraded
gnuplot but did not replace an outdated installation of gnuplot_x11.
Easy test:
   cd .../src
   setenv GNUPLOT_DRIVER_DIR .
   ./gnuplot
   set term x11; test

		Ethan

> cvs -z3 
> -d:pserver:ano...@gn...:/cvsroot/gnuplot co -D 
> 2012-10-04 -P gnuplot
> 
> rather than lines on the right side there are all kinds of filled 
> polygons and strange lines randomly placed on the screen.
> 
> As for the aspect ratio, I would guess that maybe this change:
> 
> 2012-09-25  D.K.  <>
> 
> 	* src/gplt_x11.c src/mouse.c (do_event) term/x11.trm:
> 	Feed back the x11 window size from gnuplot_x11 to gnuplot so that
> 	the coordinates can be rescaled to maintain the correct aspect ratio.
> 	This allows correct functioning of commands like 'set size square' and
> 	'set view equal xyz' in an interactive x11 output window.
> 
> led to this.  Perhaps something is overlooked in the test page.  Maybe 
> it used to have some bad compensation from the past that is no longer 
> relevant after the fix of the aspect ratio code.
> 
> As best I can figure for the random polygons, maybe this one:
> 
> 2012-09-28  D.K.  <>
> 
> 	* src/gplt_x11.c src/gplt_x11.h:  Remove dead code.
> 
> 	* src/gplt_x11.c term/x11.trm:  Modify format statements used to send
> 	commands from x11.trm to gnuplot_x11.  Before most integers were sent
> 	using "%04d", now " %d".  This prevents overflow for coordinate > 9999.
> 	The extra byte required for a 4-digit coordinate is compensated by
> 	fewer bytes needed for small integers like linetype.
> 
> 	* src/gplt_x11.c src/gplt_x11.h:  Adjust point size to accommodate
> 	changes in window size.
> 
> Dan

Qt terminal and dashed lines

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

Related to the dashed lines issue, someone noticed that {solid|dashed} 
is not listed in the documentation for the Qt terminal even though these 
terms are accepted and appear to do something relevant.  The user 
appears to not be able to get the proper dashed setting with a 
combination of "termoption" and "term", even though inside gnuplot the 
test page seems to function in a sensible way.  I'd say hold off on that 
other than perhaps adding {solid|dashed} to the Qt terminal 
documentation.  Fixing the x11 term is higher priority.

Dan

X11 terminal: dashes and test page

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

Hi Folks,

Someone on the Octave list brought up an issue with requiring "set 
termoption dashed" to get dashed lines.  The conclusion was that most 
terminals appear to work except X11.  I thought Ethan had added dashed 
line support to X11 terminal some time ago.

Well, that got me to checking into the X11 terminal with the latest 
gnuplot CVS code.  I found that the "test" screen is failing.  As far 
back as September 26:

cvs -z3 
-d:pserver:ano...@gn...:/cvsroot/gnuplot co -D 
2012-09-26 -P gnuplot

things are beginning to not look correct.  On that date the height of 
the test page is not correct within the X11 window.  By October 04:

cvs -z3 
-d:pserver:ano...@gn...:/cvsroot/gnuplot co -D 
2012-10-04 -P gnuplot

rather than lines on the right side there are all kinds of filled 
polygons and strange lines randomly placed on the screen.

As for the aspect ratio, I would guess that maybe this change:

2012-09-25  D.K.  <>

	* src/gplt_x11.c src/mouse.c (do_event) term/x11.trm:
	Feed back the x11 window size from gnuplot_x11 to gnuplot so that
	the coordinates can be rescaled to maintain the correct aspect ratio.
	This allows correct functioning of commands like 'set size square' and
	'set view equal xyz' in an interactive x11 output window.

led to this.  Perhaps something is overlooked in the test page.  Maybe 
it used to have some bad compensation from the past that is no longer 
relevant after the fix of the aspect ratio code.

As best I can figure for the random polygons, maybe this one:

2012-09-28  D.K.  <>

	* src/gplt_x11.c src/gplt_x11.h:  Remove dead code.

	* src/gplt_x11.c term/x11.trm:  Modify format statements used to send
	commands from x11.trm to gnuplot_x11.  Before most integers were sent
	using "%04d", now " %d".  This prevents overflow for coordinate > 9999.
	The extra byte required for a 4-digit coordinate is compensated by
	fewer bytes needed for small integers like linetype.

	* src/gplt_x11.c src/gplt_x11.h:  Adjust point size to accommodate
	changes in window size.

Dan

error-prone interpretation of zero-prefixed numbers as octal

[Andreas B. <abr...@mp...>]

Hi gnuplot-beta members,

some time ago we came across a strange behavior of gnuplot, which we 
suspected to be a bug. After I failed in contacting the gnuplot-bugs 
mailing list I had a private communication with Hans-Bernhard Bröker 
(the owner of the gnuplot-bugs mailing list), who told me that it is 
actually not a bug.

But since this behavior can cause wrong plots and lead to really 
annoying and time consuming debugging sessions, I want to start a 
discussion about it:

When we used "every" in a plot-file, it did not produce the result we 
expected. "every" seamed to make a difference between the data blocks 
'24' and '024':

"data.dat" ev :::024::024 u 1:3 title '1' w l
"data.dat" ev :::24::24 u 1:3 title '2' w l

(Since it is no bug, it can be produced with every version.)
I am sure, examples can be found, where this behavior causes even worse 
results. ;-)

 From the communication with H.B. Bröker I know that this is because 
gnuplot interprets zero-prefixed numbers as octal. This may be obvious 
for C-programmers, but not necessary for non C-programmers.
(For example in fortran it is quite common to output normal numbers 
zero-prefixed.)
Therefore I want to suggest the introduction of another prefix for octal 
numbers (see http://en.wikipedia.org/wiki/Octal#In_computers for 
examples), which is less error-prone.

Alternatively, or as a quick fix, it could be warned when zero-prefixed 
numbers are used.

I curious about your opinions.

( Anyway, gnuplot is a very useful tool ;-) Thanks for it. )

Greetings from Cologne
Andreas Breslau

hidden3d, linetype and linestyle

[Hagen W. <ha...@gn...>]

Hi,

the customization of the linetypes seems to have some implications on the
behavior of hidden3d.

Consider the following example:
set style line 1 lc rgb 'gray'
set parametric
set mapping spherical
set angles degrees
set urange[0:360]
set vrange[-90:90]
set isosamples 25
splot cos(v)*cos(u),cos(v)*sin(u),sin(v) w l ls 1

Until here, everything looks fine. Now we hide some lines.
set hidden3d
replot

The gray color of the plotted line has changed to red. In order to manage to get
the gray lines back, we have to apply the following commands:
set linetype 1 lc rgb 'gray'
replot

Is this behavior intended? It is not obvious that I can't use linestyle with
hidden3d, but have to use linetype to set the color.

Best regards,
Hagen

Re: possible bug in errors in fitting routine

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

On 12/09/2012 02:03 PM, Hans-Bernhard Bröker wrote:
> On 08.12.2012 21:00, Arun Persaud wrote:
> 
>> according to http://arxiv.org/abs/1210.3781 page 42 (between formulas D7
>> and D8) gnuplot outputs the wrong errors when errors in the raw data are
>> used during the fitting process.
> 
> It's a good deal less simple than the author of that paper makes it out
> to be.  The error reported by "fit" (as of the current development
> version: in its default state) only differs from the result desired by
> Mr. Young in the case where the data errors are clearly _not_ adequate,
> yielding a reduced chisq way off target.  Reporting the errors he wants
> would do the user an even bigger disservice in those cases than what
> gnuplot does now.
> 
> As a matter of fact, the Particle Data Book itself, possibly one of the
> biggest fitting jobs regularly performed in all of physics, uses the
> exact same procedue as gnuplot in those cases where the fits are too bad
> to be taken at face value.

Ok, just wanted to make you aware of this. Thanks for looking into it.

cheers
	
Arun

Re: possible bug in errors in fitting routine

[Hans-Bernhard B. <HBB...@t-...>]

On 08.12.2012 21:00, Arun Persaud wrote:

> according to http://arxiv.org/abs/1210.3781 page 42 (between formulas D7
> and D8) gnuplot outputs the wrong errors when errors in the raw data are
> used during the fitting process.

It's a good deal less simple than the author of that paper makes it out 
to be.  The error reported by "fit" (as of the current development 
version: in its default state) only differs from the result desired by 
Mr. Young in the case where the data errors are clearly _not_ adequate, 
yielding a reduced chisq way off target.  Reporting the errors he wants 
would do the user an even bigger disservice in those cases than what 
gnuplot does now.

As a matter of fact, the Particle Data Book itself, possibly one of the 
biggest fitting jobs regularly performed in all of physics, uses the 
exact same procedue as gnuplot in those cases where the fits are too bad 
to be taken at face value.

possible bug in errors in fitting routine

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

Hi

according to http://arxiv.org/abs/1210.3781 page 42 (between formulas D7
and D8) gnuplot outputs the wrong errors when errors in the raw data are
used during the fitting process. I'm not an expert on this, but I
thought I point it out to you guys.

cheers

Arun

possible parsing bug?

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

Hi

when I start gnuplot and then enter "q*2" gnuplot quits. I guess this is
because "q", "qu", "qui", and "quit" get all parsed as quit.

I used a variable q and wanted to type "print q*2", but forgot the print
statement and gnuplot exited. Is it possible to change the parsing
algorithm, so that gnuplot only exists, if "q", "qu", "qui", and "quit"
are followed by a newline?

thanks
	
Arun

Re: gnuplot reports addition in a fn as an error

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

On Saturday, 01 December 2012, sfeam (Ethan Merritt) wrote:
> On Saturday, 01 December 2012, pl...@pi... wrote:
> > Hi,
> > 
> > yet more is in the silly errors file.  Gnuplot is will to multiply be 
> > 1.4 but not add it !
> > 
> > gnuplot>  f1(x)=1.4*cos(x/15.0)
> > gnuplot>  f1(x)=1.4+cos(x/15.0)
> >                    ^
> >           ';' expected
> > 
> > 
> > In the terminal, the caret is aligned under the digit "4"
> 
> This bug was fixed by a patch to CVS on 31-October-2012
>         * src/parse.c (parse_reset_after_error) src/parse.h src/util.c:
>         Error exit from inside try_to_get_string() left the internal flags for
>         string parsing in an incorrect state.  Provide a reset routine.
> 
> It could only occur following a separate error in a command containing
> a mis-quoted string constant, which is why it went unnoticed for a while.

Simple test case showing that it is a side effect of a string parsing error:

gnuplot> print 1+2
3
gnuplot> set clabel a"
         undefined variable: a
gnuplot> print 1+2
                ^
         ';' expected
gnuplot> set clabel "a"
gnuplot> print 1+2
3

The bug goes all the way back to version 4.2, but apparently is
sufficiently hard to trigger that it was not reported until 4.6.1

	Ethan

Re: gnuplot reports addition in a fn as an error

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

On Saturday, 01 December 2012, pl...@pi... wrote:
> Hi,
> 
> yet more is in the silly errors file.  Gnuplot is will to multiply be 
> 1.4 but not add it !
> 
> gnuplot>  f1(x)=1.4*cos(x/15.0)
> gnuplot>  f1(x)=1.4+cos(x/15.0)
>                    ^
>           ';' expected
> 
> 
> In the terminal, the caret is aligned under the digit "4"

This bug was fixed by a patch to CVS on 31-October-2012
        * src/parse.c (parse_reset_after_error) src/parse.h src/util.c:
        Error exit from inside try_to_get_string() left the internal flags for
        string parsing in an incorrect state.  Provide a reset routine.

It could only occur following a separate error in a command containing
a mis-quoted string constant, which is why it went unnoticed for a while.

	Ethan

Re: gnuplot reports addition in a fn as an error

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

On 12/01/12 12:56, pl...@pi... wrote:
> Hi,
>
> yet more is in the silly errors file.  Gnuplot is will to multiply be
> 1.4 but not add it !
>
> gnuplot>  f1(x)=1.4*cos(x/15.0)
> gnuplot>  f1(x)=1.4+cos(x/15.0)
>                     ^
>            ';' expected
>
>
> In the terminal, the caret is aligned under the digit "4"
>
>
> gnuplot> show version
>
>           G N U P L O T
>           Version 4.7 patchlevel 0    last modified 2012-10-16
>           Build System: Linux i686
>
>
>
>
> Beats me .
>
> Peter.
>
>

quitting then restarting gnuplot and doing the same commands fixed this.

Does that mean some cut and paste typo could redefine the + operator ??

Peter.

gnuplot reports addition in a fn as an error

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

Hi,

yet more is in the silly errors file.  Gnuplot is will to multiply be 
1.4 but not add it !

gnuplot>  f1(x)=1.4*cos(x/15.0)
gnuplot>  f1(x)=1.4+cos(x/15.0)
                   ^
          ';' expected


In the terminal, the caret is aligned under the digit "4"


gnuplot> show version

         G N U P L O T
         Version 4.7 patchlevel 0    last modified 2012-10-16
         Build System: Linux i686




Beats me .

Peter.

Re: output of plotted points

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

> I was trying to find whether gnuplot can output a simple list of the 
> points it is plotting as f.p. text.
> 
> Is there a terminal or some means that can do this? This would at least 
> be very useful for debugging gnuplot so I'm guessing it can already do 
> this.
> 
> something like : set term numbers ?

Close! Try "help set table"

output of plotted points

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

Hi,

I am working on some data data in "%Y/%m/%d" format followed by a space 
and a final f.p. variable

Gnuplot does a good job of converting various timedate formats and it 
plots fine. However, I need to do some preprocessing before plotting and 
dealing with all the leap years, leap centuries and leap seconds is a pain.

I was trying to find whether gnuplot can output a simple list of the 
points it is plotting as f.p. text.

Is there a terminal or some means that can do this? This would at least 
be very useful for debugging gnuplot so I'm guessing it can already do 
this.

something like : set term numbers ?

If not , would this be a useful addition?

regards, Peter.

FOSS for scientists devroom at FOSDEM 2013

[Sylwester A. <sa...@ig...>]

Dear Gnuplot Team,

A day-long session ("devroom") on Free/Libre and Open Source Software 
(FLOSS) for scientists will be held during the next FOSDEM conference, 
Brussels, 2-3 February 2013 (http://fosdem.org/2013).

We aim at having a dozen or two short talks introducing projects, 
advertising brand new features of established tools, discussing issues 
relevant to the development of software for scientific computing, and 
touching on the interdependence of FLOSS and open science.

You can find more info on the call for talks at:
http://slayoo.github.com/fosdem2013/

The deadline for sending talk proposals is December 16th 2012.

Please send your submissions or comments to:
fos...@li...

Please do forward this message to anyone potentially interested.  Please 
also let us know if you have any suggestions for what would you like to 
hear about in the devroom.

Looking forward to meeting you in Brussels.
Thanks in advance.

The conveners,
Sylwester Arabas, Juan Antonio Añel, Christos Siopis

P.S. There are open calls for main-track talks, lightning talks, and 
stands at FOSDEM as well, see: http://fosdem.org/2013/news/2012-11-01-cfp/

-- 
http://www.igf.fuw.edu.pl/~slayoo/

piecewise ranges [was Re: irreversibly reversing range]

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

On Monday, 10 September 2012, Tait <gnu...@t4...> wrote:
> > "sfeam (Ethan Merritt)" <sf...@us...>
> > >>> <aside>
> > >>> As you probably recall, my opinion is that a range specifier in the plot
> > >>> command is always a bad idea.  If it were just me, I'd remove that option
> > >>> altogether.  The only reason I can see to allow it is if it is changed so
> > >>> that the in-line range applies only to the immediately following plot clause.
> > >>> That way you could get separate ranges for separate plots:
> > >>>      plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
> > >>> I don't really like that either, but at least it would provide a
> > >>> capability that isn't addressed by simply doing "set xrange" first.
> > >>> </aside>
 
> I like the idea of separating axis range from (data/function) plot range.
> It's a somewhat frequently-asked question how to use a different range for
> a function than what is used for the axis, and the current solution -- to
> use a ternary -- isn't especially elegant.

I've put a patchset on SourceForge that implements this idea.
https://sourceforge.net/tracker/?func=detail&aid=3587664&group_id=2055&atid=302055

Its documentation says:

+ By default, computed functions or data generated for the pseudo-file "+" are
+ sampled over the entire range of the plot. This range may have been specified
+ by a prior `set xrange` command, by an explicit global range specifier at the
+ very start of the plot command, or by autoscaling of the range to span data
+ seen in all the elements of this plot command.  However, individual plot
+ elements can be assigned a more restricted sampling range.
+
+ Examples:
+
+ This establishes a total range on x running from 0 to 1000 and then plots
+ data from a file and two functions each spanning a portion of the total range:
+       plot [0:1000] 'datafile', [0:200] func1(x), [200:500] func2(x)
+
+ This is similar except that the total range is established by the contents
+ of the data file. In this case the sampled functions may or may not be
+ entirely contained in the plot:
+       set autoscale x
+       plot 'datafile', [0:200] func1(x), [200:500] func2(x)
+
+ This command is ambiguous. The initial range will be interpreted as applying to
+ the entire plot, not solely to the sampling of the first function as was
+ probably the intent:
+       plot [0:10] f(x), [10:20] g(x), [20:30] h(x)
+
+ This command removes the ambiguity of the previous example by inserting a dummy
+ definition so that the range is not the first element of the plot command:
+       plot dummy=0, [0:10] f(x), [10:20] g(x), [20:30] h(x)

Re: handling of string variables by sprintf

[Juhász P. <pet...@gm...>]

There seems to be a misunderstanding here.

The string variable a = "1.234" is by no means equivalent to the numeric
variable b = 1.234 . The first is a string (sequence of characters,
really), that happens to represent a number in a human-readable decimal
form, while the second is the number itself, which gnuplot stores as a
double precision floating point value internally.

When you try this:

gp> print sprintf(".3f",a)

it gives an error - as it should! -, because you tell sprintf to expect
a floating point number, then feed a string to it.

The next example is a bit more tricky. When you use an expression like
'a + 0' where 'a' is a string, gnuplot is clever enough to figure out
that you probably wanted to use that variable as a number, so it
automagically tries to convert the string to a number. If it succeeds,
the numeric value extracted from the string will be used silently, if
not, it gives the error 'Non-numeric string found where a numeric
expression was expected'.

There are a few other operators besides + that behave this way. This
automatic conversion between numbers and strings was probably inspired
by Perl, by the way.

You can and should use the 'real' function to reliably extract the
numeric value out of a string:

gp> a = "1.234foo"
gp> print sprintf(".3f",real(a))


Peter Juhasz

On Sat, 2012-11-17 at 11:31 +0100, Karl-Friedrich Ratzsch wrote:
> Hi,
> 
> variables that are defined as string
> 
> gp> a= "1.234"
> 
> are generally equivalent to numerical variables, except for their
> handling by "sprintf" (where they aren´t allowed), e.g.
> 
> gp> print sprintf(".3f",a)
> 
> gives an error, while
> 
> gp> print sprintf(".3f",a+0)
> 
> is allowed.
> 
> I´m not sure wether this qualifies as a bug an should be changed.
> 
> Any opinions?
> 
> 
>    Karl
> 
> P.S. Occured to me with
> 
> gp> do for [a in "12 14 16.8 23"] {plot sprintf("dist_%.1f.dat",a)}
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

handling of string variables by sprintf

[Karl-Friedrich R. <mai...@gm...>]

Hi,

variables that are defined as string

gp> a= "1.234"

are generally equivalent to numerical variables, except for their
handling by "sprintf" (where they aren´t allowed), e.g.

gp> print sprintf(".3f",a)

gives an error, while

gp> print sprintf(".3f",a+0)

is allowed.

I´m not sure wether this qualifies as a bug an should be changed.

Any opinions?


   Karl

P.S. Occured to me with

gp> do for [a in "12 14 16.8 23"] {plot sprintf("dist_%.1f.dat",a)}

Re: wxt mouse scrolling anomalies

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

On 11/10/12 23:59, sfeam (Ethan Merritt) wrote:
> On Saturday, 10 November 2012, pl...@pi... wrote:
>> On 11/10/12 20:03, sfeam (Ethan Merritt) wrote:
>>> On Saturday, 10 November 2012, pl...@pi... wrote:
>>>
>>>> Actually,I'm getting some very odd things happening here.
>>>>
>>>> Firstly , being still half asleep it typed in some data with commas and
>>>> did not get what I intended (so not bug yet)
>>>>
>>>> gnuplot> f(x)=0
>>>> gnuplot> plot "-" w l , f(x)
>>>> input data ('e' ends) > -50,1
>>>> input data ('e' ends) > 0, 1
>>>> input data ('e' ends) > 50, -1
>>>> input data ('e' ends) > e
>>>>
>>>>            set xrange [ 0.00000 : 2.00000 ] noreverse nowriteback
>>>>            set yrange [ -60.0000 : 60.0000 ] noreverse nowriteback
>>>
>>> OK. So you have set explicit ranges.
>>
>> No. That was the output from "show all" command, showing what gnuplot
>> had selected automatically.
>
> I am mystified.
> That output indicates that you somehow set an explicit range.
> If it were in autoscale mode, the output would look like this:
>
>          set xrange [ * : * ] noreverse nowriteback  # (currently [-60.0000:60.0000] )
>          set yrange [ * : * ] noreverse nowriteback  # (currently [-1.00000:1.00000] )
>
>> All my commands were  as indicated by the prompts.
>
> Can't be.
> Did you maybe have commands in ~/.gnuplot ?
> Did you perform a zoom operation with the mouse?
>
>>>> Then I entered what I intended.
>>>>
>>>> gnuplot> plot "-" w l , f(x)
>>>> input data ('e' ends) > -50 -1
>>>> input data ('e' ends) > 0 1
>>>> input data ('e' ends) > 50 -1
>>>> input data ('e' ends) > e
>>>>
>>>>
>>>> However , this did not rescale, I got what appeared to be two flat lines
>>>> with the ranges still as shown above.
>> [snip]
>>>> No amount of replot, rescale etc seems to correct this
>> [snip]
>>>
>>> Did you really mean to say that the "replot" command does not prompt you
>>> to type in the data from "-" again?  That would be a bug.
>>
>> No, that's not what I meant to say, but it would be accurate to say that
>> I was not prompted to re-enter the data.
>
> I guess I'm still not understanding.
> You typed "replot" but it did not prompt you to re-enter the data?
> I go back to being mystified as to how this could happen given
> the command sequence you described.
>
>
>>>> So it seems that  scolling , which implies setting an explicit range
>>>> instead of auto, changes the way the function limits are determined.
>>>
>>> No, or at least I don't think of it that way.
>>> The hot-keys, scrolling, and rotation in 3D all try to use "refresh"
>>> rather than "replot" to avoid triggering a full re-read of all input on
>>> each event. For large input files or for substantial computation made on
>>> the input values, this can make a huge difference in responsiveness.
>>> And of course for input from the command line via "-" it is not possible
>>> to reread.
>>>
>>> You can always force a full "replot" including reevaluation of the
>>> input data if you want to.  That would also cause it to resample any
>>> functions using the current active domain on X.
>>
>> The problem I was seeing here was not that I wanted to resample the
>> funtion but that when it did so, it was not in a consistent way with the
>> initial plot command.
>>
>> Because the data was [-50:50] the function was plotted over the same
>> range as the data and autoscale (during the initial plot command)
>> created [-60:60] xrange.
>
> That's what I would have expected, but that's not what is indicated
> by the output you showed above.
>
>>
>> Recalculation of the grid, implicit as result of the scoll, then caused
>> the function to be plotted over the full  [-60:60] xrange.
>> This was a) inconsistent; b) problematic since the function was
>> ill-defined outside the intended range and was not suitable to be plotted.
>
> I agree that a function with domain restrictions could be an issue.
> But in general if the function is not defined at a sample point it just
> causes a gap in the plotted line, which is harmless other than wasting
> some of the sampling resolution on portions of the domain that do not
> contribute to the plot.
>
>> I would expect a scroll operation to do no more than move what I have
>> and fill in the gaps.
>
> That's exactly what it does if the data comes from '-'.
> On the other hand if the same data comes from a file, and you have not
> done 'set datafile volatile', then yes, the scrolling operation
> triggers both a re-read of the data file and resampling of the function
> to span the current domain on x.  For your test case with f(x)=0 I think
> that is the expected behaviour.  It means that the line at y=0 is
> always present even if the data from the file has scrolled out of range.
> Picking a function with domain restrictions, e.g. f(x)=log(x) means
> that as you scroll off to negative x the function disappears also.
> That also is as expected, no?
>
>> It seems untidy and unhelpful that , when I do the smallest scroll,
>> functions get plotted over a different range and the grid starts jumping
>> about and changing the tic internal.
>
> You mean if you zoom?
> I have never noticed that happen on a pure scroll event.
> As I said before, I can imagine tripping over a pathological case
> where the change in range causes such an effect, but I'd need a
> reproducible test case to investigate further.
>
> Do you see the same in current CVS?
> I apologize for having to ask, since I generally hate responding to bug
> reports with "please try the latest version" unless I already know that
> something relevant has been fixed.  And in this case I don't know of any
> relevant change since Feb/Mar 2012, when there was indeed a change to
> the wxt terminal code handling horizontal scolling events.  But that
> change is in the 4.6.1 release also, so if there is a difference between
> 4.6.1 and what you are seeing then it must lie somewhere else.
>
> 	Ethan
>
>
OK, let's start from the top to make sure I'm not misreporting something.

  ls ~/.gnuplot
  No such file or directory

fresh gnuplot session, repeat my initial erroneous input:

  $ gnuplot

         G N U P L O T
         Version 4.7 patchlevel 0    last modified 2012-10-16
         Build System: Linux i686
...

Terminal type set to 'wxt'
gnuplot>  f(x)=0
gnuplot>  plot "-" w l , f(x)
input data ('e' ends) > -50,1
input data ('e' ends) > 0,1
input data ('e' ends) > 50,1
input data ('e' ends) > e

[NO mouse interaction on graph}

show all
...
         set xrange [ * : * ] noreverse nowriteback  # (currently 
[0.00000:2.00000] )
         set yrange [ * : * ] noreverse nowriteback  # (currently 
[-60.0000:60.0000] )


That is the expected behaviour. Yet the first time I just did this I got 
an explicit range again. Now I'm confused :? The wxt window came up 
under the cursor on top of my xterm, was I inadvertently doing a mouse 
scroll ???

At this point replot command does prompt for input. The replot button in 
wxt does not. That is the source of that confusion. I did not say 
"replot command" and you assumed I did , I did not say "replot button" 
and I should have been more precise. I did not realise that the replot 
button did not do a replot command !!


Now repeating the correct data entry as previously reported:

gnuplot>  plot "-" w l , f(x)
input data ('e' ends) > -50 -1
input data ('e' ends) > 0 1
input data ('e' ends) > 50 -1
input data ('e' ends) > e


Now when scrolling, the function range stays locked to the data range as 
I would expect.


This is NOT what I was seeing yesterday and that I repeated a dozen 
times to verify what I was seeing , so there must be some other factor 
that I had not eliminated.


I'll go back to my real data processing and try to find out what 
triggers this defective behaviour.

There is something odd happening in a longer gnuplot session. That could 
make it tricky to pin down.


Sorry, this test case was not sufficient.

Peter.

Re: wxt mouse scrolling anomalies

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

On Saturday, 10 November 2012, pl...@pi... wrote:
> On 11/10/12 20:03, sfeam (Ethan Merritt) wrote:
> > On Saturday, 10 November 2012, pl...@pi... wrote:
> >
> >> Actually,I'm getting some very odd things happening here.
> >>
> >> Firstly , being still half asleep it typed in some data with commas and
> >> did not get what I intended (so not bug yet)
> >>
> >> gnuplot> f(x)=0
> >> gnuplot> plot "-" w l , f(x)
> >> input data ('e' ends) > -50,1
> >> input data ('e' ends) > 0, 1
> >> input data ('e' ends) > 50, -1
> >> input data ('e' ends) > e
> >>
> >>           set xrange [ 0.00000 : 2.00000 ] noreverse nowriteback
> >>           set yrange [ -60.0000 : 60.0000 ] noreverse nowriteback
> >
> > OK. So you have set explicit ranges.
> 
> No. That was the output from "show all" command, showing what gnuplot 
> had selected automatically.

I am mystified.
That output indicates that you somehow set an explicit range.
If it were in autoscale mode, the output would look like this:

        set xrange [ * : * ] noreverse nowriteback  # (currently [-60.0000:60.0000] )
        set yrange [ * : * ] noreverse nowriteback  # (currently [-1.00000:1.00000] )

> All my commands were  as indicated by the prompts.

Can't be.  
Did you maybe have commands in ~/.gnuplot ?
Did you perform a zoom operation with the mouse?

> >> Then I entered what I intended.
> >>
> >> gnuplot> plot "-" w l , f(x)
> >> input data ('e' ends) > -50 -1
> >> input data ('e' ends) > 0 1
> >> input data ('e' ends) > 50 -1
> >> input data ('e' ends) > e
> >>
> >>
> >> However , this did not rescale, I got what appeared to be two flat lines
> >> with the ranges still as shown above.
> [snip]
> >> No amount of replot, rescale etc seems to correct this
> [snip]
> >
> > Did you really mean to say that the "replot" command does not prompt you
> > to type in the data from "-" again?  That would be a bug.
> 
> No, that's not what I meant to say, but it would be accurate to say that 
> I was not prompted to re-enter the data.

I guess I'm still not understanding.
You typed "replot" but it did not prompt you to re-enter the data?
I go back to being mystified as to how this could happen given
the command sequence you described.


> >> So it seems that  scolling , which implies setting an explicit range
> >> instead of auto, changes the way the function limits are determined.
> >
> > No, or at least I don't think of it that way.
> > The hot-keys, scrolling, and rotation in 3D all try to use "refresh"
> > rather than "replot" to avoid triggering a full re-read of all input on
> > each event. For large input files or for substantial computation made on
> > the input values, this can make a huge difference in responsiveness.
> > And of course for input from the command line via "-" it is not possible
> > to reread.
> >
> > You can always force a full "replot" including reevaluation of the
> > input data if you want to.  That would also cause it to resample any
> > functions using the current active domain on X.
> 
> The problem I was seeing here was not that I wanted to resample the 
> funtion but that when it did so, it was not in a consistent way with the 
> initial plot command.
> 
> Because the data was [-50:50] the function was plotted over the same 
> range as the data and autoscale (during the initial plot command) 
> created [-60:60] xrange.

That's what I would have expected, but that's not what is indicated
by the output you showed above.

> 
> Recalculation of the grid, implicit as result of the scoll, then caused 
> the function to be plotted over the full  [-60:60] xrange.
> This was a) inconsistent; b) problematic since the function was 
> ill-defined outside the intended range and was not suitable to be plotted.

I agree that a function with domain restrictions could be an issue. 
But in general if the function is not defined at a sample point it just
causes a gap in the plotted line, which is harmless other than wasting
some of the sampling resolution on portions of the domain that do not
contribute to the plot.

> I would expect a scroll operation to do no more than move what I have 
> and fill in the gaps.

That's exactly what it does if the data comes from '-'.
On the other hand if the same data comes from a file, and you have not
done 'set datafile volatile', then yes, the scrolling operation 
triggers both a re-read of the data file and resampling of the function
to span the current domain on x.  For your test case with f(x)=0 I think
that is the expected behaviour.  It means that the line at y=0 is
always present even if the data from the file has scrolled out of range.
Picking a function with domain restrictions, e.g. f(x)=log(x) means
that as you scroll off to negative x the function disappears also.
That also is as expected, no?

> It seems untidy and unhelpful that , when I do the smallest scroll, 
> functions get plotted over a different range and the grid starts jumping 
> about and changing the tic internal.

You mean if you zoom?  
I have never noticed that happen on a pure scroll event.
As I said before, I can imagine tripping over a pathological case
where the change in range causes such an effect, but I'd need a
reproducible test case to investigate further.

Do you see the same in current CVS?
I apologize for having to ask, since I generally hate responding to bug
reports with "please try the latest version" unless I already know that
something relevant has been fixed.  And in this case I don't know of any
relevant change since Feb/Mar 2012, when there was indeed a change to
the wxt terminal code handling horizontal scolling events.  But that
change is in the 4.6.1 release also, so if there is a difference between
4.6.1 and what you are seeing then it must lie somewhere else.

	Ethan

Re: wxt mouse scrolling anomalies

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

On 11/10/12 20:03, sfeam (Ethan Merritt) wrote:
> On Saturday, 10 November 2012, pl...@pi... wrote:
>
>> Actually,I'm getting some very odd things happening here.
>>
>> Firstly , being still half asleep it typed in some data with commas and
>> did not get what I intended (so not bug yet)
>>
>> gnuplot> f(x)=0
>> gnuplot> plot "-" w l , f(x)
>> input data ('e' ends) > -50,1
>> input data ('e' ends) > 0, 1
>> input data ('e' ends) > 50, -1
>> input data ('e' ends) > e
>>
>>           set xrange [ 0.00000 : 2.00000 ] noreverse nowriteback
>>           set yrange [ -60.0000 : 60.0000 ] noreverse nowriteback
>
> OK. So you have set explicit ranges.

No. That was the output from "show all" command, showing what gnuplot 
had selected automatically.
All my commands were  as indicated by the prompts.

>
>>
>> Then I entered what I intended.
>>
>> gnuplot> plot "-" w l , f(x)
>> input data ('e' ends) > -50 -1
>> input data ('e' ends) > 0 1
>> input data ('e' ends) > 50 -1
>> input data ('e' ends) > e
>>
>>
>> However , this did not rescale, I got what appeared to be two flat lines
>> with the ranges still as shown above.
>
> Yes.
>
>> Then I hit the autoscale button (wxt) and got my triangular data line
>
> What's an "autoscale button"?  Do you mean the hot-key "a"?

" autoscale button (wxt)" is the button in wxt terminal with the hover 
hint "Apply autoscale".

>
>> but the function f(x) was only plotted over its previous x extent of 0:2
>>    and was I tiny segment on the now correct ranges:
>
> By default if you rescale/refresh a plot created from volatile
> (cannot be re-read) data, then it uses the values already stored internally.
> In your case this includes the function data sampled over the range [0:2].
>
>> No amount of replot, rescale etc seems to correct this, so there is a
>> difference of behaviour here for in line data rather than a file. (Can't
>> re-read pipe I guess).
>
> Yes, although actually an input pipe and a file act the same in this case.
> It is the difference between "refresh", which re-uses the existing data,
> and "replot" which goes back and reexecutes the previous plot command
> including reading from the data sources.  The program knows that it can't
> re-read from "-" so it automatically tries to avoid "replot".
> You can force the same behaviour for a data file or input pipe using
>     set datafile volatile
> This can be useful for example if the data source is changing in realtime
> but you want to zoom the currently visible display rather than
> replacing it with new data.
>
> Did you really mean to say that the "replot" command does not prompt you
> to type in the data from "-" again?  That would be a bug.

No, that's not what I meant to say, but it would be accurate to say that 
I was not prompted to re-enter the data.

>
>> So it seems that  scolling , which implies setting an explicit range
>> instead of auto, changes the way the function limits are determined.
>
> No, or at least I don't think of it that way.
> The hot-keys, scrolling, and rotation in 3D all try to use "refresh"
> rather than "replot" to avoid triggering a full re-read of all input on
> each event. For large input files or for substantial computation made on
> the input values, this can make a huge difference in responsiveness.
> And of course for input from the command line via "-" it is not possible
> to reread.
>
> You can always force a full "replot" including reevaluation of the
> input data if you want to.  That would also cause it to resample any
> functions using the current active domain on X.

The problem I was seeing here was not that I wanted to resample the 
funtion but that when it did so, it was not in a consistent way with the 
initial plot command.

Because the data was [-50:50] the function was plotted over the same 
range as the data and autoscale (during the initial plot command) 
created [-60:60] xrange.

Recalculation of the grid, implicit as result of the scoll, then caused 
the function to be plotted over the full  [-60:60] xrange.

This was a) inconsistent; b) problematic since the function was 
ill-defined outside the intended range and was not suitable to be plotted.

It seems untidy and unhelpful that , when I do the smallest scroll, 
functions get plotted over a different range and the grid starts jumping 
about and changing the tic internal.

I would expect a scroll operation to do no more than move what I have 
and fill in the gaps.

Peter.


>
> I suppose it might be reasonable to have "refresh" trigger resampling
> of 2D functions.  It would be computationally intensive in 3D, however,
> and hammer the responsiveness of mouse interaction.
>
> 	Ethan
>
>