Re: [matplotlib-devel] Request: make plotting of a single point more convenient

2009-07-25 Thread Nathaniel Smith 
On Sat, Jul 25, 2009 at 3:13 PM, Rob Clewley wrote:
> I wrote a wrapper to do this for my own code because I wanted it so
> much. I can't see why it would be a problem to support, it's only one
> extra if statement.

Or zero extra statements, if one just replaces the

  if len(x.shape) == 1:
x = x[:, np.newaxis]

lines with

  while len(x.shape) < 2:
x = x[:, np.newaxis]

-- Nathaniel

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

2010-01-03 Thread Nathaniel Smith 
On Tue, Dec 29, 2009 at 6:34 AM, David Cournapeau  wrote:
> Buildout, virtualenv all work by sandboxing from the system python:
> each of them do not see each other, which may be useful for
> development, but as a deployment solution to the casual user who may
> not be familiar with python, it is useless. A scientist who installs
> numpy, scipy, etc... to try things out want to have everything
> available in one python interpreter, and does not want to jump to
> different virtualenvs and whatnot to try different packages.

What I do -- and documented for people in my lab to do -- is set up
one virtualenv in my user account, and use it as my default python. (I
'activate' it from my login scripts.) The advantage of this is that
easy_install (or pip) just works, without any hassle about permissions
etc. This should be easier, but I think the basic approach is sound.
"Integration with the package system" is useless; the advantage of
distribution packages is that distributions can provide a single
coherent system with consistent version numbers across all packages,
etc., and the only way to "integrate" with that is to, well, get the
packages into the distribution.

On another note, I hope toydist will provide a "source prepare" step,
that allows arbitrary code to be run on the source tree. (For, e.g.,
cython->C conversion, ad-hoc template languages, etc.) IME this is a
very common pain point with distutils; there is just no good way to do
it, and it has to be supported in the distribution utility in order to
get everything right. In particular:
  -- Generated files should never be written to the source tree
itself, but only the build directory
  -- Building from a source checkout should run the "source prepare"
step automatically
  -- Building a source distribution should also run the "source
prepare" step, and stash the results in such a way that when later
building the source distribution, this step can be skipped. This is a
common requirement for user convenience, and necessary if you want to
avoid arbitrary code execution during builds.
And if you just set up the distribution util so that the only place
you can specify arbitrary code execution is in the "source prepare"
step, then even people who know nothing about packaging will
automatically get all of the above right.

Cheers,
-- Nathaniel

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation

2010-01-03 Thread Nathaniel Smith 
On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau  wrote:
> On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith  wrote:
>> What I do -- and documented for people in my lab to do -- is set up
>> one virtualenv in my user account, and use it as my default python. (I
>> 'activate' it from my login scripts.) The advantage of this is that
>> easy_install (or pip) just works, without any hassle about permissions
>> etc.
>
> It just works if you happen to be able to build everything from
> sources. That alone means you ignore the majority of users I intend to
> target.
>
> No other community (except maybe Ruby) push those isolated install
> solutions as a general deployment solutions. If it were such a great
> idea, other people would have picked up those solutions.

AFAICT, R works more-or-less identically (once I convinced it to use a
per-user library directory); install.packages() builds from source,
and doesn't automatically pull in and build random C library
dependencies.

I'm not advocating the 'every app in its own world' model that
virtualenv's designers had min mind, but virtualenv is very useful to
give each user their own world. Normally I only use a fraction of
virtualenv's power this way, but sometimes it's handy that they've
solved the more general problem -- I can easily move my environment
out of the way and rebuild if I've done something stupid, or
experiment with new python versions in isolation, or whatever. And
when you *do* have to reproduce some old environment -- if only to
test that the new improved environment gives the same results -- then
it's *really* handy.

>> This should be easier, but I think the basic approach is sound.
>> "Integration with the package system" is useless; the advantage of
>> distribution packages is that distributions can provide a single
>> coherent system with consistent version numbers across all packages,
>> etc., and the only way to "integrate" with that is to, well, get the
>> packages into the distribution.
>
> Another way is to provide our own repository for a few major
> distributions, with automatically built packages. This is how most
> open source providers work. Miguel de Icaza explains this well:
>
> http://tirania.org/blog/archive/2007/Jan-26.html
>
> I hope we will be able to reuse much of the opensuse build service
> infrastructure.

Sure, I'm aware of the opensuse build service, have built third-party
packages for my projects, etc. It's a good attempt, but also has a lot
of problems, and when talking about scientific software it's totally
useless to me :-). First, I don't have root on our compute cluster.
Second, even if I did I'd be very leery about installing third-party
packages because there is no guarantee that the version numbering will
be consistent between the third-party repo and the real distro repo --
suppose that the distro packages 0.1, then the third party packages
0.2, then the distro packages 0.3, will upgrades be seamless? What if
the third party screws up the version numbering at some point? Debian
has "epochs" to deal with this, but third-parties can't use them and
maintain compatibility. What if the person making the third party
packages is not an expert on these random distros that they don't even
use? Will bug reporting tools work properly? Distros are complicated.
Third, while we shouldn't advocate that people screw up backwards
compatibility, version skew is a real issue. If I need one version of
a package and my lab-mate needs another and we have submissions due
tomorrow, then filing bugs is a great idea but not a solution. Fourth,
even if we had expert maintainers taking care of all these third-party
packages and all my concerns were answered, I couldn't convince our
sysadmin of that; he's the one who'd have to clean up if something
went wrong we don't have a big budget for overtime.

Let's be honest -- scientists, on the whole, suck at IT
infrastructure, and small individual packages are not going to be very
expertly put together. IMHO any real solution should take this into
account, keep them sandboxed from the rest of the system, and focus on
providing the most friendly and seamless sandbox possible.

>> On another note, I hope toydist will provide a "source prepare" step,
>> that allows arbitrary code to be run on the source tree. (For, e.g.,
>> cython->C conversion, ad-hoc template languages, etc.) IME this is a
>> very common pain point with distutils; there is just no good way to do
>> it, and it has to be supported in the distribution utility in order to
>> get everything right. In particular:
>>  -- Generated files should never be written to the source tree
>> itself, but only the bui

Re: [matplotlib-devel] HTML5 Matplotlib Backend

2010-07-19 Thread Nathaniel Smith 
On Fri, Jul 16, 2010 at 10:21 AM, Ryan Wagner  wrote:
> (Michael Droettboom)
>
>>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not
>>> in
>
>>> data units. ?It would be great if this could display data units, though
>
>>> being general enough to support custom scales (eg. log) and projections
>>> (eg.
>
>>> polar) may be tricky without making a round-trip to the server.
>
>
>
> (Simon Ratcliffe)
>
>>As you mentioned, the trick is in giving the client some view on how
>
>>pixels should map to data values without fetching these for each mouse
>
>>movement. For simple cartesian plots this is probably pretty
>
>>straightforward. It is something we need to get working for our
>
>>internal use so it should get solved at some stage.
>
>
>
> I have accomplished this in one of my applications as follows:
>
>
>
> Axes =figure.get_axes()
>
> #The transform used in this axis is Composite Generic Transform, so get the
> two affine transformation matricies
>
> MatrixA  = axes[0].transData.inverted()._a.get_matrix()
>
> MatrixB  = axes[0].transData.inverted()._b.get_matrix()
[...]
> The simple affine transformation can be accomplished by leaving off the
> MatrixB part. Non affine will probably be similar to the above followed by a
> log or exponential operation.

The other option, which would be somewhat less accurate but would
avoid reimplementing every projection in javascript, would be to build
a mesh (e.g., a grid) over the client's viewport region, sample the
value of the projection at each point on the grid, send that to the
client, and then let the client do linear interpolation to estimate
points in between grid points.

-- Nathaniel

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

2010-09-08 Thread Nathaniel Smith 
On Wed, Sep 8, 2010 at 12:12 AM, Fernando Perez  wrote:
> ps - tip: Ctrl-. restarts the kernel

Tangentially... please make this something that's a little harder to
hit by accident, like Ctrl-Alt-. or a menu item or something? My
ipython's regularly hold state that would take a few CPU-days to
reconstruct.

(Sorry for the off-topic.)

-- Nathaniel

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...

2010-10-14 Thread Nathaniel Smith 
On Thu, Oct 14, 2010 at 7:51 AM, Fernando Perez  wrote:
> Well, the client can save a session to html, svgs and all:
>
> http://fperez.org/tmp/ipython-svg.xml
>
> If the svg has extra metadata embedded, this will preserve it.  The
> author of the html saving works in genomics at UCSF, and he embeds
> extra info in his MPL svgs so that he can later annotate and
> manipulate the generated SVGs.
>
> So I think there's a good justification for wanting SVG.  However,
> this limitation in Qt means we may want to make it at least optional,
> so that people can use png when they want accurate rendering but
> without access to the original vector figure, and SVG when they need
> the original vector info (and are OK with Qt's limitations).

I suppose you could send both, and the client could display the png
and save the svg.

-- Nathaniel

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Another colormap

2011-09-22 Thread Nathaniel Smith 
On Sep 21, 2011 5:29 PM, "Christoph Gohlke"  wrote:
> On 9/13/2011 12:24 AM, Eric Firing wrote:
> > On 07/18/2011 07:07 AM, Sameer Grover wrote:
> >> I came across this website where different colormaps have been compared
> >> and the author has come up with an optimal colormap for data
> >> visualization called the "cool-warm colormap".
> >>
> >> http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html
> >>
> >> It is somewhat similar to the cool colormap already included in
> >> matplotlib, but I've added the new colormap to matplotlib in the patch
> >> attached in case it is deemed fit to be included in the matplotlib
source.
> > We should include this, but I think the 257-entry version is overkill;
> > it adds a big chunk to the _cm.py file, and I doubt it is visually
> > distinguishable from the 33-entry version.  Would you mind providing a
> > patch for the latter?  (Or better yet, the functions that generate the
> > r,g,b values.)
> Here's a pull request for the 33 entry map:
> 

Let me open a can of worms here...

I looked at the paper, and the goal was specifically to produce a good
"default" colormap - not necessarily the best for any situation, but good
overall and certainly better than the rainbow ('jet') colormap in most
cases. (I agree with the author that jet is pretty terrible and tends to
distort data.)

Should we switch to this as the default matplotlib colormap? I think it
would be a clear improvement.

- Nathaniel
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Another colormap

2011-09-22 Thread Nathaniel Smith 
On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root  wrote:
> On Thursday, September 22, 2011, Tony Yu  wrote:
>> On Thu, Sep 22, 2011 at 5:16 PM, Nathaniel Smith  wrote:
>>> I looked at the paper, and the goal was specifically to produce a good
>>> "default" colormap - not necessarily the best for any situation, but good
>>> overall and certainly better than the rainbow ('jet') colormap in most
>>> cases. (I agree with the author that jet is pretty terrible and tends to
>>> distort data.)
>>>
>>> Should we switch to this as the default matplotlib colormap? I think it
>>> would be a clear improvement.
>>
>> I have absolutely no clout here, but I'd definitely be in favor of
>> changing the default colormap away from "jet".
>>
>> Personally, I'd prefer a two-tone colormap as the default (two-distinct
>> tones at the limits with a gradient in-between---dubbed "sequential" in the
>> paper) instead of a three-tone colormap (three-distinct tones---dubbed
>> "diverging" in the paper). (I think this is a more common use case, and I
>> think using a "diverging" colormap effectively requires setting vmin/vmax.)
>> But really, (almost) anything is better than "jet".

For those following along, the article is here:
http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
The discussion about whether to use a "sequential" or "diverging" map
is in section 3.

I had the same gut reaction as you, but found the paper fairly
convincing. I'm used to diverging maps that really highlight the
center point, like matplotlib's RdBu colormap, and use them all the
time for data where the zero point really matters (and set vmin/vmax
appropriately, like you say). But this colormap is actually really
different from the ones I'm used to, because it's really designed
*not* to highlight the center point as being special. The clearest
example of this is Figure 8 in the paper -- the image on the left is
the one that you'd get from something like RdBu, and the one on the
right is what this colormap produces. And, like he says, it gives you
better detail than a sequential map could.

I actually *wouldn't* want to use this for images that I currently use
RdBu for. But I'm picky -- the map he suggests would still make a heck
of a better colormap for those images than jet does, and Rdbu *really*
isn't appropriate for general use.

On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root  wrote:
> Anyway, this is certainly is worthy of debate, but it certainly won't happen
> for this release.  We should be cutting RC tomorrow.
>
> After the release, I encourage you guys to make your cases.  Show us plots
> that have been in "jet" and show them as better in another colormap.

Figure 16 in that paper (page 17) is a good start. In the examples
given, for both of the top two jet actively distorts the features of
the data. In row 1, it makes it look like the bars taper off as you
move towards the top of the image, which they don't (compare to the
greyscale image for reference). In row 2, it makes it look like the
"circles" vary in size across the image (which, again, they don't). In
the bottom two images, jet introduces apparent asymmetries that aren't
there: in row 3, you have these 5 apparent stripes of unequal width,
and the yellow is narrower than the cyan. In row 4, well, it's just
obviously terribly misleading. (This isn't surprising, since 'jet'
sweeps through the frequencies of visible light; the big band of
yellow in simulated deuteranope vision corresponds to where they're
missing one of the spectral sensors that most of us have.)

If you want more examples though I can certainly pull some out of my thesis :-).

> As a bit of a challenge to you all, I am not color-blind, but I do wear
> tinted glasses that make it difficult to tell the difference between darker
> blues and black, and sometimes greens and blues are hard to distinguish.
>  Furthermore, as a radar meteorologist, I am very accustomed to the
> colormaps commonly used for radar reflectivies (and is similar to "jet").

No colormap is going to be perfect for everyone, and maybe someone
else will pop up with a pointer to a map that's even better supported
than this one. I just think that jet has sufficiently manifest flaws
that it would be a great favor to science if we could switch to
*something* better as our default.

-- Nathaniel

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] How do you use numpy.ma?

2011-11-06 Thread Nathaniel Smith 
Hi matplotters,

As any of you subscribed to the numpy-discussion list will have
probably noticed, there's intense debate going on about how numpy can
do a better job of handling missing data and masked arrays. Part of
the problem is that we aren't actually sure what users need these
features to do. There's one group who just wants R-style "missing
data", and their needs are pretty straightforward -- they just want a
magic value that indicates some data point doesn't actually exist. But
it seems like there's also demand for a more "masked array"-like
feature, similar to the current numpy.ma, where the mask is
non-destructive and easily manipulable. No-one seems clear on who
exactly this should work, though, and there's a lot of disagreement
about what semantics make sense. (If you want more details, there's a
wiki page summarizing some of this[1]).

Since you seem to be the biggest users of numpy.ma, it would be really
helpful if you could explain how you actually use it, so we can make
sure that whatever we do in numpy-land is actually useful to you!

What does matplotlib use masked arrays for? Is it just a convenient
way to keep an array and a boolean mask together in one object, or do
you take advantage of more numpy.ma features? For example, do you
ever:
 - unmask values?
 - create multiple arrays that share the same storage for their data,
but have different masks? (i.e., creating a new array with new
elements masked, but without actually allocating the memory for a full
array copy)
 - use reduction operations on masked arrays? (e.g., np.sum(masked_arr))
 - use binary operations on masked arrays? (e.g., masked_arr1 + masked_arr2)

And while we're at it, any complaints about how numpy.ma works now,
that a new version might do better?

Thanks in advance,
-- Nathaniel

[1] https://github.com/njsmith/numpy/wiki/NA-discussion-status

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

2012-01-29 Thread Nathaniel Smith 
On Sun, Jan 29, 2012 at 7:42 AM, Benjamin Root  wrote:
> Not a bug.  There are only so many artist objects we assume for determining 
> the tight bbox.  Suptitle is not one of them.

Why is this the desired behavior?

-- Nathaniel

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GSOC mentoring organization

2012-03-06 Thread Nathaniel Smith 
On Tue, Mar 6, 2012 at 4:43 PM, John Hunter  wrote:
> The timeline at   http://www.google-melange.com/gsoc/events/google/gsoc2012
> says March 6th is the "[GSOC] Mentoring organization application deadline".
>  How do you interpret "mentoring organization" there?  As the PSF or someone
> under their umbrella such as statsmodels or mpl?

That's referring to PSF or other "top-level" projects.

Google doesn't care about how the PSF arranges its projects
internally, so there's not going to be anything about that on their
project calendar. As far as Google's concerned, the PSF is a single
"organization", and this is the stage where they decide which
"organizations" get funded. (The PSF will, of course.)

-- Nathaniel
(Two-time GSoC mentoring organization admin person)

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] New plot type idea -- EventRaster

2012-09-24 Thread Nathaniel Smith 
On Mon, Sep 24, 2012 at 2:33 PM, Todd  wrote:
> This sort of plot is used ubiquitously in neuroscience.  It is used to show
> the time of discrete neural (brain cell) events (called "spikes") over time
> in repeated trials, and is generally called a spike raster, raster plot, or
> raster graph.  However, it can be used in any situation where you are only
> concerned with the position of events but not their amplitude, especially if
> you want to look for patterns in those events or look for differences
> between multiple sequences of events.

This is very closely related to "rug plots", which are often used as
an axis annotation or elsewhere where it's nice to have a small 1-d
density plot. Examples:
  https://www.cl.cam.ac.uk/~sjm217/projects/graphics/
  http://rforge.org/2009/08/10/fancy-rugs-in-regression-plots/

-n

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Interactive Matplotlib in the browser

2012-10-12 Thread Nathaniel Smith 
On Thu, Oct 11, 2012 at 10:49 PM, Michael Droettboom  wrote:
> I have a proof-of-concept way to make interactive plots in the browser work
> using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.

As a bit of spiritual support for the underlying concept, I mostly use
matplotlib via exactly this mechanism, today. Except I didn't want to
modify matplotlib, so my solution is a bit more elaborate:
http://xpra.org/

There's an astonishing amount of nonsense involved in setting up a
headless X server, registering as a window manager and compositing
manager, fighting with the X keyboard model, etc., but at the end of
the day it just works by shipping PNG-style compressed screenshots
over the wire in one direction, and input events over the wire in the
other. Perhaps surprisingly, the result is dramatically more usable
over remote links than vanilla X forwarding is, and it's very
maintainable. So +1 to this approach.

-n

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Travis numpy build failures on Python 3.x

2012-11-30 Thread Nathaniel Smith 
Let's try that again...

-- Forwarded message --
From: Nathaniel Smith 
Date: Fri, Nov 30, 2012 at 11:13 PM
Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x
To: Damon McDougall 


On Fri, Nov 30, 2012 at 10:25 PM, Damon McDougall
 wrote:
> We seem to have inherited these recently. I am questioning whether it
> is something caused by us or not. Can anybody build numpy/mpl under
> Python 3.x on their own machine successfully?

Not your bug.

Workaround:
  https://github.com/travis-ci/travis-cookbooks/issues/48#issuecomment-10843018

Also for context:
  https://github.com/numpy/numpy/issues/2761
  https://github.com/pypa/virtualenv/issues/359

-n

--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

2012-11-30 Thread Nathaniel Smith 
On Fri, Nov 30, 2012 at 11:40 PM, Michiel de Hoon  wrote:
> One package (Pysam) that I use a lot relies on Cython, and requires users to 
> install Cython before they can install Pysam itself. With Cython, is that 
> always the case? Will all users need to install Cython? Or is it sufficient 
> if only matplotlib developers install Cython?

You can set things up so that end-users don't have to install cython.
You just convert the .pyx files to regular .c files before
distributing your package. Numpy itself uses cython, but end-users
don't notice or care. (It's something more of a hassle for developers
to do things this way, and cython is very easy to install, so I don't
know if it's worth it. But it's certainly possible.)

-n

--
Keep yourself connected to Go Parallel: 
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

2012-12-03 Thread Nathaniel Smith 
On Mon, Dec 3, 2012 at 8:24 PM, Chris Barker - NOAA Federal
 wrote:
> On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom  wrote:
>> so there
>> are types in libpng, for example, that we don't actually know the size
>> of.  They are different on different platforms.  In C, you just include
>> the header.  In Cython, I'd have to determine the size of the types in a
>> pre-compilation step, or manually determine their sizes and hard code
>> them for the platforms we care about.
>
> yeah -- this is a tricky problem, however, I think you can follow what
> you'd do in C -- i.e. presumable the header define their own data
> types: png_short or whatever. The actually definition is filled in by
> the pre-processor. So I wonder if you can declare those types  in
> Cython, then have it write C code that uses those types, and it all
> gets cleared up at compile time -- maybe. The key is that when you
> declare stuff in Cython, that declaration is used to determine how to
> write the C code, I don't think the declarations themselves are
> translated.

Yeah, this isn't an issue in Cython, it's a totally standard thing
(though perhaps not well documented). When you write

  cdef extern from "png.h":
  ctypedef int png_short

