On Wed, Sep 15, 2010 at 12:37 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 09/15/2010 04:55 AM, Benjamin Root wrote: > > On Tue, Sep 14, 2010 at 11:12 AM, Jan Skowron <jan.skow...@gmail.com > > <mailto:jan.skow...@gmail.com>> wrote: > > > > Hi, > > apropos this offset discussion. > > matplotlib makes offsets not aligned to the full tens or some other > > easy number with small amount of non-zero 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 non-zero 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 direction--and 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
cleanoffsets.patch
Description: Binary data
------------------------------------------------------------------------------ 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/novell-sfdev2dev
_______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
