Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Benjamin Root <ben.root@ou...>  20100915 18:25:41
Attachments:
Message as HTML
cleanoffsets.patch

From: freeeeeekk <freeeeeekk@gm...>  20100911 23:57:30

Im trying to do a very simple x vs y plot. Where the x values range between 3247 and 3256 and y between 0 and 1. This data is stored in data.dat. I plot it using the code below, the resulting plot is shown in the first of the two plots below. Everything goes well except for the x axis, for some reason tickmarks from 0 up to 9 appear. At the far end of the axis my xmin is printed: 3.247e3. I started looking for the cause and it turns out that as long as my range in x is lower than 10, this happens. If I change the xlimits to xlim(3246,3256) I get the plot at the bottom of this page, everything is fine. But if I change this to for instance xlim(3246.01,3256) or xlim(3245, 3254.99) I get the same behaviour as in the first graph. Does any one have any experience with this/ know the reason for this happening? Thanks! from numpy import * from pylab import * datafile = mlab.load('./data.dat') xx=datafile[:,0] yy=datafile[:,1] plot(xx,yy,'black') xlim(3247,3256) ylim(0,1.2) show() http://old.nabble.com/file/p29687404/wrong.png http://old.nabble.com/file/p29687404/right.png  View this message in context: http://old.nabble.com/weirdbehaviourinxaxistp29687404p29687404.html Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: Benjamin Root <ben.root@ou...>  20100913 20:43:06
Attachments:
Message as HTML

On Sat, Sep 11, 2010 at 6:57 PM, freeeeeekk <freeeeeekk@...> wrote: > > Im trying to do a very simple x vs y plot. Where the x values range between > 3247 and 3256 and y between 0 and 1. This data is stored in data.dat. I > plot > it using the code below, the resulting plot is shown in the first of the > two > plots below. Everything goes well except for the x axis, for some reason > tickmarks from 0 up to 9 appear. At the far end of the axis my xmin is > printed: 3.247e3. > I started looking for the cause and it turns out that as long as my range > in > x is lower than 10, this happens. If I change the xlimits to > xlim(3246,3256) > I get the plot at the bottom of this page, everything is fine. But if I > change this to for instance xlim(3246.01,3256) or xlim(3245, 3254.99) I get > the same behaviour as in the first graph. > > Does any one have any experience with this/ know the reason for this > happening? Thanks! > > from numpy import * > from pylab import * > > datafile = mlab.load('./data.dat') > xx=datafile[:,0] > yy=datafile[:,1] > > plot(xx,yy,'black') > xlim(3247,3256) > ylim(0,1.2) > > show() > > > http://old.nabble.com/file/p29687404/wrong.png > http://old.nabble.com/file/p29687404/right.png > What is happening isn't a bug, it is a feature, although it probably could be done a little bit better. When the range of values to display for ticks is fairly small compared to the size of the values, then matplotlib displays only the part that changes as a value relative to some constant offset. In your case, the constant offset is the +3.247e3 on the right hand side of the axis. This can also happen for the yaxis as well. This is similar to the idea of how matplotlib would display very large numbers like range(1e7, 10e7, 1e7) as "1 2 3 4 5 6 7 8 9" with a 1e7 at the end of the axis. I hope this makes sense. Ben Root 
From: Eric Firing <efiring@ha...>  20100913 22:35:37

