Re: [matplotlib-devel] Colormap survey results

[OceanWolf]

Not my cup of tea, but to get the ball rolling, how about "Truncated Rainbow"?  
[Red, Orange, Yellow, Green, Blue, Indigo, Violet][2:]
  From: Benjamin Root 
 To: Eric Firing  
Cc: matplotlib development list  
 Sent: Thursday, 2 July 2015, 4:19
 Subject: Re: [matplotlib-devel] Colormap survey results
   
I have been thinking a bit about naming. We could always go the route of "Heinz 
57", "Chanel No. 5", or "Preparation H". Not saying that "MPL-d" is a catchy 
name or not, but.. :-P

Ben Root



On Wed, Jul 1, 2015 at 9: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.
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?

(We will also need a naming scheme.)

Eric


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


  --
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

[OceanWolf]

Ooh, I do like Eric's v2, I see much more of a fall off in the sample images, 
so I would say v2 > D > ?

Any chance of the galaxy animation with v2?

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?

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule

[OceanWolf]

I think I mean that before we cherrypicked from master to colouroverhaul, as we 
only wanted a few things from master to go out in the next release, but now if 
I understand correctly we want most of master to go out in the next release, so 
we have to uncherrypick out the stuff we don't want, and I fear that such a 
branch won't have had the rigorous testing that the current color-overhaul 
branch has had.  Metaphorically speaking we have a mixture of different fluids 
that have settled into clear stratified layers, now we plan to give that 
mixture a good shake and hope we don't break everything.

Meh, perhaps I just act too overcautious.


From: Thomas Caswell 
To: OceanWolf ; 
"matplotlib-devel@lists.sourceforge.net" 
 
Sent: Wednesday, 17 June 2015, 6:04
Subject: Re: [matplotlib-devel] Release schedule



I am not sure what you mean by cherry-picking/uncherry picking.  I just looked 
at what is on `color_overhaul` which is not in master and it is: changes that 
should be discarded (changes to cxx / changes to _tri.* that rely on cxx), one 
change related to mathtext layout (and conflicts due to mathext_*68 being added 
on both branches) which we do not want to cherry pick, and documentation about 
pkg-config and a minor doc which will be easy to cherry-pick (I am going to do 
in now).

There is documentation about the coming color change in master, but that is 
probably ok to include in a point release (as it is just plans).


In either case the 2.0 release will contain _only_ style related API breaks and 
will be based on what ever the last point release was.

Tom




On Tue, Jun 16, 2015 at 9:15 AM OceanWolf  wrote:

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work 
in uncherrypicking recherrypicking.  Given the amount of testing that both 
master and color-overhaul have gone through by us devs and other interested 
people, I feel it perhaps better to keep the release schedule as it was.
>
>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and 
>then depreciate (or fully-remove) in 2.0, but personally I opt for safety over 
>nicety (plus it gives us more time to get MEP22/27 completed and have time for 
>more people to test it, find bugs, though I doubt we will have any O:)).
>
>
>Best,
>OceanWolf
>

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule

[OceanWolf]

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work 
in uncherrypicking recherrypicking.  Given the amount of testing that both 
master and color-overhaul have gone through by us devs and other interested 
people, I feel it perhaps better to keep the release schedule as it was.

>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and 
>then depreciate (or fully-remove) in 2.0, but personally I opt for safety over 
>nicety (plus it gives us more time to get MEP22/27 completed and have time for 
>more people to test it, find bugs, though I doubt we will have any O:)).


Best,
OceanWolf

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[OceanWolf]

Personally, just looking at the images I think B looks more 
professional, the others look faded.  With A and B I see more of 
"contrast" in the core of the radial image (though that might arise from 
a combination of my monitor/eyes, though I usually do quite well in 
colour perception tests).

I think we really need to see a variety of real examples before we make 
a decision though, both in application a.k.a different type of datasets, 
including ones with NaNs; and different graph types, the 3d example will 
make for a good test as we get the same information twice, from height 
and colour, which gives us a reference for comparison.

With the NaNs Andreas, why did you pick B over C?  My eyes see B going 
to white as well, only C as far as I can tell does not go to white.

Looking forward to having a play later :).  I wonder what Parula-based 
colormap would look like if we were to make it linear... one other 
thing, mpl currently doesn't select good bounds with pure 
horizontal/vertical lines, making it very difficult (at least for me) to 
see the perceptual deltas, zoomed in to option_c the line gets 
completely hidden by the axes...

On 03/06/15 09:04, Andreas Hilboll wrote:
> On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
>> You can always use green for NaN with any of these maps...
> In grayscale that then wouldn't be distinguishable at all ...
>
>> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll > > wrote:
>>
>>  > I particularly like that A ends on the white end of the spectrum
>>
>>  That's exactly why I don't like A that much.
>>
>>  In many plots, I need a color for NaN results. This color should not
>>  fall within the normal range of the colormap. In case of B and C, it
>>  would be possible to use white as NaN color. When using white for NaN
>>  in A, it would just look like large values. So I guess I'm voting
>>
>>  B > C > A
>>
>>  -- Andreas.
>>
>>  
>> --
>>
>>  ___
>>  Matplotlib-devel mailing list
>>  Matplotlib-devel@lists.sourceforge.net
>>  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Full CPU with GTKAgg when displaying a figure.

[OceanWolf]

Not sure why my message didn't go through earlier, but yes, the issue 
already exists in the system, see 
https://github.com/matplotlib/matplotlib/issues/4092


On 07/04/15 19:07, Benjamin Root wrote:
Yes, this was discovered recently in connection to changes in how idle 
events were handled. I don't recall if there was an issue created for 
it, though.


On Tue, Apr 7, 2015 at 11:48 AM, Michael Kaufman > wrote:


Hi All,

I don't have time at the moment to submit a ticket, but I thought I'd
see if anyone else is having this problem:

With latest master on 1.5-devel using GTKAgg backend, (and in ipython
3.0.0-dev, python 2.7.8, MacOSX 10.9.5) if I do figure() and nothing
else, and then run 'top', I see Python running 100% CPU for the
process.
Closing the figure stops Python hogging the CPU.

With latest 1.4.x, I do not see it.

M


--
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
Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[OceanWolf]

I like it, but perhaps we should condense it to one word for ease of 
typing, how about "Redgauntlet"?  It kind of feels appropriate (for 
those who need an explanation of why, see 
https://www.youtube.com/watch?v=_guKhYVr5vA).


On the colormap itself, it looks good apart from the fade into blue, my 
eyes on this laptop monitor see a sharp gradient around 0.2 compared 
with the more gradual gradient at the other end.  Also I see constant 
colour between 0 and 0.1, and between 0.9 and 1, with less change 
between 0.8 to 0.9 then 0.1 and 0.2.  Not sure if one causes an optical 
illusion in the other or not.


Finally a bit confused as to what all the lines mean, any chance of some 
annotation?  Also I would find it helpful to see a version without the 
big red line and what it looks like in practice (see the doc for the 
test script).


Best,
OceanWolf

On 05/04/15 23:18, Olga Botvinnik wrote:

How about "pythonic sunset" ?

On Sun, Apr 5, 2015 at 2:01 PM Benjamin Root <mailto:ben.r...@ou.edu>> wrote:


That is nice. The blue is a bit heavy, but that might be my
display. Now, how should we order it by default? I am used to
thinking of blues as lower values, and reds as higher. The yellow
at the end throws me off a bit, because I would think of it as a
"weaker" color. Maybe if it was more gold-like?

We should also start thinking of a snazzy name. BlRdYe probably
won't cut it.

Ben Root

On Apr 5, 2015 3:21 AM, "Nathaniel Smith" mailto:n...@pobox.com>> wrote:

On Mon, Feb 23, 2015 at 10:46 AM, Eric Firing
mailto:efir...@hawaii.edu>> wrote:
> On 2015/02/18 2:39 PM, Nathaniel Smith wrote:
>>
>> On Feb 16, 2015 3:39 PM, "Eric Firing" mailto:efir...@hawaii.edu>> 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
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
https://lists.sourc

Re: [matplotlib-devel] MEP 27 Backend Refactor (Gcf)

[OceanWolf]

Okay, just about finished WebAgg, but it has raised an interesting 
question about layout...
I started working to standardise using the way we do it on ``Gtk3``, 
i.e. using a pure vertical layout, adding elements from either the top 
or the bottom of the container and setting widgets (i.e. the canvas) as 
expandable.  In my original version of this MEP I used a boolean to 
specify whether to add to the beginning or the end of the window's 
layout.  ``Tk`` gave me the idea to extend past this and use string 
argument of 'top' or 'bottom', no real difference but just to keep it 
flexible for the future.

However now I rethink that strategy having converted Qt and now on 
WebAgg, perhaps we should conform around a Grid layout, by that I mean 
we have the following:

   North

|  |
E |  | W
a | Centre  |  e
s |  |  s
t |   |  t
|  |
---
   South

For now we will just use Centre and South (with the canvas in Centre; 
and Toolbar/statusbar in South), but it also leaves it open for the 
future.  If I recode it like this, I would make each 5 positions a box, 
with the compass points adding elements from the outside inwards which 
keeps the pattern explained above.

What do people think?  I don't feel 100% comfortable for limiting 
ourselves to just one layout, but I can persuade myself that we have to 
decide on something and atm we only have a really adhoc system, so 
definitely an improvement, and should anything happen in the future to 
make us change our mind we can the workaround of using centre as our new 
starting point, or wait for a major release.

Looking forward to getting some feedback on this.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP 27 Backend Refactor (Gcf)

[OceanWolf]

Correct, I meant that I don't see my refactor of the webagg backend 
affecting the refactor I have done in the main PR.  I do the refactor of 
the core classes in https://github.com/matplotlib/matplotlib/pull/4143 
and then make separate branches (which will turn into PRs once the main 
backend has finished) for the individual backends.  For example 
refactoring the 2nd backend on my list (Tk) caused me to make some small 
adjustments to the base refactor.  After then I have had no problems, so 
when I said ``but nothing

that breaks the main PR'', I meant it as an affirmation of that.

On 24/03/15 06:58, Achyut Rastogi wrote:
Changes made during refactors are always backwards compatible right? I 
just wanted to know what you mean by "breaking the main PR"?

Thank you

On Mon, Mar 23, 2015 at 10:30 PM, OceanWolf 
mailto:juichenieder-n...@yahoo.co.uk>> 
wrote:


Just updated the MEP with more info.  From what I gather, I don't see
any problems.  Refactoring WebAgg makes for slow progress, but nothing
that breaks the main PR.  As far as I can tell it can get merged
while I
work on the other backends and submit them as separate PRs. With this
main branch merged we can then progress/finalise MEPs 22 and 23.

On 02/03/15 20:20, OceanWolf wrote:
> Hi everyone,
> Over the past week or so I have been working on what I now dub 
MEP27

> <https://github.com/matplotlib/matplotlib/wiki/MEP27> .  I have
already
> gotten quite far with it, but as I do some hefty changes (no
breakages, and
> virtually 100% backward compatible) I wanted to make sure I got
some input
> before continuing.  I have now gotten far enough to know that
the base code
> should work without any more tweaking.
>
> Best,
> OceanWolf
>
>
>
> --
> View this message in context:

http://matplotlib.1069221.n5.nabble.com/MEP-27-Backend-Refactor-Gcf-tp45032.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
>

--
> 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
> Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



--
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
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP 27 Backend Refactor (Gcf)

[OceanWolf]

Just updated the MEP with more info.  From what I gather, I don't see 
any problems.  Refactoring WebAgg makes for slow progress, but nothing 
that breaks the main PR.  As far as I can tell it can get merged while I 
work on the other backends and submit them as separate PRs.  With this 
main branch merged we can then progress/finalise MEPs 22 and 23.

On 02/03/15 20:20, OceanWolf wrote:
> Hi everyone,
> Over the past week or so I have been working on what I now dub  MEP27
> <https://github.com/matplotlib/matplotlib/wiki/MEP27>  .  I have already
> gotten quite far with it, but as I do some hefty changes (no breakages, and
> virtually 100% backward compatible) I wanted to make sure I got some input
> before continuing.  I have now gotten far enough to know that the base code
> should work without any more tweaking.
>
> Best,
> OceanWolf
>
>
>
> --
> View this message in context: 
> http://matplotlib.1069221.n5.nabble.com/MEP-27-Backend-Refactor-Gcf-tp45032.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Histogram normalization and overflow bins

[OceanWolf]

Slightly off-topic, does github allow for one to tag lines/code-blocks 
with notes to the future like ``numpy1.5 removal'', similar to tags for 
issues and milestones?  This would save us from trawling through the 
code looking for comments.  If github does not have this feature, do you 
think github would add that as a feature if asked?

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Histogram normalization and overflow bins

[OceanWolf]

Yes, you have almost got what I want.  I know of both line comments in 
the pull interface, and raising DeprecationWarnings.  The problem with 
the warnings that they only want to get used when you have an alternate 
in place and want to remove old code soon.  The problem here lies in not 
knowing how long the life-cycle will last for an indeterminate amount of 
time, such as numpy-1.5 here, or python-2.7.  Lots of such items can 
stack up, and easily get forgotten about, as we see here.


On 10/03/15 17:12, Paul Hobson wrote:
You can comment on specific lines of code in the pull request 
interface, but that's not what I think you're describing. A better 
practice, IMO is to raise a DeprecationWarning when the 
soon-to-be-removed code is executed. Then you can just grep for those 
and get cracking.

-p

On Tue, Mar 10, 2015 at 8:51 AM OceanWolf 
mailto:juichenieder-n...@yahoo.co.uk>> 
wrote:


Slightly off-topic, does github allow for one to tag lines/code-blocks
with notes to the future like ``numpy1.5 removal'', similar to
tags for
issues and milestones?  This would save us from trawling through the
code looking for comments.  If github does not have this feature,
do you
think github would add that as a feature if asked?


--
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
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Histogram normalization and overflow bins

[OceanWolf]

Tom, ``When we drop numpy 1.5''?  I thought we already had... I mean we 
only test numpy 1.6 on Travis...

For the rebinning exercise, I don't have time to look, but I would 
expect a similar trick to imshow, quiver, etcetera when I want to 
compare to a baseline (e.g. for animation).  Namely I calculate the 
normalisation parameters first, and then apply those parameters on 
subsequent plots.

To ease the user, we could add a method to return the binning parameters 
from a single binning exercise, and then give an option to pass those 
params in to subsequent plots.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[OceanWolf]

One thing to note, that the backend structure will hopefully change soon 
with a huge refactor of the backends.

Take a look https://github.com/matplotlib/matplotlib/pull/4143 for the 
current progress and feel free to give your comments.

As a status update, I currently work on the WebAgg backend (which of the 
backends I have converted, seems the most obfuscated of them all) and 
have just finished reading through, and marking up the code with TODOs 
ready for refactor of that backend.  I will also update the MEP page to 
flesh out parts that I feel need more detail.

Best,
OceanWolf

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] MEP 27 Backend Refactor (Gcf)

[OceanWolf]

Hi everyone,
Over the past week or so I have been working on what I now dub  MEP27
<https://github.com/matplotlib/matplotlib/wiki/MEP27>  .  I have already
gotten quite far with it, but as I do some hefty changes (no breakages, and
virtually 100% backward compatible) I wanted to make sure I got some input
before continuing.  I have now gotten far enough to know that the base code
should work without any more tweaking.

Best,
OceanWolf



--
View this message in context: 
http://matplotlib.1069221.n5.nabble.com/MEP-27-Backend-Refactor-Gcf-tp45032.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel