[Numpy-discussion] [REL] matplotlib v2.0.0

[Thomas Caswell]

Folks,

We are happy to announce the release of (long delayed) matplotlib 2.0!
This release completely overhauls the default style of the plots.

The source tarball and wheels for Mac, Win, and manylinux for python 2.7,
3.4-3.6 are available on pypi

   pip install --upgrade matplotlib

and conda packages for Mac, Win, linux for python 2.7, 3.4-3.6 are
available from conda-forge

   conda install matplotlib -c conda-forge


Highlights include:

 - 'viridis' is default color map instead of jet.
 - Modernized the default color cycle.
 - Many more functions respect the color cycle.
 - Line dash patterns scale with linewidth.
 - Change default font to DejaVu, now supports most Western alphabets
(including Greek, Cyrillic and Latin with diacritics), math symbols and
emoji out of the box.
 - Faster text rendering.
 - Improved auto-limits.
 - Ticks out and only on the right and bottom spines by default.
 - Improved auto-ticking, particularly for log scales and dates.
 - Improved image support (imshow respects scales and eliminated a class of
artifacts).

For a full list of the default changes (along with how to revert them)
please see http://matplotlib.org/users/dflt_style_changes.html and
http://matplotlib.org/users/whats_new.html#new-in-matplotlib-2-0.

There were a number of small API changes documented at
http://matplotlib.org/api/api_changes.html#api-changes-in-2-0-0

I would like to thank everyone who helped on this release in anyway.  The
people at 2015 scipy BOF where this got started, users who provided
feedback and suggestions along the way, the beta-testers, Nathaniel, Stefan
and Eric for the new color maps, and all of the documentation and code
contributors.

Please report any issues to matplotlib-us...@python.org (will have to join
to post un-moderated) or https://github.com/matplotlib/matplotlib/issues .

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] question about long doubles on ppc64el

[Thomas Caswell]

Folks,

Over at h5py we are trying to get a release out and have discovered (via
debian) that on ppc64el there is an apparent disagreement between the size
of a native long double according to hdf5 and numpy.

For all of the gorey details see: https://github.com/h5py/h5py/issues/817 .

In short, `np.longdouble` seems to be `np.float128` and according to the
docs should map to the native 'long double'.  However, hdf5 provides a
`H5T_NATIVE_LDOUBLE` which should also refer to the native 'long double',
but seems to be a 64 bit float.

Anyone on this list have a ppc64el machine (or experience with) that can
provide some guidance here?

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [REL] matplotlib 2.0.0rc2

[Thomas Caswell]

Folks,

We are happy to announce matplotlib v2.0.0rc2 !

Please re-distribute this widely.

This is the final planned release candidate for the long awaited mpl v2.0
release.

For the full details of what is new please see
http://matplotlib.org/2.0.0rc2/users/whats_new.html

Some of the highlights:

 - new default style (see
http://matplotlib.org/2.0.0rc2/users/dflt_style_changes.html )
 - new default color map (viridis)
 - default font includes most western alphabets
 - performance improvements in text and image rendering
 - many bug fixes and documentation improvements
 - many new rcparams

Please help us by testing the release candidate!  We would like to hear
about any uses where the new defaults are significantly worse, any changes
we failed to documents, or (as always) any bugs and regressions.

To make this easy we have both wheels and conda packages for mac, linux and
windows.  You can install pre-releases via pip:

   pip install --pre matplotlib

or via conda:

   conda update --all -c conda-forge
   conda install -c conda-forge/label/rc -c conda-forge matplotlib

For more details see http://matplotlib.org/style_changes.html .

Please report any issues to https://github.com/matplotlib/matplotlib/issues or
matplotlib-users at python.org .

The target for v2.0 final is early Jan 2017.

This release is the work of over 200 individual code contributors and many
more who took part in the discussions, tested the pre-releases, and
reported bug reports.

Thank you to everyone who contributed!

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] cycler v.0.10.0 released

[Thomas Caswell]

Folks,

I am happy to announce the next release of Cycler.

This will become the minimal version for the upcoming mpl v2.0 release.

http://matplotlib.org/cycler/

Feature release for `cycler`.  This release includes a number of new
features:

 - `Cycler` objecst learned to generate an `itertools.cycle` by calling
them, a-la a generator.
 - `Cycler` objects learned to change the name of a  key via the  new
`.change_key(old_key, new_key)` method.
 - `Cycler` objects learned how to compare each other and determine if they
are equal or not (`==`).
 - `Cycler` objects learned how to join another `Cycler` to be concatenated
into a singel longer `Cycler` via `concat` method of function.
 `A.concat(B)` or `concat(A, B)`.
 - The `cycler` factory function learned to construct a complex `Cycler`
from iterables provided as keyword arguments.
 - `Cycler` objects learn do show their insides with the `by_key` method
which returns a dictionary of lists (instead of an iterable of
dictionaries).

Tom
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0b2 released

[Thomas Caswell]

The test data for mpl is available as a sperate conda package,
matplotlib-tests.  The reason for splitting it is 40Mb of tests images.

Tom

On Thu, Feb 4, 2016, 09:09 Pauli Virtanen  wrote:

> 04.02.2016, 07:56, Nathaniel Smith kirjoitti:
> [clip]
> > Whoops, got distracted talking about the results and forgot to say --
> > I guess we should think about how to combine these? I like the
> > information on warnings, because it helps gauge the impact of
> > deprecations, which is a thing that takes a lot of our attention. But
> > your approach is clearly fancier in terms of how it parses the test
> > results. (Do you think the fanciness is worth it? I can see an
> > argument for crude and simple if the fanciness ends up being fragile,
> > but I haven't read the code -- mostly I was just being crude and
> > simple because I'm lazy :-).)
>
> The fanciness is essentially a question of implementation language and
> ease of writing the reporting code. At 640 SLOC it's probably not so bad.
>
> I guess it's reasonably robust --- the test report formats are unlikely
> to change, and pip/virtualenv will probably continue to work esp. with
> pinned pip version.
>
> It should be simple to extract also the warnings from the test stdout.
>
> I'm not sure if the order of test results is deterministic in
> nose/py.test, so I don't know if just diffing the outputs always works.
>
> Building downstream from source avoids future binary compatibility issues.
>
> [clip]
> > Maybe it should be uploading the reports somewhere? So there'd be a
> > readable "what's currently broken by 1.x" page, plus with persistent
> > storage we could get travis to flag if new additions to the release
> > branch causes any new failures to appear? (That way we only have to
> > remember to look at the report manually once per release, instead of
> > constantly throughout the process.)
>
> This is probably possible to implement. Although, I'm not sure how much
> added value this is compared to travis matrix, eg.
> https://travis-ci.org/pv/testrig/
>
> Of course, if the suggestion is that the results are generated on
> somewhere else than on travis, then that's a different matter.
>
> --
> Pauli Virtanen
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Removiing 1.10.0 and 1.10.1 from sourceforge and pypi

[Thomas Caswell]

I would also vote for leaving them up.

On Sat, Nov 14, 2015 at 4:21 AM Ralf Gommers  wrote:

> On Fri, Nov 13, 2015 at 9:04 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Nov 13, 2015 at 12:50 PM, Nathaniel Smith  wrote:
>>
>>> On Nov 13, 2015 10:06 AM, "Charles R Harris" 
>>> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I think 1.10.0 and 1.10.1 are sufficiently buggy that they should be
>>> removed from circulation as soon as 1.10.2 comes out. The inner product bug
>>> for non contiguous arrays is particularly egregious. It is not customary to
>>> remove outdated Numpy releases from sourceforge and pypi, but I'd like to
>>> make an exception for those two.
>>> >
>>>
>>> Can you elaborate on what you're trying to accomplish? Like Matthew
>>> says, they'll effectively be removed from circulation once 1.10.2 is
>>> released, regardless of whether we actually delete the files. But deleting
>>> the files does make it difficult to do legitimate things. (Example:
>>> rerunning an analysis with both 1.10.1 and 1.10.2 to check whether some
>>> published results were affected by one of the bugs in 1.10.1.)
>>>
>>
>> Basically, they should never be used, but they will always be tagged in
>> the repo. That said,  if the consensus is to leave them up I won't be
>> bothered much. 
>>
>
> I'd also vote for leaving them up.
>
> Ralf
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumFOCUS fiscal sponsorship agreement

[Thomas Caswell]

+1 to posting it as part of the documentation.

I also like the idea of numfocus hosting the whole collection of them
locally so that we can just link to them.

On Sat, Oct 31, 2015, 19:01 Ralf Gommers  wrote:

> Hi all,
>
> On Wed, Oct 28, 2015 at 11:48 PM, Ralf Gommers 
> wrote:
>
>>
>> Hi all, there wasn't much feedback on this FSA, but I want to point out
>> that it's actually quite important for the project.
>>
>> Maybe everyone already thought about this when the governance model was
>> agreed on (it does include a NumFOCUS subcommittee after all), but if not:
>> read / think /ask question fast, because we're moving forward with signing
>> of the agreement with the people listed at
>> http://docs.scipy.org/doc/numpy-dev/dev/governance/people.html#numfocus-subcommittee.
>>
>>
>
> The document is now signed. No other project with an FSA seems to have
> done this (yet), but I think it would be good to publish the FSA. Either on
> numpy.org, scipy.org or numfocus.org. Any objections/concerns about that?
>
> +1's from the people that signed would be good to have before moving
> forward.
>
> Cheers,
> Ralf
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: Numpy for data manipulation

[Thomas Caswell]

I would suggest

%matplotlib notebook

It will still have to a nice png, but you get an interactive figure when it
is live.

I agree that making the example code Python3 is critical.

Tom

On Thu, Oct 1, 2015 at 8:05 PM Jaime Fernández del Río 
wrote:

> On Thu, Oct 1, 2015 at 11:46 AM, Alex Rogozhnikov <
> alex.rogozhni...@yandex.ru> wrote:
>
>> Hi, I have written some numpy tips and tricks I am using, which may be
>> interesting to you.
>> This is quite long reading, so I've splitted it into two parts:
>>
>> http://arogozhnikov.github.io/2015/09/29/NumpyTipsAndTricks1.html
>
>
> The recommendation of inverting a permutation by argsort'ing it, while it
> works, is suboptimal, as it takes O(n log(n)) time, and you can do it in
> linear time:
>
> In [14]: import numpy as np
>
> In [15]: arr = np.random.rand(10)
>
> In [16]: perm = arr.argsort()
>
> In [17]: perm
> Out[17]: array([5, 0, 9, 4, 2, 8, 6, 7, 1, 3])
>
> In [18]: inv_perm = np.empty_like(perm)
>
> In [19]: inv_perm[perm] = np.arange(len(perm))
>
> In [20]: np.all(inv_perm == perm.argsort())
> Out[20]: True
>
> It does require two lines of code, so for small stuff it is probably good
> enough to argsort, but it gave e.g. np.unique a nice boost on larger arrays
> when we applied it there.
>
> Jaime
>
>
>>
>> http://arogozhnikov.github.io/2015/09/30/NumpyTipsAndTricks2.html
>>
>> Comments are welcome, specially if you know any other ways to make this
>> code faster (or better).
>>
>> Regards,
>> Alex.
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
> de dominación mundial.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

[Thomas Caswell]

To respond to the devils advocate:

 Creating this organizational framework is a one time boot-strapping
event.  You could use wording like "The initial council will include those
who have made significant contributions to numpy in the past and want to be
on it" or "The initial council will be constructed by invitation by
Nathaniel and Chuck".  More objective criteria should be used going
forward, but in terms of getting things spun up quickly doing things by
fiat is probably ok.  I am not even sure that the method by which the
initial group is formed needs to go into the governing document.

I think this addresses most of the concerns, IBM is happy (enough) because
this was done as part of a one-time boot strapping operation of standing
the rules up and there are no explicit names in the governing documents.
It also acknowledges that there is a discontinuity/singularity in the
governance of the project which means you get to do singular thing :).

Tom


On Fri, Sep 25, 2015 at 8:40 AM Nathaniel Smith  wrote:

> [Travis: sorry for writing all this referring to you in third person
> -- I guess it might feel a bit awkward to read! You're certainly part
> of the intended audience, but then it felt even more awkward trying to
> write in second person... this is clearly a bug in English.]
>
> Hi all,
>
> On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant 
> wrote:
> > As the original author of NumPy, I would like to be on the seed council
> as
> > long as it is larger than 7 people.That is my proposal.I don't
> need
> > to be a permanent member, but I do believe I have enough history that I
> can
> > understand issues even if I haven't been working on code directly.
> >
> > I think I do bring history and information that provides all of the
> history
> > that could be helpful on occasion. In addition, if a matter is
> important
> > enough to even be brought to the attention of this council, I would like
> to
> > be involved in the discussion about it.
>
> Regarding the question of Travis being on the council:
>
> My overall feeling on this pretty neutral: I think it won't make much
> of a difference to NumPy really either way, because the important
> thing will be Travis's insights, available time to contribute, etc.,
> and these will (I assume) be pretty much the same regardless of
> whether he's on the council or not. (Any matter so intractable that it
> actually needs the council's emergency powers will presumably be
> heralded by an epic multi-month message thread of doom, plus Travis
> has plenty of friends on the council who know where to find him when
> historical insight is needed, so I'm not worried about anyone missing
> out on a chance to be involved.) I'm sure we can make it work either
> way.
>
> But, I want to play devil's advocate for a bit, because there are some
> connected issues that IMHO we should at least think through if we're
> going to do this, and I think the easiest way to do that is to try and
> articulate the case against. So, here's the case against Travis being
> on the steering council immediately + an alternative option for
> comparison:
>
> - begin devil's advocate -
>
> First, just as a procedural matter, it seems clear that putting Travis
> on the council now will require changing the document in ways that
> violate Sebastian/Chris's concept of a "no names" rule -- at least in
> spirit if not in letter. The problem isn't just the initial council
> seeding; it's that Travis formally stepped down from the project more
> than 2.5 years ago, was mostly inactive for some time before that, and
> IIRC has been almost completely unheard-from between then and a few
> weeks ago. (Of course please correct me if I'm forgetting something,
> and obviously I'm talking with respect to numpy only -- clearly Travis
> has been doing tons of great things, but while numpy certainly
> benefits from e.g. the existence of NumFOCUS, creating NumFOCUS
> doesn't really feel like what we mean by "project activity" :-).)
>
> This means that as currently written, it's pretty unambiguous: he
> doesn't qualify to be added by the normal nomination process (requires
> "sustained" activity over the last year), and if he were added anyway
> (e.g. as part of the seed council) then according to the rules he
> would then be immediately removed for inactivity (requires being
> active within the last 1 year, or else within the 2 years plus
> affirmation that they planned to "return to active participation soon"
> -- this post hoc analysis requires a bit of squinting to apply at all,
> but it's pretty hard to reconcile with >2 years inactivity + his
> "moving on from numpy to blaze" post). To avoid referencing him by
> name we could add some text about "founding developers" or something
> as a fig leaf, but judging from Robert's last email it sounds like
> Travis is the only person in question, so this really would just be a
> fig leaf.
>
> Of course we have the 

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

[Thomas Caswell]

cated and valuable contributors. Plus then we have to start making
> judgements like "well, person A has been around for a while but pretty
> inactive recently, and person B is doing awesome stuff, should we kick
> person A off the council to let person B on or...?" Judging whether
> someone is or isn't a "substantial contributor" is fine, we can do
> that. Having to make a relative judgement of which of two people is
> the *more* "substantial contributor", though -- that sounds awful.
>
> And given how conflict-adverse groups can be, I suspect that capping
> the council size would in practice just have the effect that it never
> takes in new blood. (The old effect where "science advances one
> retirement at a time".)
>
> I'd be interested to hear what Jupyter/IPython's experience with this
> is, though: they currently have a 10 (!) person steering council, I
> assume they'd love to have more. Having lots of contributors who are
> active and engaged enough to meet the steering council qualifications
> is a good problem to have :-). Technically their situation is slightly
> different because their council runs on regular voting rather than
> Apache-style consensus voting (a luxury they can afford because they
> have a BDFL to step in if regular voting ends up disenfranchising the
> minority), but I sort of get the impression that in practice they just
> don't vote unless they know it will be unanimous, and it's worked out
> for them so far. (To understate the case.)
>
> > As for make-up of the council, I think we need to expand beyond people
> > who have recently contributed core code.
> >
> > Yes, the council does need to have expertise to make technical
> > decisions, but if you think about the likely contentious issues like
> > ABI breakage, a core-code focused view is incomplete. So there should
> > be representation by:
> >
> > Someone(s) with a long history of working with the code -- that
> > institutional memory of why decisions were made the way they were
> > could be key.
>
> Sure -- though I can't really imagine any way of framing a rule like
> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
> is that such a rule would not actually have any effect on the council
> membership in practice.
>
> > Someone(s) that may not have worked on the core code, but is a major
> > player in the community, perhaps as the leader of a Numpy-dependent
> > project. This would provide representation for the broad community.
>
> Pointing out features of the current draft again for reference: In the
> current text, the "NumFOCUS subcommittee" does have an external member
> to provide some oversight. (So mathematically speaking, this means
> that the subcommittee is not a subset -- go figure. I blame IPython.)
> But, this oversight is specifically for financial matters only, not
> technical ones: "This Subcommittee shall NOT make decisions about the
> direction, scope or technical direction of the Project."
>
> Thomas Caswell (one of the leaders of matplotlib) volunteered to be
> our external member to start. We certainly could ask him to sit on the
> steering council as well, but honestly my guess is that this would
> have no effect, either positive or negative. (I know if someone asked
> me to serve on a hypothetical matplotlib steering council, then I
> would just... never do anything, because who am I to second-guess
> matplotlib's actual developers.)
>
> It's not like we don't already hear from downstream projects on a
> regular basis. And if things have gone *so* pear-shaped that we have a
> situation where the steering council feels they need to issue a
> ruling, *and simultaneously* the members of the council are so
> out-of-touch that they don't know or care about the needs of
> downstream projects, then the situation is unsalvageable and we should
> fork and start over.
>
> But I mean, it probably wouldn't hurt either. I'm not super-wedded to
> the current text. I just think we should limit how much effort we
> spend trying to cover every possible situation ahead of time. If we're
> clever enough to solve a problem now hypothetically, then we're
> probably also clever enough to solve it later when it becomes
> concrete.
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] First release candidate for the 1.5.0 series

[Thomas Caswell]

Please give it a try! (linux64 conda builds are available on the tacaswell
anaconda.org channel)

https://github.com/matplotlib/matplotlib/releases/tag/v1.5.0rc1

This release contains many new features.  The highlights include:

  - the object oriented API will now automatically re-draw the figure when
working in the command line
  - automatic unpacking of labeled data into most plotting functions
  - arbitrary style cycling
  - four new perceptually linear color maps
  - mouse-over for pixel values with `imshow`
  - many new rcparams

In addition there are significant improvements to `nbagg` and a complete
overhaul of the c++ bindings to AGG.

Please see the drafts of the [full whats new](
http://matplotlib.org/devdocs/users/whats_new.html#new-in-matplotlib-1-5)
and [api changes](
http://matplotlib.org/devdocs/api/api_changes.html#changes-in-1-5-0)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion