Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
On 08/16/2011 12:42 AM, Vlastimil Brom wrote: 2011/8/16 Eric Firingefir...@hawaii.edu: On 07/25/2011 08:21 AM, Ben Breslauer wrote: I think that I have found the problem here. Line2D.draw() (and I presume other Artist subclasses) calls gc.set_foreground(self._color) ... gc.set_alpha(self._alpha) self._color is defined by the color kwarg, whether it be a hex value, 3-tuple, 4-tuple, or something else. self._alpha is defined by the alpha kwarg, but if the alpha kwarg is None, it is not overwritten with color[3]. Therefore, using color=(R,G,B,A) does not set alpha correctly. I'm not sure the best (i.e. most matplotlib-like) way to change this so that the A value gets used iff alpha is None, but I've attached a patch that does it one way (diff'ed against the github master, commit 67b1cd650f574f9c53ce). I know the patch is less than ideal, as it adds kwarg-specific handling into a place where none had previously been done, and it's also in a for loop. Maybe it would be better to do the checking along with the scalex and scaley pops? Alpha handling is a real can of worms; it has gotten better, but as you note, there are still problems. Unfortunately, I don't think your proposed solution will work in general, because self._color could be a 4-letter string, like gray, in which case alpha would be set to y, and that would not be good at all. I suspect the right place to solve the problem is down in the GraphicsContext--although I thought I had already straightened that out some time ago. ... Eric Separately, I noticed that backend_bases.GraphicsContextBase.set_foreground claims to only expect an RGB definition, and not an RGBA definition. As such, I think that it should call self._rgb = colors.colorConverter.to_rgb(fg) instead of self._rgb = colors.colorConverter.to_rgba(fg) since that will make self._rgb a 3-tuple instead of a 4-tuple. Ben ... Just a remark for this recent proposed patch, as I unfortunately don't know the implications for the whole codebase. I believe, that the condition added in the patch if len(line._color) == 4 and line._alpha == None: could be adjusted to e.g.: if isinstance(line._color, tuple) and len(line._color) == 4 and line._alpha == None If the alpha value can be set in the color-tuple (for #RRGGBBAA some parsing would be needed, if it is accepted). Possibly the _alpha should be replace with tha alpha value of the colour passed this way like http://matplotlib.sourceforge.net/api/colors_api.html#matplotlib.colors.ColorConverter.to_rgba If arg is an RGBA sequence and alpha is not None, alpha will replace the original A. But as has been suggested already, it might be better adressed in some more general way, than in this single function. See https://github.com/matplotlib/matplotlib/pull/423 Eric regards, vbr -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
On 07/25/2011 08:21 AM, Ben Breslauer wrote: I think that I have found the problem here. Line2D.draw() (and I presume other Artist subclasses) calls gc.set_foreground(self._color) ... gc.set_alpha(self._alpha) self._color is defined by the color kwarg, whether it be a hex value, 3-tuple, 4-tuple, or something else. self._alpha is defined by the alpha kwarg, but if the alpha kwarg is None, it is not overwritten with color[3]. Therefore, using color=(R,G,B,A) does not set alpha correctly. I'm not sure the best (i.e. most matplotlib-like) way to change this so that the A value gets used iff alpha is None, but I've attached a patch that does it one way (diff'ed against the github master, commit 67b1cd650f574f9c53ce). I know the patch is less than ideal, as it adds kwarg-specific handling into a place where none had previously been done, and it's also in a for loop. Maybe it would be better to do the checking along with the scalex and scaley pops? Alpha handling is a real can of worms; it has gotten better, but as you note, there are still problems. Unfortunately, I don't think your proposed solution will work in general, because self._color could be a 4-letter string, like gray, in which case alpha would be set to y, and that would not be good at all. I suspect the right place to solve the problem is down in the GraphicsContext--although I thought I had already straightened that out some time ago. As Ben notes, you should file a bug report. Given that the handling of colors and alpha is inherently tricky (and backend-dependent--ps doesn't support alpha at all), solving the problem well is going to take a bit of time and care, most likely--and testing to make sure that a fix in one place doesn't cause a bug in another. I think we should leave it alone until after the next release. Eric Separately, I noticed that backend_bases.GraphicsContextBase.set_foreground claims to only expect an RGB definition, and not an RGBA definition. As such, I think that it should call self._rgb = colors.colorConverter.to_rgb(fg) instead of self._rgb = colors.colorConverter.to_rgba(fg) since that will make self._rgb a 3-tuple instead of a 4-tuple. Ben On Sat, Jul 23, 2011 at 3:13 PM, Ben Breslauer bbresla...@gmail.com mailto:bbresla...@gmail.com wrote: Hi, I'm trying to fade some data, using alpha values, that I am plotting with Axes.plot(). I can recreate this problem with 1 line of pylab.plot. If I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0,.2), linewidth=7) then I get the equivalent of pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7) i.e. it does not use the alpha value. However, if instead I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7, alpha=.2) then the line is faded out appropriately. The plot documentation indicates that RGBA tuples should be valid, so I'm wondering if this is a bug. Maybe alpha is defaulting to 1 or None and then not being overwritten if color is a 4-tuple? I'm using Arch Linux with kernel 2.6.39, matplotlib 1.0.1 from the Arch repo, and the Qt4 backend. My installed Qt version is 4.7.3, and I am using KDE 4.6.5. Below is verbose-debug output. Thanks for any help! Ben $HOME=/home/ben CONFIGDIR=/home/ben/.matplotlib matplotlib data path /usr/lib/python2.7/site-packages/matplotlib/mpl-data loaded rc file /usr/lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc matplotlib version 1.0.1 verbose.level debug interactive is False units is False platform is linux2 loaded modules: ['heapq', 'numpy.core.info http://numpy.core.info', 'distutils', 'numpy.lib.format', 'functools', 'pylab', '_bisect', 'subprocess', 'sysconfig', 'gc', 'matplotlib.tempfile', 'distutils.sysconfig', 'ctypes._endian', 'encodings.encodings', 'pyparsing', 'matplotlib.colors', 'numpy.core.numerictypes', 'numpy.testing.sys', 'numpy.lib.__future__', 'numpy.fft.types', 'numpy.ma.cPickle', 'struct', 'numpy.matrixlib.defmatrix', 'numpy.random.info http://numpy.random.info', 'tempfile', 'numpy.compat.types', 'pprint', 'numpy.linalg', 'matplotlib.threading', 'numpy.core.machar', 'numpy.testing.types', 'numpy.testing', 'collections', 'numpy.polynomial.sys', 'unittest.sys', 'numpy.core.umath', 'unittest.main', 'distutils.types', 'numpy.testing.operator', 'numpy.core.scalarmath', 'numpy.ma.sys', 'zipimport', 'string', 'matplotlib.subprocess', 'numpy.testing.os', 'unittest.functools', 'numpy.lib.arraysetops', 'numpy.testing.unittest', 'numpy.lib.math', 'encodings.utf_8', 'matplotlib.__future__', 'unittest.types', 'unittest.util', 'numpy.testing.re http://numpy.testing.re', 'numpy.version', 'numpy.lib.re http://numpy.lib.re', 'distutils.re http://distutils.re', 'numpy.matrixlib.sys', 'ctypes.os',
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
2011/8/16 Eric Firing efir...@hawaii.edu: On 07/25/2011 08:21 AM, Ben Breslauer wrote: I think that I have found the problem here. Line2D.draw() (and I presume other Artist subclasses) calls gc.set_foreground(self._color) ... gc.set_alpha(self._alpha) self._color is defined by the color kwarg, whether it be a hex value, 3-tuple, 4-tuple, or something else. self._alpha is defined by the alpha kwarg, but if the alpha kwarg is None, it is not overwritten with color[3]. Therefore, using color=(R,G,B,A) does not set alpha correctly. I'm not sure the best (i.e. most matplotlib-like) way to change this so that the A value gets used iff alpha is None, but I've attached a patch that does it one way (diff'ed against the github master, commit 67b1cd650f574f9c53ce). I know the patch is less than ideal, as it adds kwarg-specific handling into a place where none had previously been done, and it's also in a for loop. Maybe it would be better to do the checking along with the scalex and scaley pops? Alpha handling is a real can of worms; it has gotten better, but as you note, there are still problems. Unfortunately, I don't think your proposed solution will work in general, because self._color could be a 4-letter string, like gray, in which case alpha would be set to y, and that would not be good at all. I suspect the right place to solve the problem is down in the GraphicsContext--although I thought I had already straightened that out some time ago. ... Eric Separately, I noticed that backend_bases.GraphicsContextBase.set_foreground claims to only expect an RGB definition, and not an RGBA definition. As such, I think that it should call self._rgb = colors.colorConverter.to_rgb(fg) instead of self._rgb = colors.colorConverter.to_rgba(fg) since that will make self._rgb a 3-tuple instead of a 4-tuple. Ben ... Just a remark for this recent proposed patch, as I unfortunately don't know the implications for the whole codebase. I believe, that the condition added in the patch if len(line._color) == 4 and line._alpha == None: could be adjusted to e.g.: if isinstance(line._color, tuple) and len(line._color) == 4 and line._alpha == None If the alpha value can be set in the color-tuple (for #RRGGBBAA some parsing would be needed, if it is accepted). Possibly the _alpha should be replace with tha alpha value of the colour passed this way like http://matplotlib.sourceforge.net/api/colors_api.html#matplotlib.colors.ColorConverter.to_rgba If arg is an RGBA sequence and alpha is not None, alpha will replace the original A. But as has been suggested already, it might be better adressed in some more general way, than in this single function. regards, vbr -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
On Tue, Aug 16, 2011 at 12:22 AM, Benjamin Root ben.r...@ou.edu wrote: On Monday, August 15, 2011, Ben Breslauer bbresla...@gmail.com wrote: Hi, Has anyone else noticed this behavior? For the devs, do you prefer a github bug to the SF list? Ben I have not personally observed this, but usually, people don't specify rgba tuples for plot. I think the lack of response is due to our focus on larger bugs right now for the upcoming release. Therefore, it would probably be best to file a bug report with your patch so that we have a record of it. The fuller patch might be more involved (consider scatter and other functions). Plus, we would likely need to consider what to do if both an rgba tuple and alpha were specified, As a rule of thumb, if we don't respond on list, file a bug report. Thanks for bringing this to our attention! Ben Root Ben, Eric, and Vlastimil, Thanks for the responses. I will try and submit a bug report soon, and perhaps a patch if I can come up with something more complete, though obviously I don't know the matplotlib code base all that well. And I'll keep that rule of thumb in mind in the future. Ben -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
Hi, Has anyone else noticed this behavior? For the devs, do you prefer a github bug to the SF list? Ben On Mon, Jul 25, 2011 at 2:21 PM, Ben Breslauer bbresla...@gmail.com wrote: I think that I have found the problem here. Line2D.draw() (and I presume other Artist subclasses) calls gc.set_foreground(self._color) ... gc.set_alpha(self._alpha) self._color is defined by the color kwarg, whether it be a hex value, 3-tuple, 4-tuple, or something else. self._alpha is defined by the alpha kwarg, but if the alpha kwarg is None, it is not overwritten with color[3]. Therefore, using color=(R,G,B,A) does not set alpha correctly. I'm not sure the best (i.e. most matplotlib-like) way to change this so that the A value gets used iff alpha is None, but I've attached a patch that does it one way (diff'ed against the github master, commit 67b1cd650f574f9c53ce). I know the patch is less than ideal, as it adds kwarg-specific handling into a place where none had previously been done, and it's also in a for loop. Maybe it would be better to do the checking along with the scalex and scaley pops? Separately, I noticed that backend_bases.GraphicsContextBase.set_foreground claims to only expect an RGB definition, and not an RGBA definition. As such, I think that it should call self._rgb = colors.colorConverter.to_rgb(fg) instead of self._rgb = colors.colorConverter.to_rgba(fg) since that will make self._rgb a 3-tuple instead of a 4-tuple. Ben On Sat, Jul 23, 2011 at 3:13 PM, Ben Breslauer bbresla...@gmail.comwrote: Hi, I'm trying to fade some data, using alpha values, that I am plotting with Axes.plot(). I can recreate this problem with 1 line of pylab.plot. If I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0,.2), linewidth=7) then I get the equivalent of pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7) i.e. it does not use the alpha value. However, if instead I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7, alpha=.2) then the line is faded out appropriately. The plot documentation indicates that RGBA tuples should be valid, so I'm wondering if this is a bug. Maybe alpha is defaulting to 1 or None and then not being overwritten if color is a 4-tuple? I'm using Arch Linux with kernel 2.6.39, matplotlib 1.0.1 from the Arch repo, and the Qt4 backend. My installed Qt version is 4.7.3, and I am using KDE 4.6.5. Below is verbose-debug output. Thanks for any help! Ben $HOME=/home/ben CONFIGDIR=/home/ben/.matplotlib matplotlib data path /usr/lib/python2.7/site-packages/matplotlib/mpl-data loaded rc file /usr/lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc matplotlib version 1.0.1 verbose.level debug interactive is False units is False platform is linux2 loaded modules: ['heapq', 'numpy.core.info', 'distutils', 'numpy.lib.format', 'functools', 'pylab', '_bisect', 'subprocess', 'sysconfig', 'gc', 'matplotlib.tempfile', 'distutils.sysconfig', 'ctypes._endian', 'encodings.encodings', 'pyparsing', 'matplotlib.colors', 'numpy.core.numerictypes', 'numpy.testing.sys', 'numpy.lib.__future__', 'numpy.fft.types', 'numpy.ma.cPickle', 'struct', 'numpy.matrixlib.defmatrix', 'numpy.random.info', 'tempfile', 'numpy.compat.types', 'pprint', 'numpy.linalg', 'matplotlib.threading', 'numpy.core.machar', 'numpy.testing.types', 'numpy.testing', 'collections', 'numpy.polynomial.sys', 'unittest.sys', 'numpy.core.umath', 'unittest.main', 'distutils.types', 'numpy.testing.operator', 'numpy.core.scalarmath', 'numpy.ma.sys', 'zipimport', 'string', 'matplotlib.subprocess', 'numpy.testing.os', 'unittest.functools', 'numpy.lib.arraysetops', 'numpy.testing.unittest', 'numpy.lib.math', 'encodings.utf_8', 'matplotlib.__future__', 'unittest.types', 'unittest.util', ' numpy.testing.re', 'numpy.version', 'numpy.lib.re', 'distutils.re', 'numpy.matrixlib.sys', 'ctypes.os', 'numpy.core.os', 'numpy.lib.type_check', 'numpy.compat.sys', 'unittest.StringIO', 'bisect', 'numpy.core._internal', 'signal', 'numpy.lib.types', 'numpy.lib._datasource', 'random', 'numpy.lib.__builtin__', 'numpy.fft.fftpack_lite', 'matplotlib.cbook', 'textwrap', 'numpy.core.multiarray', 'numpy.polynomial.string', 'distutils.version', 'cStringIO', 'numpy.polynomial', 'numpy.numpy', 'matplotlib.StringIO', 'unittest.time', 'locale', 'numpy.add_newdocs', 'unittest.difflib', 'numpy.core.getlimits', 'base64', '_ssl', 'numpy.lib.sys', 'encodings', 'numpy.ma.itertools', 'unittest.pprint', ' unittest.re', 'abc', 'numpy.matrixlib', 'numpy.ctypes', 'numpy.testing.decorators', 'matplotlib.warnings', 'rfc822', 'numpy.lib.npyio', 'numpy.lib.numpy', 'matplotlib.sys', 're', 'numpy.lib._compiled_base', 'numpy.polynomial.legendre', 'threading', 'new', 'numpy.ma.warnings', 'numpy.random.mtrand', 'urllib2', 'matplotlib.cPickle', 'math', 'numpy.fft.helper', 'fcntl', 'unittest.case', 'matplotlib.numpy', 'UserDict', 'unittest.suite', 'numpy.lib.function_base', 'distutils.os',
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
On Monday, August 15, 2011, Ben Breslauer bbresla...@gmail.com wrote: Hi, Has anyone else noticed this behavior? For the devs, do you prefer a github bug to the SF list? Ben I have not personally observed this, but usually, people don't specify rgba tuples for plot. I think the lack of response is due to our focus on larger bugs right now for the upcoming release. Therefore, it would probably be best to file a bug report with your patch so that we have a record of it. The fuller patch might be more involved (consider scatter and other functions). Plus, we would likely need to consider what to do if both an rgba tuple and alpha were specified, As a rule of thumb, if we don't respond on list, file a bug report. Thanks for bringing this to our attention! Ben Root -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plot() not using alpha value from RGBA tuple
I think that I have found the problem here. Line2D.draw() (and I presume other Artist subclasses) calls gc.set_foreground(self._color) ... gc.set_alpha(self._alpha) self._color is defined by the color kwarg, whether it be a hex value, 3-tuple, 4-tuple, or something else. self._alpha is defined by the alpha kwarg, but if the alpha kwarg is None, it is not overwritten with color[3]. Therefore, using color=(R,G,B,A) does not set alpha correctly. I'm not sure the best (i.e. most matplotlib-like) way to change this so that the A value gets used iff alpha is None, but I've attached a patch that does it one way (diff'ed against the github master, commit 67b1cd650f574f9c53ce). I know the patch is less than ideal, as it adds kwarg-specific handling into a place where none had previously been done, and it's also in a for loop. Maybe it would be better to do the checking along with the scalex and scaley pops? Separately, I noticed that backend_bases.GraphicsContextBase.set_foreground claims to only expect an RGB definition, and not an RGBA definition. As such, I think that it should call self._rgb = colors.colorConverter.to_rgb(fg) instead of self._rgb = colors.colorConverter.to_rgba(fg) since that will make self._rgb a 3-tuple instead of a 4-tuple. Ben On Sat, Jul 23, 2011 at 3:13 PM, Ben Breslauer bbresla...@gmail.com wrote: Hi, I'm trying to fade some data, using alpha values, that I am plotting with Axes.plot(). I can recreate this problem with 1 line of pylab.plot. If I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0,.2), linewidth=7) then I get the equivalent of pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7) i.e. it does not use the alpha value. However, if instead I use pylab.plot([1,2,3],[1,4,9], color=(1,0,0), linewidth=7, alpha=.2) then the line is faded out appropriately. The plot documentation indicates that RGBA tuples should be valid, so I'm wondering if this is a bug. Maybe alpha is defaulting to 1 or None and then not being overwritten if color is a 4-tuple? I'm using Arch Linux with kernel 2.6.39, matplotlib 1.0.1 from the Arch repo, and the Qt4 backend. My installed Qt version is 4.7.3, and I am using KDE 4.6.5. Below is verbose-debug output. Thanks for any help! Ben $HOME=/home/ben CONFIGDIR=/home/ben/.matplotlib matplotlib data path /usr/lib/python2.7/site-packages/matplotlib/mpl-data loaded rc file /usr/lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc matplotlib version 1.0.1 verbose.level debug interactive is False units is False platform is linux2 loaded modules: ['heapq', 'numpy.core.info', 'distutils', 'numpy.lib.format', 'functools', 'pylab', '_bisect', 'subprocess', 'sysconfig', 'gc', 'matplotlib.tempfile', 'distutils.sysconfig', 'ctypes._endian', 'encodings.encodings', 'pyparsing', 'matplotlib.colors', 'numpy.core.numerictypes', 'numpy.testing.sys', 'numpy.lib.__future__', 'numpy.fft.types', 'numpy.ma.cPickle', 'struct', 'numpy.matrixlib.defmatrix', 'numpy.random.info', 'tempfile', 'numpy.compat.types', 'pprint', 'numpy.linalg', 'matplotlib.threading', 'numpy.core.machar', 'numpy.testing.types', 'numpy.testing', 'collections', 'numpy.polynomial.sys', 'unittest.sys', 'numpy.core.umath', 'unittest.main', 'distutils.types', 'numpy.testing.operator', 'numpy.core.scalarmath', 'numpy.ma.sys', 'zipimport', 'string', 'matplotlib.subprocess', 'numpy.testing.os', 'unittest.functools', 'numpy.lib.arraysetops', 'numpy.testing.unittest', 'numpy.lib.math', 'encodings.utf_8', 'matplotlib.__future__', 'unittest.types', 'unittest.util', ' numpy.testing.re', 'numpy.version', 'numpy.lib.re', 'distutils.re', 'numpy.matrixlib.sys', 'ctypes.os', 'numpy.core.os', 'numpy.lib.type_check', 'numpy.compat.sys', 'unittest.StringIO', 'bisect', 'numpy.core._internal', 'signal', 'numpy.lib.types', 'numpy.lib._datasource', 'random', 'numpy.lib.__builtin__', 'numpy.fft.fftpack_lite', 'matplotlib.cbook', 'textwrap', 'numpy.core.multiarray', 'numpy.polynomial.string', 'distutils.version', 'cStringIO', 'numpy.polynomial', 'numpy.numpy', 'matplotlib.StringIO', 'unittest.time', 'locale', 'numpy.add_newdocs', 'unittest.difflib', 'numpy.core.getlimits', 'base64', '_ssl', 'numpy.lib.sys', 'encodings', 'numpy.ma.itertools', 'unittest.pprint', ' unittest.re', 'abc', 'numpy.matrixlib', 'numpy.ctypes', 'numpy.testing.decorators', 'matplotlib.warnings', 'rfc822', 'numpy.lib.npyio', 'numpy.lib.numpy', 'matplotlib.sys', 're', 'numpy.lib._compiled_base', 'numpy.polynomial.legendre', 'threading', 'new', 'numpy.ma.warnings', 'numpy.random.mtrand', 'urllib2', 'matplotlib.cPickle', 'math', 'numpy.fft.helper', 'fcntl', 'unittest.case', 'matplotlib.numpy', 'UserDict', 'unittest.suite', 'numpy.lib.function_base', 'distutils.os', 'matplotlib', 'numpy.fft.numpy', 'exceptions', 'numpy.lib.info', 'ctypes', 'numpy.lib.warnings', 'ctypes.struct', 'codecs', 'numpy.core._sort', 'numpy.os', 'unittest.loader', '_functools', '_locale',
