gnuplot-bugs

[Gnuplot-bugs] small defects in 4.2

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

Hi,

first of all thanks for this excellent plotting utility. It takes a bit of  
getting used to but it very powerful and feature rich. The new wx terminal  
works nicely as well.

So since this is new , a bit of feedback on some minor faults, tested on  
Gentoo.

1.
resizing the wx window the graph scales well but so does the text. Once  
the drag is finished it remains too large until a replot is done.

I guess this is just an oversight detail since I dont imagine setting the  
font size would be a large overhead for this to be done on the fly as is  
done with the plot itself.

2.
Dragging the window by any size handle or corner does resize the graph but  
it remains at the same aspect ratio. Again hitting the replot button (or  
reloading the .gnu) will resize to fit the new window fully.

If this is to minimise on the fly redrawing it should probably at least  
replot once the drag event terminates.

3. colours do not come out the same in outputting to png , for example.  
It's rather confusing seeing different output stored as an image and  
annoying in transmitting to others since I cant say "look at the green  
line" because it's probably blue in the other output format.

4. I had a lot of time wasted trying to get y2 scale markings. I found the  
label readily enough but could not understand why I was not getting the  
tics and numerical markings. I now realise it required that I explicitly  
set y2tics . What confused me is that this is not the case with y1 they  
just come up automatically.

It would seem more logical and consistant if y2tics behaved in the same  
way as the main y-axis, ie as soon as there is a y2scale defined the  
default tics and numerical label come up as well.

This is obviously not new on 4.2 , it seems it was always this way.


Sorry for putting several issues in one thread but they are minor and you  
are probably aware of most of them anyway.


Apart from that I can report that Version 4.2 patchlevel 0 works without  
any major flaws in the use I have put it to.

Tested on Gentoo linux ~x86 profile compiled with  
i686-pc-linux-gnu-4.2.0-alpha20070307 on a 2.6.20 patched kernel.

Many thanks to all concerned for an excellent piece of software.
:)

Re: [Gnuplot-bugs] set table using time format data

[<pe...@pi...>]

On Thu, 03 May 2007 22:43:12 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>> here's a line from my working .gnu that does plot the line I want to
>> output to a table:
>>
>>
>>    plot  "150tank-txC.data"   using 1:($1<"14:00")?(P( Th4($3-2.0) -
>>    Th5($2) )/10):(P1( Th4($3-2.0) - Th5($2) )/10) with lines t "useful
>> power"
>
> That's almost certainly not going to work as planned.  Time/date data
> and $1 notation for extended using columns don't mix.  If it ever
> appears to work, that's a fluke.

OK let's forget the conditional syntax, that's irrelevant here because  
I've already stripped this down to the most simple form and posted that as  
the error.

>
>> however , if I use this in a table context I get an error:
>
>>    gnuplot> load "150tank-txC.gnu"
>>           "150tank-txC.gnu", line 46: Bad format character
>
> I'm reasonably sure you get the same basic error in every other context
> -- you just don't see it.
>

Do you mean that gnuplot is picking this up here and choking on it but  
deals with it incorrectly elsewhere without producing an error ?

> For more precise help, you'll have to actually _show_ us that command
> script (or a sufficient subset reproducing the problem).
>

I thought I had done just that, I'll try again.

Here's the start of the data. All other lines are empty or start with #



12:00  6.89 8.63 6.31 6.77 7.84
12:17  6.84 8.45 5.96 6.67 5.50
12:24  6.88 8.26 5.78 6.64 5.43
12:38  6.60 7.65 5.16 6.38 4.61

Here's the essencials of the script, calibration-results.gnu was created  
by save command with the plot command commented out later so it contains a  
full set of instructions. I believe the time data settings needed are  
explicitly set below so should override anything done be that file.

# load thermistor calibration data and functions: eg Th5() etc.
load "calibration-results.gnu"

set xdata time
set timefmt "%H:%M"

set format x "%02H:%02M"
set xr ["11:30":"18:30"]

datafile="150tank-txC.data";

set title "150 litre tank forced flow test 12 - PC cover"
set yrange [-5:85]
set y2range [-50:850]
set y2tics 0,100,800
set xlabel "time CES: sol +2h"
set ylabel "temp / C"
set y2label "power / W"
set key box
set key top right


   set table "tmp.data"
#  plot datafile  using 1:(Th5($2));
#  plot datafile  using 1:($2);
#  plot datafile  using (timecolumn(1)):($2);
#  plot datafile  using (column(1)):($2);
   unset table


plot datafile   using 1:(Th5($2))  with lines t "tank outlet"




Now if I uncomment each of those table lines in turn here's the errors I  
get.



gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 47: Bad format character

gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 48: Bad format character

gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 49: Bad format character

gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 50: Bad format character




I seems pretty clear that in table mode it is unable to parse the the time  
data whatever way I go about it.

If all are commented out the graph gets plotted beautifully on wxt , png,  
or svg by the later plot command.



I hope that gives you a clearer picture of what is happening.

Thanks for your help.

Re: [Gnuplot-bugs] set table using time format data

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

On Thu, 03 May 2007 23:40:24 +0200, <pe...@pi...> wrote:

> Here's the essencials of the script, calibration-results.gnu was created
> by save command with the plot command commented out later so it contains  
> a
> full set of instructions. I believe the time data settings needed are
> explicitly set below so should override anything done be that file.


OK just to eliminate any doubts I have removed the call to load  
calibration-results.gnu

The error in line 49 remains identical:

gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 49: Bad format character

thx.

Re: [Gnuplot-bugs] set table using time format data

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

On Thu, 03 May 2007 22:43:12 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>> here's a line from my working .gnu that does plot the line I want to
>> output to a table:
>>
>>
>>    plot  "150tank-txC.data"   using 1:($1<"14:00")?(P( Th4($3-2.0) -
>>    Th5($2) )/10):(P1( Th4($3-2.0) - Th5($2) )/10) with lines t "useful
>> power"
>
> That's almost certainly not going to work as planned.  Time/date data
> and $1 notation for extended using columns don't mix.  If it ever
> appears to work, that's a fluke.
>
>> however , if I use this in a table context I get an error:
>
>>    gnuplot> load "150tank-txC.gnu"
>>           "150tank-txC.gnu", line 46: Bad format character
>
> I'm reasonably sure you get the same basic error in every other context
> -- you just don't see it.
>
> For more precise help, you'll have to actually _show_ us that command
> script (or a sufficient subset reproducing the problem).
>

maybe you could post a few lines that do actually read my simple x time  
data in table mode.

If I have an example of this feature working I can build towards my code  
until I find what is breaking it.

Thanks again.

Re: [Gnuplot-bugs] set table using time format data

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

On Fri, 04 May 2007 08:06:21 +0200, <pl...@pi...> wrote:

>
>> For more precise help, you'll have to actually _show_ us that command
>> script (or a sufficient subset reproducing the problem).

Hi,

I have narrowed the problem down to "set format x"

It seems if I have a time format as in the example I posted it produces  
the  "Bad format character" error.

This presumably means it was producing an error on trying to output a  
datum rather than reading in a line.

Now I guess you're going to tell me this is a feature but I did not notice  
anything in the doc indicating time format data could not be in table mode  
so it seems like a bug to me.

That the output is in seconds is not a big problem now it is actually  
outputting something. So that's good news.

Now I can do all the "number crunching", like finding the mean of 12 data  
points, that gnuplot can't do.

Seems like an aweful lot of work for something so trivial.

;)

Re: [Gnuplot-bugs] set table using time format data

[<pe...@pi...>]

On Sun, 06 May 2007 00:06:05 +0200, <pl...@pi...> wrote:

> Now I guess you're going to tell me this is a feature but I did not  
> notice
> anything in the doc indicating time format data could not be in table  
> mode
> so it seems like a bug to me.

No, help table tells me :

   The data format is determined by the format of the axis
  labels (see `set format`)

this is a bug.

Re: [Gnuplot-bugs] small defects in 4.2

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

pl...@pi... wrote:

> 1.
> resizing the wx window the graph scales well but so does the text. Once  
> the drag is finished it remains too large until a replot is done.

Done on purpose by the implementors of the wx driver.

