gnuplot-info — For questions and discussion about gnuplot

Re: [Gnuplot-info] integer vs. floating point division

[Ethan A M. <EAM...@gm...>]

On Wednesday, 15 November 2017 01:44:04 you wrote:
> > > I'd say integer division is gradually becoming an anachronism,
> > > and the new trend seems to be not just fixed floating-point but
> > > full rational-number support or arbitrary- (even infinite-)
> > > precision calculations, to avoid frustrating behaviors like
> > > ceil(900e-7/12e-7) => 76.
> > 
> > There you intrigue me.  I have a patch series queued that adds 64-bit
> > integer arithmetic with full overflow handling everywhere.  Would it indeed
> > be feasible to similarly upgrade the floating point evaluation code to
> > provide more  graceful handling of very large numbers?
> > The int64 conversion was surprisingly easy so I can believe that
> > modernizing the floating point would also be  straightforward.
> > But I wouldn't know where to start.  Do you have suggestions?
> 
> That particular example will "misbehave" even with 64b doubles
> (or at least it did in my test, which is why I used that
> particular example).

It does not misbehave here  in gnuplot (linux x86-64 platform)

I tried a few larger exponents at random, up to
ceil(900e-101/12e-101), without tripping an error.
Is there some particular pattern that is prone to error?

> But in general, the only reason I see not
> to convert from float to double is that some platforms wouldn't
> have built-in double support.

Gnuplot has used (double) everywhere since 2011, when we
dropped support for 16-bit Windows.

The only exception is that when reading in binary matrix files,
the matrix is stored as (float).  I don't know why that was, but 
it's on my list of things to fix in 5.3

> I don't work on esoteric platforms
> anymore, and obviously Win/Linux/Mac all handle double fine.

Exactly.

	Ethan

Re: [Gnuplot-info] integer vs. floating point division

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

> > > > ceil(900e-7/12e-7) => 76.
> > > ...
> > That particular example will "misbehave" even with 64b doubles
> > (or at least it did in my test, which is why I used that
> > particular example).
> 
> It does not misbehave here  in gnuplot (linux x86-64 platform)
> 
> I tried a few larger exponents at random, up to
> ceil(900e-101/12e-101), without tripping an error.
> Is there some particular pattern that is prone to error?

Sorry; I meant it misbehaves in a dumb little C++
program I was using to test, not in gnuplot.

#include <iostream>
#include <ios>
#include <iomanip>
#include <cmath>

int main() {
    double num1 = 900e-7;
    double num2 = 12e-7;
    std::cout << std::setprecision(30) << std::fixed
        << num1 << std::endl
        << num2 << std::endl
        << num1/num2 << std::endl
        << std::ceil(num1/num2) << std::endl;
    return 0;
}

Although as you say, it doesn't go to 76 in gnuplot,
which makes me wonder why it behaves differently.

Re: [Gnuplot-info] integer vs. floating point division

[David K. <da...@gn...>]

Tait <gnu...@t4...> writes:

>> > I'd say integer division is gradually becoming an anachronism,
>> > and the new trend seems to be not just fixed floating-point but
>> > full rational-number support or arbitrary- (even infinite-)
>> > precision calculations, to avoid frustrating behaviors like
>> > ceil(900e-7/12e-7) => 76.
>> 
>> There you intrigue me.  I have a patch series queued that adds 64-bit
>> integer arithmetic with full overflow handling everywhere.  Would it indeed
>> be feasible to similarly upgrade the floating point evaluation code to
>> provide more  graceful handling of very large numbers?
>> The int64 conversion was surprisingly easy so I can believe that
>> modernizing the floating point would also be  straightforward.
>> But I wouldn't know where to start.  Do you have suggestions?
>
> That particular example will "misbehave" even with 64b doubles
> (or at least it did in my test, which is why I used that
> particular example). But in general, the only reason I see not
> to convert from float to double is that some platforms wouldn't
> have built-in double support.

Since historically double had been the _only_ floating point
_expression_ format in K&R C (as opposed to floating point storage
format that could be just float), platforms without built-in double
support would be really peculiar once using them for C became a
mainstream choice.

-- 
David Kastrup

Re: [Gnuplot-info] integer vs. floating point division

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

> > I'd say integer division is gradually becoming an anachronism,
> > and the new trend seems to be not just fixed floating-point but
> > full rational-number support or arbitrary- (even infinite-)
> > precision calculations, to avoid frustrating behaviors like
> > ceil(900e-7/12e-7) => 76.
> 
> There you intrigue me.  I have a patch series queued that adds 64-bit
> integer arithmetic with full overflow handling everywhere.  Would it indeed
> be feasible to similarly upgrade the floating point evaluation code to
> provide more  graceful handling of very large numbers?
> The int64 conversion was surprisingly easy so I can believe that
> modernizing the floating point would also be  straightforward.
> But I wouldn't know where to start.  Do you have suggestions?

That particular example will "misbehave" even with 64b doubles
(or at least it did in my test, which is why I used that
particular example). But in general, the only reason I see not
to convert from float to double is that some platforms wouldn't
have built-in double support. I don't work on esoteric platforms
anymore, and obviously Win/Linux/Mac all handle double fine.

Re: [Gnuplot-info] integer vs. floating point division

[Ethan M. <eam...@gm...>]

On Tue, Nov 14, 2017 at 4:38 PM, Tait <gnu...@t4...> wrote:

>
> It's worth mentioning that Python has changed this behavior. In
> Python2, division defaults to integer-division and 1/2 is 0.
> Starting with Python3 (which in my experience is used everywhere
> except niche applications by now) "true" division applies,
> meaning types are auto-promoted such that 1/2 is 0.5.
>

My experience differs. I have seen hardly a sign of Python3.
Then again, probably every single application in my field counts as "niche".
Either way I really, really don't think we want to use Python as a guide.

I'd say integer division is gradually becoming an anachronism,
> and the new trend seems to be not just fixed floating-point but
> full rational-number support or arbitrary- (even infinite-)
> precision calculations, to avoid frustrating behaviors like
> ceil(900e-7/12e-7) => 76.
>

There you intrigue me.  I have a patch series queued that adds 64-bit
integer arithmetic with full overflow handling everywhere.  Would it indeed
be feasible to similarly upgrade the floating point evaluation code to
provide more  graceful handling of very large numbers?
The int64 conversion was surprisingly easy so I can believe that
modernizing the floating point would also be  straightforward.
But I wouldn't know where to start.  Do you have suggestions?

    Ethan

Re: [Gnuplot-info] integer vs. floating point division

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

> >> as described in gnuplot help, gnuplot does integer divison if the
> >> dividend and the divisors are integers.
> >> As a normal user, you don't expect this
> >
> > [shrug]  integer division is "normal" for most programming and
> > scripting languages.
> 
> Octave: 0.50000
> Guile: 1/2
> awk: 0.5
> Perl: 0.5
> Lua: 0.5
> Python: 0
> bc: 0
> Bash: 0
> Pascal: 0.5
> Fortran: 0
> 
> Now I'll grant you Fortran and Python.  The rest either gives 0.5 or is
> not intended for floating point calculations anyway.
> 
> Arguably Octave is the most relevantly similar in scope.

It's worth mentioning that Python has changed this behavior. In
Python2, division defaults to integer-division and 1/2 is 0.
Starting with Python3 (which in my experience is used everywhere
except niche applications by now) "true" division applies,
meaning types are auto-promoted such that 1/2 is 0.5.

I'd say integer division is gradually becoming an anachronism,
and the new trend seems to be not just fixed floating-point but
full rational-number support or arbitrary- (even infinite-)
precision calculations, to avoid frustrating behaviors like
ceil(900e-7/12e-7) => 76.

Re: [Gnuplot-info] integer vs. floating point division

[David K. <da...@gn...>]

Ethan Merritt <eam...@gm...> writes:

> On Tue, Nov 14, 2017 at 3:13 PM, David Kastrup <da...@gn...> wrote:
>
>> Ethan Merritt <eam...@gm...> writes:
>>
>> > On Tue, Nov 14, 2017 at 1:39 PM, theozh <th...@gm...> wrote:
>> >> as described in gnuplot help, gnuplot does integer divison if the
>> >> dividend and the divisors are integers.
>> >> As a normal user, you don't expect this
>> >
>> > [shrug]  integer division is "normal" for most programming and
>> > scripting languages.
>>
>> Octave: 0.50000
>
> Guile: 1/2
>> awk: 0.5
>> Perl: 0.5
>> Lua: 0.5
>> Python: 0
>> bc: 0
>> Bash: 0
>> Pascal: 0.5
>> Fortran: 0
>>
>> Now I'll grant you Fortran and Python.  The rest either gives 0.5 or is
>> not intended for floating point calculations anyway.
>>
>
> You left out the most relevant of all.
> Gnuplot is written in C and uses C language code for internal and
> user-visible evaluations.

The implementation is completely irrelevant for the semantics (most
scripting languages are implemented in C), and Gnuplot has operators
like ** eq ne .

> [now I'm nit-picking...]
>
> Lua doesn't have integer variables, so there the question is moot.

Uh what?  Octave does not have integer variables either because it is
intended for numerical work.  As is Gnuplot.

Really, it's completely irrelevant what Gnuplot is implemented in.  The
question is what its application domain is.

The user has nothing to gain from getting some technical analogy to the
implementation language as an explanation for tripping him up.

C is prone to crashes due to its memory access and allocation semantics,
but that does not mean that it's Gnuplot's duty to give the user ways to
crash the machine.

At any rate, we are talking about decisions that have managed to stick
around for decades, similar to % only being permitted for integers, as
if there never was a need to, say, wrap a value in the 0..2pi domain or
even calculate 420.5 % 360 for the sake of degrees.

The main reason appears to me to rub the users' noses in the
programmers' superior knowledge of C semantics.

Gnuplot does not use a C parser so there is no inherent reason to
prescribe C semantics.

-- 
David Kastrup

Re: [Gnuplot-info] integer vs. floating point division

[Ethan M. <eam...@gm...>]

On Tue, Nov 14, 2017 at 3:13 PM, David Kastrup <da...@gn...> wrote:

> Ethan Merritt <eam...@gm...> writes:
>
> > On Tue, Nov 14, 2017 at 1:39 PM, theozh <th...@gm...> wrote:
> >> as described in gnuplot help, gnuplot does integer divison if the
> >> dividend and the divisors are integers.
> >> As a normal user, you don't expect this
> >
> > [shrug]  integer division is "normal" for most programming and
> > scripting languages.
>
> Octave: 0.50000

Guile: 1/2
> awk: 0.5
> Perl: 0.5
> Lua: 0.5
> Python: 0
> bc: 0
> Bash: 0
> Pascal: 0.5
> Fortran: 0
>
> Now I'll grant you Fortran and Python.  The rest either gives 0.5 or is
> not intended for floating point calculations anyway.
>

You left out the most relevant of all.
Gnuplot is written in C and uses C language code for internal and
user-visible evaluations.

[now I'm nit-picking...]

Lua doesn't have integer variables, so there the question is moot.

Ruby:
stonelion [186] ruby
print 1/2, "\n"
0


   Ethan



> Arguably Octave is the most relevantly similar in scope.
>
> --
> David Kastrup
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/
> lists/listinfo/gnuplot-info
>

Re: [Gnuplot-info] integer vs. floating point division

[David K. <da...@gn...>]

Ethan Merritt <eam...@gm...> writes:

> Pascal (ah nostalgia...) it's been years.  I no longer remember, and I
> don't have a Pascal
> compiler on my current machines to try it.

Pascal has "div" and "mod" operators if you want integer results.

-- 
David Kastrup

Re: [Gnuplot-info] integer vs. floating point division

[David K. <da...@gn...>]

Ethan Merritt <eam...@gm...> writes:

> On Tue, Nov 14, 2017 at 1:39 PM, theozh <th...@gm...> wrote:
>> as described in gnuplot help, gnuplot does integer divison if the
>> dividend and the divisors are integers.
>> As a normal user, you don't expect this
>
> [shrug]  integer division is "normal" for most programming and
> scripting languages.

Octave: 0.50000

Guile: 1/2

awk: 0.5

Perl: 0.5

Lua: 0.5

Python: 0

bc: 0

Bash: 0

Pascal: 0.5

Fortran: 0

Now I'll grant you Fortran and Python.  The rest either gives 0.5 or is
not intended for floating point calculations anyway.

Arguably Octave is the most relevantly similar in scope.

-- 
David Kastrup

Re: [Gnuplot-info] integer vs. floating point division

[Ethan M. <eam...@gm...>]

On Tue, Nov 14, 2017 at 2:19 PM, theozh <th...@gm...> wrote:
> Thanks Ethan,
> I knew the int() function but didn't know about the real() function. I
thought this is for extracting the real part of complex numbers, but
obviously it can also be used to convert an integer number to a real number.
>
>> [shrug]  integer division is "normal" for most programming and
>> scripting languages.
> [ahem]... then the few languages I know a little bit (Perl, Python,
Pascal,... ) are not "normal" ;-)

I think you are mis-remembering

> stonelion [163] python
> Python 2.7.13 (default, Jan 28 2017, 17:29:29)
> [GCC 5.4.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> print 5/2
> 2
> >>>
>
>
Perl being perl, you have your choice :-)  Although it is true that perl
defaults to floating division,
it is recommended to place the "use integer" pragma at the start of any
program that cares.

stonelion [164] perl
> use integer;
> print 5/2, "\n";
> 2
>
>
Pascal (ah nostalgia...) it's been years.  I no longer remember, and I
don't have a Pascal
compiler on my current machines to try it.

> What worries me a bit is:
> Quote help:
> "The result of division of a negative integer by a positive one may vary
among compilers. Try a test like "print -5/2" to determine if your system
chooses -2 or -3 as the answer."

I suspect that statement dates all the way back to 1980something, and
refers to
compilers or computer architectures from last century.
C99 compliance guarantees truncation towards zero.
(But C89 did not, so yes at the time gnuplot was first written it made
sense to worry about this).

As a side note - people contributing code to gnuplot recently often assume
that use of
C99 features is OK.   We may want to require use of a C99 compliant
complier in the future,
but so far the gnuplot coding guidelines and installation instructions
don't say that.
If we add that caveat for 5.3, I will remove the caution you point to in
the docs.

> Well, as long as I am working only on my system I should know what I will
get ;-).

Anyhow, using real(variable) will force floating point arithmetic if you
need that.

Re: [Gnuplot-info] integer vs. floating point division

[theozh <th...@gm...>]

Thanks Ethan,
I knew the int() function but didn't know about the real() function. I thought this is for extracting the real part of complex numbers, but obviously it can also be used to convert an integer number to a real number.

> [shrug]  integer division is "normal" for most programming and 
> scripting languages.
[ahem]... then the few languages I know a little bit (Perl, Python, Pascal,... ) are not "normal" ;-)

What worries me a bit is:
Quote help:
"The result of division of a negative integer by a positive one may vary among compilers. Try a test like "print -5/2" to determine if your system chooses -2 or -3 as the answer."

Well, as long as I am working only on my system I should know what I will get ;-).

Re: [Gnuplot-info] integer vs. floating point division

[Ethan M. <eam...@gm...>]

On Tue, Nov 14, 2017 at 1:39 PM, theozh <th...@gm...> wrote:
> as described in gnuplot help, gnuplot does integer divison if the dividend and the divisors are integers.
> As a normal user, you don't expect this

[shrug]  integer division is "normal" for most programming and
scripting languages.

> and you will learn about this "pitfall" when you're wondering why you get wrong plotting results (or if you read the manual from the beginning to the end and will stumble across it).
>
> How to force a floating point division with two integer variables, e.g. in loops?

If you need to force a variable to be a real number, use real(var).
Conversely if you need an integer, use int(var).


> The only way I found is to multiply the first number by 1.0
> Is this really the way to go?
>
> Example:
>
> do for [i=1:6] {
>   do for [j=1:6] { print sprintf("%g\t%g",i/j,i*1./j) }
> }
>
> Isn't there maybe a way to set a flag to always use floating point divison?

print real(i) / real(j)

           Ethan

[Gnuplot-info] integer vs. floating point division

[theozh <th...@gm...>]

as described in gnuplot help, gnuplot does integer divison if the dividend and the divisors are integers.
As a normal user, you don't expect this and you will learn about this "pitfall" when you're wondering why you get wrong plotting results (or if you read the manual from the beginning to the end and will stumble across it).

How to force a floating point division with two integer variables, e.g. in loops?
The only way I found is to multiply the first number by 1.0
Is this really the way to go?

Example:

do for [i=1:6] {
  do for [j=1:6] { print sprintf("%g\t%g",i/j,i*1./j) }
}

Isn't there maybe a way to set a flag to always use floating point divison?

Re: [Gnuplot-info] X values from data set headers in boxplot

[Martin P. <ma...@po...>]

Ah, that worked. Thanks a lot! I'll keep in mind to use pngcairo rather than png 
in the future.

- Martin


On Friday, November 10, 2017 8:54:41 PM CET theozh wrote:
> sorry, I tested it in a wxt terminal.
> 
> Obviously, it is different with png (btw I would use pngcairo terminal).
> 
> Something with "set output".
> Apparently, you have to set it twice (once again between the dummy plot 
and
> the second plot command). Furthermore, you need to close your output with
> "set output" at the end.
> 
> The following should now really be working as all-in-one copy&paste code.

Re: [Gnuplot-info] X values from data set headers in boxplot

[theozh <th...@gm...>]

sorry, I tested it in a wxt terminal.

Obviously, it is different with png (btw I would use pngcairo terminal).

Something with "set output".
Apparently, you have to set it twice (once again between the dummy plot and the second plot command). 
Furthermore, you need to close your output with "set output" at the end.

The following should now really be working as all-in-one copy&paste code.

Re: [Gnuplot-info] X values from data set headers in boxplot

[Martin P. <ma...@po...>]

Thank you for your two suggestions! I have tried them both, and although I 
don't get any error message, the plots are empty. The plot in the first 
suggestion maintain the desired X range from 0 to 60, while the plot in the 
second example has a range from -0.5 to 2.5. The data has only been modified 
in the first suggestion; I replaced three line breaks by two line breaks, 
causing only a single empty line between data sets.

Attached are the samples I tried with. Do our .g files differ? I run
   Version 5.2 patchlevel 0    last modified 2017-09-01
for the record.

- Martin


On fredag 3 november 2017 kl. 23:22:25 CET you wrote:
> hi again,
> it should work without changing your data with these lines:
> 
> array XValue[3]
> plot for [i=0:STATS_blocks-1] 'data.dat' index i using (XValue[i+1]=$1,1):1
> every 1:1:0:0:0:0 notitle plot for [i=0:STATS_blocks-1] 'data.dat' index i
> using (XValue[i+1]):1 title columnheader(i + 1)

[Gnuplot-info] What does 'line 0' mean?

[Aleksey T. <ats...@gm...>]

As a Web application owner, I wanted to graph the number of daily unique
visitors (out of my Apache httpd log) for the last six weeks.

My httpd log goes 5 months back (from July to November 2017) -- here it is
sorted by month:

    # cat /var/cfengine/httpd/logs/access_log* |   awk '/GET \/api\/user\//
{print $4, $7}'|   cut -b2-12,22- |   grep -v admin  |   sort -u |   sort
 -k2  -t/ -M |   awk '{print $1}' |   uniq -c |   awk 'NR == 1 { print }
END { print }'
          1 12/Jul/2017
          2 09/Nov/2017
    #



I tried the following:

    set xdata time
    set xtics rotate
    set timefmt "%d/%b/%Y"
    set format x "%d/%b/%Y"

    set autoscale xfixmin
    set autoscale xfix

    # only show visitors for last 6 weeks (sliding window)
    min=system("date -d '6 weeks ago' +%d/%h/%Y")
    max=system("date -d 'now' +%d/%h/%Y")
    set xrange [ "min" : "max"]
    show xrange

    plot '-' using 2:1 with lines


which generated:

             line 0: illegal day of month


            set xdata time
            set xrange [ * : * ] noreverse nowriteback  # (currently
["01/Jan/2000":"01/Jan/2000"] )
    set autoscale xfixmin
    set autoscale xfixmax

So then I took out the xrange stuff and instead just added "| tail -42" to
my one-liner:

    cat /var/cfengine/httpd/logs/access_log* |   awk '/GET \/api\/user\//
{print $4, $7}'|   cut -b2-12,22- |   grep -v admin  |   sort -u |   sort
 -k2  -t/ -M |   awk '{print $1}' |   uniq -c |  tail -42

I can feed THAT into gnuplot and it does what I want, graphs the last six
months only. Yay! So I've solved my graphing needs, but I'd like to
understand the error message.  What does 'line 0' mean?  There is nothing
wrong with my input...  What am I doing wrong with the gnuplot commands?

Love the tool, by the way. So powerful and useful!

Thanks!
Aleksey

Re: [Gnuplot-info] X values from data set headers in boxplot

[theozh <th...@gm...>]

hi again,
it should work without changing your data with these lines:

array XValue[3]
plot for [i=0:STATS_blocks-1] 'data.dat' index i using (XValue[i+1]=$1,1):1 every 1:1:0:0:0:0 notitle
plot for [i=0:STATS_blocks-1] 'data.dat' index i using (XValue[i+1]):1 title columnheader(i + 1)

Re: [Gnuplot-info] X values from data set headers in boxplot

[theozh <th...@gm...>]

Hi Martin,

if you exchange your line:
plot for [i=0:(STATS_blocks - 1)] 'data.dat' index i using (50 + (i * 5)):1 title columnheader(i + 1)

by these lines:

array XValue[3]
plot for [i=1:3] 'data.dat' u 1:(XValue[i]=$1,1) every 1:1::(i-1)::(i-1) w p ls 1 not
plot for [i=1:3] 'data.dat' u (XValue[i]):1 every 1:1:1:(i-1)::(i-1) title sprintf("%g",XValue[i])

and if you change your data such there is only one empty line instead of two, you should get your desired result.

What it basically does is
- creating an array of XValues
- the first plot just extracts the first numbers of each datablock and writes them into the array
- the second plot command finally plots at the XValues from this array.

However, seems to work but not very elegant... maybe there is a smarter way...

Limitation: 
in the for loop you can't use [i=1:STATS_block] for a variable number of blocks, because apparently STATS_blocks needs two empty data lines two count datablocks, whereas "every" only allows for one empty line.

See also my other question/post about datablock separation, which hopefully somebody can comment on.
Theo.

[Gnuplot-info] Confusion about datablock separation

[theozh <th...@gm...>]

Hi,
I am confused with the separation of datablocks.
Apparently, the keyword "every" requires 1 (and not more) empty line for block separation,
whereas the function STATS_blocks requires 2 empty lines for block separation.
If you want to use both, STATS_blocks to count blocks and "every" to plot blocks this seems to contradict.
How can this be solved?
Below is a copy&paste gnuplot code to illustrate. I expected to get two identical plots, however, which is not the case. What have I missed? I am using Win7/64 gnuplot 5.2rc4.
Thank you for clarification.


### start gnuplot code
reset
$Data1 <<EOD
1
3
2

5
4
6

8
7
9
EOD

$Data2 <<EOD
1
3
2


5
4
6


8
7
9
EOD

set colorsequence classic
set multiplot layout 1,2
stats $Data1 using 1 nooutput
set label 1 sprintf("STATS blocks: %g",STATS_blocks) at graph 0.5,0.5
plot for [i=0:2] $Data1 using 0:1 every 1:1::i::i w lp ls i+1

stats $Data2 using 1 nooutput
set label 1 sprintf("STATS blocks: %g",STATS_blocks) at graph 0.5,0.5
plot for [i=0:2] $Data2 using 0:1 every 1:1::i::i w lp ls i+1
unset multiplot

### end gnuplot code

[Gnuplot-info] X values from data set headers in boxplot

[Martin P. <ma...@po...>]

Hello,

I am trying to plot multiple sets of data with the boxplot style. All sets of 
data have their unique X axis value. In my small example, I have got it to 
work for X = 50, X = 55 and X = 60 in the same plot. However, I am not quite 
satisfied with the solution.

>From boxplot.g.txt, this is the part where the X values are determined:
   index i using (50 + (i * 5)):1

As you can see, the X value is calculated based on the index of the set in the 
data file. However, I would like to use the set's numeric header instead. I 
have tried to replace (50 + (i*5)) by (columnheader(i + 1)), but Gnuplot 
complains about "undefined function: columnheader." The columnheader(i + 1) 
call works perfectly fine just a few characters away in the same plot line, 
when it is used for setting the title.

How can I use the header of the data set as the X axis value?

Best regards,
Martin Pola

Re: [Gnuplot-info] How to place values on a columnstacked histogram?

[sfeam <sf...@us...>]

On Monday, 30 October 2017 00:18:31 theozh wrote:
> Thanks again for your patient explanations.
> 
> My (mis)understanding probably is that I thought you can place 
> either (i.e. XOR) a <definition> or a <function> or a <data source>
> 
>   plot-element:
>         {<iteration>}
>         <definition> | {sampling-range} <function> | <data source>
>         {axes <axes>} {<title-spec>}
>         {with <style>}

Your have a point.
The BNF syntax shown in the help text is not correct.
Probably it has been amended in parallel to changes in the plot code
and at some point the logic diverged.

I should probably go back to the source and work out a proper description
from the ground up.

	Ethan


> however, 
> plot n=n+1 sin(x*n)
> is a <definition> AND a <function>
> whereas <function> AND <data source> at the same time is not supposed to work.

Re: [Gnuplot-info] How to place values on a columnstacked histogram?

[theozh <th...@gm...>]

Thanks again for your patient explanations.

My (mis)understanding probably is that I thought you can place 
either (i.e. XOR) a <definition> or a <function> or a <data source>

  plot-element:
        {<iteration>}
        <definition> | {sampling-range} <function> | <data source>
        {axes <axes>} {<title-spec>}
        {with <style>}

however, 
plot n=n+1 sin(x*n)
is a <definition> AND a <function>
whereas <function> AND <data source> at the same time is not supposed to work.

Re: [Gnuplot-info] How to place values on a columnstacked histogram?

[sfeam <sf...@us...>]

On Sunday, 29 October 2017 01:01:10 theozh wrote:
> Thank you again, Ethan, for the explanations and links.
> 
> What's still not clear to me why you can place the
> ysum=0 between two plot commands...

That part is explained by "help plot".
 Syntax:
       plot {<ranges>} <plot-element> {, <plot-element>, <plot-element>}

 Each plot element consists of a definition, a function, or a data source
 together with optional properties or modifiers:
       plot-element:
            {<iteration>}
            <definition> | {sampling-range} <function> | <data source>
            {axes <axes>} {<title-spec>}
            {with <style>}

the "ysum = 0" matches the <definition> template  "foo = <expression>".

> What else can you place in front of a plot command?
> For example:
> n=1
> plot n=n+1 sin(x*n) # works
> plot (n=1,n=n+1) sin(x*n) # doesn't work... why?

because "(n=1,n=n+1)" is not a definition.
You could make it one by adding a dummy assignment:

  plot   dummy=(n=1,n=n+1) sin(x*n)


	Ethan
 
> 
> Anyway, my original question is solved :-).
> Nevertheless, I played around a little further.
> If the portions in the stacked histogram are too small to fit a number,
> the following code shows a way to place those numbers on the side with a
> pointing arrow.
> Maybe some people also mind find this useful.
> 
> The following code was working on my system (Win7, gnuplot 5.2) and
> should be ready for copy&paste&plot. Be aware that the mail program
> might have "messed up" the line breaks.
> 
> ###### start gnuplot code
> reset
> $Data <<EOD
> XXX Header1 Header2
> one 10 50
> two 3 2
> three 30 15
> four 40 5
> five 0.5 0.5
> six 0.6 0.6
> seven 1 17
> EOD
> 
> set style data histogram
> set style histogram columnstacked
> set style fill solid border -1
> set boxwidth 0.6
> 
> YminSpace = 4
> YStep = 2
> YExtraDistance = -YStep
> XShift(n) = (n < YminSpace) ? 0.45 : 0
> YShift(n) = (n < YminSpace) ?
> (YExtraDistance=YExtraDistance+YStep,YExtraDistance) :
> (YExtraDistance=-YStep,0)
> 
> plot \
>   $Data u 2 ti col , '' u 3:key(1) ti col, \
>   ysum=0 '' skip 1 using (0+XShift($2)):((ysum = ysum + $2,
> ysum-$2/2+YShift($2))):2 with labels notitle, \
>   ysum=0 '' skip 1 using (1+XShift($3)):((ysum = ysum + $3,
> ysum-$3/2+YShift($3))):3 with labels notitle,\
>   ysum=0 '' skip 1 using ($2>YminSpace ? 1/0:(0+XShift($2)-0.05)):((ysum
> = ysum + $2, ysum-$2/2+YShift($2))):(-0.1):(-YExtraDistance) ls -1 with
> vectors not,\
>   ysum=0 '' skip 1 using ($3>YminSpace ? 1/0:(1+XShift($3)-0.05)):((ysum
> = ysum + $3, ysum-$3/2+YShift($3))):(-0.1):(-YExtraDistance) ls -1 with
> vectors not,\
> 
> ###### end gnuplot code