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}
(9) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2
(2) 
3

4

5

6

7
(1) 
8
(8) 
9
(15) 
10
(5) 
11
(4) 
12
(2) 
13
(1) 
14
(3) 
15
(5) 
16

17
(5) 
18

19

20

21
(2) 
22

23

24

25

26
(3) 
27

28
(1) 
29

30






From: Petr Mikulik <mikulik@ph...>  20070408 20:40:06

Thread: http://www.cae.wisc.edu/pipermail/helpoctave/2007April/003542.html >Wed Apr 4 09:33:03 CDT 2007 > until version 2.9.9, it was possible to enable zoom with the > "set mouse" command (e.g. in ~/.gnuplot). After changing to > version 2.9.10, this does not function anymore. > >It still works for me with gnuplot 4.0. > >With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots >does not work for me when gnuplot is called from Octave. It does work >when I run gnuplot directly. I don't know what the proper fix is. In >any case, the changes you make with the mouse will still not be >reflected in the axes settings seen by Octave as the communication >with gnuplot is still a simple one way pipe. I had a look what octave 2.9.10 is doing by: octave> gnuplot_binary('tee a.log  gnuplot'); and there appears: plot "" using ($1):($2) title "" with lines linestyle 1; 20 20 19 19 18 18 Therefrom, octave does no longer use temporary data files but switched to inline data. That's a nice improvement. Unfortunately, gnuplot ignores "replot" for plots with "", and consequently mousing+hotkeys do not work. Thus, it looks like a strong demand to gnuplot developers to implement replot for "". This matter was discussed recently, see below... Note: 3D plots, e.g. octave> mesh(hilb(9)) which produces splot "" using ($1):($2):($3) title "" with line palette; 1 1 1 1 2 2 can be rotated by mouse, because gnuplot reuses the loaded 3D data in this case (no reload  fast rotation); but hotkeys relying on replot do not work again. Does somebody know how to implement it?  PM ********* Thu, 15 Mar 2007, gnuplotbeta <gnuplotbeta@...> > > Furthermore, it would be possible to do a more efficient job > > of "replot" in the core code that would benefit all terminals. > > Perhaps I am overlooking something, but I don't see any hard > > requirement to reread the original data from a file on each > > replot command. Yes, this is sometimes exactly what you want > > because you know the data has changed. But more often you > > just want to redraw the plot with a different plot option, > > or zoom or view angle. In these cases there should be enough, > > or almost enough, information already stored in the data structures > > from the previous plot. Why reread the data file when it is > > just storing the same information all over again? This would in > > particular be of plot '', where it is very annoying to type in > > the same data all over again. > > Mousing in 3D  rotating by mouse  does not reread the data, but > uses those in the memory. It would be useful for those "" to do the > same. > > Thus there could be two replots, e.g. replot and Replot, where the > second would not reread the data from disk. 
From: Petr Mikulik <mikulik@ph...>  20070408 20:40:06

Thread: http://www.cae.wisc.edu/pipermail/helpoctave/2007April/003542.html >Wed Apr 4 09:33:03 CDT 2007 > until version 2.9.9, it was possible to enable zoom with the > "set mouse" command (e.g. in ~/.gnuplot). After changing to > version 2.9.10, this does not function anymore. > >It still works for me with gnuplot 4.0. > >With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots >does not work for me when gnuplot is called from Octave. It does work >when I run gnuplot directly. I don't know what the proper fix is. In >any case, the changes you make with the mouse will still not be >reflected in the axes settings seen by Octave as the communication >with gnuplot is still a simple one way pipe. I had a look what octave 2.9.10 is doing by: octave> gnuplot_binary('tee a.log  gnuplot'); and there appears: plot "" using ($1):($2) title "" with lines linestyle 1; 20 20 19 19 18 18 Therefrom, octave does no longer use temporary data files but switched to inline data. That's a nice improvement. Unfortunately, gnuplot ignores "replot" for plots with "", and consequently mousing+hotkeys do not work. Thus, it looks like a strong demand to gnuplot developers to implement replot for "". This matter was discussed recently, see below... Note: 3D plots, e.g. octave> mesh(hilb(9)) which produces splot "" using ($1):($2):($3) title "" with line palette; 1 1 1 1 2 2 can be rotated by mouse, because gnuplot reuses the loaded 3D data in this case (no reload  fast rotation); but hotkeys relying on replot do not work again. Does somebody know how to implement it?  PM ********* Thu, 15 Mar 2007, gnuplotbeta <gnuplotbeta@...> > > Furthermore, it would be possible to do a more efficient job > > of "replot" in the core code that would benefit all terminals. > > Perhaps I am overlooking something, but I don't see any hard > > requirement to reread the original data from a file on each > > replot command. Yes, this is sometimes exactly what you want > > because you know the data has changed. But more often you > > just want to redraw the plot with a different plot option, > > or zoom or view angle. In these cases there should be enough, > > or almost enough, information already stored in the data structures > > from the previous plot. Why reread the data file when it is > > just storing the same information all over again? This would in > > particular be of plot '', where it is very annoying to type in > > the same data all over again. > > Mousing in 3D  rotating by mouse  does not reread the data, but > uses those in the memory. It would be useful for those "" to do the > same. > > Thus there could be two replots, e.g. replot and Replot, where the > second would not reread the data from disk. ` 
From: Ethan A Merritt <merritt@u.washington.edu>  20070408 16:50:38

