On 22 Nov 2014 02:22, "Benjamin Root" <ben.r...@ou.edu> wrote:
>
> Some of your wishes are in progress already:
https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width,
and you are right, the spacing for the dashes are terrible.
Nice!
> I can definitely see the argument to making a bunch of these visual
changes together. Preferably, I would like to do these changes via style
sheets so that we can provide a "classic" stylesheet for backwards
compatibility.
Yeah, I didn't want to get into the details of mechanism here because
that's a comparatively simple technical question, compared to the questions
about whether we should make changes and which changes we should make. But
I'm definitely assuming we'll provide a simple supported/documented way to
request the old defaults, and I agree that the obvious way is by swapping
out stylesheets. This might require adding a few more parameters to
rcParam, but I'm guessing that won't be a big deal.
> I do actually like the autoscaling system as it exists now. The problem
is that the data margins feature is applied haphazardly. The power spectra
example is a good example of where we could "smarten" the system.
Can you elaborate on what you like about it? Like I said, when I first
heard about it sounded like a neat idea. But in practice, over my years of
using matplotlib... sometimes it's been fine, and sometimes it's made me
roll my eyes/swear, but I don't think there's been a single instance where
I looked at a graph and thought "oo, nice one matplotlib - your insistence
on shrinking my data to use fewer pixels in order to get a major tick lined
up exactly with the spines has really improved this graph. Neat tick/spine
alignment really is the highest priority in data visualization".
Even in the rare cases where my measurement scale actually does have a neat
0-1 or 0-100 range, I usually find that matplotlib has chosen something
like 0-90, or, if we fix the issue with cramming data right up into the
axes, then I guess I'll end up with -10 - 110. Which looks worse than
something like -4 - 104, because with -4 - 104, my outermost axis labels
are 0 and 100. With -10 - 110, the outermost labels are -10 and 110, and
it's weird and confusing to have axis labels naming impossible values.
So can you share your examples of where this behavior has given you
substantively better results?
> As for the ticks... I think that is a very obscure edge-case. I
personally prefer inward.
Yeah, that one is a pet peeve - I was gratified to see that the seaborn
folks also took the trouble to fix it (I'm not alone!). To be fair, though,
the reason I noticed isn't that I care a lot about ticks per se, it's
because the default was screwing up my figures so I had to go track it down
:-/. Here's another example -- the final versions of the autocorrelation
graphs I mentioned above.
[image: Inline image 1]
In both of these graphs, having the ticks to point inwards created weird
confusing intersections with the lines, so I had to flip them to point
outwards. It's just an objective thing, if you use the same pixels for data
and metadata then that creates room for ugly stuff to happen. And when it
comes to defaults, if you have two choices that are basically equivalent,
except that one is always fine and one is usually fine but sometimes screws
things up, then the former seems like the obvious choice...
-n
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
