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}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





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

12
(4) 
13
(9) 
14
(8) 
15
(5) 
16
(2) 
17
(1) 
18
(2) 
19
(1) 
20

21
(2) 
22
(2) 
23
(2) 
24
(1) 
25

26
(4) 
27
(1) 
28
(4) 
29
(5) 
30
(7) 
31
(7) 
From: Daniel J Sebald <daniel.sebald@ie...>  20070331 22:44:52

HansBernhard Bröker wrote: > Daniel J Sebald wrote: > >> HansBernhard Bröker wrote: >> >>> Daniel J Sebald wrote: > > >>>> In some way it also removes the question that Hans raised in the >>>> code. I'm sure you can't recall that far back, Hans, but a question >>>> I have is just exactly was this approach supposed to achieve? > > >>> Basically, it's that pow() isn't required to treat integer exponents >>> specially, so it can easily destroy more precision than dbl_raise() >>> in its existing form does. > > >> Right. But the premise, I guess, is that for the application in >> question we're interested in raising an integer to an integer power, >> which results in an integer. > > > No. We're interested in raising a double to an integer power, which > results in a double. For simple cases, the input and output doubles > will have integer values, but they're not integers by design. This equation double power = dbl_raise(10.0, floor(log10(arg))); from a purely mathematical standpoint, is raising an integer, 10, to an integer, floor(), power. Generally, that's a rational number. Now, looking more closely at dbl_raise(x,y), we have int i = abs(y); An integer raised to a positive integer power is an integer. (I forgot to clarify it is a positive integer power last time, maybe that's where the confusion is.) We are free to round the value and remove any finite math effects. > If we > only had to worry about cases where the power is small enough for the > result to be integer, a table of all 10 powersoften from 10^0 to 10^9 > would suffice. But that's not the case. [snip] > As good as it can be. It's still likely to be better than that of the > typical naive implementation of pow(x,y): If the ultimate result can't be represented with a binary float, that's a different matter. But I'm saying that isn't unique to pow() because neither can 10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10 be contained in binary float. It reaches a point along the way in the multiplication loop that the ability to represent the large integer is gone and each multiplication results in poorer and poorer resolution relative to the increasing product. Who knows? Perhaps the pow() function has better numerical behavior and ends up being more accurate in some circumstances. > For the fun of it, be sure to make some plots of this function: > > powdiff(base,power) = (base**power / exp(power*log(base)))  1.0 > > E.g. > > set samples 301 ; plot [0:60] powdiff(10,x) > > to see just how badly wrong this can go. > >> floor(log10(arg)) Interesting plot, and that is the issue at hand. >> >> We aren't guaranteed that will come out to be exactly the exponent >> desired. > > > No, we're not. Which is why this result is used only as a guide, not as > the single piece of information, by quantize_tics. There's a reason > that there are cases of that switch outside the expected range of [2:20]. > >> Maybe the best we could hope for is some kind of internal consistency >> between log10() and pow(), by which I mean it would be nice that if >> >> E = floor(log10(arg)) >> >> then >> >> pow(10,E) <= arg < pow(10,E+1) >> >> is always true. > > > No, the best we can do is avoid having to rely on such assumptions. The > code in quantize_tics() does that. You're looking at this in one level broader scope than I am. I'm just focused on getting xnorm to be accurate given whatever the value of arg is, i.e., the correct value of the exponent E rather than possibly being off by one... which is a little subjective in itself meaning that E being one less than the mathematically correct value won't result in overly bad number of tics anyway. Dan 
From: <HBB<roeker@t...>  20070331 21:42:46

Daniel J Sebald wrote: > HansBernhard Bröker wrote: >> Daniel J Sebald wrote: >>> In some way it also removes the question that Hans raised in the >>> code. I'm sure you can't recall that far back, Hans, but a question >>> I have is just exactly was this approach supposed to achieve? >> Basically, it's that pow() isn't required to treat integer exponents >> specially, so it can easily destroy more precision than dbl_raise() in >> its existing form does. > Right. But the premise, I guess, is that for the application in > question we're interested in raising an integer to an integer power, > which results in an integer. No. We're interested in raising a double to an integer power, which results in a double. For simple cases, the input and output doubles will have integer values, but they're not integers by design. If we only had to worry about cases where the power is small enough for the result to be integer, a table of all 10 powersoften from 10^0 to 10^9 would suffice. But that's not the case. > Your statement may be true for relatively small numbers. To confirm > that for larger numbers, one would have to look at the pow() code. I > mean, the way gnuplot is programmed, what if someone enters numbers on > the order of 1e30? What's the precision of 10*10*...*10*10 as a floating > point number? As good as it can be. It's still likely to be better than that of the typical naive implementation of pow(x,y): exp(y*log(x)) For the fun of it, be sure to make some plots of this function: powdiff(base,power) = (base**power / exp(power*log(base)))  1.0 E.g. set samples 301 ; plot [0:60] powdiff(10,x) to see just how badly wrong this can go. > floor(log10(arg)) > > We aren't guaranteed that will come out to be exactly the exponent > desired. No, we're not. Which is why this result is used only as a guide, not as the single piece of information, by quantize_tics. There's a reason that there are cases of that switch outside the expected range of [2:20]. > Maybe the best we could hope for is some kind of internal consistency > between log10() and pow(), by which I mean it would be nice that if > > E = floor(log10(arg)) > > then > > pow(10,E) <= arg < pow(10,E+1) > > is always true. No, the best we can do is avoid having to rely on such assumptions. The code in quantize_tics() does that. 
From: Daniel J Sebald <daniel.sebald@ie...>  20070331 20:55:07

HansBernhard Bröker wrote: > Daniel J Sebald wrote: > > >>The issue in dbl_raise is a multiplying loop for raising a value to an integer >>power. I'm guessing the library function pow() does such a thing more >>efficiently in addition to handling the pathological NaN. > > > Maybe so, but at the same time, there's a solid probability that it is > just too inaccurate to work. > > Tics generation is extremely sensitive to rounding error, mainly in > extreme cases: very large or small arguments, arguments already slightly > distrubed by earlier rounding errors. > > A while ago we had a longstanding bug where tic generation was broken > just by turning on O2 in GCC, but only on some platforms. Suffice it > to say that this is a kind of problem I'd rather not have to face again. > > >>In some way it also removes the question that Hans raised in the code. I'm sure >>you can't recall that far back, Hans, but a question I have is just exactly was >>this approach supposed to achieve? > > > Basically, it's that pow() isn't required to treat integer exponents > specially, so it can easily destroy more precision than dbl_raise() in > its existing form does. Right. But the premise, I guess, is that for the application in question we're interested in raising an integer to an integer power, which results in an integer. So, we are free to round the pow() result to an integer and can feel fairly certain the result is the same as dbl_raise(). Your statement may be true for relatively small numbers. To confirm that for larger numbers, one would have to look at the pow() code. I mean, the way gnuplot is programmed, what if someone enters numbers on the order of 1e30? What's the precision of 10*10*...*10*10 as a floating point number? It's beyond the largest value the mantissa can hold so we know some precision is likely lost since the underlying math is binary floating point. Also, there may even be something about the existing code that is questionable, but probably the log10() function behaves nicely in this regard. This bit: floor(log10(arg)) We aren't guaranteed that will come out to be exactly the exponent desired. Say the argument is 1e15 for which we'd expect the resulting value to be 15. But, if by chance because of the way the particular log10() function is implemented in a library, it comes out to 14.9999992, the floor() would produce the incorrect result. We can't round in this case. This kind of precision issue probably works best if the number system is binary float. Then we could use frexp() and ldexp() and get the exponent directly and do highly accurates tests and checks. But I don't see any creative way of changing the problem into that realm. Maybe the best we could hope for is some kind of internal consistency between log10() and pow(), by which I mean it would be nice that if E = floor(log10(arg)) then pow(10,E) <= arg < pow(10,E+1) is always true. For what it is worth, this extra test: exponent = floor(log10(arg)); if (pow(10,exponent+1) <= arg) exponent++; does nothing to change the PostScript results. Dan 
From: Ethan A Merritt <merritt@u.washington.edu>  20070331 16:47:20

On Saturday 31 March 2007 08:09, Ethan A Merritt wrote: > On Saturday 31 March 2007 01:58, Bastian M=C3=A4rkisch wrote: > > I just noticed that gnuplot does not have it's own version of the > > famous 99 bottles of beer song (http://99bottlesofbeer.net/). > Surely gnuplot should produce plotted output! > Here's my go at it. It doesn't quite work for the last 2 conditions, > but maybe it will inspire you to new heights. I couldn't resist. Here is a working version that correctly starts at 99 and counts down to "No bottles of beer". =2D=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: Ethan A Merritt <merritt@u.washington.edu>  20070331 15:09:19

On Saturday 31 March 2007 01:58, Bastian M=C3=A4rkisch wrote: > I just noticed that gnuplot does not have it's own version of the > famous 99 bottles of beer song (http://99bottlesofbeer.net/). A shocking oversight. Why has no one reported this bug before? =20 > Here I present my version for discussion before I submit it. gnuplot> load '99bottles.gp' "99bottles.gp", line 8: undefined variable: bottles =46ix: # Create and initialize the bottles counter =2Dif (!defined(bottles)) bottles =3D max + 1 +if (!exists("bottles")) bottles =3D max + 1 > On the site it is stated that "Your example should demonstrate the > main advantages and features of the language". I would appreciate > suggestions to improve the script with respect to this. Surely gnuplot should produce plotted output! Here's my go at it. It doesn't quite work for the last 2 conditions, but maybe it will inspire you to new heights. =2D=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 
From: <HBB<roeker@t...>  20070331 11:32:15

Daniel J Sebald wrote: > The issue in dbl_raise is a multiplying loop for raising a value to an integer > power. I'm guessing the library function pow() does such a thing more > efficiently in addition to handling the pathological NaN. Maybe so, but at the same time, there's a solid probability that it is just too inaccurate to work. Tics generation is extremely sensitive to rounding error, mainly in extreme cases: very large or small arguments, arguments already slightly distrubed by earlier rounding errors. A while ago we had a longstanding bug where tic generation was broken just by turning on O2 in GCC, but only on some platforms. Suffice it to say that this is a kind of problem I'd rather not have to face again. > In some way it also removes the question that Hans raised in the code. I'm sure > you can't recall that far back, Hans, but a question I have is just exactly was > this approach supposed to achieve? Basically, it's that pow() isn't required to treat integer exponents specially, so it can easily destroy more precision than dbl_raise() in its existing form does. > One thing I wonder about is the following. Say I modify the above code to be: [...] > Wouldn't you think that this is a better formulation in terms of precision? > That is, we've a direct division in one case, and avoid a double division in > another case. But if I run this version of gnuplot on all.dem, the result is > differences other than just the times and dates. Well, you've just proved that it's not a better formulation, haven't you? 
From: <bmaerkisch@we...>  20070331 08:58:47

I just noticed that gnuplot does not have it's own version of the famous 99 bottles of beer song (http://99bottlesofbeer.net/). Here I present my version for discussion before I submit it. On the site it is stated that "Your example should demonstrate the main advantages and features of the language". I would appreciate suggestions to improve the script with respect to this. Bastian 