On Sunday 08 April 2007 01:52, Daniel J Sebald wrote: > Daniel J Sebald wrote: > > > gnuplot> print > > 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 > >  1e25 > > 2147483648.0 > > And this seems to be accurate: > > gnuplot> print > 1e25/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 >  1.0 > 0.0 > > Ummmm, so why is the division accurate while the multiplication above appears > not to be? That is exactly what you should expect. Sequential division reduces the inaccuracy of the original number by a factor of 10 at each step. Simple subtraction exposes the size of the original discrepancy. Note that 2147483648.0, although a large number in absolute terms, corresponds to an error in the 15th decimal place of the decimal representation of 10^25. More to the point, that corresponds to about 50 bits of precision. Since doubleprecision IEEE format only provides 52 bits of precision in the mantissa, this is within one bit of the expected rounding error. (And that one bit may be my mistake; I'm doing this on my fingers, as it were). Note also that if you care about this level of precision then you also must pay attention to the IEEE rounding mode. > Is there something going on with the translation from exponential > notation and the machine IEEE float representation somewhere around 10^25? Yes. That's where you hit the limit of the IEEE representation. To do better than that you'd have to switch to some other floating point representation. There are infiniteprecision math libraries available, but gnuplot isn't using one.  Ethan A Merritt 
From: Petr Mikulik <mikulik@mo...>  20070408 11:23:43

I went through the octavehelp archive and a message (see its copy at the bottom) says that mousing (zooming, and also hotkeys) does no longer work with octave 2.9.10. I had a look what this octave version is doing by: octave> gnuplot_binary('tee a.log  gnuplot'); and there appears: plot "" using ($1):($2) title "" with lines linestyle 1; 20 20 19 19 18 18 Therefrom, octave does no longer use temporary data files but switched to inline data. That's a nice improvement. Unfortunately, gnuplot ignores "replot" for plots with "", and consequently mousing+hotkeys do not work. Thus, it looks like a strong demand to gnuplot developers to implement replot for "". This matter was discussed recently, see below... Note: 3D plots, e.g. octave> mesh(hilb(9)) which produces splot "" using ($1):($2):($3) title "" with line palette; 1 1 1 1 2 2 can be rotated by mouse, because gnuplot reuses the loaded 3D data in this case; but hotkeys do not work again. Does somebody know how to implement it? (Me not.)  PM On Thu, 15 Mar 2007, Petr Mikulik wrote: > > Furthermore, it would be possible to do a more efficient job > > of "replot" in the core code that would benefit all terminals. > > Perhaps I am overlooking something, but I don't see any hard > > requirement to reread the original data from a file on each > > replot command. Yes, this is sometimes exactly what you want > > because you know the data has changed. But more often you > > just want to redraw the plot with a different plot option, > > or zoom or view angle. In these cases there should be enough, > > or almost enough, information already stored in the data structures > > from the previous plot. Why reread the data file when it is > > just storing the same information all over again? This would in > > particular be of plot '', where it is very annoying to type in > > the same data all over again. > > Mousing in 3D  rotating by mouse  does not reread the data, but uses > those in the memory. It would be useful for those "" to do the same. > > Thus there could be two replots, e.g. replot and Replot, where the second > would not reread the data from disk. === According to: http://www.cae.wisc.edu/pipermail/helpoctave/2007April/003542.html >gnuplot zoom not functioning anymore in octave 2.9.10 >John W. Eaton jwe at bevo.che.wisc.edu >Wed Apr 4 09:33:03 CDT 2007 > until version 2.9.9, it was possible to enable zoom with the > "set mouse" command (e.g. in ~/.gnuplot). After changing to > version 2.9.10, this does not function anymore. > >It still works for me with gnuplot 4.0. > >With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots >does not work for me when gnuplot is called from Octave. It does work >when I run gnuplot directly. I don't know what the proper fix is. In >any case, the changes you make with the mouse will still not be >reflected in the axes settings seen by Octave as the communication >with gnuplot is still a simple one way pipe. > >jwe 
From: Daniel J Sebald <daniel.sebald@ie...>  20070408 08:53:01

Daniel J Sebald wrote: > gnuplot> print > 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 >  1e25 > 2147483648.0 > > Very strange. Not concrete proof, but my conjecture about not knowing which is > more accurate, outright multiplying via dbl_raise() vs. pow(), does seem a > pertinent question. And this seems to be accurate: gnuplot> print 1e25/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  1.0 0.0 Ummmm, so why is the division accurate while the multiplication above appears not to be? Is there something going on with the translation from exponential notation and the machine IEEE float representation somewhere around 10^25? Dan 
From: Daniel J Sebald <daniel.sebald@ie...>  20070408 08:06:34

Ethan A Merritt wrote: > On Saturday 07 April 2007 21:28, you wrote: > >>Ethan A Merritt wrote: >> >>>On Saturday 07 April 2007 15:58, Daniel J Sebald wrote: >>> >>> >>>>Move the patch into CVS or dump it? (Discussing things and not resolving them, >>>>even for as trivial a patch as this, isn't productive.) >>> >>> >>>Was there a real problem that this was supposed to solve? >>>If not, drop it. >> >>Recap: The patch mimics dbl_raise() behavior, but uses an existing library >>function pow() that is probably more efficient > > > I was not paying close attention, but didn't HBB show that your > proposed "more efficient" alternative function could be off by > 15 orders of magnitude in the worst case? Well, I'm not sure. This might be an apples and oranges kind of thing. Here is the script HBB suggested: powdiff(base,power) = (base**power / exp(power*log(base)))  1.0 set samples 301 ; plot [0:60] powdiff(10,x) Note that this sampling contains both "integers" and "floats". What we are ultimately interested in our use of pow(,) or dbl_raise() is raising an integer value (speaking mathwise, not computerwise) to an integer power (again, mathwise), but that is getting off course. Let's pause to look at the behavior of gnuplot on some simple examples, say 10^10: gnuplot> print 10**10 1410065408 gnuplot> print 10**10.0 10000000000.0 gnuplot> print 10.0**10 10000000000.0 gnuplot> print exp(10*log(10)) 10000000000.0 pow(base,power) = base**power gnuplot> print pow(10,10) 1410065408 gnuplot> print pow(10,10.0) 10000000000.0 OK, so we see that gnuplot treats integers (computerwise) with integer math which is much more limiting in size compared to floating point math. But this is not how the innards of the pow(), floor(), etc. functions work: #include <math.h> double floor( double arg ); The documentation of these C functions might say "largest integer not greater than arg", but that means the math vernacular, not computer vernacular. That is why I say apples and oranges. Given gnuplot's behavior, can we come up with a comparison at the command line the reflects the behavior of C routines? I've followed the parsing to internal.c and see that ** operator does in fact use the C library pow(,) function. So we've got that. The expression exp(power*log(base)) loses accuracy, but that isn't really related to the use of pow() I've applied in the range application. So let's not look at that any further. Try this: powint(base,power) = power==0 ? 1.0 : base * powint(base,power  1) powdiff(base,power) = (base**power / powint(base,power))  1.0 set samples 61 ; plot [0:60] powdiff(10,x) You may see something different than what I'm seeing, but what I see is that near x=25 there appears to be some discrepancy. So let's pick a few points there: gnuplot> print 10.0**23  powint(10.0,23) 0.0 gnuplot> print 10.0**24  powint(10.0,24) 0.0 gnuplot> print 10.0**25  powint(10.0,25) 2147483648.0 gnuplot> print 10.0**26  powint(10.0,26) 17179869184.0 gnuplot> print 10.0**27  powint(10.0,27) 137438953472.0 gnuplot> print 10.0**28  powint(10.0,28) 0.0 gnuplot> print 10.0**29  powint(10.0,29) 0.0 So, something does become flaky here. Let's see if we can figure out where exactly the discrepancy is: gnuplot> print 10.0**23  1e23 0.0 gnuplot> print 10.0**24  1e24 0.0 gnuplot> print 10.0**25  1e25 0.0 gnuplot> print 10.0**26  1e26 0.0 gnuplot> print 10.0**27  1e27 0.0 gnuplot> print 10.0**28  1e28 0.0 gnuplot> print powint(10.0,23.0)  1e23 0.0 gnuplot> print powint(10.0,24.0)  1e24 0.0 gnuplot> print powint(10.0,25.0)  1e25 2147483648.0 gnuplot> print powint(10.0,26.0)  1e26 17179869184.0 gnuplot> print powint(10.0,27.0)  1e27 137438953472.0 gnuplot> print powint(10.0,28.0)  1e28 0.0 gnuplot> Now that' odd. It would seem that the power function is correct and multiplying isn't. Let's go one step further to confirm this: gnuplot> print 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 1e+25 gnuplot> print 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0  1e25 2147483648.0 Very strange. Not concrete proof, but my conjecture about not knowing which is more accurate, outright multiplying via dbl_raise() vs. pow(), does seem a pertinent question. I was long winded, Ethan, but the answer to your question is "I don't think so." Dan 
From: Daniel J Sebald <daniel.sebald@ie...>  20070408 04:28:41

Ethan A Merritt wrote: > On Saturday 07 April 2007 15:58, Daniel J Sebald wrote: > >>Move the patch into CVS or dump it? (Discussing things and not resolving them, >>even for as trivial a patch as this, isn't productive.) > > > Was there a real problem that this was supposed to solve? > If not, drop it. Recap: The patch mimics dbl_raise() behavior, but uses an existing library function pow() that is probably more efficient than a multiplicative loop and handles the NaN value for which gnuplot appears to hang for five minutes. E.g., slightly cleaner code and handles NaN. Feel free to close the patch, but at the same time please remove /* FIXME HBB 20000426: is this really useful? */ which only invites people to investigate suggesting there is a problem. Dan 
From: Ethan A Merritt <merritt@u.washington.edu>  20070408 02:06:52

On Saturday 07 April 2007 15:58, Daniel J Sebald wrote: > Move the patch into CVS or dump it? (Discussing things and not resolving= them, > even for as trivial a patch as this, isn't productive.) Was there a real problem that this was supposed to solve? If not, drop it. Ethan >=20 > Dan >=20 >=20 > Daniel J Sebald wrote: > > HansBernhard Br=F6ker wrote: > >=20 > >>Daniel J Sebald wrote: > >> > >> > >>>HansBernhard Br=F6ker wrote: > >>> > >>> > >>>>Daniel J Sebald wrote: > >> > >> > >>>>>In some way it also removes the question that Hans raised in the=20 > >>>>>code. I'm sure you can't recall that far back, Hans, but a question= =20 > >>>>>I have is just exactly was this approach supposed to achieve? =20 > >> > >> > >>>>Basically, it's that pow() isn't required to treat integer exponents= =20 > >>>>specially, so it can easily destroy more precision than dbl_raise()=20 > >>>>in its existing form does. > >> > >> > >>>Right. But the premise, I guess, is that for the application in=20 > >>>question we're interested in raising an integer to an integer power,=20 > >>>which results in an integer. =20 > >> > >> > >>No. We're interested in raising a double to an integer power, which=20 > >>results in a double. For simple cases, the input and output doubles=20 > >>will have integer values, but they're not integers by design. > >=20 > >=20 > > This equation > >=20 > > double power =3D dbl_raise(10.0, floor(log10(arg))); > >=20 > > from a purely mathematical standpoint, is raising an integer, 10, to an= integer,=20 > > floor(), power. Generally, that's a rational number. Now, looking mor= e closely=20 > > at dbl_raise(x,y), we have > >=20 > > int i =3D abs(y); > >=20 > > An integer raised to a positive integer power is an integer. (I forgot= to=20 > > clarify it is a positive integer power last time, maybe that's where th= e=20 > > confusion is.) > >=20 > > We are free to round the value and remove any finite math effects. > >=20 > >=20 > > > 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 1= 0^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 t= he > > > typical naive implementation of pow(x,y): > >=20 > > If the ultimate result can't be represented with a binary float, that's= a=20 > > different matter. But I'm saying that isn't unique to pow() because ne= ither can > >=20 > > 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 > >=20 > > be contained in binary float. It reaches a point along the way in the= =20 > > multiplication loop that the ability to represent the large integer is = gone and=20 > > each multiplication results in poorer and poorer resolution relative to= the=20 > > increasing product. Who knows? Perhaps the pow() function has better = numerical=20 > > behavior and ends up being more accurate in some circumstances. > >=20 > >=20 > >=20 > >>For the fun of it, be sure to make some plots of this function: > >> > >> powdiff(base,power) =3D (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)) > >=20 > >=20 > > Interesting plot, and that is the issue at hand. > >=20 > >=20 > >=20 > >>>We aren't guaranteed that will come out to be exactly the exponent=20 > >>>desired. =20 > >> > >> > >>No, we're not. Which is why this result is used only as a guide, not a= s=20 > >>the single piece of information, by quantize_tics. There's a reason=20 > >>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= =20 > >>>between log10() and pow(), by which I mean it would be nice that if > >>> > >>> E =3D floor(log10(arg)) > >>> > >>>then > >>> > >>> pow(10,E) <=3D arg < pow(10,E+1) > >>> > >>>is always true. =20 > >> > >> > >>No, the best we can do is avoid having to rely on such assumptions. Th= e=20 > >> code in quantize_tics() does that. > >=20 > >=20 > > You're looking at this in one level broader scope than I am. I'm just = focused=20 > > on getting xnorm to be accurate given whatever the value of arg is, i.e= =2E, the=20 > > correct value of the exponent E rather than possibly being off by one..= =2E which=20 > > is a little subjective in itself meaning that E being one less than the= =20 > > mathematically correct value won't result in overly bad number of tics = anyway. > >=20 > > Dan > >=20 > > = =2D > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > > opinions on IT & business topics through brief surveysand earn cash > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > gnuplotbeta mailing list > > gnuplotbeta@... > > https://lists.sourceforge.net/lists/listinfo/gnuplotbeta > >=20 >=20 >=20 =2D=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 981957742 