or whatever, what you are saying is "the C compiler knows about a type
called png_short, which acts in an int-like fashion, so Cython, please
use your int rules when dealing with it". So this means that Cython
will know that if you return a png_short from a python function, it
should insert a call to PyInt_FromLong (or maybe PyInt_FromSsize_t? --
cython worries about these things so I don't have to). But Cython only
takes care of the Python<->C interface. It will leave the C compiler
to actually allocate the appropriate memory for png_shorts, perform C
arithmetic, coerce a png_short into a 'long' when necessary, etc.

It's kind of mind-bending to wrap your head around, and it definitely
does help to spend some time reading the C code that Cython spits out
to understand how the mapping works (it's both more and less magic
than it looks -- Python stuff gets carefully expanded, C stuff goes
through almost verbatim), but the end result works amazingly well.

>> It would at least make this a more fair comparison to have the Cython
>> code as Cythonic as possible.  However, I couldn't find any ways around
>> using these particular APIs -- other than the Numpy stuff which probably
>> does have a more elegant solution in the form of Cython arrays and
>> memory views.
>
> yup -- that's what I noticed right away -- I"m note sure it there is
> easier handling of file handles.

For the file handle, I would just write

  cdef FILE *fp = fdopen(file_obj.fileno(), "w")

and be done with it. This will work with any version of Python etc.

-n

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Experiments in removing/replacing PyCXX

2012-12-03 Thread Nathaniel Smith 
On Mon, Dec 3, 2012 at 11:50 PM, Chris Barker - NOAA Federal
 wrote:
> On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith  wrote:
>> For the file handle, I would just write
>>
>>   cdef FILE *fp = fdopen(file_obj.fileno(), "w")
>>
>> and be done with it. This will work with any version of Python etc.
>
> yeah, that makes sense -- though what if you want to be able to
> read_to/write_from a file that is already open, and in the middle of
> the file somewhere -- would that work?
>
> I just posted a question to the Cython list, and indeed, it looks like
> there is no easy answer to the file issue.

Yeah, this is a general problem with the Python file API, trying to
hook it up to stdio is not at all an easy thing. A better version of
this code would skip that altogether like:

cdef void write_to_pyfile(png_structp s, png_bytep data, png_size_t count):
fobj = png_get_io_ptr(s)
pydata = PyString_FromStringAndSize(data, count)
fobj.write(pydata)

cdef void flush_pyfile(png_structp s):
# Not sure if this is even needed
fobj = png_get_io_ptr(s)
fobj.flush()

# in write_png:
write_png_c(pix_buffer, width, height,
  NULL, file_obj, write_to_pyfile, flush_pyfile, dpi)

But this is a separate issue :-) (and needs further fiddling to make
exception handling work).

Or if you're only going to work on real OS-level file objects anyway,
you might as well just accept a filename as a string and fopen() it
locally. Having Python do the fopen just makes your life harder for no
reason.

-n

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] DeprecationWarnings in matplotlib effectively invisible (with proposed fix)

2012-12-05 Thread Nathaniel Smith 
On Wed, Dec 5, 2012 at 9:45 PM, Paul Ivanov  wrote:
> Hey everyone,
>
> In adding a deprecation warning in this pull request [1], Damon and I
> learned that DeprecationWarnings are ignored by default in Python 2.7
>
> This is rather unfortunate, and I outlined possible workarounds that I
> see in a commend on that PR [2].
>
> In trying to rectify this situation, I have created a
> MatplotlibDeperecationWarning class that inherits from UserWarning,
> which is *not* ignored by default. [3]
>
> 1. https://github.com/matplotlib/matplotlib/pull/1535
> 2. https://github.com/matplotlib/matplotlib/pull/1535#issuecomment-11061572
> 3. https://github.com/matplotlib/matplotlib/pull/1565

If you're defining your own warning class, you might consider using
FutureWarning instead of UserWarning.

We had a discussion about this issue for numpy recently:
  http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
What we eventually ended up with:
  http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html

-n

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] DeprecationWarnings in matplotlib effectively invisible (with proposed fix)

2012-12-10 Thread Nathaniel Smith 
On Wed, Dec 5, 2012 at 10:23 PM, Paul Ivanov  wrote:
> On Wed, Dec 5, 2012 at 1:52 PM, Nathaniel Smith  wrote:
>> If you're defining your own warning class, you might consider using
>> FutureWarning instead of UserWarning.
>>
>> We had a discussion about this issue for numpy recently:
>>   http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
>> What we eventually ended up with:
>>   http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
>
> Thanks for the pointers, Nathaniel. Though I think I disagree with
> continuing to use DeprecationWarnings for features that will go away
> and just break code - shouldn't users be given ample opportunity of
> coming changes without having to find out by having their code break
> at a future release?

Yeah, there aren't any perfect solutions here. That's why I didn't
express an opinion on what you ought to do :-).

Basically what the debate comes down to is, deprecation warnings are
useful to developers, and annoying and scary to users. (And users can
easily end up seeing them, e.g. if they use a package which depends on
matplotlib, and then upgrade matplotlib, their existing package may
suddenly start spewing scary warnings, and that package's developers
can't do anything about this because this version of matplotlib is
newer than anything that existed when they released their package.)
This problem becomes worse the lower your package is in the stack, and
the more widely used it is by third-party packages.

It's easier to tell developers how to turn on deprecation warnings
than it is to tell users how to turn them off, so that's why the
Python stdlib turned them off by default, and similarly numpy.

The main thing I took from this personally is that I went and added
'export PYTHONWARNINGS=default' to all my package's test scripts, to
ensure deprecation warnings would be enabled...

-n

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Github Downloads going away...

2012-12-14 Thread Nathaniel Smith 
On 14 Dec 2012 16:59, "Michael Droettboom"  wrote:
>
> Github has removed the ability to host binaries.  They've removed this
feature without any apparent notification except on their blog saying "it's
gone today".  And the suggested alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a Python 3.2
from Russell Owen in the near future.  So much for that.
>
> Any thoughts?  Do we go back to Sourceforge for our download hosting?  Is
anyone familiar with any other services?  Do we try to piggy-back on what
other scipy projects are doing?

I don't think other scipy projects are doing anything special here; numpy
and scipy never stopped using sourceforge. If you wanted to lead the way on
setting up some simple download hosting on S3 or whatever for scipy
projects then you could probably get numfocus to pay the hosting costs.
Alternatively I'd consider Google code before going back to sourceforge -
IME the service is similar overall but without sourceforge's horror of an
interface.

-n
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Github Downloads going away...

2012-12-23 Thread Nathaniel Smith 
On Sun, Dec 23, 2012 at 12:42 AM, Damon McDougall
 wrote:
> On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom  wrote:
>> On 12/16/2012 03:44 PM, Eric Firing wrote:
>>> On 2012/12/16 9:21 AM, Damon McDougall wrote:
>>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
>>>>  wrote:
>>>>> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>>>>>> sourceforge's horror of an interface.
>>>>> I'll second that.  Every time I go to Sourceforge, I have to figure out
>>>>> how in the world to download what I want (and I have to figure out which
>>>>> things *not* to click on too).
>>>> Ok sounds like there is a reasonable amount of resistance towards 
>>>> Sourceforge.
>>>>
>>>> Eric, when you suggest that NumFocus could 'provide hosting directly',
>>>> do you mean they would have the physical hardware to host the files,
>>>> or are you suggesting they provide the finances to seek hosting
>>>> elsewhere?
>>> I was thinking that perhaps NumFocus would be running a server that
>>> could provide the hosting.  Funding for an external service is also
>>> possible, though, and might make more sense.
>>
>> I'll definitely walk down the hall and talk to my local Numfocus board
>> member ;)
>
> At the 6th Annual Scientific Software Day here at UT Austin, I met and
> spoke to Travis Oliphant regarding funding for hosting our binaries.
> Travis has links with NumFOCUS and was eager to help the matplotlib
> community host binaries should we choose to not go with sourceforge or
> another free option.
>
> I'll need touch base with him again to get specifics, but I thought
> I'd just let everyone here know that that's still an option.
>
> To be honest with you, I'm thinking that if we only want to link to
> binaries from the matplotlib web page then sourceforge really doesn't
> sound like a bad option at all.

Or -- I'll just point this out one more time then leave the dead horse
alone :-) -- you could just register a project called
'matplotlib-downloads' on google code hosting, and have static URLs
that look like e.g.
  https://apa6e.googlecode.com/files/apa6e-v0.3.zip
and let Google foot the bill for reliable high-bandwidth CDN hosting.

-n

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Usefulness of Travis-CI

2013-01-16 Thread Nathaniel Smith 
On 16 Jan 2013 09:30, "Fernando Perez"  wrote:
>
> On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux
>  wrote:
>
> > Last but not least, maybe we can see what numfocus has to offer.
>
> Absolutely!  I'll be offline for two weeks, but others on the list can
> certainly propose this to numfocus on the list and we can look into
> what can be done, esp. in a way that could also help other projects as
> well.

When this has come up on the numfocus list before the status was, sure,
they can provide resources/funding if you can find someone to do the actual
work :-). If anyone is interested in putting in the time to solve this
problem properly then a lot of projects would be grateful I think...

-n
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: Moving plots out of axes

2013-03-15 Thread Nathaniel Smith 
On 15 Mar 2013 16:50, "Todd"  wrote:
> Within the axes constructor, the constructor would run through each of
these modules and store them as attributes with the same name as the
function and the function itself being the contents.  At least if me
understanding is correct, this would make them behave as methods (since
they are already set up to take an axes instance as their first argument).

This won't work as described - the function -> unbound method -> bound
method magic only happens for attributes that aren't found in the object
dict, when  lookup falls back on the type dict. You'll want to inject the
functions into the Axes type object, either via a metaclass constructor or
just by hand after the type is created.

-n
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Refactoring the axes module

2013-06-29 Thread Nathaniel Smith 
On Sat, Jun 29, 2013 at 8:13 PM, Damon McDougall
 wrote:
> To reiterate, remember that you'll need to nuke your previous local install.  
> Installing over an existing mpl distribution will cause problems.  This is 
> because `python setup.py install` will not remove the old axes.py for you.

NB that this is in general a good reason to make a habit of using 'pip
install .' instead of 'python setup.py install'. pip *will* nuke old
versions for you, and thus gives you a better chance of importing the
code that was actually shipped.

-n

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating copyright model in license

2013-07-02 Thread Nathaniel Smith 
On Tue, Jul 2, 2013 at 8:31 PM, Michael Droettboom  wrote:
> As many of you are well aware, John Hunter has been the sole copyright
> holder on matplotlib from the beginning.  I'm sorry it's taken nearly a year
> to do this (as can often happen in sad situations like this), but I think we
> do need to address it going forward.
>
> I have a PR for this change in #2195.
>
> Heavily influenced by the IPython licensing, I propose to move us to a
> shared copyright model, where authors retain copyright on their individual
> contributions, but the code base as a whole belongs to the entire community
> of contributors.

Purely as a legal matter, I believe that what you mean is, you're
suggesting updating the documentation in the source files to more
accurately reflect the current model? Unless everyone's been signing
written documents transferring their copyright (which is the only
effective way to transfer copyright in the US and AFAIK most other
jurisdictions), then right now matplotlib's copyright is owned by the
community of contributors, and has been so long as there have been
contributors.

-n

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

2013-07-22 Thread Nathaniel Smith 
On Sun, Jul 21, 2013 at 2:48 AM, Chris Beaumont  wrote:
> I don't fully agree with Eric that changing the defaults should be treated
> as an API break -- yes, it may irritate a minority of users, but their code
> will still run. I'd flip around your argument for the role of rcParams and
> customization: the majority user is probably someone who doesn't know much
> about rcParams, or all the ways plots can be customized. *That* is the use
> case to optimize, not the "legacy" users invested in the current style.

As one small data point here, from a really excellent paper reviewing
the trade-offs in colormap design and deriving the "cool-warm"
colormap as a good default:

"This diverging color map interpolation has also been added to
ParaView, a free, open-source end-user scientific visualization
application, and was first featured in the 3.4 release in October
2008. Although ParaView does let users change the color map and there
is no way to track who does so, in our experience few users actually
do this. In the nearly 3000 messages on the ParaView users’ mailing
list from October 2008 to July 2009, there was no mention of the
change of color map from rainbow to cool-warm diverging. Users seem to
have accepted the change with little notice despite most users’
affinity for rainbow color maps."

- http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf

It absolutely should be easy to go back to the way things were, for
reproduction of old carefully hand-tweaked plots etc. But, there are
cases where our defaults are demonstrably terrible; and, these
defaults are demonstrably the direct cause of people producing
unnecessarily inferior plots; and, it's been many years now that this
situation has continued out and nothing has happened because we don't
want to be hasty. At some point we need to bite the bullet and make
these things better.

-n

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

2013-07-22 Thread Nathaniel Smith 
On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom  wrote:
> This is why I suggested that the best way forward is to implement some sort
> of easy styling functionality (like what Tony Yu has submitted in #2236,
> though I haven't had a chance to look at it yet), and make it explicit for
> the user to select a new style.  This could be either by adding a new line
> to the top of the plotting script, or adding a single switch in the global
> matplotlibrc file.  But there needs to be an explicit turning on of this.

Are you saying that the defaults can't change (i.e., any changes must
be opt-in), or just that there needs to be some transition period
before the defaults can change and a simple way to opt out afterwards?
I agree with the latter :-).

I have mixed feelings about a full "styling system" though, since, how
many coherent "styles" for plots are there? If we provide a menu of
plot styles right in the main documentation then it seems like it
would just end up being an excuse for people to procrastinate playing
with the different settings, and increase the number of manuscripts I
read that have baroque and poorly chosen colormaps, plots that use the
"ggplot as drawn by xkcd" style, etc. And what value would it really
add? IMO we have a responsibility to nudge users towards making good
plots, and that means having good defaults, and perhaps also means
encouraging people to use them instead of just picking things that
optimize some vague aesthetic judgement at 2am before the submission
deadline...

How about
  mpl.approximately_emulate()
which sets the defaults to whatever version of matplotlib is named?
That could be used a-priori by people who want to future-proof their
scripts, is very easy to add after the fact if you upgrade matplotlib
and discover some plot of yours has been broken, and also encompasses
the "future" functionality (you could ask your current matplotlib to
emulate the next version, if it knows how).

The advantage of a limited API that just takes a version number is not
just that it's simpler on the backend (no need for a system to name
and discover styles, etc. etc.), but it can also easily encapsulate
knowledge like "the defaults were the same from 0.99 through 1.2, so
if anything in that range is requested use *this* file, but then in
1.3...". This means that if a user knows that their plot worked on 1.1
but broke on 1.4, they don't have to care -- they can just say
  mpl.approximately_emulate("1.1")
instead of having to somehow figure out that the right call is:
  mpl.style("0.99-through-1.2")

-n

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Minimum python version 2.6 vs 2.7

2014-05-07 Thread Nathaniel Smith 
It is also technically possible to use a drop-in fallback
implementation on older pythons, e.g.:
  https://github.com/pydata/patsy/blob/master/patsy/compat.py#L120
  https://github.com/pydata/patsy/blob/master/patsy/compat_ordereddict.py

-n

On Wed, May 7, 2014 at 4:03 PM, Federico Ariza  wrote:
> Hello
>
> Working on the MEP22 I would like to use an OrderedDict but it is only
> natively available from python 2.7
>
> Are there any plans to remove 2.6 for matplotlib 1.5?
>
> If not. I will just use a list with dicts inside, not as elegant but works.
>
> Thanks
> Federico
>
>
> --
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] numpy indexing changes

2014-06-10 Thread Nathaniel Smith 
On 10 Jun 2014 19:07, "Eric Firing"  wrote:
>
> This is just a heads-up: some indexing changes in the numpy 1.9rc break
> matplotlib, as revealed in the mpl tests; there is a discussion on the
> numpy-discussion list about what to do about it.  It looks like they
> will back off on the changes and put in deprecations, giving us time to
> modify mpl.

Yes, and please do test the numpy betas/RCs - we're trying to do a better
job at not breaking downstreams on every release, but it's easy for us to
miss breakages, or to think we've fixed something in the second beta but be
wrong about this. If you notice *anything* broken by the betas then please
at least let us know (even if the code is easy to fix on tour end), and
when doing so please use the magic word "regression" so that we can assign
it appropriate priority.

-n
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Numpy-discussion] Questions about fixes for 1.9.0rc2

2014-07-04 Thread Nathaniel Smith 
On Fri, Jul 4, 2014 at 9:48 PM, Charles R Harris
 wrote:
>
> On Fri, Jul 4, 2014 at 2:41 PM, Nathaniel Smith  wrote:
>>
>> On Fri, Jul 4, 2014 at 9:33 PM, Charles R Harris
>>  wrote:
>> >
>> > On Fri, Jul 4, 2014 at 2:09 PM, Nathaniel Smith  wrote:
>> >>
>> >> On Fri, Jul 4, 2014 at 9:02 PM, Ralf Gommers 
>> >> wrote:
>> >> >
>> >> > On Fri, Jul 4, 2014 at 10:00 PM, Charles R Harris
>> >> >  wrote:
>> >> >>
>> >> >> On Fri, Jul 4, 2014 at 1:42 PM, Charles R Harris
>> >> >>  wrote:
>> >> >>>
>> >> >>> Sebastian Seberg has fixed one class of test failures due to the
>> >> >>> indexing
>> >> >>> changes in numpy 1.9.0b1.  There are some remaining errors, and in
>> >> >>> the
>> >> >>> case
>> >> >>> of the Matplotlib failures, they look to me to be Matplotlib bugs.
>> >> >>> The
>> >> >>> 2-d
>> >> >>> arrays that cause the error are returned by the overloaded
>> >> >>> _interpolate_single_key function in CubicTriInterpolator that is
>> >> >>> documented
>> >> >>> in the base class to return a 1-d array, whereas the actual
>> >> >>> dimensions
>> >> >>> are
>> >> >>> of the form (n, 1). The question is, what is the best work around
>> >> >>> here
>> >> >>> for
>> >> >>> these sorts errors? Can we afford to break Matplotlib and other
>> >> >>> packages on
>> >> >>> account of a bug that was previously accepted by Numpy?
>> >> >
>> >> >
>> >> > It depends how bad the break is, but in principle I'd say that
>> >> > breaking
>> >> > Matplotlib is not OK.
>> >>
>> >> I agree. If it's easy to hack around it and issue a warning for now,
>> >> and doesn't have other negative consequences, then IMO we should give
>> >> matplotlib a release or so worth of grace period to fix things.
>> >
>> >
>> > Here is another example, from skimage.
>> >
>> > ==
>> > ERROR: test_join.test_relabel_sequential_offset1
>> > --
>> > Traceback (most recent call last):
>> >   File "X:\Python27-x64\lib\site-packages\nose\case.py", line 197, in
>> > runTest
>> > self.test(*self.arg)
>> >   File
>> >
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\tests\test_join.py",
>> > line 30, in test_relabel_sequential_offset1
>> > ar_relab, fw, inv = relabel_sequential(ar)
>> >   File
>> > "X:\Python27-x64\lib\site-packages\skimage\segmentation\_join.py",
>> > line 127, in relabel_sequential
>> > forward_map[labels0] = np.arange(offset, offset + len(labels0) + 1)
>> > ValueError: shape mismatch: value array of shape (6,) could not be
>> > broadcast
>> > to indexing result of shape (5,)
>> >
>> > Which is pretty clearly a coding error. Unfortunately, the error is in
>> > the
>> > package rather than the test.
>> >
>> > The only easy way to fix all of these sorts of things is to revert the
>> > indexing changes, and I'm loathe to do that. Grrr...
>>
>> Ugh, that's pretty bad :-/. Do you really think we can't use a
>> band-aid over the new indexing code, though?
>
>
> Yeah, we can. But Sebastian doesn't have time and I'm unfamiliar with the
> code, so it may take a while...

Fair enough!

I guess that if what are (arguably) bugs in matplotlib and
scikit-image are holding up the numpy release, then it's worth CC'ing
their mailing lists in case someone feels like volunteering to fix
it... ;-).

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot_directive, context and multiple plots

2014-07-14 Thread Nathaniel Smith 
Wouldn't a better default be to just close all figures when they're
displayed? It can't be common that someone wants to show the same plot
repeatedly (and if they do that could have an option)...?

-n
On 14 Jul 2014 22:16, "Matthew Brett"  wrote:

> Hi,
>
> I am happily using `plot_directive`, but I've run into an
> inconvenience when using the 'context' option.  Consider this rst
> file:
>
> ```
> ###
> A title
> ###
>
> .. plot::
> :context:
>
> import matplotlib.pyplot as plt
> plt.plot(range(10))
>
> Then some text.
>
> .. plot::
> :context:
>
> plt.figure()
> plt.plot(range(5), 'r')
> ```
>
> In the second panel you see plots for both the first figure and the
> second figure, because the underlying code is making this call:
>
> fig_managers = _pylab_helpers.Gcf.get_all_fig_managers()
>
> to find all current figures, finding the first and the second figure,
> and rendering both.  I think this is unlikely to be what the user
> expects (it confused me), but I wasn't sure what the best way to work
> round it was.  I considered adding another option like `:myfigs: true`
> to the directive which would only pick up figures I create using the
> current code block - is there a better way?
>
> Cheers,
>
> Matthew
>
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] getting a DOI for v1.4.0

2014-08-26 Thread Nathaniel Smith 
On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell  wrote:
> Hey all,
>
> Github has made it possible to get a DOI for a release (
> https://guides.github.com/activities/citable-code/ ).
>
> I am inclined to do this for 1.4.0.  I think doing this is a good
> first step towards being good (leading?) citizens in the reproducible
> science community.

FYI, since I just spent half an hour figuring this out:

To use the Zenodo magic DOI feature you have to:

1) Attach Zenodo to the repository like it says in the tutorial.

2) Create a "release" on github, which is *not* the same as a tag,
even though the github UI claims that they are identical. See all of
these releases that are listed on your github releases page?
https://github.com/matplotlib/matplotlib/releases
None of them are actually releases in the sense that Zenodo wants.

Here's an example of what it looks like after you've made Zenodo happy:
https://github.com/pydata/patsy/releases

The trick is to click "draft a new release", and then type in the name
of your existing tag. You can add some release notes if desired, which
will be copied to the archived Zenodo page, which will look like this:
   https://zenodo.org/record/11445
(The text "See release notes: " is what I typed into the Github
release description box.) And then click "Publish release" obviously.
This will convert your existing release tag into an *extra-special*
release tag, which AFAICT works the same as before except that (a) it
gets snazzier graphics in the github UI, and (b) Zenodo will archive
it.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot-OO convergence

2014-09-28 Thread Nathaniel Smith 
n Sun, Sep 28, 2014 at 12:40 AM, Eric Firing  wrote:
> One of the biggest causes of controversy in mpl, and of difficulty in
> teaching and learning mpl, is the divide between pyplot and the rest of
> the library.  There are at least two aspects:
>
> 1) plt.title() versus ax.set_title(), etc; that is, all the clunky
> getters and setters on the OO side.  JDH used to note that they were a
> side-effect of his C++ heritage, and that he probably wouldn't have used
> them if he had had more Python experience when he started mpl.
>
> 2) For interactive use, such as in the ipython console, one really wants
> pyplot's draw_if_interactive() functionality; one doesn't want to have
> to type explicit plt.draw() commands.  Worse, plt.draw() operates on the
> current figure, which might not be the figure that one just updated with
> "ax2.set_title('the other plot')".

I'm not very familiar with matplotlib's guts, but as a user I agree
100%. I'm sure there are Reasons why 90% of pylot functions aren't
simply:

  def foo(*args, **kwargs):
  return gca().foo(*args, **kwargs)

but I have no idea what they are, so whenever I have to memorize two
different APIs for doing the same thing it ends up feeling like a
pointless waste of time.

> I think that both of these speed bumps can be removed fairly easily, in
> an entirely backwards-compatible way.
>
> The first is just a matter of propagating some shorter-form pyplot
> function names back to Axes and Figure.  This idea is mentioned at the
> end of MEP 13, as an alternative to properties.

I'd much rather write ax.xlim(...) than ax.xlim =  The use of that
many magical properties feels unpythonic to me (too much magic!), and
pyplot.xlim() isn't going anywhere. So, it would still mean that
everyone has to learn both the pyplot and the OO APIs separately.
Learning 1 API is always going to be easier than learning two
different APIs, no matter how fancy and polished you make the second
one.

> The second requires accepting some behavior in the Axes and Figure
> classes that is conditional on the backend and the interactive state.  I
> think it would look *roughly* like this:
>
> Add a method to Figure:
>
> def draw_if_interactive():
>  if not is_interactive:
>  return
>  if not isinstance(self.canvas, interactive_canvases):
>  return
>  self.canvas.draw()
>
> Append this method to suitable Figure methods such as suptitle().
>
> Add a method to Axes:
>
> def draw_if_interactive():
>  self.figure.draw_if_interactive()
>
> Append this method to suitable Axes methods--all those that execute
> changes, or at least those with corresponding pyplot functions.

In most scene-graphy frameworks, triggering redraws is simply not the
job of the mutator; it's the job of the rendering system to observe
the model for changes. (Using "observe" in the "observer pattern"
sense.) In this approach, every time an artist changes you'd call some
"note_change()" method, which would then propagate upwards. And then
some top-level piece of logic (the canvas or backend, I guess?) would
be responsible for deciding whether it wanted to respond to these
changes. So... very similar to what you're proposing, though with
different terminology :-).

> Some additional logic (either a kwarg, or temporary manipulation of the
> "interactive" flag, or of an Axes instance flag) would be needed to
> block the drawing at intermediate stages--e.g., when boxplot is drawing
> all its bits and pieces.

Presumably this would be a context manager, 'with artist.hold_changes(): ...'

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matlab parula colormap

2014-10-21 Thread Nathaniel Smith 
On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig
 wrote:
> Hi,
>
> Matlab is now shipping with a new default colormap, named "parula"
> [1,2]. It is meant to overcome the many issues of the current default
> "jet". It seems that the RGB values of this new colormap are already
> onnline [3].
>
> So my question is:
> * is it worth adding this parula in the Matplotlib colormap collection ?
> (I think it is)
> * is there any copyright issue with that ? (I have no idea how
> copyrightable a list of numbers is !)

The general rule is that copyright requires "creative expression".
This is a pretty marginal case at best, since that the colormap
appears to have been derived by solving an optimization problem, but
worst case we could always re-solve that optimization problem
ourselves. (I've played before with using CAM02-UCS to automatically
generate perceptually uniform colormaps - it's not terribly difficult
to do.)

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matlab parula colormap

2014-10-21 Thread Nathaniel Smith 
On Tue, Oct 21, 2014 at 8:09 PM, Eric Firing  wrote:
> On 2014/10/21, 6:27 AM, Nathaniel Smith wrote:
>> On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig
>>  wrote:
>>> Hi,
>>>
>>> Matlab is now shipping with a new default colormap, named "parula"
>>> [1,2]. It is meant to overcome the many issues of the current default
>>> "jet". It seems that the RGB values of this new colormap are already
>>> onnline [3].
>>>
>>> So my question is:
>>> * is it worth adding this parula in the Matplotlib colormap collection ?
>>> (I think it is)
>>> * is there any copyright issue with that ? (I have no idea how
>>> copyrightable a list of numbers is !)
>>
>> The general rule is that copyright requires "creative expression".
>> This is a pretty marginal case at best, since that the colormap
>> appears to have been derived by solving an optimization problem, but
>> worst case we could always re-solve that optimization problem
>> ourselves. (I've played before with using CAM02-UCS to automatically
>> generate perceptually uniform colormaps - it's not terribly difficult
>> to do.)
>>
> There are additional considerations, such as working well for the most
> common form of color-blindness, providing as much resolution as
> possible, and being aesthetically pleasing to most people.

Sure, but the first two of those are just extra constraints on the optimization.

Apparently they'll be making another blog post soon describing the
actual constraints they used.

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib on Android

2014-11-07 Thread Nathaniel Smith 
On 7 Nov 2014 14:44, "Apps Embedded"  wrote:
>
> Hi,
>
> You are right.
> Maybe a "Science Console" name should simply do it.
>
> And for the Python trademark, is there any legal issue with charging an
Android app using the python langage ?

This is like me asking you whether I can legally call something "android"
because you are android developers and thus totally qualified to speak on
behalf of Google's legal department.

-n
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

2014-11-21 Thread Nathaniel Smith 
On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale  wrote:
> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson  wrote:
>>
>> Please use this thread to discuss the best choice for a new default
>> matplotlib colormap.
>>
>> This follows on from a discussion on the matplotlib-devel mailing list
>> entitled "How to move beyond JET as the default matplotlib colormap".
>
>
> I remember reading a (peer-reviewed, I think) article about how "jet" was a
> very unfortunate choice of default. I can't find the exact article now, but
> I did find some other useful ones:
>
> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
> http://www.sandia.gov/~kmorel/documents/ColorMaps/
> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf

Those are good articles. There's a lot of literature on the problems
with "jet", and lots of links in the matplotlib issue [1]. For those
trying to get up to speed quickly, MathWorks recently put together a
nice review of the literature [2]. One particularly striking paper
they cite studied a group of medical students and found that (a) they
were used to/practiced at using jet, (b) when given a choice of
colormaps they said that they preferred jet, (c) they nonetheless made
more *medical diagnostic errors* when using jet than with better
designed colormaps (Borkin et al, 2011).

I won't suggest a specific colormap, but I do propose that whatever we
chose satisfy the following criteria:

- it should be a sequential colormap, because diverging colormaps are
really misleading unless you know where the "center" of the data is,
and for a default colormap we generally won't.

- it should be perceptually uniform, i.e., human subjective judgements
of how far apart nearby colors are should correspond as linearly as
possible to the difference between the numerical values they
represent, at least locally. There's lots of research on how to
measure perceptual distance -- a colleague and I happen to have
recently implemented a state-of-the-art model of this for another
project, in case anyone wants to play with it [3], or just using
good-old-L*a*b* is a reasonable quick-and-dirty approximation.

- it should have a perceptually uniform luminance ramp, i.e. if you
convert to greyscale it should still be uniform. This is useful both
in practical terms (greyscale printers are still a thing!) and because
luminance is a very strong and natural cue to magnitude.

- it should also have some kind of variation in hue, because hue
variation is a really helpful additional cue to perception, having two
cues is better than one, and there's no reason not to do it.

- the hue variation should be chosen to produce reasonable results
even for viewers with the more common types of colorblindness. (Which
rules out things like red-to-green.)

And, for bonus points, it would be nice to choose a hue ramp that
still works if you throw away the luminance variation, because then we
could use the version with varying luminance for 2d plots, and the
version with just hue variation for 3d plots. (In 3d plots you really
want to reserve the luminance channel for lighting/shading, because
your brain is *really* good at extracting 3d shape from luminance
variation. If the 3d surface itself has massively varying luminance
then this screws up the ability to see shape.)

Do these seem like good requirements?

-n

[1] https://github.com/matplotlib/matplotlib/issues/875
[2] 
http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
[3] https://github.com/njsmith/pycam02ucs ; install (or just run out
of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
the perceptual distance between two RGB colors. It's also possible to
use the underlying color model stuff to do things like generate colors
with evenly spaced luminance and hues, or draw 3d plots of the shape
of the human color space. It's pretty fun to play with :-)

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Better defaults all around?

2014-11-21 Thread Nathaniel Smith 
Hi all,

Since we're considering the possibility of making a matplotlib 2.0
release with a better default colormap, it occurred to me that it
might make sense to take this opportunity to improve other visual
defaults.

Defaults are important. Obviously for publication graphs you'll want
to end up tweaking every detail, but (a) not everyone does but we
still have to read their graphs, and (b) probably only 1% of the plots
I make are for publication; the rest are quick one-offs that I make
on-the-fly to help me understand my own data. For such plots it's
usually not worth spending much/any time tweaking layout details, I
just want something usable, quickly. And I think there's a fair amount
of low-hanging improvements possible.

Batching multiple visual changes like this together seems much better
than spreading them out over multiple releases. It keeps the messaging
super easy to understand: "matplotlib 2.0 is just like 1.x, your code
will still work, the only difference is that your plots will look
better by default". And grouping these changes together makes it
easier to provide for users who need to revert back to the old
defaults -- it's easy to provide simple binary choice between "before
2.0" versus "after 2.0", harder to keep track of a bunch of different
changes spread over multiple releases.

Some particular annoyances I often run into and that might be
candidates for changing:

- The default method of choosing axis limits is IME really, really
annoying, because of the way it tries to find "round number"
boundaries. It's a clever idea, but in practice I've almost never seen
this pick axis limits that are particularly meaningful for my data,
and frequently it picks particularly bad ones. For example, suppose
you want to plot the spectrum of a signal; because of FFT's preference
for power-of-two sizes works it's natural to end up with samples
ranging from 0 to 255. If you plot this, matplotlib will give you an
xlim of (0, 300), which looks pretty ridiculous. But even worse is the
way this method of choosing xlims can actually obscure data -- if the
extreme values in your data set happen to fall exactly on a "round
number", then this will be used as the axis limits, and you'll end up
with data plotted directly underneath the axis spine. I frequently
encounter this when making scatter plots of data in the 0-1 range --
the points located at exactly 0 and 1 are very important to see, but
are nearly invisible by default. A similar case I ran into recently
was when plotting autocorrelation functions for different signals. For
reference I wanted to include the theoretically ideal ACF for white
noise, which looks like this:
plt.plot(np.arange(1000), [1] + [0] * 999)
Good luck reading that plot!

R's default rule for deciding axis limits is very simple: extend the
data range by 4% on each side; those are your limits. IME this rule --
while obviously not perfect -- always produces something readable and
unobjectionable.

- Axis tickmarks should point outwards rather than inwards: There's
really no advantage to making them point inwards, and pointing inwards
means they can obscure data. My favorite example of this is plotting a
histogram with 100 bins -- that's an obvious thing to do, right? Check
it out:
  plt.hist(np.random.RandomState(0).uniform(size=10), bins=100)
This makes me do a double-take every few months until I remember
what's going on: "WTF why is the bar on the left showing a *stacked*
barplot...oh right those are just the ticks, which happen to be
exactly the same width as the bar." Very confusing.

Seaborn's built-in themes give you the options of (1) no axis ticks at
all, just a background grid (by default the white-on-light-grey grid
as popularized by ggplot2), (2) outwards pointing tickmarks. Either
option seems like a better default to me!

- Default line colors: The rgbcmyk color cycle for line plots doesn't
appear to be based on any real theory about visualization -- it's just
the corners of the RGB color cube, which is a highly perceptually
non-uniform space. The resulting lines aren't terribly high contrast
against the default white background, and the different colors have
varying luminance that makes some lines "pop out" more than others.

Seaborn's default is to use a nice isoluminant variant on matplotlib's default:
   http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
ggplot2 uses isoluminant colors with maximally-separated hues, which
also works well. E.g.:
   
http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png

- Line thickness: basically every time I make a line plot I wish the
lines were thicker. This is another thing that seaborn simply changes
unconditionally.

In general I guess we could do a lot worse than to simply adopt
seaborn's defaults as the matplotlib defaults :-) Their full list of
overrides can be seen here:
   https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
   https://githu

Re: [matplotlib-devel] Better defaults all around?

2014-11-25 Thread Nathaniel Smith 
On 22 Nov 2014 02:22, "Benjamin Root"  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better defaults all around?

2014-11-26 Thread Nathaniel Smith 
On Wed, Nov 26, 2014 at 9:30 AM, Todd  wrote:
> On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith  wrote:
>>
>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>> appear to be based on any real theory about visualization -- it's just
>> the corners of the RGB color cube, which is a highly perceptually
>> non-uniform space. The resulting lines aren't terribly high contrast
>> against the default white background, and the different colors have
>> varying luminance that makes some lines "pop out" more than others.
>>
>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>> default:
>>
>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>> also works well. E.g.:
>>
>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
> About this, I am not expert so forgive me if this is nonsensical.  However,
> it would seem to me that these requirements are basically the same as the
> requirements for the new default colormap that prompted this whole
> discussion.  So, rather than create two inconsistent set of colors that
> accomplish similar goals, might it be better to instead use the default
> colormap for the line colors?  You could pick "N" equally-spaced colors from
> the colormap and use those as the line colors.

The main differences in requirements are:
- for the color cycle, you want isoluminant colors, to avoid the issue
where one line is glaring bright red and one is barely-visible-grey.
For general-purpose 2d colormaps, though, you almost always want the
luminance to vary to help distinguish colors from each other.
- for the color cycle, there's no problem with using widely separated
hues -- in fact it's usually better b/c it increases contrast between
the different items, and there's no need to communicate an ordering
between them. But if you try to use the whole hue space in a colormap
then you end up with the much-loathed jet.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Better defaults all around?

2014-11-27 Thread Nathaniel Smith 
On Thu, Nov 27, 2014 at 9:54 AM, Todd  wrote:
>
> On Nov 26, 2014 10:04 PM, "Nathaniel Smith"  wrote:
>>
>> The main differences in requirements are:
>> - for the color cycle, you want isoluminant colors, to avoid the issue
>> where one line is glaring bright red and one is barely-visible-grey.
>> For general-purpose 2d colormaps, though, you almost always want the
>> luminance to vary to help distinguish colors from each other.
>
> If you used isoluminance colors for the lines, wouldn't that mean a plot
> printed in grayscale would have all lines be the same shade of gray?

Yes. But IME it's very difficult to use greyscale alone to distinguish
between multiple plot lines no matter what: you can't go much beyond 2
lines before you either end up with hard-to-see lines (b/c they don't
have enough contrast with the white background) or the lines become
nigh-indistinguishable ("which one is the slightly-darker grey?"). And
if you have substantial luminance variation to make the greyscale
work, then the color images end up looking really weird (the scarlet
versus faint-yellow problem, where you end up emphasizing one set of
data over another -- emphasis should be done on purpose! in
matplotlib's current color cycle the yellow and cyan tend to
disappear).

If you're worried about greyscale then IMHO you should use different
line styles (solid/dashed/dotted/...) and/or use solid black for
everything and label the lines directly.

Which isn't to say that there's never any value in picking line colors
from a colormap, it's just more complicated than it seems :-).

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

2015-01-08 Thread Nathaniel Smith 
On Tue, Jan 6, 2015 at 2:37 AM, Maximilian Albert
 wrote:
> Happy new year everyone!
>
> Apologies for the long silence. I was snowed in with work before Christmas
> and then mostly cut off from the internet for the past two weeks.
> Fortunately, I had a chance over the holidays to flesh out the GUI which I
> mentioned in my previous email. You can find it here:
>
>https://github.com/maxalbert/colormap-selector
>
> Basically, it allows you to pick the start/end color of a colormap from two
> cross sections in CIELab space and interpolates those colors linearly (see
> the README file for more details).

There's a downside to this approach for the kinds of colormaps we've
been talking about in this thread, where we want both a large
lightness range plus a colorful result. The problem is that the way
color space is shaped, you can't simultaneously have both high
saturation (colorfulness) *and* high/low lightness. So if you pick
your extreme points to be near black and white, then they can only
have a slight tinting of color, and then if you linearly interpolate
between these, then you end up with slightly tinted greyscale.

Colormaps like YlGnBu or cubehelix or parula are designed to start out
with low saturation, then as they move into the middle of the
lightness scale they arc outwards, then arc back in again.

This is a lot easier to visualize (e.g. by playing with the script I
posted upthread) than it is to explain in text :-). Like, if you do
viscm(YlGnBu_r) and look at the plot in the lower-right then it's
clear that it's not a simple straight line in (J'/K, a', b') space
(which is a higher-tech analogue to L* a* b* space).

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

2015-01-08 Thread Nathaniel Smith 
On Thu, Jan 8, 2015 at 10:30 PM, Maximilian Albert
 wrote:
> Hi Nathaniel,
>
>>
>> > Basically, it allows you to pick the start/end color of a colormap from
>> > two
>> > cross sections in CIELab space and interpolates those colors linearly
>> > (see
>> > the README file for more details).
>>
>> There's a downside to this approach for the kinds of colormaps we've
>> been talking about in this thread, where we want both a large
>> lightness range plus a colorful result. The problem is that the way
>> color space is shaped, you can't simultaneously have both high
>> saturation (colorfulness) *and* high/low lightness. So if you pick
>> your extreme points to be near black and white, then they can only
>> have a slight tinting of color, and then if you linearly interpolate
>> between these, then you end up with slightly tinted greyscale.
>
>
> You raise an excellent point here. It explains nicely what I have
> experienced while playing with my GUI. Indeed, I found that a simple linear
> interpolation did not result in totally satisfactory colormaps (see my
> previous reply to Federico). I couldn't quite explain why, but your
> explanation makes this clear.
>
> One exception I encountered is an interpolation between dark blue and yellow
> as in the attached screenshot (which I hope makes it through to the mailing
> list) - probably because it mostly avoids the low-saturation (grey-ish)
> region of the color space.

I guess this probably also has to do with another weird feature of how
the colorspace is shaped. You'll often see pictures in books that
illustrate it like two cones:
   
http://www.tvtechnology.com/BE_Files/uploads/2013/05/ColorTopCones-305be18.jpg
which does capture the general idea that your range of saturations is
widest when lightness is in the middle, and narrows down when you move
towards black or white. But it's actually a bit more complicated than
that -- the actual shape is sorta lumpy, more like the picture here:
http://www.gamutvision.com/
In particular, you can have pretty-saturated blues even at very low
lightnesses, and pretty-saturated yellows even at high lightnesses.
E.g. there literally does not exist a dark red that's as intense as
the most intense dark blue.

So this makes dark-blue-to-light-yellow the obvious way to go if you
want a dark-to-light colormap that is also colorful.

I don't think it's a coincidence that parula does exactly this :-)

There is an obvious degree of freedom here though -- the color wheel
is, like, a wheel, so if you want to go from blue to yellow you can do
that either clockwise or counterclockwise, i.e., you can go through
green or you can go through red. Parula goes via green (and so does
matplotlib's YlGnBu, for that matter). If we want to have a
distinctive colormap that people won't confuse with Matlab(R)(TM) then
maybe we should make a blue-purple-red-yellow one.

And in fact, this is probably theoretically optimal! As another weird
quirk of how color works, the 4 focal colors (red/green/blue/yellow)
are not actually at right angles to each other on the hue circle --
see the lower diagram on this figure:


https://books.google.co.uk/books?id=MZ-TM0f2twAC&lpg=PA323&ots=XB_jHt0wz1&dq=%22the%20cie%20colour%20appearance%20model%22%20hunt%20and%20pointer&pg=PA307#v=onepage&q&f=false

>From yellow-to-blue via red is a ~213 degree angle, while
yellow-to-blue-via-green is only a ~147 degree angle (in a space where
we define our "hue angle" based on perceptual
just-noticeable-differences). So a blue-purple-red-yellow colormap
should theoretically have higher perceptual resolution than a
blue-green-yellow colormap.

> But I agree with you that using a curved, rather
> than linear, interpolation can probably yield better results.
>
> It sounds like you have a good deal of experience with various color spaces
> and colormaps. Do you have an idea for a good "recipe" how to pick a curve
> in a given colorspace that leads to a satisfactory colormap?

I haven't tried it yet, but my first idea would be to say that I want
a linear ramp in lightness (CIECAM02's "J"), and a linear ramp in hue
(CIECAM02's "h"), that starts at blue and ends at yellow, and then run
an optimizer to try and find a set of colorfulness values (CIECAM02's
"M") that maximize some criteria, i.e.:
  -- need to stay within the sRGB gamut
  -- the points should be as close to equidistant as possible
(measured in CAM02-UCS space)
  -- the total arc should be as long as possible (measured in
CAM02-UCS space) (this forces it to use the large colorfulness values
when available)
  -- and maybe some sort of wiggliness penalty (integral of squared
third derivative or something?) to smooth it out a bit

Then it just becomes an optimization problem -- given any proposed set
of JMh values we can convert into sRGB to check the gamut, convert in
CAM02-UCS to check the distances, etc., and compute an objective
function.

> My first idea
> was to change the interpolating line to a circular arc passing

Re: [matplotlib-devel] Capitalization of Matplotlib

2015-02-16 Thread Nathaniel Smith 
On Feb 16, 2015 10:35 AM, "Eric Firing"  wrote:
>
> On 2015/02/16 8:16 AM, Benjamin Root wrote:
> > I am in the final rounds of edits for my book and a question has come up
> > between me and the editors. When should the matplotlib be capitalized?
> >
> > 1) never
> > 2) mostly never (even in the beginning of a sentence), except when used
> > in a title
> > 3) usually never, except at the beginning of a sentence and in titles
> > 4) capitalize when referring to the project, not capitalized when
> > referring to the package
> > 5) usually capitalize like a proper noun except in code examples
> >
> > Thoughts?
> > Ben Root
>
> Do numpy and scipy have a consistent policy that could be used as a
> model?

Not that I'm aware of. I tend to write "numpy" in prose (somewhere in the
1-3 range in Ben's terminology) because that's what I write in code. But as
I recently discovered, when writing for a general audience (e.g., "people
reading your job application") it is crucial to write NumPy so that it
doesn't look like it's pronounced nump-ee. :-)

Matplotlib cleverly avoids that particular problem through its surfeit of
stops, but if we want a general cross-project rule then it might be a hint.

-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=190641631&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy and the color revolution

2015-02-18 Thread Nathaniel Smith 
On Feb 16, 2015 3:39 PM, "Eric Firing"  wrote:
>
> On 2015/02/16 1:29 PM, Michael Waskom wrote:
>
> > Nathaniel's January 9 message in that thread (can't figure out how to
> > link to it in the archives) had a suggestion that I thought was very
> > promising, to do something similar to Parula but rotate around the hue
> > circle the other direction so that the hues would go blue - purple - red
> > - yellow. I don't think we've seen an example of exactly what it would
> > look like, but I reckon it would be similar to the middle colormap here
> > http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
> > (from the elegant figures block series linked above), which I've always
> > found quite attractive.
>
> Certainly it can be considered--but we have to have a real implementation.

While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes... FWIW.

Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
  http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166

I agree that now is definitely the time to get serious about making
these changes, but it seems like there's enough to be worked out that
sticking to the original plan and keeping mainline quasi-frozen until
2.0 is ready might create frustration and hasty decisions. Maybe it
would be less stressful all around if we let mainline development
proceed at whatever pace makes sense while these things get sorted
out, and then once the appearance changes are ready make the call
about whether to cut a quick 1.5 first or not? Presumably these
defaults will stick around for many years so it's worth taking a few
months to get a complete proposal together, get feedback, etc., IMO.

In an ideal world version 1.last might even provide a
style.use("matplotlib2") command to preview what 2.0 will do, just
like 2.0 will presumably have a style.use("matplotlib1") command for
those who want to (temporarily) revert.

-n

[1] well I would think that wouldn't I ;-)

--
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=190641631&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy and the color revolution

2015-04-05 Thread Nathaniel Smith 
On Mon, Feb 23, 2015 at 10:46 AM, Eric Firing  wrote:
> On 2015/02/18 2:39 PM, Nathaniel Smith wrote:
>>
>> On Feb 16, 2015 3:39 PM, "Eric Firing"  wrote:
>>>
>>>
>>> On 2015/02/16 1:29 PM, Michael Waskom wrote:
>>>
>>>> Nathaniel's January 9 message in that thread (can't figure out how to
>>>> link to it in the archives) had a suggestion that I thought was very
>>>> promising, to do something similar to Parula but rotate around the hue
>>>> circle the other direction so that the hues would go blue - purple - red
>>>> - yellow. I don't think we've seen an example of exactly what it would
>>>> look like, but I reckon it would be similar to the middle colormap here
>>>>
>>>> http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
>>>> (from the elegant figures block series linked above), which I've always
>>>> found quite attractive.
>>>
>>>
>>> Certainly it can be considered--but we have to have a real
>>> implementation.
>>
>>
>> While I hate to promise vaporware, I actually was planning to have a
>> go at implementing such a colormap in the next few weeks, based on
>> optimizing the same set of parameters that viscm visualizes... FWIW.
>
>
> It might be worth quite a bit--and the sooner, the better.

While it's taking longer than hoped, just to reassure you that this
isn't total vaporware, here's a screenshot from the colormap designer
that Stéfan van der Walt and I have been working on... still needs
fine-tuning (which at this point probably won't happen until after I
get back from PyCon), but we like what we're seeing so far :-)

The colormap shown has, by construction, perfect lightness linearity
and perfect perceptual uniformity, according to the better-than-CIELAB
model used by the viscm tool I linked upthread.

-- 
Nathaniel J. Smith -- http://vorpus.org
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy and the color revolution

2015-04-05 Thread Nathaniel Smith 
On Sun, Apr 5, 2015 at 12:46 AM, Eric Firing  wrote:
> On 2015/04/04 9:20 PM, Nathaniel Smith wrote:
>
>> While it's taking longer than hoped, just to reassure you that this
>> isn't total vaporware, here's a screenshot from the colormap designer
>> that Stéfan van der Walt and I have been working on... still needs
>> fine-tuning (which at this point probably won't happen until after I
>> get back from PyCon), but we like what we're seeing so far :-)
>>
>> The colormap shown has, by construction, perfect lightness linearity
>> and perfect perceptual uniformity, according to the better-than-CIELAB
>> model used by the viscm tool I linked upthread.
>>
>
> Thanks for the update, and the progress.  The example colormap looks
> promising as a viable alternative.  It appears to have good contrast. How
> well does this type of map work with the colorblindness filters?

Blue/yellow contrast is preserved with the common types of
colorblindness, so it should become a smooth ramp of blue ->
(reddish/greyish, depending on details/severity of color deficiency)
-> yellow. And the luminance remains linear. So it's definitely not a
disaster.

Beyond that I'm not entirely sure how to numerically quantify
perceptual uniformity for colorblind users -- we could use the
sRGB->sRGB formulas for simulating colorblindness for non-colorblind
viewers and then use the regular non-colorblind uniformity estimates,
but I have no idea how accurate that would be... my guess though is
that the way that colormaps is designed ATM it will have somewhat
faster hue shifts in the lower (blue) region than the upper (yellow)
region, and fastest in the middle, though this effect shouldn't be
huge (and to some extent is inevitable with any map that's both
colorful and perceptually uniform for non-colorblind users). Thinking
through these details is one of the things I had in mind when I
mentioned "fine tuning" above though :-).

We'd welcome any feedback from readers with non-simulated color deficiency!

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy and the color revolution

2015-04-05 Thread Nathaniel Smith 
On Apr 5, 2015 8:29 PM, "gary ruben"  wrote:
>
> Just wondering whether anyone has suggested checking candidate colormaps
against typical printer color gamuts?

How would you go about doing this in practice? Is it even possible to
choose a subset of sRGB space and have printers take advantage of that when
doing gamut mapping? (I guess I always assumed that printer gamut mapping
applied to an RGB image would map all of RGB into their gamut, so there
would be no advantage to restricting oneself go a subspace. But maybe I'm
wrong -- color management is pretty fancy these days.)

-n
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] RFC: candidates for a new default colormap

2015-06-02 Thread Nathaniel Smith 
Hi all,

As was hinted at in a previous thread, Stéfan van der Walt and I have
been using some Fancy Color Technology to attempt to design a new
colormap intended to become matplotlib's new default. (Down with jet!)

Unfortunately, while our Fancy Color Technology includes a
computational model of perceptual distance, it does not include a
computational model of aesthetics. So this is where you come in.

We've put up three reasonable candidates at:
https://bids.github.io/colormap/
(along with some well-known colormaps for comparison), and we'd like
your feedback.

They are all optimal on all of the objective criteria we know how to
measure. What we need judgements on is which one you like best, both
aesthetically and as a way of visualizing data. (There are some sample
plots to look at there, plus you can download them and play with them
on your own data if you want.)

We especially value input from anyone with anomalous color vision.
There are some simulations there, but computational models are
inherently limited here. (It's difficult to ask someone with
colorblindness "does this look to you, the same way this other picture
looks to me?")

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-02 Thread Nathaniel Smith 
On Tue, Jun 2, 2015 at 9:01 PM, Olga Botvinnik  wrote:
> Great work! Very nice post describing the methodology. I especially like the
> choice of images you used to expose differences between colormaps.

Thanks!

> My ranking is:
> 1. C
> 2. A
> 3. B
>
> To my eyes, C has the highest dynamic range (somehow the opposite of Eric!)
> and I like the purple/blue undertone in the dark colors.

Unfortunately it's going to depend a bit on individual variations in
monitors (and eyes!).

Bonus points for anyone who sends in feedback based on viewing the
test images on your department's most terrible projector :-).

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-02 Thread Nathaniel Smith 
On Tue, Jun 2, 2015 at 10:03 PM, Paul Ivanov  wrote:
> 1. C
> 2. B
> 3. A
>
> But I wouldn't call them aesthetic - the purple in there just looks off -
> I'd prefer something like hot, afmhot, or gist_heat - or variations on
> those.

It turns out that it's very difficult to go ~blue to anything like a
red to ~white/yellow, while keeping to our other constraints
(perceptual uniformity in both color and black-and-white). The problem
is that red is way off in a corner of the sRGB color space --
basically anything near red but brighter takes you outside of sRGB.
But you *must* get brighter at a constant rate, while you can only
move away from the corner at a fixed speed, so you tend to
overshoot...

That said, if you want to play around with the editor tool, it's
linked on the webpage :-). Drag to move spline control points,
shift-click to add a control point, control-click to delete a control
point, bottom bars let you set the min/max lightness, and click the
colormap on the side to select which hue/saturation slice of color
space you want the left pane to show. (The game is to keep the yellow
dot inside the slice.) If it starts acting weird try tapping your
modifier keys, sometimes that fixes things.

> Since this thread is bound to get plenty of attention (I suggest getting
> feedback from -users, too), we would be remiss if we didn't point those who
> didn't already see the writeup of colormaps that  Kristen Thyng and
> colleagues did in the docs [1]. Also, I added a pointer to this thread over
> on #875 [2].
>
> 1. http://matplotlib.org/users/colormaps.html
> 2. https://github.com/matplotlib/matplotlib/issues/875

I'm not on -users, but please do distribute the link far and wide to
whoever you think might be interested! With, again, major bonus points
for feedback on colorblindness-friendliness and readability under
adverse display conditions like lousy projectors, since IMO at this
point they're all pretty decent when viewed under optimal conditions.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-03 Thread Nathaniel Smith 
On Wed, Jun 3, 2015 at 1:51 PM, Eric Firing  wrote:
> On 2015/06/02 7:58 PM, Nathaniel Smith wrote:
>>
>> On Tue, Jun 2, 2015 at 10:03 PM, Paul Ivanov  wrote:
>
>
>> That said, if you want to play around with the editor tool, it's
>> linked on the webpage :-).
>
>
> This is a really nice tool!
>
> Attached is an example of a map that circles the other direction, and that
> sacrifices some visual delta for less extreme ends.  Although I think the
> "sunrise" type of map that you offered in versions A, B, and C is a good one
> to have in the arsenal, I am not convinced that it should be the only
> category to be considered as a default.  Do we really want to reject the
> somewhat Parula-like category just because Matlab uses the real Parula?
>
> I'm not saying the attached example is particularly good; it is intended to
> re-introduce the category.  (It is somewhat similar to a reversal of our
> ColorBrewer YlGnBu, so I tried to name it following that scheme.)

That is nice! For those following along at home, here's what Eric's
colormap looks like:
   https://bids.github.io/colormap/images/screenshots/erics_PuBuGnYl_r.png

We also tried tweaking it a bit to end on a more saturated yellow,
which I think helps increase contrast in the deuteranomalous version
in particular, and put this on the website as an "option D":
   https://bids.github.io/colormap/images/screenshots/option_d.png

We also previously designed a colormap that follows parula's ideas
pretty closely, in terms of starting/ending points, overall
brightness, and the trick of kinking over through orange at the top
end. It ends up being much much more green than parula though:
   https://bids.github.io/colormap/images/screenshots/fake_parula.png

> It seems that the fundamental constraints in this map generator tend to
> yield a somewhat muddy dark end and a muted middle.  That's one compromise
> among many that are possible.

You can somewhat avoid the muddy end by bumping up the minimum
brightness (option C does this to some extent), but of course that has
other trade-offs.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-04 Thread Nathaniel Smith 
On Jun 4, 2015 9:28 AM, "Joe Kington"  wrote:
>
> One other (admittedly very minor) consideration is how the colormaps look
with shading applied.  To borrow from the hillshading example:
>
> (The image appears to be too large to attatch. Try here:
http://www.geology.beer/images/hillshaded.png)
>
> I personally really like option D for a lot of reasons, but this is
another reason to prefer it. Providing additional information through
"shading" etc, still works quite well. Option C also does well in this
particular test, though it appears too "washed out" for my tastes.

I'm not sure what I'm looking at in that picture exactly, or how to
distinguish a good result from a poor one -- could you elaborate?

FYI I should also note that we're planning on additionally providing
isoluminant (or approximately isoluminant) variants for whatever colormaps
we end up contributing, exactly for cases where you want to preserve the
lightness channel for shading effects. So in any case you'll have a choice
between "mapA" and "mapA-isoluminant", etc.

-n
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-04 Thread Nathaniel Smith 
On Thu, Jun 4, 2015 at 3:32 PM, Benjamin Root  wrote:
> As for option D, my only apprehension for it is on the blue (purple?) end of
> the scale. I can't really perceive any changes on that end and it just seems
> like a solid color to me. Does it seem that way to anybody else? Maybe shift
> the curve a bit to start a little more into the greens and have more
> yellow/orange?

This is useful feedback, but FWIW it looks fine here... so my first
guess is that this is due to variation between individual monitors.
While the Fancy Color Math we're using is definitely not perfect, it
does represent basically everything anyone knows about how color
works. The biggest limitation is that at the end of the day we have to
write down the colormap using RGB values, and you can send the exact
same RGB values to two different monitors and get different colors. So
the only thing we can do is to target sRGB, which has two virtues:
it's designed to be an inexact but reasonable approximation to what
most hardware does if you use it in a naive way; and, it's also what's
expected by more sophisticated setups -- like OSes and applications
that are color-management-aware, and ideally have access to calibrated
models of specific monitors / printers / whatever.

Over time this will hopefully improve as software and hardware are
upgraded, and more workflows will become "sophisticated". But until
then there's not much to do besides target sRGB and cross our fingers.
Unless anyone has access to some data on how popular consumer hardware
systematically deviates from sRGB... designing the perfect colormap
for "the monitor sitting on Benjamin Root's desk with its current
software drivers" may or may not help for anyone else :-).

Lacking real data like this, the best we can hope for is to try and
avoid any colormap that lots of people report causing specific
problems on the hardware they have access to (which is why I was
asking about projectors in particular upthread).

TL;DR: please do report such issues, but IMO these reports are only
really useful if lots of people report the same thing, or if it causes
many people to prefer one colormap to another; unfortunately it's not
very useful for tweaking small details.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

2015-06-04 Thread Nathaniel Smith 
On Thu, Jun 4, 2015 at 12:42 AM, Nathan Goldbaum  wrote:
>
> On Wed, Jun 3, 2015 at 5:17 PM, Stéfan van der Walt 
> wrote:
>>
>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum 
>> wrote:
>> > I'm a big fan of option D.  So much so that when I needed to make a
>> > movie of
>> > ony my galaxy simulations today I went ahead and used it:
>> >
>> > https://youtu.be/bnm554et0T8
>>
>> Beautiful!  How hard would it be to also do this for the other
>> proposed colormaps?
>
>
> Thankfully you made it pretty easy to script this.
>
> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>
> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>
> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>
> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>
> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>
> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k

Awesome! Added these to the webpage.

For extra fun (90 mb download, but worth it):
http://vorpus.org/~njs/goldbaum-galaxies-all-colormaps.mkv

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot functions: do you rely on the "hold" kwarg?

2015-06-07 Thread Nathaniel Smith 
On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing  wrote:
> Matplotlib's pyplot retains quite a few vestiges from its original
> Matlab-workalike heritage; we would like to gradually eliminate those
> that no longer make sense.  One such candidate is the "hold" kwarg that
> every pyplot function has, with a "True" default.  I don't think it
> serves any useful purpose now, and getting rid of it would allow
> considerable simplification to the code and, to a lesser extent, the
> documentation.  The default behavior would not change, only the ability
> to change that behavior via either the rcParams['axes.hold'] parameter
> or the "hold" kwarg in a pyplot function call.
>
> If you routinely use 'hold=False' and believe that removing it would be
> a mistake, please let us know.

I do actually use it with some regularity interactively, though I'm
not particularly attached to it. Is there some equivalent though, like
   plt.whatever(..., hold=False)
can become
   plt.clear(); plt.whatever(...)
? The semantics would be that the current figure remains the current
figure, but is reset so that the next operation starts from scratch. I
notice that plt.clear() does not exist, but maybe it has another
spelling :-).

(Basically the use case here is getting something like the
edit-and-rerun-a-cell workflow, but when using a classic interactive
REPL rather than the ipython notebook -- so I have a specific plot
window up on my screen at a size and place where I can see it, and
maybe some other plots in other windows in the background somewhere,
and I want to quickly display different things into that window.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Colormap survey results

2015-06-16 Thread Nathaniel Smith 
Greetings, matplotliberators!

I've counted up the various "votes" people made regarding the
different colormap options at
  https://bids.github.io/colormap
including the ones in the matplotlib-devel and -users threads and
elsewhere (private email, twitter), etc.

There were two phases -- some people saw A/B/C, and some saw A/B/C/D,
so I'll separate the votes into those two groups. It's a bit
complicated to break down, also, because people expressed preferences
with different degrees of specificity ("I like X" vs total order vs
partial order...).

--- Round 1 votes ---

For those comparing A/B/C, the number of people with different preferences were:

First choice A: 6 votes
  Of which:
 A > C > B got 1 vote
 A > B > C got 2 votes

First choice B: 8 votes
  Of which:
B > A > C got 3 votes
B > C > A got 1 vote

First choice C: 7 votes
  Of which:
C > A > B got 1 vote
C > B > A got 4 votes

--- end of round 1 votes ---

Then we added option D.

--- Round 2 votes ---

For those comparing A/B/C/D, the number of people with different
preferences were:

First choice A: 0 votes

First choice B: 2 votes
  Of which:
  B > A > C/D got 1 vote

First choice C: 1 votes
  Of which:
  C > D > A/B got 1 vote

First choice D: 12 votes
  Of which:
  D > C > A/B got 1 vote
  D > A > C > B got 1 vote

--- end of round 2 votes ---

It seems that voting works better in some cases than others.

So the next question is where we go from here. We need to pick a color
for this bikeshed at some point. One theory is that the next step is
to propose a bunch of variations on option D and have another round of
voting etc. Another is that we should just call it a day and decide
now :-).

For reference, here's option D:
https://bids.github.io/colormap/images/screenshots/option_d.png

And here are the other greenish colormaps that have been mentioned:
https://bids.github.io/colormap/images/screenshots/fake_parula.png
https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png
https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png
https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png

My personal feeling is that all these alternatives are basically
reasonable colormaps, but compared to option D I find them kinda ugly,
and, more importantly, substantially worse for colorblind users, which
IMO should outweigh a marginal/debateable improvement for the rest of
us.

So if it were up to me I'd be inclined to declare we've reached the
point of diminishing returns and go with D, but I don't know how
everyone else is feeling. Shall we just go for it?

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

2015-06-16 Thread Nathaniel Smith 
On Jun 16, 2015 7:31 PM, "Juan Nunez-Iglesias"  wrote:
>
> As long as A and B are included as named options, I have no objections to
D as default.

Yeah, all the colormaps will be available over way or another, it's just
the default in question.

-n
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

2015-06-17 Thread Nathaniel Smith 
On Jun 17, 2015 8:36 AM, "OceanWolf"  wrote:
>
> Another question, why does a reason exist why the colour-maps start at
yellow and go to blue, either anti-clockwise, or clockwise?  What about a
rotation of 90deg rather than just a mirror inverse on the a' b' plane?

Colorblind users can reliably distinguish blue/yellow and dark/light, but
that's all, so an accessible colormap has to use those for its dominant
axis. And then you have to do dark+bluish and light+yellowish if you want
something colorful, because it just turns out that the way the brain works,
there is no such thing as a saturated light blue or a saturated dark yellow.

-n
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

2015-07-01 Thread Nathaniel Smith 
On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith  wrote:

[...snip discussion of how option D was the favorite of 80% of people
in the survey...]

> So the next question is where we go from here. We need to pick a color
> for this bikeshed at some point. One theory is that the next step is
> to propose a bunch of variations on option D and have another round of
> voting etc. Another is that we should just call it a day and decide
> now :-).
>
> For reference, here's option D:
> https://bids.github.io/colormap/images/screenshots/option_d.png
>
> And here are the other greenish colormaps that have been mentioned:
> https://bids.github.io/colormap/images/screenshots/fake_parula.png
> https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png
> https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png
> https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png
>
> My personal feeling is that all these alternatives are basically
> reasonable colormaps, but compared to option D I find them kinda ugly,
> and, more importantly, substantially worse for colorblind users, which
> IMO should outweigh a marginal/debateable improvement for the rest of
> us.
>
> So if it were up to me I'd be inclined to declare we've reached the
> point of diminishing returns and go with D, but I don't know how
> everyone else is feeling. Shall we just go for it?

So it's been 2 weeks with no real followup on this. I don't really
care where we end up (though I selfishly would somewhat prefer if
there is a decision before our SciPy talk next week, just so we can
tell people what it is :-)), but we need to resolve this somehow.
What's the plan?

Michael, Thomas, I see from the credits page that you're the Official
Lead Developers :-), so given the intrinsic bikeshedditude of this
topic I suspect it may come down to you taking a deep breath and
making a decision (or at least declaring some specific concrete
process for making the decision)?

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

2015-07-01 Thread Nathaniel Smith 
On Jul 1, 2015 6:31 PM, "Eric Firing"  wrote:
>
> On 2015/07/01 1:56 PM, Nathaniel Smith wrote:
> > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith  wrote:
> >
> > [...snip discussion of how option D was the favorite of 80% of people
> > in the survey...]
> >
> >> So the next question is where we go from here.
>
> One thing we need to do is get some of these maps into  _cm.py via PR.

We've been a bit distracted getting the software and talk together ahead of
scipy, but PR (with names) will follow within the next week or so. The
decision part is pretty orthogonal though I think? It's not like matplotlib
2.0 is going to branch between now and scipy :-).

> I would prefer not to have them go in as huge tables if they can be made
> more compact, either by being function-generated or by using the
> LinearSegmentedColormap mechanism with a moderate number of breakpoints.
>
> Suggestions?

Depends on how you define "moderate", but my guess is that linear segmented
is the best approach -- the exact colormaps have a pretty terse
representation as bezier control points, but using this at runtime would
require pulling in the full colorspace apparatus as a dependency. Which I
guess has points in its favor for other reasons, but nonetheless.

These kinds of details can be worked out in the PR review process, though.
The blocking issue is that we need a decision :-).

-n
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel