Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #3008 > unrolled thread

Xtics offset

Back to article view | Back to comp.graphics.apps.gnuplot

Contents

  Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-15 02:05 +0200
    Re: Xtics offset Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-08-15 12:34 +0200
      Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-15 12:57 +0200
        Re: Xtics offset Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-08-15 21:38 +0200
          [meta] Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-15 23:34 +0200
        Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 00:57 +0200
          Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 01:15 +0200
            Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 01:59 +0200
    Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 01:04 +0200
      Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 01:11 +0200
        Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 01:22 +0200
          Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 01:57 +0200
            [meta] Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 14:03 +0200
              Re: [meta] Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 14:49 +0200
                Re: [meta] Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 15:35 +0200
                  Re: [meta] Re: Xtics offset Ethan A Merritt <merritt@u.washington.edu> - 2015-08-17 10:26 -0700
                    Re: [meta] Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-17 21:27 +0200
          Re: Xtics offset Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-16 02:19 +0200
            Re: Xtics offset Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-16 14:22 +0200

#3008 — Xtics offset

I have tabular data of amount values to be plotted over time. I use

  set xdata time
  set format x "%Y"
  set xlabel "Date"
  set mxtics 0

Unfortunately the date labels are not placed centered (to visualize that
the whole range from 1st Jan to 31st Dec belongs to the respective year)

  |----|----|----|
   2009 2010 2011

but rather the year labels are placed at (virtually) 1st Jan

  |----|----|----|
 2009 2010 2011

So I worked around the issue with 'set xtics ... offset ...'.

The problem I am facing is that the effect of any hard coded offset will
depend on the number of data on the xaxis; i.e. with a data range of e.g.
15 years the date labels will be placed too far to the right

  |----|----|----|
    2009 2010 2011

while with a data range of e.g. six years the date labels will be placed
too far to the left

  |----|----|----|
  2009 2010 2011

As initially mentioned I want the labels centered. How can I achieve that?

I'm using gnuplot 4.4 PL2

Thanks!

Janis

[toc] | [next] | [standalone]

#3010

Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:

> So I worked around the issue with 'set xtics ... offset ...'.

Looks like you should have read more of the documentation about that option.

> The problem I am facing is that the effect of any hard coded offset will
> depend on the number of data on the xaxis;

Only if you specify it in the wrong coordinate system.

> I'm using gnuplot 4.4 PL2

Then you should consider updating.  That version is 5 years old.

[toc] | [prev] | [next] | [standalone]

#3013

On 15.08.2015 12:34, Hans-Bernhard Bröker wrote:
> Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:
> 
>> So I worked around the issue with 'set xtics ... offset ...'.
> 
> Looks like you should have read more of the documentation about that option.

I've read it - but certainly not the whole 225 pages but only the matches of
my searches for the respected keywords -, and therefore I am asking, because
it was not clear.

> 
>> The problem I am facing is that the effect of any hard coded offset will
>> depend on the number of data on the xaxis;
> 
> Only if you specify it in the wrong coordinate system.

Sadly this statement is not helpful without explanation or concrete sample.

> 
>> I'm using gnuplot 4.4 PL2
> 
> Then you should consider updating.  That version is 5 years old.

I'm using the software installed on my system and not overwrite the defaults
by any appearing new release.

Your statements are obviously not the least helpful. I still appreciate some
more concrete information about the issue(s) of my original post. Thanks!

Janis

[toc] | [prev] | [next] | [standalone]

#3017

Am 15.08.2015 um 12:57 schrieb Janis Papanagnou:
> On 15.08.2015 12:34, Hans-Bernhard Bröker wrote:
>> Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:
>>
>>> So I worked around the issue with 'set xtics ... offset ...'.
>>
>> Looks like you should have read more of the documentation about that option.
>
> I've read it - but certainly not the whole 225 pages but only the matches of
> my searches for the respected keywords -, and therefore I am asking, because
> it was not clear.

Nobody was talking about the entire 225 pages.  The paragraph in 
question, i.e. the one _about_that_option_,  is closer to 225 characters 
--- and you apparently missed half of that.

> Your statements are obviously not the least helpful.

Well, I'll refrain from being helpful then.  Good bye.

[toc] | [prev] | [next] | [standalone]

#3018 — [meta] Re: Xtics offset

On 15.08.2015 21:38, Hans-Bernhard Bröker wrote:
> Am 15.08.2015 um 12:57 schrieb Janis Papanagnou:
>> On 15.08.2015 12:34, Hans-Bernhard Bröker wrote:
>>> Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:
>>>
>>>> So I worked around the issue with 'set xtics ... offset ...'.
>>>
>>> Looks like you should have read more of the documentation about that option.
>>
>> I've read it - but certainly not the whole 225 pages but only the matches of
>> my searches for the respected keywords -, and therefore I am asking, because
>> it was not clear.
> 
> Nobody was talking about the entire 225 pages.  The paragraph in question,
> i.e. the one _about_that_option_,  is closer to 225 characters --- and you
> apparently missed half of that.

You presumed in your post that I did not RTFM; in my reply I told you that I
clearly did RTFM. It was still not clear how to solve the issue, otherwise I
wouldn't have bothered to post.

> 
>> Your statements are obviously not the least helpful.
> 
> Well, I'll refrain from being helpful then.  Good bye.

Have you ever been helpful here? Hardly to believe given that non-informative
arrogant reply. I politely asked a clear question, and all you could do was
effectively a "RTFM", a vague statement, and an "update your software". Well,
this behaviour is not uncommon in some Usenet groups and in some web forums,
so you don't surprise me. Good bye.

But maybe there's some folks here who do *have* the necessary experience and
could provide some concrete and helpful hint on the original question. Thanks!

Janis

[toc] | [prev] | [next] | [standalone]

#3021

Am 15.08.2015 um 12:57 schrieb Janis Papanagnou:
> On 15.08.2015 12:34, Hans-Bernhard Bröker wrote:
>> Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:
>>
>>> So I worked around the issue with 'set xtics ... offset ...'.
>>
>> Looks like you should have read more of the documentation about that option.
> 
> I've read it - but certainly not the whole 225 pages but only the matches of
> my searches for the respected keywords -, and therefore I am asking, because
> it was not clear.
> 

He meant just the section about "offset" under "set xtics". ;-)

>>
>>> The problem I am facing is that the effect of any hard coded offset will
>>> depend on the number of data on the xaxis;
>>
>> Only if you specify it in the wrong coordinate system.
> 
> Sadly this statement is not helpful without explanation or concrete sample.
> 

It says you can specify the coordinate system for the offset. Use
"first" instead of the default "screen" and give an offset of half a
year (in seconds).

	set xtics offset first 365./2*24*3600, 0

>>
>>> I'm using gnuplot 4.4 PL2
>>
>> Then you should consider updating.  That version is 5 years old.
> 
> I'm using the software installed on my system and not overwrite the defaults
> by any appearing new release.

Just install locally. Or try pestering your sysadmin about updating
your distribution. From my experience, the latter is a lot harder. ;-)

  Karl

[toc] | [prev] | [next] | [standalone]

#3024

On 16.08.2015 00:57, Karl-Friedrich Ratzsch wrote:
> Am 15.08.2015 um 12:57 schrieb Janis Papanagnou:
>> On 15.08.2015 12:34, Hans-Bernhard Bröker wrote:
>>> Am 15.08.2015 um 02:05 schrieb Janis Papanagnou:
>>>
>>>> So I worked around the issue with 'set xtics ... offset ...'.
>>>
>>> Looks like you should have read more of the documentation about that option.
>>
>> I've read it - but certainly not the whole 225 pages but only the matches of
>> my searches for the respected keywords -, and therefore I am asking, because
>> it was not clear.
>>
> 
> He meant just the section about "offset" under "set xtics". ;-)

Thanks! - I already knew about the 'offset first'; actually I started from
that point. (Please see my recent posting about my additional insights where
the actual problem seems to be - 'logscale y' with 'xtics offset first'.)

> 
>>>
>>>> The problem I am facing is that the effect of any hard coded offset will
>>>> depend on the number of data on the xaxis;
>>>
>>> Only if you specify it in the wrong coordinate system.
>>
>> Sadly this statement is not helpful without explanation or concrete sample.
>>
> 
> It says you can specify the coordinate system for the offset. Use
> "first" instead of the default "screen" and give an offset of half a
> year (in seconds).
> 
> 	set xtics offset first 365./2*24*3600, 0

I used such code (though in my recent tries I used absolute numbers instead
of the more legible expressions, because I wanted to rule out problems here).

But wait! - I seem to have missed that final '0'. (Have to look its meaning
up in the manual.)

> 
>>>
>>>> I'm using gnuplot 4.4 PL2
>>>
>>> Then you should consider updating.  That version is 5 years old.
>>
>> I'm using the software installed on my system and not overwrite the defaults
>> by any appearing new release.
> 
> Just install locally. Or try pestering your sysadmin about updating
> your distribution. From my experience, the latter is a lot harder. ;-)

The point is that I had made bad experience with updates of gnuplot; older
gnuplot programs did not work any more, and I had to spend more time than
worth to spend for the project to fix the gnuplot-incompatibility-issues.
(I use that tool maybe once a year, so I am reluctant to jump on every new
release. So, please, bear with me! :-)

Thanks for your explanations!

Janis

[toc] | [prev] | [next] | [standalone]

#3027

Am 16.08.2015 um 01:15 schrieb Janis Papanagnou:
>> It says you can specify the coordinate system for the offset. Use
>> "first" instead of the default "screen" and give an offset of half a
>> year (in seconds).
>>
>> 	set xtics offset first 365./2*24*3600, 0
> 
> I used such code (though in my recent tries I used absolute numbers instead
> of the more legible expressions, because I wanted to rule out problems here).
> 
> But wait! - I seem to have missed that final '0'. (Have to look its meaning
> up in the manual.)

It's the y offset. Unfortunately gnuplot implies it's value as
"zero" even if you don't give any. And log(0) gives an error, obviously.

[toc] | [prev] | [next] | [standalone]

#3022

On 15.08.2015 02:05, Janis Papanagnou wrote:
> I have tabular data of amount values to be plotted over time. I use
> 
>   set xdata time
>   set format x "%Y"
>   set xlabel "Date"
>   set mxtics 0
> 
> Unfortunately the date labels are not placed centered (to visualize that
> the whole range from 1st Jan to 31st Dec belongs to the respective year)
> 
>   |----|----|----|
>    2009 2010 2011
> 
> but rather the year labels are placed at (virtually) 1st Jan
> 
>   |----|----|----|
>  2009 2010 2011
> 
> So I worked around the issue with 'set xtics ... offset ...'.
> 
> The problem I am facing is that the effect of any hard coded offset will
> depend on the number of data on the xaxis; i.e. with a data range of e.g.
> 15 years the date labels will be placed too far to the right
> 
>   |----|----|----|
>     2009 2010 2011
> 
> while with a data range of e.g. six years the date labels will be placed
> too far to the left
> 
>   |----|----|----|
>   2009 2010 2011
> 
> As initially mentioned I want the labels centered. How can I achieve that?

Some more trial and error gave me these insights:

In my very first approach (where I started) I had defined

   set xtics 31536000 offset first 15768000

which had been fine, until I added a a logarithmic Y-axis

   set logscale y

which gave me this error

   line 0: ytics has y coord of 0; must be above 0 for log scale!

That error vanished after I removed the 'first' offset specifier

   set xtics 31536000 offset 5

which has the reported problem of being dependent of the number of dates on
the X-axis.

To sum up: Introduction of the 'logscale' for Y-axis made it impossible to
use the 'offset first' specifier for the X-axis without getting above error.

Now I am confused. The defaults for 'ytics' works fine with *linear* Y-axis.
And the defaults for 'ytics' works also fine with an X-axis *without X-axis
offset* and *logarithmic* Y-axis. But it does *not* work with X-axis 'offset'
and logarithmic Y-axis. Note the dependency of X-axis and Y-axis definitions!
(I abstain to comment on intuitive behaviour here, beyond that the defaults
seem not be well defined.) It seems in this case I need to specify explicitly
the 'ytics' to prevent that error wich 'logscale y' and 'xtics offset first'.
(I couldn't find a working 'ytics' setting, though. Hmm..)

Janis

> 
> I'm using gnuplot 4.4 PL2
> 
> Thanks!
> 
> Janis
> 

[toc] | [prev] | [next] | [standalone]

#3023

Am 16.08.2015 um 01:04 schrieb Janis Papanagnou:
> Some more trial and error gave me these insights:
> 
> In my very first approach (where I started) I had defined
> 
>    set xtics 31536000 offset first 15768000
> 
> which had been fine, until I added a a logarithmic Y-axis
> 
>    set logscale y
> 
> which gave me this error
> 
>    line 0: ytics has y coord of 0; must be above 0 for log scale!
> 
> That error vanished after I removed the 'first' offset specifier
> 
>    set xtics 31536000 offset 5
> 
> which has the reported problem of being dependent of the number of dates on
> the X-axis.
> 
> To sum up: Introduction of the 'logscale' for Y-axis made it impossible to
> use the 'offset first' specifier for the X-axis without getting above error.
> 
> Now I am confused. The defaults for 'ytics' works fine with *linear* Y-axis.
> And the defaults for 'ytics' works also fine with an X-axis *without X-axis
> offset* and *logarithmic* Y-axis. But it does *not* work with X-axis 'offset'
> and logarithmic Y-axis. Note the dependency of X-axis and Y-axis definitions!
> (I abstain to comment on intuitive behaviour here, beyond that the defaults
> seem not be well defined.) It seems in this case I need to specify explicitly
> the 'ytics' to prevent that error wich 'logscale y' and 'xtics offset first'.
> (I couldn't find a working 'ytics' setting, though. Hmm..)

That is a bug, i see the same with gnuplot 5.01.

You can circumvent it by explicitly specifying the y offset in
screen coordinates:


	set offset xtics offset first 35153000, screen 0

[toc] | [prev] | [next] | [standalone]

#3025

On 16.08.2015 01:11, Karl-Friedrich Ratzsch wrote:
[...]
>>
>> Now I am confused. The defaults for 'ytics' works fine with *linear* Y-axis.
>> And the defaults for 'ytics' works also fine with an X-axis *without X-axis
>> offset* and *logarithmic* Y-axis. But it does *not* work with X-axis 'offset'
>> and logarithmic Y-axis. Note the dependency of X-axis and Y-axis definitions!
>> (I abstain to comment on intuitive behaviour here, beyond that the defaults
>> seem not be well defined.) It seems in this case I need to specify explicitly
>> the 'ytics' to prevent that error wich 'logscale y' and 'xtics offset first'.
>> (I couldn't find a working 'ytics' setting, though. Hmm..)
> 
> That is a bug, i see the same with gnuplot 5.01.

Wow! - Now, you know, I use gnuplot maybe once every other year (or so), and
stumbled already on the *second* [IMO severe] bug. - At least that is news I
can work with; until now I thought I've done something wrong. - Thanks again!
Your post saved me a lot time I would otherwise have uselessly spent.

> 
> You can circumvent it by explicitly specifying the y offset in
> screen coordinates:
> 
> 
> 	set offset xtics offset first 35153000, screen 0

I'll experiment with that. Or maybe I use varying absolute offsets depending
on the data; I can do that since I can extract the year margins from the
original data, and I anyway construct the gnuplot commands from a dynamically
generated template.

Janis

[toc] | [prev] | [next] | [standalone]

#3026

Am 16.08.2015 um 01:22 schrieb Janis Papanagnou:
> On 16.08.2015 01:11, Karl-Friedrich Ratzsch wrote:

>> That is a bug, i see the same with gnuplot 5.01.
> 
> Wow! - Now, you know, I use gnuplot maybe once every other year (or so), and
> stumbled already on the *second* [IMO severe] bug. - At least that is news I
> can work with; until now I thought I've done something wrong. - Thanks again!
> Your post saved me a lot time I would otherwise have uselessly spent.

Welcome to the world of open source software: Bug get fixed as users
report them.

Sadly, most people don't do that. Like you: The program clearly
behaved illogically (y logscale influenced xtics x offset), but you
didn't tell about it at first. That wastes not only your time but
also mine. And that's why Hans-Bernhard was a bit unfriendly: He
could smell you were trying to waste his'. ;-)

Nevermind.

  Karl

[toc] | [prev] | [next] | [standalone]

#3031 — [meta] Re: Xtics offset

On 16.08.2015 01:57, Karl-Friedrich Ratzsch wrote:
> Am 16.08.2015 um 01:22 schrieb Janis Papanagnou:
>> On 16.08.2015 01:11, Karl-Friedrich Ratzsch wrote:
> 
>>> That is a bug, i see the same with gnuplot 5.01.
>>
>> Wow! - Now, you know, I use gnuplot maybe once every other year (or so), and
>> stumbled already on the *second* [IMO severe] bug. - At least that is news I
>> can work with; until now I thought I've done something wrong. - Thanks again!
>> Your post saved me a lot time I would otherwise have uselessly spent.
> 
> Welcome to the world of open source software: Bug get fixed as users
> report them.
> 
> Sadly, most people don't do that.

Since first you mentioned that it's a bug, how should I file a bug in
the first place; how could I see that the behaviour of gnuplot wasn't
correct? Usually I first have to assume that I missed some point. And
the gnuplot documentation is far from having specification qualities to
be able to distinguish bugs from intentional designed behaviour. YMMV.
From my perspective; I didn't knew what the actual problem was, so I
posted.

> Like you: The program clearly
> behaved illogically (y logscale influenced xtics x offset), but you
> didn't tell about it at first.

Unfortunately I didn't knew that at that time.

> That wastes not only your time but also mine.

My apologies. But I really couldn't see that an "illogical behaviour"
gnuplot-bug was the reason. My working thesis was that I missed something,
despite having read the docs and tried a lot in a trial and error fashion.
And since I assumed folks here are experienced, they can quickly point me
to the error I made.

Usually it's good to focus on the specific observable issue; if one makes
a bulky post that's usually also not what people like reading.

> And that's why Hans-Bernhard was a bit unfriendly: He
> could smell you were trying to waste his'. ;-)

I still don't think his behaviour was, though not untypical in Usenet
and Web-Fora, appropriate.

Moreover, posts like the one from HBP wastes everyones time, IMO; since
he did not provide any concrete information, but rather only spit out
that unfriendly, vague, off-topic, bla-bla. In case I would have missed
something in the docs a simple chapter reference would certainly have
helped.

Thanks for reading.

Janis

> 
> Nevermind.
> 
>   Karl
> 

[toc] | [prev] | [next] | [standalone]

#3034 — Re: [meta] Re: Xtics offset

Am 16.08.2015 um 14:03 schrieb Janis Papanagnou:
> My apologies. But I really couldn't see that an "illogical behaviour"
> gnuplot-bug was the reason. My working thesis was that I missed something,
> despite having read the docs and tried a lot in a trial and error fashion.
> And since I assumed folks here are experienced, they can quickly point me
> to the error I made.
> 
> Usually it's good to focus on the specific observable issue; if one makes
> a bulky post that's usually also not what people like reading.

Of course you should be succinct, but you definitely need to tell
what exactly you tried and didn't work. Otherwise people are
inclined to think you're just _saying_ you read the docs and tried
to solve it, and bark "RTFM!" at you.

The docs clearly give the solution (specify the coordinate system),
but we didn't know it breaks with logscales, didn't even know you
were using a logscale. So we concluded you hadn't read it.

[toc] | [prev] | [next] | [standalone]

#3035 — Re: [meta] Re: Xtics offset

On 16.08.2015 14:49, Karl-Friedrich Ratzsch wrote:
> Am 16.08.2015 um 14:03 schrieb Janis Papanagnou:
>> My apologies. But I really couldn't see that an "illogical behaviour"
>> gnuplot-bug was the reason. My working thesis was that I missed something,
>> despite having read the docs and tried a lot in a trial and error fashion.
>> And since I assumed folks here are experienced, they can quickly point me
>> to the error I made.
>>
>> Usually it's good to focus on the specific observable issue; if one makes
>> a bulky post that's usually also not what people like reading.
> 
> Of course you should be succinct, but you definitely need to tell
> what exactly you tried and didn't work.

The point is (since I didn't knew it's a bug) I tried so many variants
that, for one, I couldn't post every variant I tried, and second, the
final version (the one that finally didn't threw the error message) had
that absolute offset (i.e. without 'first'). I posted what didn't work
in the last version, which I had to believe was closest to the correct
implementation.

The problem, as already said, was this "illogical [gnuplot] behaviour".
Don't expect that illogical behaviour (coupling of X specs with Y specs)
would make it sensible for posters to provide (presumedly) "unrelated"
information. In one case it could be good, in most other cases it would
be considered bulky irrelevance so that people don't want to read it at
all.

> Otherwise people are
> inclined to think you're just _saying_ you read the docs and tried
> to solve it, and bark "RTFM!" at you.

I still think people should not "think" what I might have omitted to do
("RTFM") if that "thought" results in non-informative trollish replies.
If some folks start with a "bark" instead of trying to help, well, that
tells more about those folks than about anything else. If information
is missing - and the experts here are certainly the ones who could tell
best! -, then a polite request to post the whole code (if necessary or
helpful) would certainly be the simplest reply, and least time-wasting.

> 
> The docs clearly give the solution (specify the coordinate system),
> but we didn't know it breaks with logscales, didn't even know you
> were using a logscale. So we concluded you hadn't read it.

That the problem was actually related to those (presumedly) unrelated
entities was not obvious. Mind, I am only a very casual gnuplot user,
not an expert like many of you here.

Janis

[toc] | [prev] | [next] | [standalone]

#3039 — Re: [meta] Re: Xtics offset

People use gnuplot for an amazing variety of applications.
I am continually surprised at where I come across it,
and at what people tell me they use it for.
Probably no one person has ever made use of all the options, settings,
features, and quirks that have accummulated in the gnuplot code.

The point I am trying to make is that you should not assume that
what you are trying to do lies on some well-trodden path from which
many previous users have found and removed all the obstacles and bugs.
In this case you have tripped over a behavior that has been there
for the last 10 years, when the "offset" option was added for "set tics".
  
Is it a bug?   yeah
Is it fixable? probably
Are you really the first one to hit it?
I don't know, but I see no previous bug reports on the tracker.
Either nobody tried this or they found a work-around and didn't
bother to report it.  That doesn't match the profile I would
expect for a "severe" bug - more like an unexpected restriction
in a little-used feature.

Anyhow, it's got a tracker number now, and will probably get
a fix in due time:

   https://sourceforge.net/p/gnuplot/bugs/1662/

- Ethan



Janis Papanagnou wrote:

> On 16.08.2015 14:49, Karl-Friedrich Ratzsch wrote:
>> Am 16.08.2015 um 14:03 schrieb Janis Papanagnou:
>>> My apologies. But I really couldn't see that an "illogical behaviour"
>>> gnuplot-bug was the reason. My working thesis was that I missed
>>> something, despite having read the docs and tried a lot in a trial and
>>> error fashion. And since I assumed folks here are experienced, they can
>>> quickly point me to the error I made.
>>>
>>> Usually it's good to focus on the specific observable issue; if one
>>> makes a bulky post that's usually also not what people like reading.
>> 
>> Of course you should be succinct, but you definitely need to tell
>> what exactly you tried and didn't work.
> 
> The point is (since I didn't knew it's a bug) I tried so many variants
> that, for one, I couldn't post every variant I tried, and second, the
> final version (the one that finally didn't threw the error message) had
> that absolute offset (i.e. without 'first'). I posted what didn't work
> in the last version, which I had to believe was closest to the correct
> implementation.
> 
> The problem, as already said, was this "illogical [gnuplot] behaviour".
> Don't expect that illogical behaviour (coupling of X specs with Y specs)
> would make it sensible for posters to provide (presumedly) "unrelated"
> information. In one case it could be good, in most other cases it would
> be considered bulky irrelevance so that people don't want to read it at
> all.
> 
>> Otherwise people are
>> inclined to think you're just _saying_ you read the docs and tried
>> to solve it, and bark "RTFM!" at you.
> 
> I still think people should not "think" what I might have omitted to do
> ("RTFM") if that "thought" results in non-informative trollish replies.
> If some folks start with a "bark" instead of trying to help, well, that
> tells more about those folks than about anything else. If information
> is missing - and the experts here are certainly the ones who could tell
> best! -, then a polite request to post the whole code (if necessary or
> helpful) would certainly be the simplest reply, and least time-wasting.
> 
>> 
>> The docs clearly give the solution (specify the coordinate system),
>> but we didn't know it breaks with logscales, didn't even know you
>> were using a logscale. So we concluded you hadn't read it.
> 
> That the problem was actually related to those (presumedly) unrelated
> entities was not obvious. Mind, I am only a very casual gnuplot user,
> not an expert like many of you here.
> 
> Janis
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

[toc] | [prev] | [next] | [standalone]

#3042 — Re: [meta] Re: Xtics offset

On 17.08.2015 19:26, Ethan A Merritt wrote:
> People use gnuplot for an amazing variety of applications.
> I am continually surprised at where I come across it,
> and at what people tell me they use it for.

(Erm, you mean for something else than plotting data?)

I mean, one plots graphs with it, flat, 2D, projected-3D, whatever,
with circles, bars, dots, etc. - But some parts are fundamental, like
axes, scales, annotations; I wouldn't expect flaws at least in those
basic building blocks, specifically in a software that is so old (or
"mature"?).

> Probably no one person has ever made use of all the options, settings,
> features, and quirks that have accummulated in the gnuplot code.

You're most likely right here.

> 
> The point I am trying to make is that you should not assume that
> what you are trying to do lies on some well-trodden path from which
> many previous users have found and removed all the obstacles and bugs.
> In this case you have tripped over a behavior that has been there
> for the last 10 years, when the "offset" option was added for "set tics".

Why I think that it's basic features is that logarithmic scales and tics,
are basic features in both, in science and in [other] plotting software.
The 'offset', well, I agree that this part *may* be arguable; OTOH, on
software development scales, 10 years is really a lot (even if ignoring
that one gets rebuked if using a 5 year old release; LOL) - I'm wondering
that no one would have come across it (or no one reported it, given that
there seems to be a lot folks - specifically here around - that use that
tool more often than just sporadic (as I do).

>   
> Is it a bug?   yeah
> Is it fixable? probably
> Are you really the first one to hit it?
> I don't know, but I see no previous bug reports on the tracker.
> Either nobody tried this or they found a work-around and didn't
> bother to report it.  That doesn't match the profile I would
> expect for a "severe" bug - more like an unexpected restriction
> in a little-used feature.

(Little used feature? - Well, I have no research data and can't speak
for others; but, as explained above, it's hard to believe that.)

My intention was certainly not to anger all the fans of this software
with that qualification. ;-)  It was certainly influenced by the
frustration; about the bug, the hours I spent to understand what goes
on in that software, about the (first) response here, and that the
posted work-around did not work for me out of the box. - I take back
that qualification ("severe") that I made.

> 
> Anyhow, it's got a tracker number now, and will probably get
> a fix in due time:
> 
>    https://sourceforge.net/p/gnuplot/bugs/1662/

Thanks. I saw Karl-Friedrich's post.

Janis

> 
> - Ethan

[toc] | [prev] | [next] | [standalone]

#3028

Am 16.08.2015 um 01:22 schrieb Janis Papanagnou:
> On 16.08.2015 01:11, Karl-Friedrich Ratzsch wrote:
>> That is a bug, i see the same with gnuplot 5.01.
> 
> Wow! - Now, you know, I use gnuplot maybe once every other year (or so), and
> stumbled already on the *second* [IMO severe] bug. - At least that is news I

Can't quite see what's severe about this one, it's rather hard to
trigger, and has a simple workaround.

Anyway, I filed it on

https://sourceforge.net/p/gnuplot/bugs/1662/

Best, Karl

[toc] | [prev] | [next] | [standalone]

#3032

On 16.08.2015 02:19, Karl-Friedrich Ratzsch wrote:
> Am 16.08.2015 um 01:22 schrieb Janis Papanagnou:
>> On 16.08.2015 01:11, Karl-Friedrich Ratzsch wrote:
>>> That is a bug, i see the same with gnuplot 5.01.
>>
>> Wow! - Now, you know, I use gnuplot maybe once every other year (or so), and
>> stumbled already on the *second* [IMO severe] bug. - At least that is news I
> 
> Can't quite see what's severe about this one,

A term "severe" (for me) means that it will not produce output at all,
but an error message. And specifically so if such behaviour is in a basic
function. YMMV.

> it's rather hard to trigger, and has a simple workaround.

For me it was easy to trigger. The intended task is a simple one. YMMV.

The workaround you suggested did not work for me; but - considering your
other post about time waste - I will not bother you or the newsgroup with
it. Now that I know it's a bug (thanks again!) I'll apply my own workarounds.

> 
> Anyway, I filed it on
> 
> https://sourceforge.net/p/gnuplot/bugs/1662/

Thanks.

Janis

> 
> Best, Karl
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.graphics.apps.gnuplot

csiph-web