On 09/11/2010 11:12 AM, freeeeeekk wrote: > > Im trying to do a very simple x vs y plot. Where the x values range between > 3247 and 3256 and y between 0 and 1. This data is stored in data.dat. I plot > it using the code below, the resulting plot is shown in the first of the two > plots below. Everything goes well except for the x axis, for some reason > tickmarks from 0 up to 9 appear. At the far end of the axis my xmin is > printed: 3.247e3. > I started looking for the cause and it turns out that as long as my range in > x is lower than 10, this happens. If I change the xlimits to xlim(3246,3256) > I get the plot at the bottom of this page, everything is fine. But if I > change this to for instance xlim(3246.01,3256) or xlim(3245, 3254.99) I get > the same behaviour as in the first graph. > > Does any one have any experience with this/ know the reason for this > happening? Thanks! > > from numpy import * > from pylab import * > > datafile = mlab.load('./data.dat') > xx=datafile[:,0] > yy=datafile[:,1] > > plot(xx,yy,'black') > xlim(3247,3256) > ylim(0,1.2) with older mpl, try this: gca().xaxis.set_major_formatter(ScalarFormatter(useOffset=False)) with 1.0 or later try the following instead: ticklabel_format(useOffset=False) Eric > > show() > > > http://old.nabble.com/file/p29687404/wrong.png > http://old.nabble.com/file/p29687404/right.png 
From: Jan Skowron <jan.skowron@gm...>  20100914 16:12:55

Hi, apropos this offset discussion. matplotlib makes offsets not aligned to the full tens or some other easy number with small amount of nonzero digits in front? For example having ticks: 4917, 4918, 4919, 4920, 4921, 4922 it will now display: 1, 2, 3, 4, 5, 6 with offset 4916 (of even +4.916e3) this makes reading values on the axis really really hard as every time one have to perform not obvious summations with all digits of length. It would be beneficial to have as a default behaviour some optimization of offsets to have it as some basic number for easy reading instead of current behaviour that tries to minimize the number of digits in the ticks and starts from a low number like 1 or 0.05 or so. In our case the best display would be: 17, 18, 19, 20, 21, 22 with offset 4900 So we minimize the number of nonzero digits in offset and not a number of digits in tick labels. Another more ridiculous example (from life) are ticks with values: 4916.25, 4916.30, 4916.35, 4916.40, 4916.45 are displayed as: 0.05, 0.10, 0.15, 0.20, 0.25 with offset +4.9162e3 and with good algorithm should be displayed as: 0.25, 0.30, 0.35, 0.40, 0.45 with offset 4962 (nottice that not +4.962e3 as it usually displays now) and if we would cross the boundary between 4962 and 4963 than ticks should look like: 2.80, 2.85, 2.90, 2.95, 3.00, 3.05 with offset 4960 In my opinion the current behaviour of offsets really hampers the usability of these at all, and probably 90% of users spent some time on nothing but trying to figure out how to turn this thing off (thanks for sending this solutions here). So this is message to signal or show the need for fixing this algorithm. For now I think that the title of this post: "weird behaviour in x axis", really summarize current offset algorithm nicely. Thanks for your comments, Jan On Mon, Sep 13, 2010 at 18:35, Eric Firing <efiring@...> wrote: > On 09/11/2010 11:12 AM, freeeeeekk wrote: >> >> Im trying to do a very simple x vs y plot. Where the x values range between >> 3247 and 3256 and y between 0 and 1. This data is stored in data.dat. I plot >> it using the code below, the resulting plot is shown in the first of the two >> plots below. Everything goes well except for the x axis, for some reason >> tickmarks from 0 up to 9 appear. At the far end of the axis my xmin is >> printed: 3.247e3. >> I started looking for the cause and it turns out that as long as my range in >> x is lower than 10, this happens. If I change the xlimits to xlim(3246,3256) >> I get the plot at the bottom of this page, everything is fine. But if I >> change this to for instance xlim(3246.01,3256) or xlim(3245, 3254.99) I get >> the same behaviour as in the first graph. >> >> Does any one have any experience with this/ know the reason for this >> happening? Thanks! >> >> from numpy import * >> from pylab import * >> >> datafile = mlab.load('./data.dat') >> xx=datafile[:,0] >> yy=datafile[:,1] >> >> plot(xx,yy,'black') >> xlim(3247,3256) >> ylim(0,1.2) > > with older mpl, try this: > > gca().xaxis.set_major_formatter(ScalarFormatter(useOffset=False)) > > with 1.0 or later try the following instead: > > ticklabel_format(useOffset=False) > > Eric > >> >> show() >> >> >> http://old.nabble.com/file/p29687404/wrong.png >> http://old.nabble.com/file/p29687404/right.png > > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers > 
From: Benjamin Root <ben.root@ou...>  20100915 14:56:07
Attachments:
Message as HTML

On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron <jan.skowron@...> wrote: > Hi, > apropos this offset discussion. > matplotlib makes offsets not aligned to the full tens or some other > easy number with small amount of nonzero digits in front? > > For example having ticks: > 4917, 4918, 4919, 4920, 4921, 4922 > > it will now display: > 1, 2, 3, 4, 5, 6 with offset 4916 (of even +4.916e3) > > this makes reading values on the axis really really hard as every time > one have to perform not obvious summations with all digits of length. > It would be beneficial to have as a default behaviour some > optimization of offsets to have it as some basic number for easy > reading instead of current behaviour that tries to minimize the number > of digits in the ticks and starts from a low number like 1 or 0.05 or > so. > In our case the best display would be: > > 17, 18, 19, 20, 21, 22 with offset 4900 > > So we minimize the number of nonzero digits in offset and not a > number of digits in tick labels. > > Another more ridiculous example (from life) are ticks with values: > > 4916.25, 4916.30, 4916.35, 4916.40, 4916.45 > > are displayed as: > > 0.05, 0.10, 0.15, 0.20, 0.25 with offset +4.9162e3 > > and with good algorithm should be displayed as: > > 0.25, 0.30, 0.35, 0.40, 0.45 with offset 4962 (nottice that not > +4.962e3 as it usually displays now) > > and if we would cross the boundary between 4962 and 4963 than ticks > should look like: > 2.80, 2.85, 2.90, 2.95, 3.00, 3.05 with offset 4960 > > > In my opinion the current behaviour of offsets really hampers the > usability of these at all, and probably 90% of users spent some time > on nothing but trying to figure out how to turn this thing off (thanks > for sending this solutions here). > > So this is message to signal or show the need for fixing this > algorithm. For now I think that the title of this post: "weird > behaviour in x axis", really summarize current offset algorithm > nicely. > > > Thanks for your comments, > Jan > > I like that idea as it is certainly more intuitive. Essentially, it would find the most significant bits that are common to all ticks and use that for the offset. Does anybody know where the current code is? I would be willing to take a look at it today and see what I can do. Thanks, Ben Root 
From: freeeeeekk <freeeeeekk@gm...>  20100915 14:47:49

Thanks! This got it working. Also thanks to the other for explaining why python does it. I understand the reason, but I think its weird to have that as the default setting. efiring wrote: > > On 09/11/2010 11:12 AM, freeeeeekk wrote: >> >> Im trying to do a very simple x vs y plot. Where the x values range >> between >> 3247 and 3256 and y between 0 and 1. This data is stored in data.dat. I >> plot >> it using the code below, the resulting plot is shown in the first of the >> two >> plots below. Everything goes well except for the x axis, for some reason >> tickmarks from 0 up to 9 appear. At the far end of the axis my xmin is >> printed: 3.247e3. >> I started looking for the cause and it turns out that as long as my range >> in >> x is lower than 10, this happens. If I change the xlimits to >> xlim(3246,3256) >> I get the plot at the bottom of this page, everything is fine. But if I >> change this to for instance xlim(3246.01,3256) or xlim(3245, 3254.99) I >> get >> the same behaviour as in the first graph. >> >> Does any one have any experience with this/ know the reason for this >> happening? Thanks! >> >> from numpy import * >> from pylab import * >> >> datafile = mlab.load('./data.dat') >> xx=datafile[:,0] >> yy=datafile[:,1] >> >> plot(xx,yy,'black') >> xlim(3247,3256) >> ylim(0,1.2) > > with older mpl, try this: > > gca().xaxis.set_major_formatter(ScalarFormatter(useOffset=False)) > > with 1.0 or later try the following instead: > > ticklabel_format(useOffset=False) > > Eric > >> >> show() >> >> >> http://old.nabble.com/file/p29687404/wrong.png >> http://old.nabble.com/file/p29687404/right.png > > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers > >  View this message in context: http://old.nabble.com/weirdbehaviourinxaxistp29687404p29718992.html Sent from the matplotlib  users mailing list archive at Nabble.com. 
From: Eric Firing <efiring@ha...>  20100915 17:37:19

On 09/15/2010 04:55 AM, Benjamin Root wrote: > On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron <jan.skowron@... > <mailto:jan.skowron@...>> wrote: > > Hi, > apropos this offset discussion. > matplotlib makes offsets not aligned to the full tens or some other > easy number with small amount of nonzero digits in front? > > For example having ticks: > 4917, 4918, 4919, 4920, 4921, 4922 > > it will now display: > 1, 2, 3, 4, 5, 6 with offset 4916 (of even +4.916e3) > > this makes reading values on the axis really really hard as every time > one have to perform not obvious summations with all digits of length. > It would be beneficial to have as a default behaviour some > optimization of offsets to have it as some basic number for easy > reading instead of current behaviour that tries to minimize the number > of digits in the ticks and starts from a low number like 1 or 0.05 or > so. > In our case the best display would be: > > 17, 18, 19, 20, 21, 22 with offset 4900 > > So we minimize the number of nonzero digits in offset and not a > number of digits in tick labels. > > Another more ridiculous example (from life) are ticks with values: > > 4916.25, 4916.30, 4916.35, 4916.40, 4916.45 > > are displayed as: > > 0.05, 0.10, 0.15, 0.20, 0.25 with offset +4.9162e3 > > and with good algorithm should be displayed as: > > 0.25, 0.30, 0.35, 0.40, 0.45 with offset 4962 (nottice that not > +4.962e3 as it usually displays now) > > and if we would cross the boundary between 4962 and 4963 than ticks > should look like: > 2.80, 2.85, 2.90, 2.95, 3.00, 3.05 with offset 4960 > > > In my opinion the current behaviour of offsets really hampers the > usability of these at all, and probably 90% of users spent some time > on nothing but trying to figure out how to turn this thing off (thanks > for sending this solutions here). > > So this is message to signal or show the need for fixing this > algorithm. For now I think that the title of this post: "weird > behaviour in x axis", really summarize current offset algorithm > nicely. > > > Thanks for your comments, > Jan > > > I like that idea as it is certainly more intuitive. Essentially, it > would find the most significant bits that are common to all ticks and > use that for the offset. > > Does anybody know where the current code is? I would be willing to take > a look at it today and see what I can do. In ticker.ScalarFormatter._setOffset (or something like that). Be careful not to make it too complicated; maybe it can even be made simpler. I think that as a first shot, something like adding +3 (or maybe it would be 3) to a couple lines of code might be a step in the right directionand maybe adequate. Thank you. Eric > > Thanks, > Ben Root > > > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > > > > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
From: Benjamin Root <ben.root@ou...>  20100915 18:25:41
Attachments:
Message as HTML
cleanoffsets.patch

From: Eric Firing <efiring@ha...>  20100915 18:42:26

On 09/15/2010 08:25 AM, Benjamin Root wrote: > On Wed, Sep 15, 2010 at 12:37 PM, Eric Firing <efiring@... > <mailto:efiring@...>> wrote: > > On 09/15/2010 04:55 AM, Benjamin Root wrote: > > On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron > <jan.skowron@... <mailto:jan.skowron@...> > > <mailto:jan.skowron@... <mailto:jan.skowron@...>>> wrote: > > > > Hi, > > apropos this offset discussion. > > matplotlib makes offsets not aligned to the full tens or some > other > > easy number with small amount of nonzero digits in front? > > > > For example having ticks: > > 4917, 4918, 4919, 4920, 4921, 4922 > > > > it will now display: > > 1, 2, 3, 4, 5, 6 with offset 4916 (of even +4.916e3) > > > > this makes reading values on the axis really really hard as > every time > > one have to perform not obvious summations with all digits of > length. > > It would be beneficial to have as a default behaviour some > > optimization of offsets to have it as some basic number for easy > > reading instead of current behaviour that tries to minimize > the number > > of digits in the ticks and starts from a low number like 1 or > 0.05 or > > so. > > In our case the best display would be: > > > > 17, 18, 19, 20, 21, 22 with offset 4900 > > > > So we minimize the number of nonzero digits in offset and not a > > number of digits in tick labels. > > > > Another more ridiculous example (from life) are ticks with > values: > > > > 4916.25, 4916.30, 4916.35, 4916.40, 4916.45 > > > > are displayed as: > > > > 0.05, 0.10, 0.15, 0.20, 0.25 with offset +4.9162e3 > > > > and with good algorithm should be displayed as: > > > > 0.25, 0.30, 0.35, 0.40, 0.45 with offset 4962 (nottice that not > > +4.962e3 as it usually displays now) > > > > and if we would cross the boundary between 4962 and 4963 than > ticks > > should look like: > > 2.80, 2.85, 2.90, 2.95, 3.00, 3.05 with offset 4960 > > > > > > In my opinion the current behaviour of offsets really hampers the > > usability of these at all, and probably 90% of users spent > some time > > on nothing but trying to figure out how to turn this thing > off (thanks > > for sending this solutions here). > > > > So this is message to signal or show the need for fixing this > > algorithm. For now I think that the title of this post: "weird > > behaviour in x axis", really summarize current offset algorithm > > nicely. > > > > > > Thanks for your comments, > > Jan > > > > > > I like that idea as it is certainly more intuitive. Essentially, it > > would find the most significant bits that are common to all ticks and > > use that for the offset. > > > > Does anybody know where the current code is? I would be willing > to take > > a look at it today and see what I can do. > > In ticker.ScalarFormatter._setOffset (or something like that). Be > careful not to make it too complicated; maybe it can even be made > simpler. I think that as a first shot, something like adding +3 (or > maybe it would be 3) to a couple lines of code might be a step in the > right directionand maybe adequate. > > Thank you. > > Eric > > > Here is what I came up with. In ticker.ScalarFormatter._setOffset, I > set a variable called "common_oom" to the same value as 'range_oom'. > This order of magnitude should be the smallest possible magnitude where > there all the significant digits are the same. Then, I do: > > tickdiff = np.sum(np.diff(np.trunc(locs * 10**common_oom))) > while tickdiff >= 1.0 : > common_oom += 1.0 > tickdiff = np.sum(np.diff(np.trunc(locs * 10**common_oom))) > > Essentially, I find increment common_oom until the differences in the > rounded versions of the locs become significant. Then, I use common_oom > instead of range_oom in calculating the offset. > > I suspect it could be done better, and I am not certain that there are > no edge cases regarding the use of trunc. > > Thoughts, concerns? > > Ben Root Ben, I can't look closely right now, so here are only very quick offthecuff comments: 1) for testing, try to come up with a good selection of cases: negative, positive, very close to, but less than 1, very close to, but greater than, 1, etc. 2) I'm concerned that the sort of approach you are describing may be slow. The process of generating a plot, and redrawing it upon zoom/pan/resize, is already badly slowed down by the ticks and tick labels, and I would hate to see this pesky offset make the situation worse. 3) Isn't there a goodenough solution involving a single math calculation? 4) Although I have complained about the everexpanding set of rcParams, *maybe* the useOffset default should be added. Rather than a boolean, it could be a threshold. Eric > > > >  > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novellsfdev2dev > > > > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
Sign up for the SourceForge newsletter:
No, thanks