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

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}
(83) 
_{Nov}
(57) 
_{Dec}
(111) 
2004 
_{Jan}
(38) 
_{Feb}
(121) 
_{Mar}
(107) 
_{Apr}
(241) 
_{May}
(102) 
_{Jun}
(190) 
_{Jul}
(239) 
_{Aug}
(158) 
_{Sep}
(184) 
_{Oct}
(193) 
_{Nov}
(47) 
_{Dec}
(68) 
2005 
_{Jan}
(190) 
_{Feb}
(105) 
_{Mar}
(99) 
_{Apr}
(65) 
_{May}
(92) 
_{Jun}
(250) 
_{Jul}
(197) 
_{Aug}
(128) 
_{Sep}
(101) 
_{Oct}
(183) 
_{Nov}
(186) 
_{Dec}
(42) 
2006 
_{Jan}
(102) 
_{Feb}
(122) 
_{Mar}
(154) 
_{Apr}
(196) 
_{May}
(181) 
_{Jun}
(281) 
_{Jul}
(310) 
_{Aug}
(198) 
_{Sep}
(145) 
_{Oct}
(188) 
_{Nov}
(134) 
_{Dec}
(90) 
2007 
_{Jan}
(134) 
_{Feb}
(181) 
_{Mar}
(157) 
_{Apr}
(57) 
_{May}
(81) 
_{Jun}
(204) 
_{Jul}
(60) 
_{Aug}
(37) 
_{Sep}
(17) 
_{Oct}
(90) 
_{Nov}
(122) 
_{Dec}
(72) 
2008 
_{Jan}
(130) 
_{Feb}
(108) 
_{Mar}
(160) 
_{Apr}
(38) 
_{May}
(83) 
_{Jun}
(42) 
_{Jul}
(75) 
_{Aug}
(16) 
_{Sep}
(71) 
_{Oct}
(57) 
_{Nov}
(59) 
_{Dec}
(152) 
2009 
_{Jan}
(73) 
_{Feb}
(213) 
_{Mar}
(67) 
_{Apr}
(40) 
_{May}
(46) 
_{Jun}
(82) 
_{Jul}
(73) 
_{Aug}
(57) 
_{Sep}
(108) 
_{Oct}
(36) 
_{Nov}
(153) 
_{Dec}
(77) 
2010 
_{Jan}
(42) 
_{Feb}
(171) 
_{Mar}
(150) 
_{Apr}
(6) 
_{May}
(22) 
_{Jun}
(34) 
_{Jul}
(31) 
_{Aug}
(38) 
_{Sep}
(32) 
_{Oct}
(59) 
_{Nov}
(13) 
_{Dec}
(62) 
2011 
_{Jan}
(114) 
_{Feb}
(139) 
_{Mar}
(126) 
_{Apr}
(51) 
_{May}
(53) 
_{Jun}
(29) 
_{Jul}
(41) 
_{Aug}
(29) 
_{Sep}
(35) 
_{Oct}
(87) 
_{Nov}
(42) 
_{Dec}
(20) 
2012 
_{Jan}
(111) 
_{Feb}
(66) 
_{Mar}
(35) 
_{Apr}
(59) 
_{May}
(71) 
_{Jun}
(32) 
_{Jul}
(11) 
_{Aug}
(48) 
_{Sep}
(60) 
_{Oct}
(87) 
_{Nov}
(16) 
_{Dec}
(38) 
2013 
_{Jan}
(5) 
_{Feb}
(19) 
_{Mar}
(41) 
_{Apr}
(47) 
_{May}
(14) 
_{Jun}
(32) 
_{Jul}
(18) 
_{Aug}
(68) 
_{Sep}
(9) 
_{Oct}
(42) 
_{Nov}
(12) 
_{Dec}
(10) 
2014 
_{Jan}
(14) 
_{Feb}
(139) 
_{Mar}
(137) 
_{Apr}
(66) 
_{May}
(72) 
_{Jun}
(142) 
_{Jul}
(70) 
_{Aug}
(31) 
_{Sep}
(39) 
_{Oct}
(98) 
_{Nov}
(133) 
_{Dec}
(44) 
2015 
_{Jan}
(70) 
_{Feb}
(27) 
_{Mar}
(36) 
_{Apr}
(11) 
_{May}
(15) 
_{Jun}
(70) 
_{Jul}
(30) 
_{Aug}
(63) 
_{Sep}
(18) 
_{Oct}
(15) 
_{Nov}
(42) 
_{Dec}
(29) 
2016 
_{Jan}
(37) 
_{Feb}
(48) 
_{Mar}
(59) 
_{Apr}
(28) 
_{May}
(30) 
_{Jun}
(43) 
_{Jul}
(47) 
_{Aug}
(14) 
_{Sep}
(21) 
_{Oct}
(26) 
_{Nov}
(10) 
_{Dec}
(2) 
2017 
_{Jan}
(14) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(5) 
2
(1) 
3
(2) 
4
(1) 
5
(3) 
6
(2) 
7
(3) 
8
(2) 
9
(1) 
10

