SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec

Showing results of 13841

1 2 3 .. 554 > >> (Page 1 of 554)
From: Chris B. - N. F. <chr...@no...> - 2018年07月06日 22:49:39
MPL does not have a backend that used "real" GPU rendering.
And it’s very hard to make one, due to the really low level nature of
OpenGL and similar APIs, and MPL’s rendering model.
You might try VisPy — it was designed for OpenGL from the start.
-CHB
Sent from my iPhone
On Jul 5, 2018, at 5:37 AM, Francesco Faccenda <f.f...@gm...>
wrote:
Dear all,
I am writing to you because of an issue regarding the use of OpenGL in
cairo backends from matplotlib. As I set a cairo backend with the
instruction matplotlib.Use("WXCairo"), there is evidence that the graphic
computation is not being carried out by the graphic card.
Since the significative amount of plotted data, the chart are heavy and
slow when the user is interacting with them, so a graphic acceleration
would be really appreciated.
As a side note, I am embedding matplotlib canvas on wxPython stages, that’s
why I choose WXCairo as backend, at first. However, setting other backends
(GTKCario, TKCairo, Qt4Cairo, Qt5Cairo etc) while still using wx, still
provides a working code without any errors, even if the graphic card is
still not exploited.
Is this an actual malfunction or am I missing something? What should I do
to run matplotlib graphic computation on a graphic card? Thank you in
advance.
Best regards,
Francesco Faccenda
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
From: Francesco F. <f.f...@gm...> - 2018年07月05日 12:37:38
Dear all,
I am writing to you because of an issue regarding the use of OpenGL in
cairo backends from matplotlib. As I set a cairo backend with the
instruction matplotlib.Use("WXCairo"), there is evidence that the graphic
computation is not being carried out by the graphic card.
Since the significative amount of plotted data, the chart are heavy and
slow when the user is interacting with them, so a graphic acceleration
would be really appreciated.
As a side note, I am embedding matplotlib canvas on wxPython stages, that’s
why I choose WXCairo as backend, at first. However, setting other backends
(GTKCario, TKCairo, Qt4Cairo, Qt5Cairo etc) while still using wx, still
provides a working code without any errors, even if the graphic card is
still not exploited.
Is this an actual malfunction or am I missing something? What should I do
to run matplotlib graphic computation on a graphic card? Thank you in
advance.
Best regards,
Francesco Faccenda
From: Thomas C. <tca...@gm...> - 2017年09月22日 02:37:16
Depending on the exact use case you can get pretty good mileage out of
blitting (See http://matplotlib.org/api/animation_api.html#funcanimation for
an explanation or how it is used in the widgets module).
The best way to make things faster is to just do less work :)
Tom
On Thu, Sep 21, 2017 at 5:14 PM Chris Barker <chr...@no...> wrote:
> On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <
> f.f...@gm...> wrote:
>
>> I have to admit I already stumbled on VisPy while doing my research on
>> the web. Still, I've got a lot of code already working with *matplotlib*.
>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>> to provide the users usefool tools, like lines picking, tooltips, lines
>> copy/paste, square selectors for multiple selections, context menu and so
>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>> at the beginning few lines were managed and noone complained, now that big
>> amout of data has to be displayed, the non-GPU core of the library is
>> starting to show its limits.
>>
>> Since matplotlib is a reference library for this kind of applications, I
>> thought it deserved an update in this direction.
>>
>
> Well, As I understand it, VisPY made some effort to be compatible with the
> MPL API -- but that is going to depend on how much you use the lower-level
> parts f the API -- things like the transform, etc. to take advantage of GPU
> rendering, all the transforms, etc needs to be pushed to the GPU, so the
> architecture (and API) needs to be quite different.
>
>
>> If anyone is willing to do so, I'm available to discuss possible
>> solutions and also provide any help I can give.
>>
>
> As Ben pointed out, and I was trying to make clear -- it really isn't a
> matter of "just" writing an OpenGL backend -- there really needs to be a
> major restructuring.
>
> And VisPy is pretty much that project. Whether it is feature complete,
> robust and maintained enough for your use-cases, I have no idea, but even
> if not -- you'll probably be better off contributing to that effort than
> starting all over with trying to make an GPU_based OPenGL back-end.
>
> However -- maybe there is another option:
>
> Taking full advantage of GPUs does require a full restructuring, but maybe
> there are other ways to get better performance -- for instance, optimizing
> the transform code, etc:
>
> Using the GPU with PyCuda or [what the heck is the name of the more
> general GPU-using lib??]
>
> using numba
>
> Maybe there is still room for Cython, etc....
>
> In short, profiling MPL carefully, to see where the performance
> bottlenecks are:
>
> With modern hardware, actually rendering stuff is no longer the slow part
> of visualization. Rather, it's pushing data to the renderer, transforming
> data etc.
>
> This is why to take advantage of the GPU, you need to do the
> transformations, etc on the GPU -- which the MPL architecture doesn't make
> easy by dropping in a new back-end.
>
> Which is why VisPy built a new architecture from the bottom up.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
From: Chris B. <chr...@no...> - 2017年09月21日 21:14:06
On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <f.f...@gm...
> wrote:
> I have to admit I already stumbled on VisPy while doing my research on the
> web. Still, I've got a lot of code already working with *matplotlib*.
> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
> to provide the users usefool tools, like lines picking, tooltips, lines
> copy/paste, square selectors for multiple selections, context menu and so
> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
> the beginning few lines were managed and noone complained, now that big
> amout of data has to be displayed, the non-GPU core of the library is
> starting to show its limits.
>
> Since matplotlib is a reference library for this kind of applications, I
> thought it deserved an update in this direction.
>
Well, As I understand it, VisPY made some effort to be compatible with the
MPL API -- but that is going to depend on how much you use the lower-level
parts f the API -- things like the transform, etc. to take advantage of GPU
rendering, all the transforms, etc needs to be pushed to the GPU, so the
architecture (and API) needs to be quite different.
> If anyone is willing to do so, I'm available to discuss possible solutions
> and also provide any help I can give.
>
As Ben pointed out, and I was trying to make clear -- it really isn't a
matter of "just" writing an OpenGL backend -- there really needs to be a
major restructuring.
And VisPy is pretty much that project. Whether it is feature complete,
robust and maintained enough for your use-cases, I have no idea, but even
if not -- you'll probably be better off contributing to that effort than
starting all over with trying to make an GPU_based OPenGL back-end.
However -- maybe there is another option:
Taking full advantage of GPUs does require a full restructuring, but maybe
there are other ways to get better performance -- for instance, optimizing
the transform code, etc:
Using the GPU with PyCuda or [what the heck is the name of the more general
GPU-using lib??]
using numba
Maybe there is still room for Cython, etc....
In short, profiling MPL carefully, to see where the performance bottlenecks
are:
With modern hardware, actually rendering stuff is no longer the slow part
of visualization. Rather, it's pushing data to the renderer, transforming
data etc.
This is why to take advantage of the GPU, you need to do the
transformations, etc on the GPU -- which the MPL architecture doesn't make
easy by dropping in a new back-end.
Which is why VisPy built a new architecture from the bottom up.
-CHB
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
From: Thomas C. <tca...@gm...> - 2017年09月20日 17:36:36
Folks,
Matthias as just helped us to install the meeseeks bot than ipython /
jupyter is using to help with their backporting onto matplotlib.
For details, see https://github.com/MeeseeksBox/MeeseeksDev .
The most important command is
@MeeseeksDev backport [to] {branch}
to automatically open a PR with the backport against the correct branch.
Currently the bot will only respond to:
 'tacaswell',
 'QuLogic',
 'anntzer',
 'NelleV',
 'dstansby',
 'efiring',
 'choldgraf'
We will open this up more as we sort out if we like this and how to use it.
Tom
From: Francesco F. <f.f...@gm...> - 2017年09月14日 13:34:11
Thank you, Ben.
unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.
I am starting from this: https://github.com/ChrisBeaumont/mplgl
Can anyone confirm this is the last update we have for this project?
Francesco Faccenda
2017年09月13日 16:21 GMT+02:00 Benjamin Root <ben...@gm...>:
> A bit of background regarding efforts in this area...
>
> A long time ago, some experiments were done to see if an opengl backend
> could be made for matplotlib. The results weren't that great, particularly
> for text rendering, so the effort was dropped. The core developers all
> agree that an opengl backend would be neat to have, but we all have
> limited, if any, experience developing opengl. Furthermore, such a backend
> would likely require a lot of rapid development and trial-n-error. So, we
> encouraged others to go develop a package or two separately, with the eye
> for bringing it back into matplotlib when it was ready. Glumpy and a few
> other projects were born from that prodding.
>
> VisPy was an attempt to consolidate the development efforts for those
> projects. The matplotlib devs had very fruitful discussions with some VisPy
> devs back at SciPy 2015, but the project became non-responsive shortly
> afterwards.
>
> Ben Root
>
>
> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
> f.f...@gm...> wrote:
>
>> Thank you Chris for your reply.
>>
>> I have to admit I already stumbled on VisPy while doing my research on
>> the web. Still, I've got a lot of code already working with *matplotlib*.
>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>> to provide the users usefool tools, like lines picking, tooltips, lines
>> copy/paste, square selectors for multiple selections, context menu and so
>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>> at the beginning few lines were managed and noone complained, now that big
>> amout of data has to be displayed, the non-GPU core of the library is
>> starting to show its limits.
>>
>> Since matplotlib is a reference library for this kind of applications, I
>> thought it deserved an update in this direction. If anyone is willing to do
>> so, I'm available to discuss possible solutions and also provide any help I
>> can give.
>>
>> Best regards,
>> Francesco Faccenda
>>
>> 2017年09月13日 0:46 GMT+02:00 Chris Barker <chr...@no...>:
>>
>>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>>> f.f...@gm...> wrote:
>>>
>>>> But there’s a good news, I have a nice GPU available (an NVIDIA Tesla
>>>> K40c), so I’d like to know if there is a way to make matplotlib run on it,
>>>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>>
>>>
>>> I tihnk you want VisPy:
>>>
>>> https://vispy.readthedocs.io/en/latest/
>>>
>>> It's a plotting package with a kinda like matplotlib API, built on
>>> OpenGL.
>>>
>>> Unfortunately, it doesn't look like it's been updated in a while -- from
>>> teh docs. But the gitHub project is active:
>>>
>>> https://github.com/vispy/vispy
>>>
>>> So maybe it's only the docs that haven't been updated!
>>>
>>> But probably a much better option than trying to shoehorn GPU rendering
>>> into MPL.
>>>
>>> The problem is that while MPL was designed to be "backend" independent
>>> -- so it is "easy" to plug in an alternative renderer, the rendering model
>>> is not really well suited to GPU rendering -- it would take a lot of
>>> refactoring to really be able to take advantage of the graphics card.
>>>
>>> -CHB
>>>
>>>
>>> --
>>>
>>> Christopher Barker, Ph.D.
>>> Oceanographer
>>>
>>> Emergency Response Division
>>> NOAA/NOS/OR&R (206) 526-6959 voice
>>> 7600 Sand Point Way NE
>>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>> (206) 526-6329 fax
>>> Seattle, WA 98115 (206) 526-6317 main reception
>>>
>>> Chr...@no...
>>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@py...
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>>
>
From: Francesco F. <f.f...@gm...> - 2017年09月13日 07:31:44
Thank you Chris for your reply.
I have to admit I already stumbled on VisPy while doing my research on the
web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events* to
provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.
Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction. If anyone is willing to do
so, I'm available to discuss possible solutions and also provide any help I
can give.
Best regards,
Francesco Faccenda
2017年09月13日 0:46 GMT+02:00 Chris Barker <chr...@no...>:
> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
> f.f...@gm...> wrote:
>
>> But there’s a good news, I have a nice GPU available (an NVIDIA Tesla
>> K40c), so I’d like to know if there is a way to make matplotlib run on it,
>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>
>
> I tihnk you want VisPy:
>
> https://vispy.readthedocs.io/en/latest/
>
> It's a plotting package with a kinda like matplotlib API, built on OpenGL.
>
> Unfortunately, it doesn't look like it's been updated in a while -- from
> teh docs. But the gitHub project is active:
>
> https://github.com/vispy/vispy
>
> So maybe it's only the docs that haven't been updated!
>
> But probably a much better option than trying to shoehorn GPU rendering
> into MPL.
>
> The problem is that while MPL was designed to be "backend" independent --
> so it is "easy" to plug in an alternative renderer, the rendering model is
> not really well suited to GPU rendering -- it would take a lot of
> refactoring to really be able to take advantage of the graphics card.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE
> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
> (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
From: Chris B. <chr...@no...> - 2017年09月12日 23:17:46
On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <f.f...@gm...>
wrote:
> But there’s a good news, I have a nice GPU available (an NVIDIA Tesla
> K40c), so I’d like to know if there is a way to make matplotlib run on it,
> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>
I tihnk you want VisPy:
https://vispy.readthedocs.io/en/latest/
It's a plotting package with a kinda like matplotlib API, built on OpenGL.
Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:
https://github.com/vispy/vispy
So maybe it's only the docs that haven't been updated!
But probably a much better option than trying to shoehorn GPU rendering
into MPL.
The problem is that while MPL was designed to be "backend" independent --
so it is "easy" to plug in an alternative renderer, the rendering model is
not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.
-CHB
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
From: Francesco F. <f.f...@gm...> - 2017年09月12日 15:47:48
Greetings to everyone,
I'm Francesco Faccenda and I'm developing a sfotware in *python* where I
need to show some charts, so I chose matplotlib as a plot library. Anyway,
since lots of data are shown on matplotlip stages (thousands of curves with
hundreds of points each), the charts become very heavy, interactive events
and functions start lagging and users experience becomes unacceptable.
But there’s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I’d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
Do you have any suggestion how to do it? I never went through matplotlib
source code before and I don’t know if this feature has already been
scheduled for future releases or it’s something completely new.
I would really appreciate some suggestions on this subject.
Thank you in advance.
Best regards,
Francesco
From: Thomas C. <tca...@gm...> - 2017年07月31日 12:57:02
That wording is unclear. Could you open a PR on github to fix that? For
small wording changes like this you can do it through the github web
interface.
Tom
On Mon, Jul 31, 2017 at 6:52 AM <kei...@bt...> wrote:
> "*shrink* 1.0; fraction by which to shrink the colorbar"
>
>
> should be something like
>
>
> "*shrink* 1.0; fraction by which to scale the size size of the colorbar"
>
>
> since the original wording implies that a bigger shrink causes
> a smaller size.
>
>
>
> Keith
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
"shrink 1.0; fraction by which to shrink the colorbar"
should be something like
"shrink 1.0; fraction by which to scale the size size of the colorbar"
since the original wording implies that a bigger shrink causes a smaller size.
Keith
From: Thomas C. <tca...@gm...> - 2017年07月25日 16:50:18
Folks,
Sorry for the late notice. This weeks call have been moved to today at the
normal time (1500 EDT).
Tom
From: Joe K. <jof...@gm...> - 2017年02月17日 23:03:09
Well, if Freetype were only distributed under the GPL, you couldn't
distribute matplotlib in binary form without providing the source code.
However, Freetype is distributed under more than one license. (see:
https://www.freetype.org/license.html )
Because it's distributed under a BSD-style license in addition to the GPL,
it can be distributed in binary form, subject to an accreditation clause:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/FTL.TXT
In the past, I have gotten approval from corporate lawyers at a very large
company to use freetype (and matplotlib) in an application that was being
distributed in binary form. The dual-licensing of freetype was key in that
particular case.
Or that's my take on it, anyway. I'm not a Lawyer, so don't consider this
legal advice in any way.
Cheers!
-Joe
On Fri, Feb 17, 2017 at 4:52 PM, Paul Hobson <pmh...@gm...> wrote:
> Chad,
>
> My recollections is that matplotlib doesn't distribute the source code to
> FreeType, it only uses it as a dependency. As such, MPL is in the clear
> with its more permissive licensing.
> -Paul
>
> On Fri, Feb 17, 2017 at 12:45 PM, CAB <ca...@ya...> wrote:
>
>> Hi, All,
>>
>> I just went to install matplotlib version 2.0.0, and it has a dependency
>> called "freetype". This software appears to be licensed under GPL3. My
>> reading of that latter license is that, if someone wanted to distribute a
>> compiled version of a program requiring matplotlib, that entire program
>> would fall under the GPL3 license. I'm sure that would be a non-starter
>> for many, many projects.
>>
>> Does anyone have any takes on this?
>>
>> Chad
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
From: Paul H. <pmh...@gm...> - 2017年02月17日 22:52:38
Chad,
My recollections is that matplotlib doesn't distribute the source code to
FreeType, it only uses it as a dependency. As such, MPL is in the clear
with its more permissive licensing.
-Paul
On Fri, Feb 17, 2017 at 12:45 PM, CAB <ca...@ya...> wrote:
> Hi, All,
>
> I just went to install matplotlib version 2.0.0, and it has a dependency
> called "freetype". This software appears to be licensed under GPL3. My
> reading of that latter license is that, if someone wanted to distribute a
> compiled version of a program requiring matplotlib, that entire program
> would fall under the GPL3 license. I'm sure that would be a non-starter
> for many, many projects.
>
> Does anyone have any takes on this?
>
> Chad
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
From: Paul H. <pmh...@gm...> - 2017年02月02日 16:58:21
It appears that the build of matplotlib in conda-forge does not require
pyqt5:
https://github.com/conda-forge/matplotlib-feedstock/blob/master/recipe/meta.yaml
So in your case, I would do:
conda remove pyqt5 matplotlib
conda install --channel=conda-forge matplotlib
On Thu, Feb 2, 2017 at 8:48 AM, Benjamin Root <ben...@gm...> wrote:
> no, pyqt5 is not a dependency for matplotlib. this looks like a conda
> packaging issue.
>
> Side note: the sourceforge mailing list is deprecated. Please use the
> python.org version instead (you'll have to re-register).
>
> Ben Root
>
>
> On Thu, Feb 2, 2017 at 11:43 AM, Osborn, Raymond <ro...@an...> wrote:
>
>> I just created a new conda environment with Matplotlib included, and it
>> duly installed matplotlib: 2.0.0-np111py27_0. It installed PyQt5 by
>> default, whereas I need PyQt4, but when I installed PyQt4 (conda install
>> pyqt=4), it automatically downgraded Matplotlib to 1.5.1.
>> --------
>> The following packages will be DOWNGRADED due to dependency conflicts:
>>
>> matplotlib: 2.0.0-np111py27_0 --> 1.5.1-np111py27_0
>> pyqt: 5.6.0-py27_2 --> 4.11.4-py27_4
>> qt: 5.6.2-0 --> 4.8.7-4
>> --------
>> Is PyQt5 really a dependency for Matplotlib v2? I have been testing
>> release candidate versions of Matplotlib v2 without any problem. This will
>> cause headaches to my users who want the latest features.
>>
>> Ray
>> --
>> Ray Osborn, Senior Scientist
>> Materials Science Division
>> Argonne National Laboratory
>> Argonne, IL 60439, USA
>> Phone: +1 (630) 252-9011 <(630)%20252-9011>
>> Email: RO...@an...
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
From: Benjamin R. <ben...@gm...> - 2017年02月02日 16:48:52
no, pyqt5 is not a dependency for matplotlib. this looks like a conda
packaging issue.
Side note: the sourceforge mailing list is deprecated. Please use the
python.org version instead (you'll have to re-register).
Ben Root
On Thu, Feb 2, 2017 at 11:43 AM, Osborn, Raymond <ro...@an...> wrote:
> I just created a new conda environment with Matplotlib included, and it
> duly installed matplotlib: 2.0.0-np111py27_0. It installed PyQt5 by
> default, whereas I need PyQt4, but when I installed PyQt4 (conda install
> pyqt=4), it automatically downgraded Matplotlib to 1.5.1.
> --------
> The following packages will be DOWNGRADED due to dependency conflicts:
>
> matplotlib: 2.0.0-np111py27_0 --> 1.5.1-np111py27_0
> pyqt: 5.6.0-py27_2 --> 4.11.4-py27_4
> qt: 5.6.2-0 --> 4.8.7-4
> --------
> Is PyQt5 really a dependency for Matplotlib v2? I have been testing
> release candidate versions of Matplotlib v2 without any problem. This will
> cause headaches to my users who want the latest features.
>
> Ray
> --
> Ray Osborn, Senior Scientist
> Materials Science Division
> Argonne National Laboratory
> Argonne, IL 60439, USA
> Phone: +1 (630) 252-9011
> Email: RO...@an...
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
From: Osborn, R. <ro...@an...> - 2017年02月02日 16:43:09
I just created a new conda environment with Matplotlib included, and it duly installed matplotlib: 2.0.0-np111py27_0. It installed PyQt5 by default, whereas I need PyQt4, but when I installed PyQt4 (conda install pyqt=4), it automatically downgraded Matplotlib to 1.5.1.
--------
The following packages will be DOWNGRADED due to dependency conflicts:
 matplotlib: 2.0.0-np111py27_0 --> 1.5.1-np111py27_0
 pyqt: 5.6.0-py27_2 --> 4.11.4-py27_4 
 qt: 5.6.2-0 --> 4.8.7-4
--------
Is PyQt5 really a dependency for Matplotlib v2? I have been testing release candidate versions of Matplotlib v2 without any problem. This will cause headaches to my users who want the latest features.
Ray
-- 
Ray Osborn, Senior Scientist
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: RO...@an...
From: Nelle V. <nel...@gm...> - 2016年10月29日 21:46:06
Attachments: matplotlib_labels.png
Hi team,
We've been discussing at several occasions of cleaning up our GitHub
labels, and merging some. In order to guide the discussion of which
labels to keep and to move, I've analysed a bit what where the labels
we were using. Attached is a plot of the number of issues (including
PRs) open and closed for each labels.
Maybe we have too many labels? Most of them don't seem actively used.
For example, py3k seem to be used 4 times, only on closed tickets/PR.
I've done a similar analysis on scikit-image, scikit-learn and
ipython. Some labels seem to be consistently used quite highly across
all projects: the 3 difficulty levels, bug, ENH, DOC.
I'm playing a bit with the github API this afternoon, so if any other
statistics is useful, just let me know.
Cheers,
N
From: Thomas C. <tca...@gm...> - 2016年10月19日 12:21:36
We have moved our mailing lists hosting to python.org, the source-forge
lists should no longer be used.
The new lists are
mat...@py...
https://mail.python.org/mailman/listinfo/matplotlib-devel
mat...@py...
https://mail.python.org/mailman/listinfo/matplotlib-users
mat...@py...
https://mail.python.org/mailman/listinfo/matplotlib-announce
To unsubscribe from the current lists see
http://www.list.org/mailman-member/node14.html
The auto-responders on the source-forge lists have been set to be more
aggressive.
Tom
From: Nelle V. <nel...@gm...> - 2016年10月18日 18:47:42
Hello everyone,
Nathan just proposed names for the new vega colors:
https://github.com/matplotlib/matplotlib/issues/7248
As Antony mentioned, getting the names right is quite important as
this is probably going to be the default for the next 10 years.
Cheers,
N
From: Nelle V. <nel...@gm...> - 2016年09月30日 16:26:01
Hello matplotlib-devs !
As some of you may know, I am involved with Stéfan van der Walt in an
initiative around Berkeley campus known as the "BIDS Machine Shop". It
consists of trying to bridge the gap in software development and best
practises around campus by introducing undergraduates to research
software development and open source communities.
Stéfan and I will manage students on different research projects and
open source packages, including matplotlib and scikit-image. I'll be
managing the matplotlib side of the machine shop, and you should see
(I hope) a bunch of contributions from our students popping up on
github.
I am going to create a label "Machine Shop" and a project "Machine
Shop" for the duration of the semester (maybe longer if this
experiment is a success). I'll assign "easy fix" tickets to our
students. I expect them to do peer-review before opening the PRs for
broader reviews. Please, wait for the tag "need review" to be set on
those PR before reviewing theme. Once they fixed these issues, I'll
assign them to more complex tasks.
If you have questions/suggestions, don't hesitate to chime in.
Thanks,
Nelle
PS: we should have a website up and running soon with more details.
From: Paul H. <pmh...@gm...> - 2016年08月26日 20:05:34
Madhav,
Do I understand correctly that you want to generate a 14k x 14k image in
matplotlib? Are there computer monitors available that can display such an
image in native quality?
-p
On Thu, Aug 25, 2016 at 11:59 PM, Jens Nielsen <jen...@gm...>
wrote:
> Hi Madhav
>
> We have moved our mailing lists off source forge to python.org I
> recommend that you use one of the mailing lists here see the readme
> https://github.com/matplotlib/matplotlib/blob/master/README.rst this type
> of question is probably most suited for the user list rather than the
> developer list.
>
> Did you recently find a link to the old one? In which case we would like
> to know where so we can update the reference.
>
> Back to your question, If I understand correctly I think what you are
> looking for is a data cursor that can show you information when you click
> on a specific point.
>
> https://pypi.python.org/pypi/mpldatacursor/ is one such package.
>
> Best Jens
> On 2016年8月25日 at 21:57, Madhav Sharan <ms...@us...> wrote:
>
>> *Sending again after joining list*
>>
>> Hi matplotlib users,
>>
>> I am trying to generate a fairly huge heatmap of a 7000 X 7000. This is a
>> 2D matrix in which each cell i,j have a similarity score between ith and
>> jth label.
>>
>> PFA my first attempt (code - [0]).
>>
>> Now I am looking for better visualization which can also tell me more
>> about *cell level information*. To start with can I create a higher
>> resolution image such that I have at least 2X2 pixel for every cell.
>> Resultant should be of resolution 14000 X 14000
>>
>> Are there more features like- By some user interaction can I know what
>> pair it represent? and what's the similarity score?
>>
>> [0] https://github.com/smadha/hadoop-pot/blob/cartesian/src/
>> main/bin/similarity_heatmap.py
>>
>> --
>> Madhav Sharan
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
From: Jens N. <jen...@gm...> - 2016年08月26日 06:59:25
Hi Madhav
We have moved our mailing lists off source forge to python.org I recommend
that you use one of the mailing lists here see the readme
https://github.com/matplotlib/matplotlib/blob/master/README.rst this type
of question is probably most suited for the user list rather than the
developer list.
Did you recently find a link to the old one? In which case we would like to
know where so we can update the reference.
Back to your question, If I understand correctly I think what you are
looking for is a data cursor that can show you information when you click
on a specific point.
https://pypi.python.org/pypi/mpldatacursor/ is one such package.
Best Jens
On 2016年8月25日 at 21:57, Madhav Sharan <ms...@us...> wrote:
> *Sending again after joining list*
>
> Hi matplotlib users,
>
> I am trying to generate a fairly huge heatmap of a 7000 X 7000. This is a
> 2D matrix in which each cell i,j have a similarity score between ith and
> jth label.
>
> PFA my first attempt (code - [0]).
>
> Now I am looking for better visualization which can also tell me more
> about *cell level information*. To start with can I create a higher
> resolution image such that I have at least 2X2 pixel for every cell.
> Resultant should be of resolution 14000 X 14000
>
> Are there more features like- By some user interaction can I know what
> pair it represent? and what's the similarity score?
>
> [0]
> https://github.com/smadha/hadoop-pot/blob/cartesian/src/main/bin/similarity_heatmap.py
>
> --
> Madhav Sharan
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
From: Madhav S. <ms...@us...> - 2016年08月25日 20:56:20
*Sending again after joining list*
Hi matplotlib users,
I am trying to generate a fairly huge heatmap of a 7000 X 7000. This is a
2D matrix in which each cell i,j have a similarity score between ith and
jth label.
PFA my first attempt (code - [0]).
Now I am looking for better visualization which can also tell me more
about *cell
level information*. To start with can I create a higher resolution image
such that I have at least 2X2 pixel for every cell. Resultant should be of
resolution 14000 X 14000
Are there more features like- By some user interaction can I know what pair
it represent? and what's the similarity score?
[0] https://github.com/smadha/hadoop-pot/blob/cartesian/src/main
/bin/similarity_heatmap.py
--
Madhav Sharan
Hello Benjamin,
last weekend (after more than a year... :-[ ) I found some spare time to 
refactor a bit the solution I implemented to solve the axis synchronisation.
I have answered my own question on stackoverflow 
(http://stackoverflow.com/questions/28239054/update-the-x-axis-of-a-matplotlib-subplot-according-to-the-y-axis-of-a-different/37265661#37265661)
and I have shared on github 
(https://github.com/apbard/OrthogonalProjection) a simple class that 
allows to easily make orthogonal projections plots with full axis 
syncronisation and support for different basic plot types.
Thanks again for the hint and sorry for the delay...
Alessandro
On 12/02/2015 19:58, Alessandro Pietro Bardelli wrote:
> thanks for your answer.
> I have played a bit with the callbacks and seems very promising.
> i'll work on it in the weekend and drop an email as soon as I have 
> tested it properly :)
> thanks again
>
> Alessandro
>
> On 12/02/2015 15:35, Benjamin Root wrote:
>> Sharing the same axis across subplots is implemented via matplotlib's 
>> interactive framework, and is available by default. Glue is built on 
>> top of matplotlib, extending its interactive framework with many 
>> additional tools. Yes, it might be overkill for this singular task, 
>> but implementing orthogonal axis sharing isn't trivial, either, so 
>> suggesting a pre-packaged solution is merely pragmatic.
>>
>> Essentially, one would have to register callbacks for changes in each 
>> of the parent subplot's axis. This, in of itself, isn't really all 
>> that difficult once one learns the event framework. I think what 
>> might be very tricky is doing it for the 3d axes. As the de facto 
>> maintainer of mplot3d, I have never really tested axis sharing for 
>> mplot3d. I suspect that it would work exactly as you'd expect for the 
>> x and y axes, but the z axis may prove to be quirky. I don't know, I 
>> haven't ever tried it out. In general, the z-axis implementation is a 
>> bit of a kludge, so things tend to be different for it...
>>
>> Here is an example of how to register callbacks to changes in a 
>> particular axis. Hopefully, it can give you a nice leg up on the 
>> problem. Let me know if you have problems with the z-axis, I might be 
>> able to help sort it out. If you can get this to work, I would 
>> certainly love to include it in the gallery.
>> http://matplotlib.org/examples/event_handling/viewlims.html
>>
>> Cheers!
>> Ben Root
>>
>>
>> On Thu, Feb 12, 2015 at 4:32 AM, Alessandro Pietro Bardelli 
>> <ale...@he...> wrote:
>>
>> Thanks for the answer.
>> Glue seems a quite cool project but it is also a bit overkill for
>> this specific task, isn't it?
>> Basically I just would like tell sharex to point the Yaxis of the
>> axes object.
>> Isn't there a way to do this within matplotlib?
>> thanks
>>
>> Alessandro
>>
>> On 11/02/2015 16:41, Benjamin Root wrote:
>>> Sounds to me like you want to use glue:
>>> http://www.glueviz.org/en/stable/
>>>
>>>
>>> On Wed, Feb 11, 2015 at 3:15 AM, Alessandro Pietro Bardelli
>>> <ale...@he...
>>> <mailto:ale...@he...>> wrote:
>>>
>>> I would like to plot an orthogonal projection (like this one
>>> http://i.stack.imgur.com/DnNds.jpg) using matplotlib
>>> possibly including also the 3D subplot. All the pictures
>>> should share common axes.
>>>
>>> |fig =plt.figure()ax =fig.add_subplot(221,title="XZ")bx
>>> =fig.add_subplot(222,title="YZ",sharey=ax)cx
>>> =fig.add_subplot(223,title="XY",sharex=ax,sharey=[something
>>> like bx.Xaxis])dx
>>> =fig.add_subplot(224,title="XYZ",projection="3d",sharex=ax,sharey=bx,sharez=[something
>>> like bx.Yaxis]|
>>>
>>> The problem is that I have to "link" on X axis of a plot
>>> with the Y one of another and
>>> Is there a way to accomplish this?
>>>
>>> Thanks
>>>
>>> Alessandro
>>>
>>> p.s. i have posted this question also on StackOverflow:
>>> http://stackoverflow.com/questions/28239054/update-x-axis-of-a-subplot-according-to-the-y-axis-of-another-one-in-python-matp
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>> -- 
>>
>> ----------------------------------
>> Alessandro Pietro Bardelli
>>
>> HENESIS s.r.l.
>> P.IVA (VAT. N.) IT02280660354
>> Viale dei Mille, 108
>> 43125 PARMA (IT)
>>
>> Email: ale...@he...
>> <mailto:ale...@he...>
>>
>> Tel: (+39)05211854211 <tel:%28%2B39%2905211854211>
>> Fax: (+39)05211854515 <tel:%28%2B39%2905211854515>
>> SkypeID: henesis_srl
>> Web: www.henesis.eu <http://www.henesis.eu>
>> ----------------------------------
>>
>>
>
> -- 
>
> ----------------------------------
> Alessandro Pietro Bardelli
>
> HENESIS s.r.l.
> P.IVA (VAT. N.) IT02280660354
> Viale dei Mille, 108
> 43125 PARMA (IT)
>
> Email: ale...@he...
>
> Tel: (+39)05211854211
> Fax: (+39)05211854515
> SkypeID: henesis_srl
> Web: www.henesis.eu
> ----------------------------------
-- 
----------------------------------
Alessandro Pietro Bardelli
Camlin Italy S.r.l - part of Camlin group
P.IVA (VAT. N.) IT02280660354
Strada Budellungo, 2
43123 PARMA (IT)
Email: ale...@he...
Tel: (+39)05211854211 (extension 14)
Fax: (+39)05211854515
Web: www.henesis.eu
----------------------------------
127 messages has been excluded from this view by a project administrator.

Showing results of 13841

1 2 3 .. 554 > >> (Page 1 of 554)
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /