You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(2) 
_{Dec}


2004 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(2) 
_{Apr}
(22) 
_{May}
(52) 
_{Jun}
(43) 
_{Jul}
(36) 
_{Aug}
(59) 
_{Sep}
(37) 
_{Oct}
(55) 
_{Nov}
(39) 
_{Dec}
(36) 
2005 
_{Jan}
(64) 
_{Feb}
(40) 
_{Mar}
(62) 
_{Apr}
(58) 
_{May}
(256) 
_{Jun}
(77) 
_{Jul}
(80) 
_{Aug}
(39) 
_{Sep}
(56) 
_{Oct}
(36) 
_{Nov}
(113) 
_{Dec}
(68) 
2006 
_{Jan}
(43) 
_{Feb}
(64) 
_{Mar}
(69) 
_{Apr}
(60) 
_{May}
(71) 
_{Jun}
(53) 
_{Jul}
(63) 
_{Aug}
(63) 
_{Sep}
(76) 
_{Oct}
(85) 
_{Nov}
(82) 
_{Dec}
(73) 
2007 
_{Jan}
(75) 
_{Feb}
(82) 
_{Mar}
(84) 
_{Apr}
(104) 
_{May}
(67) 
_{Jun}
(101) 
_{Jul}
(107) 
_{Aug}
(138) 
_{Sep}
(128) 
_{Oct}
(106) 
_{Nov}
(112) 
_{Dec}
(112) 
2008 
_{Jan}
(94) 
_{Feb}
(87) 
_{Mar}
(146) 
_{Apr}
(169) 
_{May}
(75) 
_{Jun}
(26) 
_{Jul}
(26) 
_{Aug}
(7) 
_{Sep}
(18) 
_{Oct}
(53) 
_{Nov}
(42) 
_{Dec}
(19) 
2009 
_{Jan}
(43) 
_{Feb}
(39) 
_{Mar}
(18) 
_{Apr}
(45) 
_{May}
(66) 
_{Jun}
(87) 
_{Jul}
(56) 
_{Aug}
(41) 
_{Sep}
(56) 
_{Oct}
(139) 
_{Nov}
(98) 
_{Dec}
(88) 
2010 
_{Jan}
(81) 
_{Feb}
(79) 
_{Mar}
(83) 
_{Apr}
(97) 
_{May}
(124) 
_{Jun}
(84) 
_{Jul}
(53) 
_{Aug}
(85) 
_{Sep}
(89) 
_{Oct}
(50) 
_{Nov}
(98) 
_{Dec}
(78) 
2011 
_{Jan}
(97) 
_{Feb}
(74) 
_{Mar}
(68) 
_{Apr}
(54) 
_{May}
(63) 
_{Jun}
(59) 
_{Jul}
(65) 
_{Aug}
(58) 
_{Sep}
(37) 
_{Oct}
(40) 
_{Nov}
(59) 
_{Dec}
(35) 
2012 
_{Jan}
(16) 
_{Feb}
(56) 
_{Mar}
(63) 
_{Apr}
(25) 
_{May}
(48) 
_{Jun}
(58) 
_{Jul}
(20) 
_{Aug}
(13) 
_{Sep}
(43) 
_{Oct}
(35) 
_{Nov}
(20) 
_{Dec}
(17) 
2013 
_{Jan}
(22) 
_{Feb}
(11) 
_{Mar}
(51) 
_{Apr}
(34) 
_{May}
(57) 
_{Jun}
(27) 
_{Jul}
(70) 
_{Aug}
(30) 
_{Sep}
(38) 
_{Oct}
(53) 
_{Nov}
(40) 
_{Dec}
(25) 
2014 
_{Jan}
(26) 
_{Feb}
(35) 
_{Mar}
(60) 
_{Apr}
(12) 
_{May}
(17) 
_{Jun}
(15) 
_{Jul}
(9) 
_{Aug}
(18) 
_{Sep}
(46) 
_{Oct}
(18) 
_{Nov}
(19) 
_{Dec}
(15) 
2015 
_{Jan}
(17) 
_{Feb}
(28) 
_{Mar}
(21) 
_{Apr}
(54) 
_{May}
(36) 
_{Jun}
(8) 
_{Jul}
(30) 
_{Aug}
(13) 
_{Sep}
(3) 
_{Oct}
(28) 
_{Nov}
(3) 
_{Dec}
(3) 
2016 
_{Jan}
(11) 
_{Feb}
(9) 
_{Mar}
(29) 
_{Apr}
(10) 
_{May}
(8) 
_{Jun}
(5) 
_{Jul}
(50) 
_{Aug}
(57) 
_{Sep}
(13) 
_{Oct}
(5) 
_{Nov}
(17) 
_{Dec}
(11) 
2017 
_{Jan}
(3) 
_{Feb}
(23) 
_{Mar}
(16) 
_{Apr}
(7) 
_{May}
(15) 
_{Jun}
(12) 
_{Jul}
(48) 
_{Aug}
(15) 
_{Sep}
(3) 
_{Oct}
(20) 
_{Nov}
(26) 
_{Dec}

From: theozh <theozh@gm...>  20171124 19:19:43

In the following simplified dataset I just want to plot the last point of each block, here: 7, 4, 1. How can I do that? Isn't there anything like: plot $Data u 0:1 every ::1::1 $Data <<EOD 9 8 7 6 5 4 3 2 1 EOD # With the following: stats $Data using 1 plot $Data index STATS_blocks1 w lp I could plot the complete last block (3,2,1), but ONLY if there were 2 empty lines between the blocks. But I need to plot the last point of each block, i.e. 7, 4, 1 
From: HansBernhard Bröker <HBBroeker@t...>  20171121 18:45:02

Am 20.11.2017 um 16:32 schrieb Daniel Hatton via gnuplotinfo: > Please can anyone confirm whether I've correctly assessed what the fit > routine is putting in those output variables? Not from those Unicode jungles I can't, sorry. Had you found and considered the documentation under "help statistical_overview"? > As an aside, I believe the following two statements to be true when > this leastsquares fitting process is done in a Bayesian framework: [...] You can rest assured that no Bayesianstyle reasoning whatsoever was used in the design or implementation of this function. This is strictly classical statistics and optimization theory, assuming normaldistributed inputs etc. 
From: Daniel Hatton <vi5u0gnuplot@ya...>  20171120 15:36:49

Dear All, I find myself using Gnuplot (5.0 patchlevel 3) in teaching leastsquares fitting in a Bayesian framework. As such, I need to know some of the details of how the various outputs from the fit command are defined. >From a mixture of reading the manual and experimenting with running various commands, I've come to the following tentative view of what's happening: Let's say that I have run set fit noerrorscaling set fit errorvariables set fit covariancevariables fit some_equation(L,M,x) 'some_data_set.dat' using ($1):($3):($2):($4) errors x,z via L,M where some_equation(L,M,x) is a theoretical formula, with adjustable parameters L and M, which is supposed to predict the quantity in the third column of the data file, when the value of the quantity in the first column of the data file is x; the second column of the data file contains the standard uncertainties in the measured values in the first column of the data file 'some_data_set.dat'; and the fourth column of the data file contains the standard uncertainties in the measured values in the third column of the data file 'some_data_set.dat'. Then I _think_ I expect to find (with apologies if my Unicode equations don't display correctly):  in the variables L and M, the values l and m of the L and M parameters respectively, which, among all the (L,M) pairs that the MarquardtLevenberg algorithm has tried, produce the lowest value of the χ statistic;  in the variable FIT_WSSR, the value Χ of the χ statistic that is achieved by setting L = l and M = m;  in the variable L_err, the value (presumably calculated in a finitedifference way) of √(2/((∂(χ)/∂L)ₗ¸ₘ((∂(χ)/(∂L∂M))ₗ¸ₘ)/(∂(χ)/∂M)ₗ¸ₘ));  in the variable M_err, the value (presumably calculated in a finitedifference way) of √(2/((∂(χ)/∂M)ₗ¸ₘ((∂(χ)/(∂L∂M))ₗ¸ₘ)/(∂(χ)/∂L)ₗ¸ₘ)); and  in the variable FIT_COV_M_L, the value (presumably calculated in a finitedifference way) of 2(∂(χ)/(∂L∂M))ₗ¸ₘ/((∂(χ)/∂L)ₗ¸ₘ(∂(χ)/∂M)ₗ¸ₘ((∂(χ)/(∂L∂M))ₗ¸ₘ)). Please can anyone confirm whether I've correctly assessed what the fit routine is putting in those output variables? As an aside, I believe the following two statements to be true when this leastsquares fitting process is done in a Bayesian framework:  As long as the prior probability density over parameter space, evaluated at the point (L,M) = (l,m), is nonzero, the leadingorder Laplace's method approximation to the standard deviation of the posterior probability distribution for L, marginalized over M, is √(2/((∂(χ)/∂L)ₗ¸ₘ((∂(χ)/(∂L∂M))ₗ¸ₘ)/(∂(χ)/∂M)ₗ¸ₘ)).  As long as the prior probability density over parameter space, evaluated at the point (L,M) = (l,m), is nonzero, the leadingorder Laplace's method approximation to the standard deviation of the posterior probability distribution for M, marginalized over L, is √(2/((∂(χ)/∂M)ₗ¸ₘ((∂(χ)/(∂L∂M))ₗ¸ₘ)/(∂(χ)/∂L)ₗ¸ₘ)). I had to (re)invent those two statements myself, by means of an enormously longwinded derivation: I haven't seen them in any published source. However, I can't believe that I'm the first to make those statements, and I have a sneaking suspicion that the person who wrote the phrase "asymptotic standard error", both in the Gnuplot manual and in the comments of file <src/fit.c>, in the Gnuplot source code tree, _has_ seen those two statements or something very like them in a published source. If that person is on this mailing list, it'd be great if s/he could provide a reference, please. Thanks very much.  Kind regards, Dan 
From: David Kastrup <dak@gn...>  20171115 11:34:14

Ethan Merritt <eamerritt@...> writes: > [now I'm nitpicking...] > > Lua doesn't have integer variables, so there the question is moot. That nit, by the way, is dead. dak@...:/usr/local/tmp/lilypond$ lua5.3 Lua 5.3.3 Copyright (C) 19942016 Lua.org, PUCRio > =math.type(4.0) float > =math.type(4) integer >  David Kastrup 
From: Ethan A Merritt <EAMerritt@gm...>  20171115 02:45:34

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 floatingpoint but > > > full rationalnumber support or arbitrary (even infinite) > > > precision calculations, to avoid frustrating behaviors like > > > ceil(900e7/12e7) => 76. > > > > There you intrigue me. I have a patch series queued that adds 64bit > > 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 x8664 platform) I tried a few larger exponents at random, up to ceil(900e101/12e101), 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 builtin double support. Gnuplot has used (double) everywhere since 2011, when we dropped support for 16bit 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 
From: Tait <gnuplotinfo@t4...>  20171115 02:32:19

> > > > ceil(900e7/12e7) => 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 x8664 platform) > > I tried a few larger exponents at random, up to > ceil(900e101/12e101), 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 = 900e7; double num2 = 12e7; 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. 
From: David Kastrup <dak@gn...>  20171115 01:48:13

Tait <gnuplotinfo@...> writes: >> > I'd say integer division is gradually becoming an anachronism, >> > and the new trend seems to be not just fixed floatingpoint but >> > full rationalnumber support or arbitrary (even infinite) >> > precision calculations, to avoid frustrating behaviors like >> > ceil(900e7/12e7) => 76. >> >> There you intrigue me. I have a patch series queued that adds 64bit >> 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 builtin 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 builtin double support would be really peculiar once using them for C became a mainstream choice.  David Kastrup 
From: Tait <gnuplotinfo@t4...>  20171115 01:42:55

> > I'd say integer division is gradually becoming an anachronism, > > and the new trend seems to be not just fixed floatingpoint but > > full rationalnumber support or arbitrary (even infinite) > > precision calculations, to avoid frustrating behaviors like > > ceil(900e7/12e7) => 76. > > There you intrigue me. I have a patch series queued that adds 64bit > 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 builtin double support. I don't work on esoteric platforms anymore, and obviously Win/Linux/Mac all handle double fine. 
From: Ethan Merritt <eamerritt@gm...>  20171115 01:03:29

On Tue, Nov 14, 2017 at 4:38 PM, Tait <gnuplotinfo@...> wrote: > > It's worth mentioning that Python has changed this behavior. In > Python2, division defaults to integerdivision 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 autopromoted 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 floatingpoint but > full rationalnumber support or arbitrary (even infinite) > precision calculations, to avoid frustrating behaviors like > ceil(900e7/12e7) => 76. > There you intrigue me. I have a patch series queued that adds 64bit 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 
From: Tait <gnuplotinfo@t4...>  20171115 00:37:07

> >> 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 integerdivision 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 autopromoted 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 floatingpoint but full rationalnumber support or arbitrary (even infinite) precision calculations, to avoid frustrating behaviors like ceil(900e7/12e7) => 76. 
From: David Kastrup <dak@gn...>  20171115 00:06:20

Ethan Merritt <eamerritt@...> writes: > On Tue, Nov 14, 2017 at 3:13 PM, David Kastrup <dak@...> wrote: > >> Ethan Merritt <eamerritt@...> writes: >> >> > On Tue, Nov 14, 2017 at 1:39 PM, theozh <theozh@...> 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 > uservisible 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 nitpicking...] > > 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 
From: Ethan Merritt <eamerritt@gm...>  20171114 23:43:00

On Tue, Nov 14, 2017 at 3:13 PM, David Kastrup <dak@...> wrote: > Ethan Merritt <eamerritt@...> writes: > > > On Tue, Nov 14, 2017 at 1:39 PM, theozh <theozh@...> 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 uservisible evaluations. [now I'm nitpicking...] 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 > _______________________________________________ > gnuplotinfo mailing list > gnuplotinfo@... > Membership management via: https://lists.sourceforge.net/ > lists/listinfo/gnuplotinfo > 
From: David Kastrup <dak@gn...>  20171114 23:15:34

Ethan Merritt <eamerritt@...> 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 
From: David Kastrup <dak@gn...>  20171114 23:13:43

Ethan Merritt <eamerritt@...> writes: > On Tue, Nov 14, 2017 at 1:39 PM, theozh <theozh@...> 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 
From: Ethan Merritt <eamerritt@gm...>  20171114 23:07:35

On Tue, Nov 14, 2017 at 2:19 PM, theozh <theozh@...> 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 misremembering > 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. 
From: theozh <theozh@gm...>  20171114 22:20:01

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 ;). 
From: Ethan Merritt <eamerritt@gm...>  20171114 21:56:04

On Tue, Nov 14, 2017 at 1:39 PM, theozh <theozh@...> 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 
From: theozh <theozh@gm...>  20171114 21:39:40

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? 
From: Martin Pola <martin@po...>  20171113 08:55:33

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 allinone copy&paste code. 
From: theozh <theozh@gm...>  20171110 19:54:46

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 allinone copy&paste code. 
From: Martin Pola <martin@po...>  20171110 15:24:13

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 20170901 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_blocks1] 'data.dat' index i using (XValue[i+1]=$1,1):1 > every 1:1:0:0:0:0 notitle plot for [i=0:STATS_blocks1] 'data.dat' index i > using (XValue[i+1]):1 title columnheader(i + 1) 
From: Aleksey Tsalolikhin <atsaloli.tech@gm...>  20171110 01:59:04

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 b212,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 oneliner: cat /var/cfengine/httpd/logs/access_log*  awk '/GET \/api\/user\// {print $4, $7}' cut b212,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 
From: theozh <theozh@gm...>  20171103 22:22:40

hi again, it should work without changing your data with these lines: array XValue[3] plot for [i=0:STATS_blocks1] 'data.dat' index i using (XValue[i+1]=$1,1):1 every 1:1:0:0:0:0 notitle plot for [i=0:STATS_blocks1] 'data.dat' index i using (XValue[i+1]):1 title columnheader(i + 1) 
From: theozh <theozh@gm...>  20171103 00:51:37

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::(i1)::(i1) w p ls 1 not plot for [i=1:3] 'data.dat' u (XValue[i]):1 every 1:1:1:(i1)::(i1) 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. 
From: theozh <theozh@gm...>  20171103 00:30:26

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 