Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation?

 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-24 14:08:41 ```Hi Hans, Let me ask, what do you think would be the correct labels? As I remember, Matlab will go out to 4 decimal points, so your ticks would be labeled 1,1.0000,1.0000. I have been meaning to do some work with the tick formatters. It has been suggested here that all significant digits are preserved, so for example, your ticks would be 1,1,1 (If you want to go out to 9 sig digits, I think you would have to write your own custom formatter, which is discussed on this list and in the user's guide). If you ticks are 1,1.01,1.02, the labels would be 1.00,1.01,1.02. I think this results in the best looking result, but I'd like to know others opinions before I start. Also, for ticks like 1e5,2e5,3e5, I am intending to make the ticks 1,2,3, and have a x10^5 just outside the axis or in the last label. Comments, suggestions? Darren On Thursday 24 February 2005 05:53 am, Hans Fangohr wrote: > Dear Matplotlib developers, > > running the following program > > import pylab > > x=pylab.arange(0,1e-8,1e-9)+1.0 > pylab.plot(x) > pylab.show() > > with matplotlib 0.70.1 results in a graph that shows: > > (i) correctly the linear increase of x > (ii) but the labels on the y-axis of the plot all show "1e", apart from > the lowest one, which shows (correctly) just "1". > > All works fine when I subtract the mean of x but there seems to be a > problem with labelling axes for plotted data which is not close to zero > but shows only small variations. > > By the way: thank you for providing matplotlib. > > Cheers, > > Hans > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Darren ```

 [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Hans Fangohr - 2005-02-24 10:53:41 ```Dear Matplotlib developers, running the following program import pylab x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() with matplotlib 0.70.1 results in a graph that shows: (i) correctly the linear increase of x (ii) but the labels on the y-axis of the plot all show "1e", apart from the lowest one, which shows (correctly) just "1". All works fine when I subtract the mean of x but there seems to be a problem with labelling axes for plotted data which is not close to zero but shows only small variations. By the way: thank you for providing matplotlib. Cheers, Hans ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-24 14:08:41 ```Hi Hans, Let me ask, what do you think would be the correct labels? As I remember, Matlab will go out to 4 decimal points, so your ticks would be labeled 1,1.0000,1.0000. I have been meaning to do some work with the tick formatters. It has been suggested here that all significant digits are preserved, so for example, your ticks would be 1,1,1 (If you want to go out to 9 sig digits, I think you would have to write your own custom formatter, which is discussed on this list and in the user's guide). If you ticks are 1,1.01,1.02, the labels would be 1.00,1.01,1.02. I think this results in the best looking result, but I'd like to know others opinions before I start. Also, for ticks like 1e5,2e5,3e5, I am intending to make the ticks 1,2,3, and have a x10^5 just outside the axis or in the last label. Comments, suggestions? Darren On Thursday 24 February 2005 05:53 am, Hans Fangohr wrote: > Dear Matplotlib developers, > > running the following program > > import pylab > > x=pylab.arange(0,1e-8,1e-9)+1.0 > pylab.plot(x) > pylab.show() > > with matplotlib 0.70.1 results in a graph that shows: > > (i) correctly the linear increase of x > (ii) but the labels on the y-axis of the plot all show "1e", apart from > the lowest one, which shows (correctly) just "1". > > All works fine when I subtract the mean of x but there seems to be a > problem with labelling axes for plotted data which is not close to zero > but shows only small variations. > > By the way: thank you for providing matplotlib. > > Cheers, > > Hans > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Darren ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: John Hunter - 2005-02-25 04:14:22 ```>>>>> "Hans" == Hans Fangohr writes: Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() Hans> All works fine when I subtract the mean of x but there seems Hans> to be a problem with labelling axes for plotted data which Hans> is not close to zero but shows only small variations. I agree it's a bug. It's not immediately clear to me what the labels should be though 1.0000000002 1.0000000004 1.0000000006 and so on? That takes up a lot of room. Granted, correct but ugly is better than incorrect but pretty, but I'm curious if there is a better way to format these cases. Perhaps ideal would be an indicator at the bottom or top of the y axis that read '1+' and then use 2e-9, 4e-9, etc as the actual tick labels. Do you agree this is ideal? To achieve this, as you may know, you can pass in a custom tick formatter. Eg import pylab def myformatter(x, pos): return '%1.0e'%(x-1) ax = pylab.subplot(111) x=pylab.arange(0,1e-8,1e-9)+1.0 ax.plot(x) formatter = pylab.FuncFormatter(myformatter) ax.yaxis.set_major_formatter(formatter) ax.text(-.125, 1.025, '1+', transform=ax.transAxes) pylab.show() See also examples/custom_ticker1.py. This is not to say that I don't want to fix this bug; I just wanted to make sure you are aware of this workaround. JDH ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Hans Fangohr - 2005-02-25 10:20:00 ```Hi John, > Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() > > Hans> All works fine when I subtract the mean of x but there seems > Hans> to be a problem with labelling axes for plotted data which > Hans> is not close to zero but shows only small variations. > > I agree it's a bug. It's not immediately clear to me what the labels > should be though > > 1.0000000002 > 1.0000000004 > 1.0000000006 > > and so on? That takes up a lot of room. Granted, correct but ugly > is better than incorrect but pretty, but I'm curious if there is a > better way to format these cases. Perhaps ideal would be an indicator > at the bottom or top of the y axis that read '1+' and then use 2e-9, > 4e-9, etc as the actual tick labels. Do you agree this is ideal? That would be very cool ;-) [but not soo easy to code I suppose]. I just checked what Matlab does (seeing that they have been in the business for a while), and if I run the equivalent program (i.e. plotting date from 1+0e-9, 1+1e-9, 1+2e-9,...,1e-8), the plot just shows "1" at each tick. So: yes, I agree with your suggested ideal solution but as long as Matlab doesn't do this and there is a workaround (as you show below), this is probably not a high-priority bug ;-) > To achieve this, as you may know, you can pass in a custom tick > formatter. Eg > > import pylab > > def myformatter(x, pos): > return '%1.0e'%(x-1) > > ax = pylab.subplot(111) > x=pylab.arange(0,1e-8,1e-9)+1.0 > ax.plot(x) > formatter = pylab.FuncFormatter(myformatter) > ax.yaxis.set_major_formatter(formatter) > ax.text(-.125, 1.025, '1+', transform=ax.transAxes) > pylab.show() > > See also examples/custom_ticker1.py. > > This is not to say that I don't want to fix this bug; I just wanted to > make sure you are aware of this workaround. That's very useful information -- I wasn't aware of this possibility and am sure it will be useful to others searching the mailing list for answers. Best wishes, Hans ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Matt Newville - 2005-02-25 16:11:58 ```> > I agree it's a bug. It's not immediately clear to me what the labels > > should be though > > > > 1.0000000002 > > 1.0000000004 > > 1.0000000006 > > > > and so on? That takes up a lot of room. Granted, correct but ugly > > is better than incorrect but pretty, but I'm curious if there is a > > better way to format these cases. Perhaps ideal would be an indicator > > at the bottom or top of the y axis that read '1+' and then use 2e-9, > > 4e-9, etc as the actual tick labels. Do you agree this is ideal? More likely, the plot should be of 1-x, not x, with 1 subtracted from the data before being sent to the plot. Would you use seconds-since-1970 to make a plot versus Time with a range of 1 sec and data every millisecond? The data plotted should be the "significant digits" after all. FWIW, a custom tick formatter I've been using is below. It's a slight variation on the default, and won't solve the space needed to display "1 + n*1.e-9", but it will do a reasonable job of picking the number of significant digits to show based on the data range for the Axis. It could be expanded.... --Matt ! def myformatter(self, x=1.0, axis=None): ! """ custom tick formatter to use with FuncFormatter(): ! x value to be formatted ! axis Axis instance to use for formatting ! """ ! fmt = '%1.5g' ! if axis == None: ! return fmt % x ! ! # attempt to get axis span (range of values to format) ! delta = 0.2 ! try: ! ticks = axis.get_major_locator()() ! delta = abs(ticks[1] - ticks[0]) ! except: ! try: ! delta = 0.1 * axis.get_view_interval().span() ! except: ! pass ! ! if delta > 99999: fmt = '%1.6e' ! elif delta > 0.99: fmt = '%1.0f' ! elif delta > 0.099: fmt = '%1.1f' ! elif delta > 0.0099: fmt = '%1.2f' ! elif delta > 0.00099: fmt = '%1.3f' ! elif delta > 0.000099: fmt = '%1.4f' ! elif delta > 0.0000099: fmt = '%1.5f' ! ! s = fmt % x ! s.strip() ! s = s.replace('+', '') ! while s.find('e0')>0: s = s.replace('e0','e') ! while s.find('-0')>0: s = s.replace('-0','-') ! ! return s ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-25 13:45:47 ```Having some email problems, my original reply wasnt sent. Hopefully this one will be... On Thursday 24 February 2005 11:02 pm, John Hunter wrote: > >>>>> "Hans" == Hans Fangohr writes: > > Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() > > Hans> All works fine when I subtract the mean of x but there seems > Hans> to be a problem with labelling axes for plotted data which > Hans> is not close to zero but shows only small variations. > > I agree it's a bug. It's not immediately clear to me what the labels > should be though > > 1.0000000002 > 1.0000000004 > 1.0000000006 > > and so on? That takes up a lot of room. Granted, correct but ugly > is better than incorrect but pretty, but I'm curious if there is a > better way to format these cases. Perhaps ideal would be an indicator > at the bottom or top of the y axis that read '1+' and then use 2e-9, > 4e-9, etc as the actual tick labels. Do you agree this is ideal? Matlab will not do an offset of this type, it goes to 4 decimal places and gives up. I have been meaning to do some work with the scalarFormatter for a while now. I think we can accomplish the above using the numerix mean,std,and maybe allclose functions. I will work on it this weekend, but will need some guidance to add a new bbox to add the result to the plot. At the same time, I'll work on an option to move the scientific notation to the same place, so 1e10,2e10 will be come 1,2, with a x10^10 at the top of the axis. It was also suggested to keep the significant decimal points in the labels. I agree with that 0,0.5,1.0,1.5 looks better than 0,0.5,1,1.5. If there are any suggestions or comments, please let me know. -- Darren ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-26 20:12:42 ```On Friday 25 February 2005 08:45 am, Darren Dale wrote: > On Thursday 24 February 2005 11:02 pm, John Hunter wrote: > > >>>>> "Hans" == Hans Fangohr writes: > > > > Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show() > > > > Hans> All works fine when I subtract the mean of x but there seems > > Hans> to be a problem with labelling axes for plotted data which > > Hans> is not close to zero but shows only small variations. > > > > I agree it's a bug. It's not immediately clear to me what the labels > > should be though > > > > 1.0000000002 > > 1.0000000004 > > 1.0000000006 > > > > and so on? That takes up a lot of room. Granted, correct but ugly > > is better than incorrect but pretty, but I'm curious if there is a > > better way to format these cases. Perhaps ideal would be an indicator > > at the bottom or top of the y axis that read '1+' and then use 2e-9, > > 4e-9, etc as the actual tick labels. Do you agree this is ideal? I worked on a new formatter yesterday and today. It includes the indicator that John described above, right now in the last ticklabel at the top of the axis. This custom formatter also includes scientific notation in the last ticklabel only. The ultimate goal is to have scientific notation be formatted like in the logplots, but I havent gotten that far yet. Using the offset makes a large ticklabel at the moment. You can pass useOffset=False to ScalarFormatterScientific to turn this feature off (see end of script below). Interested parties, please give this script a whirl and send me your comments. (John, I have now subclassed ScalarFormatter, I didnt realize I had altered a method that other formatters were inheriting.) Darren from matplotlib import * rc('font',size='smaller') rc('tick',labelsize='smaller') from matplotlib.ticker import ScalarFormatter, LinearLocator import math from matplotlib.numerix import absolute, average from pylab import * class ScalarFormatterScientific(ScalarFormatter): """ Tick location is a plain old number. If viewInterval is set, the formatter will use %d, %1.#f or %1.ef as appropriate. If it is not set, the formatter will do str conversion """ def __init__(self, useOffset=True): """ useOffset allows plotting small data ranges with large offsets: for example: [1+1e-9,1+2e-9,1+3e-9] """ self._useOffset = useOffset def set_locs(self, locs): self.locs = locs self._set_offset() self._set_orderOfMagnitude() self._set_format() def _set_offset(self): # offset of 20,001 is 20,000, for example if self._useOffset: ave_loc = average(self.locs) std_loc = std(self.locs) if ave_loc: # dont want to take log10(0) ave_oom = math.floor(math.log10(absolute(ave_loc))) if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs # add 1e-15 because of floating point precision, fixes conversion self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom else: self.offset = 0 def _set_orderOfMagnitude(self): # if using an offset, oom applies after applying the offset locs = array(self.locs)-self.offset ave_loc_abs = average(absolute(locs)) oom = math.floor(math.log10(ave_loc_abs)) # need to special-case for range of 0-1e-5 if oom <= 0 and std(locs) < 1e-4:#10**(2*oom): self.orderOfMagnitude = oom elif oom <=0 and oom >= -5: pass elif math.fabs(oom) >= 4: self.orderOfMagnitude = oom def _set_format(self): locs = (array(self.locs,'d')-self.offset) / \ 10**self.orderOfMagnitude+1e-15 sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \ for loc in locs] sigfigs.sort() self.format = '%1.' + str(sigfigs[-1]) + 'f' def pprint_val(self, x, d): xp = (x-self.offset)/10**self.orderOfMagnitude if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): offsetStr = '' sciNotStr = '' xp = self.format % xp if self.offset: p = '%1.e+'% self.offset offsetStr = self._formatSciNotation(p) if self.orderOfMagnitude: p = 'x%1.e'% 10**self.orderOfMagnitude sciNotStr = self._formatSciNotation(p) return ''.join((offsetStr,xp,sciNotStr)) elif xp==0: return '%d'% xp else: return self.format % xp def _formatSciNotation(self,s): tup = s.split('e') mantissa = tup[0] sign = tup[1][0].replace('+', '') exponent = tup[1][1:].lstrip('0') return '%se%s%s' %(mantissa, sign, exponent) figure(1,figsize=(6,6)) ax1 = axes([.2,.74,.75,.2]) ax1.plot(arange(11)*5e2) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('BIG NUMBERS',fontsize=14) ax2 = axes([.2,.51,.75,.2]) ax2.plot(arange(11)*1e4) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e4,'6e4') ax2.xaxis.set_visible(False) ax3 = axes([.2,.28,.75,.2]) ax3.plot(arange(11)*1e4+1e10) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,6e4+1e10,'1e10+6e4') ax3.xaxis.set_visible(False) ax4 = axes([.2,.05,.75,.2]) ax4.plot(arange(11)*1e4+1e10) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e10+6e4,'same as above, no offset') figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*5e-5) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('small numbers',fontsize=8) ax2 = axes([.225,.51,.75,.2]) ax2.plot(arange(11)*1e-5) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e-5,'6e-5') ax2.xaxis.set_visible(False) ax3 = axes([.225,.28,.75,.2]) ax3.plot(arange(11)*1e-10+1e-5) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,1e-5+6e-10,'6e-10+1e-5') ax3.xaxis.set_visible(False) ax4 = axes([.225,.05,.75,.2]) ax4.plot(arange(11)*1e-10+1e-5) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e-5+6e-10,'same as above, no offset') show() ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-28 01:40:50 ```oops, I just noticed a bug, the first script I posted wont run. This updated script worked for me with a fresh 0.72.1 installation. Sorry about the error. Darren from matplotlib import * rc('font',size='smaller') rc('tick',labelsize='smaller') from matplotlib.ticker import ScalarFormatter, LinearLocator import math from matplotlib.numerix import absolute, average from pylab import * class ScalarFormatterScientific(ScalarFormatter): """ Tick location is a plain old number. If useOffset==True and the data range <1e-4* the data average, then an offset will be determined such that the tick labels are meaningful. Scientific notation is used for data < 1e-4 or data >= 1e4. Scientific notation is presented once for each axis, in the last ticklabel. """ def __init__(self, useOffset=True): """ useOffset allows plotting small data ranges with large offsets: for example: [1+1e-9,1+2e-9,1+3e-9] """ self._useOffset = useOffset self.offset = 0 self.orderOfMagnitude = 0 self.format = None def set_locs(self, locs): self.locs = locs self._set_offset() self._set_orderOfMagnitude() self._set_format() def _set_offset(self): # offset of 20,001 is 20,000, for example if self._useOffset: ave_loc = average(self.locs) std_loc = std(self.locs) if ave_loc: # dont want to take log10(0) ave_oom = math.floor(math.log10(absolute(ave_loc))) if std_loc/math.fabs(ave_loc) < 1e-4: # four sig-figs # add 1e-15 because of floating point precision, fixes conversion self.offset = int(ave_loc/10**ave_oom+1e-15)*10**ave_oom else: self.offset = 0 def _set_orderOfMagnitude(self): # if scientific notation is to be used, find the appropriate exponent # if using an offset, find the OOM after applying the offset locs = array(self.locs)-self.offset ave_loc_abs = average(absolute(locs)) oom = math.floor(math.log10(ave_loc_abs)) # need to special-case for range of 0-1e-5 if oom <= 0 and std(locs) < 1e-4:#10**(2*oom): self.orderOfMagnitude = oom elif oom <=0 and oom >= -5: pass elif math.fabs(oom) >= 4: self.orderOfMagnitude = oom def _set_format(self): # set the format string to format all the ticklabels locs = (array(self.locs,'d')-self.offset) / \ 10**self.orderOfMagnitude+1e-15 sigfigs = [len(str('%1.4f'% loc).split('.')[1].rstrip('0')) \ for loc in locs] sigfigs.sort() self.format = '%1.' + str(sigfigs[-1]) + 'f' def pprint_val(self, x, d): # d is no longer necessary, x is the tick location. xp = (x-self.offset)/10**self.orderOfMagnitude if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): offsetStr = '' sciNotStr = '' xp = self.format % xp if self.offset: p = '%1.e+'% self.offset offsetStr = self._formatSciNotation(p) if self.orderOfMagnitude: p = 'x%1.e'% 10**self.orderOfMagnitude sciNotStr = self._formatSciNotation(p) return ''.join((offsetStr,xp,sciNotStr[2:])) elif xp==0: return '%d'% xp else: return self.format % xp def _formatSciNotation(self,s): # transform 1e+004 into 1e4, for example tup = s.split('e') mantissa = tup[0] sign = tup[1][0].replace('+', '') exponent = tup[1][1:].lstrip('0') return '%se%s%s' %(mantissa, sign, exponent) figure(1,figsize=(6,6)) ax1 = axes([.2,.74,.75,.2]) ax1.plot(arange(11)*5e2) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('BIG NUMBERS',fontsize=14) ax2 = axes([.2,.51,.75,.2]) ax2.plot(arange(11)*1e4) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e4,'y=1e4*x') ax2.xaxis.set_visible(False) ax3 = axes([.2,.28,.75,.2]) ax3.plot(arange(11)*1e4+1e10) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,6e4+1e10,'y=1e4*x+1e10') ax3.xaxis.set_visible(False) ax4 = axes([.2,.05,.75,.2]) ax4.plot(arange(11)*1e4+1e10) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e10+6e4,'y=1e4*x+1e10, no offset') figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-4) ax1.yaxis.set_major_formatter(ScalarFormatterScientific()) ax1.xaxis.set_visible(False) ax1.set_title('small numbers',fontsize=8) ax2 = axes([.225,.51,.75,.2]) ax2.plot(arange(11)*1e-5) ax2.yaxis.set_major_formatter(ScalarFormatterScientific()) ax2.text(1,6e-5,'y=1e-5*x') ax2.xaxis.set_visible(False) ax3 = axes([.225,.28,.75,.2]) ax3.plot(arange(11)*1e-10+1e-5) ax3.yaxis.set_major_formatter(ScalarFormatterScientific()) ax3.text(1,1e-5+6e-10,'y=1e-10*x+1e-5') ax3.xaxis.set_visible(False) ax4 = axes([.225,.05,.75,.2]) ax4.plot(arange(11)*1e-10+1e-5) ax4.yaxis.set_major_formatter(ScalarFormatterScientific(useOffset=False)) ax4.text(1,1e-5+6e-10,'y=1e-10*x+1e-5, no offset') show() ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: John Hunter - 2005-02-28 17:23:25 ```>>>>> "Darren" == Darren Dale writes: Darren> oops, I just noticed a bug, the first script I posted wont Darren> run. This updated script worked for me with a fresh 0.72.1 Darren> installation. Sorry about the error. Hi Darren, this is very nice work. Sorry for the delay in getting back but I've been tied up for the last week or so. One comment I have is that I think we might choose the default offset label differently. Visually 1e-5+12e-10 10 8 6 4 2 is hard to read because the two 10s line up when you should be comparing the 12 with the 10. I wonder if this is better 1e-5+1e-10*12 10 8 6 4 2 Still an eyeful but at least the significant part of the ticks are co-registered. What so you think? Likewise 10e-5 8 6 4 2 Becomes 1e-5*10 8 6 4 2 It takes more room but I find it easier to read because one naturally expects the significant digits to be in the same place. Another comment is that these labels take up a lot of space, and will pretty much break any default subplot which doesn't leave enough room for them. Although I like the idea of using one of the tick labels itself to handle the offset formatting, I wonder if we might be better off using a special axis.set_offset command, so that for example, the yaxis could place the offset above the ticks and thus take up less horizontal space. Just a thought. Also, I'm inclined to make this the default formatter -- do you see any problems with this? What troubles did you run into when you tried to add these changes to the ScalarFormatter class and then rolled them back because of clashes with derived classes? JDH ```
 Re: [Matplotlib-users] 'bug' in labelling axes for data with small variation? From: Darren Dale - 2005-02-28 18:50:50 ```Hi John, On Monday 28 February 2005 12:11 pm, John Hunter wrote: > >>>>> "Darren" == Darren Dale writes: > > Darren> oops, I just noticed a bug, the first script I posted wont > Darren> run. This updated script worked for me with a fresh 0.72.1 > Darren> installation. Sorry about the error. > > Hi Darren, this is very nice work. Sorry for the delay in getting > back but I've been tied up for the last week or so. Thanks. > > One comment I have is that I think we might choose the default offset > label differently. Visually > > 1e-5+12e-10 > 10 > 8 > 6 > 4 > 2 > > is hard to read because the two 10s line up when you should be > comparing the 12 with the 10. I wonder if this is better > > 1e-5+1e-10*12 > 10 > 8 > 6 > 4 > 2 > > Still an eyeful but at least the significant part of the ticks are > co-registered. What so you think? I originally did it the way you suggest, and changed it to make it more compact.... [...] > > Another comment is that these labels take up a lot of space, and will > pretty much break any default subplot which doesn't leave enough room > for them. > > Although I like the idea of using one of the tick labels > itself to handle the offset formatting, I wonder if we might be better > off using a special axis.set_offset command, so that for example, the > yaxis could place the offset above the ticks and thus take up less > horizontal space. Just a thought. Yeah, my intention this weekend was just to get the information into the plot, so it was clear what I was trying to accomplish. I would really like to get the scientific notation out of that last ticklabel, and put it above the axis as you suggest. Can we do proper exponential formatting, like with the logscale? I know there are scholarly journals out there that will complain about using the 'e' notation. > > Also, I'm inclined to make this the default formatter -- I am glad to hear that. > do you see > any problems with this? What troubles did you run into when you tried > to add these changes to the ScalarFormatter class and then rolled them > back because of clashes with derived classes? I originally hijacked ScalarFormatter, then noticed that the LogFormatter* classes inherited the pprint_val method from ScalarFormatter. That is really not a problem, we could just copy the old ScalarFormatter.pprint_val method to LogFormatter, then it will override the new ScalarFormatter method. Questions/problems before making this the default formatter: 1) Will the gui windows still report the appropriate coordinates? I noticed in the script I posted that the y coordinate was only reported as an integer. 2) in the script, near the bottom, try changing figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-4) to read figure(2,figsize=(6,6)) ax1 = axes([.225,.74,.75,.2]) ax1.plot(arange(11)*1e-15) #<--- changed order of magnitude The resulting plot does not render the last ticklabel. I checked my script, and the string is generated by pprint_val, but it is not rendered. I dont understand why. Several orders of magnitude wont render. For example, 1e-107 doesnt render, nor does 1e-60, but 1e-61 does. I didnt see a problem with scientific notation containing positive exponents. Maybe this odd bug will not be reproducible once the information is rendered in its own space, I dont know. 3) (Almost not worth mentioning) I could run the same script 10 times and once it would yield an unsubscriptable object error message. When this happened, self.locs was set to None, and pprint_val was choking on this line: if x==self.locs[-1] and (self.orderOfMagnitude or self.offset): This problem will not exist when we stop rendering the offset/sci.not. in the ticklabel. I hesitate to even bring this nonexistent problem up, but if somebody notices this behavior, they should know it will not exist in the final product. -- Darren ```