> 2.
> Dragging the window by any size handle or corner does resize the graph but  
> it remains at the same aspect ratio. Again hitting the replot button (or  
> reloading the .gnu) will resize to fit the new window fully.

Ditto.

> 3. colours do not come out the same in outputting to png , for example.  

The same ... as what?

> It's rather confusing seeing different output stored as an image and  
> annoying in transmitting to others since I cant say "look at the green  
> line" because it's probably blue in the other output format.

You _could_ look at the actual file you're sending them, though ;->

There's a price to be paid for having a tool that just works, without 
you having to rewrite the entire script, for so many different output 
formats.  One part of that price is that while gnuplot will try to do 
something useful for a given script regardless of the terminal driver 
it's run over, it can't be guaranteed that it'll do the _same_ for all 
of them.

> 4. I had a lot of time wasted trying to get y2 scale markings. I found the  
> label readily enough but could not understand why I was not getting the  
> tics and numerical markings. I now realise it required that I explicitly  
> set y2tics . What confused me is that this is not the case with y1 they  
> just come up automatically.

That's because every graph has *some* data on the y1 axis, while most 
graphs neither neither nor want a y2 axis.  There's also historic 
precedent to be maintained.  y2 axes were added to gnuplot a long time 
after the default behaviour of y1 axes was defined to have the tics 
mirrored to where the y2 axis would go.  This default behaviour would 
get in the way of y2 tics.

> It would seem more logical and consistant if y2tics behaved in the same  
> way as the main y-axis, ie as soon as there is a y2scale defined the  
> default tics and numerical label come up as well.

That's not actually how the y1 axis behaves, so why should y2?  The 
trick being that "there is a y1scale defined" is a non-event.  It's 
always defined.

Re: [Gnuplot-bugs] small defects in 4.2

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

On Mon, 30 Apr 2007 23:36:31 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>> 1.
>> resizing the wx window the graph scales well but so does the text. Once
>> the drag is finished it remains too large until a replot is done.
>
> Done on purpose by the implementors of the wx driver.
>
>> 2.
>> Dragging the window by any size handle or corner does resize the graph  
>> but
>> it remains at the same aspect ratio. Again hitting the replot button (or
>> reloading the .gnu) will resize to fit the new window fully.
>
> Ditto.
>
Fine , I guess there must be some reason for doing it that way then  
although it makes resizing the plot an iterative process which seems a bit  
untidy.

>> 3. colours do not come out the same in outputting to png , for example.
>
> The same ... as what?
>

Er , same as wx terminal.

>> It's rather confusing seeing different output stored as an image and
>> annoying in transmitting to others since I cant say "look at the green
>> line" because it's probably blue in the other output format.
>
> You _could_ look at the actual file you're sending them, though ;->
>

Yes , clearly it _can_ , but pulling up another app. to see how it  
rendered that colours differently from the gnuplot terminal I work in is a  
drag.

Also , I sent a plot to a college as svg , which is great for this sort of  
thing but it repeated some colours making the graph a lot less clear. I  
dont see any technical reason why svg should be limitted to fewer colours  
so this would seem to be defect.

> There's a price to be paid for having a tool that just works, without
> you having to rewrite the entire script, for so many different output
> formats.  One part of that price is that while gnuplot will try to do
> something useful for a given script regardless of the terminal driver
> it's run over, it can't be guaranteed that it'll do the _same_ for all
> of them.
>

Not a big issue but one thing that could improve gnuplot should an  
occasion arise to fix it. There seems no intrinsic reason why wx, png and  
svg should assign different colours.


>> 4. I had a lot of time wasted trying to get y2 scale markings. I found  
>> the
>> label readily enough but could not understand why I was not getting the
>> tics and numerical markings. I now realise it required that I explicitly
>> set y2tics . What confused me is that this is not the case with y1 they
>> just come up automatically.
>
> That's because every graph has *some* data on the y1 axis, while most
> graphs neither neither nor want a y2 axis.

Which is *exactly* why I suggested it was only done once a y2scale was  
defined. At this point mirroring y1tics becomes wrong and the lack of y2  
numbering is inappropriate to the newly displayed label.

> There's also historic
> precedent to be maintained.  y2 axes were added to gnuplot a long time
> after the default behaviour of y1 axes was defined to have the tics
> mirrored to where the y2 axis would go.  This default behaviour would
> get in the way of y2 tics.
>
Ditto.

>> It would seem more logical and consistant if y2tics behaved in the same
>> way as the main y-axis, ie as soon as there is a y2scale defined the
>> default tics and numerical label come up as well.
>
> That's not actually how the y1 axis behaves, so why should y2?  The
> trick being that "there is a y1scale defined" is a non-event.  It's
> always defined.
>

Sorry. Maybe I explained this badly.

I curreny have a graph with y1 and y2 .

set xdata time
set timefmt "%H:%M"

set format x "%02H:%02M"
set xr ["11:30":"18:30"]

set title "150 litre tank forced flow test 12 - PC cover"
set yrange [-5:85]
set y2range [-50:850]
set y2tics 0,100,800
set xlabel "time CES: sol +2h"
set ylabel "temp / C"
set y2label "power / W"


I do not define ytics yet I get the numbers , if I do not define y2tics  
explicitly as done here , I don't get any numbers on y2, I just get the  
y2label. There is inconsistancy between the two which is confusing when  
learning to use gnuplot.

The difference in behaviour , if there is a reason to retain it which I  
dont see, probably ought to be documented.

Thanks for you reply. I hope my comments are useful in improving this very  
useful tool.

Kind regards.

Re: [Gnuplot-bugs] small defects in 4.2

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

pl...@pi... wrote:
> On Mon, 30 Apr 2007 23:36:31 +0200, Hans-Bernhard Bröker  
> <HBB...@t-...> wrote:
>> pl...@pi... wrote:

>>> 3. colours do not come out the same in outputting to png , for example.
>> The same ... as what?

> Er , same as wx terminal.

It would be hard to achieve the same colours between theses colours 
automatically, given that the colours used by both terminals can be 
changed by the user.  See 'help term png' and check the configuration 
dialog of the wxt version.

> I do not define ytics yet I get the numbers , if I do not define y2tics  
> explicitly as done here , I don't get any numbers on y2, I just get the  
> y2label. There is inconsistancy between the two which is confusing when  
> learning to use gnuplot.

The inconsistency exists for a pretty good reason: most new users spend 
quite a while using gnuplot without needing, nor wanting to be bothered 
by having to control, a second axis.  Requiring them to specify xtics 
before they get a readable plot would be obviously wrong.  By the time 
they find out about secondary axes, they usually know about 'set xtics' 
already, so they can figure out the rest.

I don't think there's a pressing need to explain this any more verbosely 
than it already is in 'help xtics'.

[Gnuplot-bugs] set table using time format data

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

Hi,

Having some difficulty making this work. I started with 4.2 but find the  
same results using today's CVS.

here's a line from my working .gnu that does plot the line I want to
output to a table:


   plot  "150tank-txC.data"   using 1:($1<"14:00")?(P( Th4($3-2.0) -
   Th5($2) )/10):(P1( Th4($3-2.0) - Th5($2) )/10) with lines t "useful  
power"


however , if I use this in a table context I get an error:


   gnuplot> load "150tank-txC.gnu"
          "150tank-txC.gnu", line 46: Bad format character



Even if I take it to it's simplest form and explicitly use
timecolumn() it always gives that error.

   set table "tmp.data"
   plot "150tank-txC.data" using (timecolumn(1)):($2)
   unset table

line 46 is the plot command here above.

It seems it's getting parsed differently, is there something else I
need to know here?

It would appear that table output does not correctly process time format  
data at this point.
Is that correct?

TIA.

Re: [Gnuplot-bugs] set table using time format data

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

pl...@pi... wrote:

> here's a line from my working .gnu that does plot the line I want to
> output to a table:
> 
> 
>    plot  "150tank-txC.data"   using 1:($1<"14:00")?(P( Th4($3-2.0) -
>    Th5($2) )/10):(P1( Th4($3-2.0) - Th5($2) )/10) with lines t "useful  
> power"

That's almost certainly not going to work as planned.  Time/date data 
and $1 notation for extended using columns don't mix.  If it ever 
appears to work, that's a fluke.

> however , if I use this in a table context I get an error:

>    gnuplot> load "150tank-txC.gnu"
>           "150tank-txC.gnu", line 46: Bad format character

I'm reasonably sure you get the same basic error in every other context 
-- you just don't see it.

For more precise help, you'll have to actually _show_ us that command 
script (or a sufficient subset reproducing the problem).

[Gnuplot-bugs] illogical error fitting polynomial

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

Hi,

I am fitting a simple polynomial to some data. It works fine and gives  =

what looks to the naked eye like a credible fit .


pow(x)=3Da*(x-k)*(x-k)+b*(x-k)+c;
fit pow(x) datafile  using 1:( P( Th4($3-2.0) - Th5($2) )/10 ) via a,b,c=
,k;


However if I remove the constant /10 or make it /1 or /1.0 the call to f=
it  =

fails saying there are not enough data points. Same data , same params s=
o  =

not too logical.


fit pow(x) datafile  using 1:( P( Th4($3-2.0) - Th5($2) ) ) via a,b,c,k;=


gnuplot> load "150tank-txC.gnu"
          Number of data points smaller than number of parameters


This is presumably a different error condition that is not getting trapp=
ed  =

correctly and displaying an incorrect error message.

I currently have to multiply by ten later :?
Any suggestions?

TIA.

Re: [Gnuplot-bugs] illogical error fitting polynomial

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

pl...@pi... wrote:

> However if I remove the constant /10 or make it /1 or /1.0 the call to fit  
> fails saying there are not enough data points. 

You defined a y range, but without the division, most data points are 
outside that range.  Yes, 'fit' does respect 'set yrange'.

> This is presumably a different error condition that is not getting trapped  
> correctly and displaying an incorrect error message.

You presume prematurely.

Re: [Gnuplot-bugs] illogical error fitting polynomial

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

On Fri, 04 May 2007 23:36:24 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>> However if I remove the constant /10 or make it /1 or /1.0 the call to  
>> fit
>> fails saying there are not enough data points.
>
> You defined a y range, but without the division, most data points are
> outside that range.  Yes, 'fit' does respect 'set yrange'.
>
hmm, the doc for fit command says the following:

>> Ranges may be specified to temporarily limit the data which is to be  
>> fitted;any out-of-range data points are ignored.

The result of not specifying a range for fit is not explained.

Since it would be possible to inadvertantly exclude some data from a fit  
and hence produce incorrect results (eg require a fit over whole range of  
data but plot expanded detail of one region) this probably should be  
documented explicitly.

>> This is presumably a different error condition that is not getting  
>> trapped
>> correctly and displaying an incorrect error message.
>
> You presume prematurely.

Indeed I do, my appologies. Though a more explicit error message would  
help avoid confusion.

"Insufficient data points in specified range" would point the user more  
clearly to cause of the problem.

I would say "what range?" and quickly realise my mistake.


Many thanks for pointing me to the cause, it is quite possible that some  
points are still getting ignored with my /10 formular, I will expliticly  
add range parameters to fit.


Have you been able to establish whether table mode deals correctly with  
time data or not? This is holding me back in passing my data out to a  
script .

Thanks again for your help.

Re: [Gnuplot-bugs] illogical error fitting polynomial

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

pl...@pi... wrote:
> On Fri, 04 May 2007 23:36:24 +0200, Hans-Bernhard Bröker  
> <HBB...@t-...> wrote:
>> pl...@pi... wrote:

>> You defined a y range, but without the division, most data points are
>> outside that range.  Yes, 'fit' does respect 'set yrange'.

> hmm, the doc for fit command says the following:

>>> Ranges may be specified to temporarily limit the data which is to be  
>>> fitted;any out-of-range data points are ignored.

> The result of not specifying a range for fit is not explained.

It's explained by cross-reference to the plot command.  Ranges for 'fit' 
behave the same way as they do for 'plot'.  That's why there's a 
hyperlink to 'help plot ranges' in 'help fit'.

> "Insufficient data points in specified range" would point the user more  
> clearly to cause of the problem.

... assuming that a range restriction was actually the cause of there 
not being enough data.  There could just as easily be a problem with the 
fitted function being undefined over the whole data range, or the number 
of data points being just a bit too small.  Incorrect error messages 
would be a good deal worse than terse ones.