11

12
(1) 
13

14
(1) 
15
(2) 
16
(5) 
17
(11) 
18

19

20
(1) 
21
(1) 
22
(6) 
23
(15) 
24
(8) 
25
(3) 
26
(2) 
27
(9) 
28
(4) 
29
(12) 
30


From: <dsebald@ch...>  20050923 21:24:28

> > From: Juergen Wieferink <wieferink@...> > Date: 2005/09/23 Fri PM 03:02:15 EDT > To: gnuplotbeta@... > Subject: Re: gnuplot cvs source bug > > On Friday 23 September 2005 20:34 Ethan Merritt wrote: > > I happen to disagree. Integer arithmetic is quite useful in many > > contexts, and it is a standard part of programming languages and > > natural languages. Adding peculiar arithmetic operators to indicate > > that a number is an integer strikes me as being an obfuscation, not > > a clarification. Sure, sometimes even an experienced user will > > forget, and mistype (n/2) where it should have been (n/2.0). > > But also people type "if (a = b)" where it should have been > > "if (a == b)" or "if (a eq b)". Hiding this useful distinction > > in a choice of operators is not likely to reduce the number of > > mistakes. > > I would agree if variables in gnuplot had explicit types. But the > type is part of the value. In a script it can be hard or even > impossible to say if an expression "a/b" is integer or floating > point division. So an additional operator would make the code more > readable. > > I just wanted to make my point clear. I'm aware that this is > unlikly to be included. Nothing Ethan said seems to rule out the "treat all numbers as floats"/"treat nondecimal point numbers as ints" variable that someone else suggested. It is something that could be put in the gnuplot startup file for those who want gnuplot always to treat numbers as floats even immediately after launch. But yeah, int(...) of this and float(...) of that scatter about the scripts is nasty and unnecessary. Dan 
From: Juergen Wieferink <wieferink@fr...>  20050923 19:04:29

On Friday 23 September 2005 20:34 Ethan Merritt wrote: > I happen to disagree. Integer arithmetic is quite useful in many > contexts, and it is a standard part of programming languages and > natural languages. Adding peculiar arithmetic operators to indicate > that a number is an integer strikes me as being an obfuscation, not > a clarification. Sure, sometimes even an experienced user will > forget, and mistype (n/2) where it should have been (n/2.0). > But also people type "if (a = b)" where it should have been > "if (a == b)" or "if (a eq b)". Hiding this useful distinction > in a choice of operators is not likely to reduce the number of > mistakes. I would agree if variables in gnuplot had explicit types. But the type is part of the value. In a script it can be hard or even impossible to say if an expression "a/b" is integer or floating point division. So an additional operator would make the code more readable. I just wanted to make my point clear. I'm aware that this is unlikly to be included. Juergen 
From: Ethan Merritt <merritt@u.washington.edu>  20050923 18:34:46

On Friday 23 September 2005 07:19 am, Robert Hart wrote: > > Yes, but we are talking about a situation where floats *do* apply. > Surely it is more logical to treat numbers as floats *unless* they are > used in a context where only integers apply. For any ambiguous case > (division and exponentiation), anybody who wants the integer math > *knows* they want it and can use int() I happen to disagree. Integer arithmetic is quite useful in many contexts, and it is a standard part of programming languages and natural languages. Adding peculiar arithmetic operators to indicate that a number is an integer strikes me as being an obfuscation, not a clarification. Sure, sometimes even an experienced user will forget, and mistype (n/2) where it should have been (n/2.0). But also people type "if (a = b)" where it should have been "if (a == b)" or "if (a eq b)". Hiding this useful distinction in a choice of operators is not likely to reduce the number of mistakes.  Ethan A Merritt merritt@... Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 
From: Juergen Wieferink <wieferink@fr...>  20050923 16:31:29

On Friday 23 September 2005 17:38 Aapo Lankinen wrote: > Gnuplot could even warn every time you try to use integers in > interactive interpreted mode: >  > gnuplot> print 1/2 > Warning: Numeric input interpreted as integers. Consider using "set > numbermode floating" or "set numbermode integer". >  > And of course, scripts would just silently do what they are directed to > do even if "numbermode interpreted" would be used. Hmm. I'd vote for the introduction of some explicit integer division operator like "//" (as in python). So at the end it would be gnuplot> print 1/2 0.5 gnuplot> print 1//2 0 I'm aware of the compatibility issues. The use of "/" as integer division would have to be depricated for at least one release [=> about five years ;)]. It should lead to some warning message as you suggested. Juergen 
From: <dsebald@ch...>  20050923 16:18:08

> Gnuplot could even warn every time you try to use integers in > interactive interpreted mode: >  > gnuplot> print 1/2 > Warning: Numeric input interpreted as integers. Consider using "set > numbermode floating" or "set numbermode integer". But only the first time integer math is used. Otherwise it would be too, um, annoying. Dan 
From: Aapo Lankinen <aapo.lankinen@gm...>  20050923 15:39:11

On Fri, 20050923 at 16:33 +0200, Petr Mikulik wrote: > > gnuplot> print 1/(5**1) > > 0 > > gnuplot> print (5**1) > > 0.2 > > Whether we like it or not, changing it now would break scripts, so we have > to accept this behaviour. (Well, it is a FAQ for a long long time.) Could it be like gnuplot> set numbermode floating or gnuplot> set numbermode integer or gnuplot> set numbermode interpreted where the default would be "interpreted", which would have the current behaviour. That way the old scripts wouldn't be broken, and the new users could be directed to always use numbermode floating. Gnuplot could even warn every time you try to use integers in interactive interpreted mode:  gnuplot> print 1/2 Warning: Numeric input interpreted as integers. Consider using "set numbermode floating" or "set numbermode integer".  And of course, scripts would just silently do what they are directed to do even if "numbermode interpreted" would be used. Aapo Lankinen 
From: Robert Hart <enxrah@no...>  20050923 14:59:35

On Fri, 20050923 at 16:33 +0200, Petr Mikulik wrote: > > Other counterintuitive behaviour: > > > > gnuplot> print 1/(5**1) > > 0 > > gnuplot> print (5**1) > > 0.2 > > Whether we like it or not, changing it now would break scripts, so we have > to accept this behaviour. (Well, it is a FAQ for a long long time.) No, we just have to bear in mind that there would be a cost to changing it and weigh that up against the cost of not changing it. In fact in this case, it wouldn't surprise me if we ended up fixing currently broken scripts.  Robert Hart <enxrah@...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 
From: Petr Mikulik <mikulik@ph...>  20050923 14:34:16

> Other counterintuitive behaviour: > > gnuplot> print 1/(5**1) > 0 > gnuplot> print (5**1) > 0.2 Whether we like it or not, changing it now would break scripts, so we have to accept this behaviour. (Well, it is a FAQ for a long long time.)  PM 
From: Robert Hart <enxrah@no...>  20050923 14:20:16

On Fri, 20050923 at 15:48 +0200, HansBernhard Broeker wrote: > Yes, and I will until the day the first DIWM (for "dowhatImean") > interfaced computer becomes available  it's been elusive for so long > that I seriously doubt it will ever happen, though. Until then we have the "principle of least surprise"  in other words a computer can be made to "DWIM" as much of the time as possible by doing what you would expect most likely it to do. Thus in the context of a scientific plotting package that primarily plots continuous functions and arbitrary discrete data, the mathematical (and human) definition of division would be expected. > > Can you actually think of a reallife case where integer maths is the > > "correct" way of doing a calculation *and* explicitly using the int() > > function would not be appropriate? > > Yes. It's quite obvious, too: integer maths has applications where > floats simply don't apply. gnuplot has binary operators like '%', '', > '&' and '^' which are applicable only to integers. Yes, but we are talking about a situation where floats *do* apply. Surely it is more logical to treat numbers as floats *unless* they are used in a context where only integers apply. For any ambiguous case (division and exponentiation), anybody who wants the integer math *knows* they want it and can use int() Other counterintuitive behaviour: gnuplot> print 1/(5**1) 0 gnuplot> print (5**1) 0.2 gnuplot> x=1000000000000000000 gnuplot> print x 2147483647 gnuplot> x=1000000000000000000.0 gnuplot> print x 1e+18 gnuplot> x=1*10**18 gnuplot> print x 1486618624  Robert Hart <enxrah@...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 
From: Robert Hart <enxrah@no...>  20050923 13:12:51

On Fri, 20050923 at 14:57 +0200, HansBernhard Broeker wrote: > Well, you don't have a computer with a mindreading interface, do you? > So how do you expect it to be able to know what you *think*, > particularly in a case like this where what you think openly disagrees > with what you actually told it via keyboard? Do you actually believe that? Even if you are a C programmer, and you understand why there is a distinction between 2/3 and 2.0/3.0 this must still catch you out time and time again? Thankfully in this case the symptoms are strong enough that the error is easily noticed, and therefor fixed, but it's also easy to get caught out in more subtle ways too. i.e. with larger integers. It's even worse that although we use the C convention of integer division but also have implicitly typed variables, something like this is wrong too: f(x) = 1/a*x a = 5 plot f(x) a = 5.0 plot f(x) Can you actually think of a reallife case where integer maths is the "correct" way of doing a calculation *and* explicitly using the int() function would not be appropriate?  Robert Hart <enxrah@...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 
From: HansBernhard Broeker <broeker@ph...>  20050923 12:55:29

Pentek Imre Geza wrote: > this is not a feature, its a very annoying malfunction. Following this same style of argument, what you wrote is not a bug report, but an very annoying complaint. > when I write 2/3 I'm not thinking about computerexecuted > mathematical computations, but thinking about mathematical operation. Well, you don't have a computer with a mindreading interface, do you? So how do you expect it to be able to know what you *think*, particularly in a case like this where what you think openly disagrees with what you actually told it via keyboard? 
From: Pentek Imre Geza <pentek_i@in...>  20050923 11:18:37

On Fri, 23 Sep 2005 11:53:24 +0200, HansBernhard Broeker wrote > Péntek Imre wrote: > > Hello, > > > > I use gnuplot compiled by me from cvs source, I found this bug: > > Terminal type set to 'x11' > > gnuplot> plot exp(2/3*x); > > Warning: empty y range [1:1], adjusting to [0.99:1.01] > > That's not a bug. That's just integer arithmetic. Try the > following two commands in a gnuplot prompt, and you'll see it: > > print 2/3 > print 2.0/3 > > And before you ask: yes, this documented behaviour. See "help expressions". this is not a feature, its a very annoying malfunction. when I write 2/3 I'm not thinking about computerexecuted mathematical computations, but thinking about mathematical operation. the two of the above ones should be equivalent.  Üdvözlettel: Ifj. Péntek Imre EMail: pentek_i@... 
From: Pentek Imre Geza <pentek_i@in...>  20050923 11:16:17

On Fri, 23 Sep 2005 10:14:10 +0100, Robert Hart wrote > plot exp(2.0/3.0*x) ? not yet, thanks I will try that. > I really don't see why a scientific plotting program is doing integer > math. urgh. When I write 2/3*x I don't thinking about computerexecuted math, but instead I think about mathematical operation, and should work anyways.  Üdvözlettel: Ifj. Péntek Imre EMail: pentek_i@... 
From: HansBernhard Broeker <broeker@ph...>  20050923 09:50:55

P=E9ntek Imre wrote: > Hello, >=20 > I use gnuplot compiled by me from cvs source, I found this bug: > Terminal type set to 'x11' > gnuplot> plot exp(2/3*x); > Warning: empty y range [1:1], adjusting to [0.99:1.01] That's not a bug. That's just integer arithmetic. Try the following=20 two commands in a gnuplot prompt, and you'll see it: print 2/3 print 2.0/3 And before you ask: yes, this documented behaviour. See "help expression= s". 
From: Robert Hart <enxrah@no...>  20050923 09:14:34

On Thu, 20050922 at 20:04 +0200, P=E9ntek Imre wrote: > Hello, >=20 > I use gnuplot compiled by me from cvs source, I found this bug: > Terminal type set to 'x11' > gnuplot> plot exp(2/3*x); > Warning: empty y range [1:1], adjusting to [0.99:1.01] > gnuplot> plot [3:3] exp(2/3*x); > Warning: empty y range [1:1], adjusting to [0.99:1.01] > gnuplot> plot [3:3][0:3] exp(2/3*x); > gnuplot> > And in this version (cvs2005091) exp(2/3*x) is interpreted as a constant = 1=20 > function, however it should be exp(x):=3De**x:=3Dsum n=3D0 to +infinity (= x**n)/(n!) Have you tried=20 plot exp(2.0/3.0*x) ? I really don't see why a scientific plotting program is doing integer math. urgh. Rob =20 Robert Hart <enxrah@...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 