matplotlib-users Mailing List for matplotlib

I'm certain this is in an example somewhere but I can't seem to find it.  If
someone can just point me to the example I'll take it from there.  Thank
you!

I have a line chart.  I just want to add text or callout box that shows the
last value in the line.

Thank you very much,
Chris
-- 
View this message in context: http://old.nabble.com/Line-chart---want-to-show-value-of-last-data-point-tp26505250p26505250.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello,

I would like to do animations of a 3d scene. Thus I would need do to
animation of some mplot3d-generated plot. Has somebody already tried it ? Is
it possible at all ? My first test don't work, but I never did an animation
in matplotlib before. I would like to be sure this is not a dead end befor
digging deeper.

 Thank you !

I was able to reproduce your problem on one of our Pentium III computers 
and traced it down to a bug in the _path module initialization function 
(will file a separate bug report). Please try again installing the 
updated <matplotlib-0.99.1.1.win32-py2.6.exe> from 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>.

Christoph

Phillip M. Feldman wrote:
> Jeff Whitaker wrote:
>> Phillip M. Feldman wrote:
>>> Jeff Whitaker wrote:
>>>> Dr. Phillip M. Feldman wrote:
>>>>> The basemap demo `cubed_sphere.py` contains the following line of 
>>>>> code:
>>>>>
>>>>>    fig.subplots_adjust(bottom=0, left=0, right=1, top=0, wspace=0, 
>>>>> hspace=0)
>>>>>
>>>>> >From the documentation, it would appear that `wspace=0` should 
>>>>> remove all
>>>>> horizontal space between the subplots.  But, this isn't what 
>>>>> happens.  (I
>>>>> tried to insert an image, but this feature of Nabble appears to be 
>>>>> broken).
>>>>>   
>>>> Phillip:  Do you see any white space between the unfolded faces of 
>>>> the cube on the cubed_sphere plot?  If not, then that command is 
>>>> working as expected.
>>>>
>>>> -Jeff
>>> Jeff:
>>>
>>> (I posted this same message via Nabble, but it doesn't seem to be 
>>> getting through).
>>>
>>> I have some further information: I just tried it again, and realized 
>>> that if I use the original figure size and don't maximize the figure 
>>> window, there are no white spaces. I don't see the white spaces 
>>> unless I maximize the figure window. Maximizing the figure window 
>>> should change the overall size of the image, but everything should 
>>> scale together, so this is definitely a bug.
>>>
>>> Phillip
>> Philip:  It's not really a bug - but a "feature" of this particular 
>> example.  For the white space to disappear, the figure must have 
>> exactly the same aspect ratio as the map projection.  It's set that 
>> way in the example, but if you change but maximizing the window 
>> Basemap tries to maintain the aspect ratio of the map and leaves some 
>> whitespace.  To get rid of the whitespace, at the expensive of 
>> messing up the aspect ratio of the map when you resize, set 
>> fix_aspect=True when initializing the basemap instance (for basemap 
>> >= 0.99.4).
>>
>> -Jeff
>>
> Jeff: According to the documentation (in 
> http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html), 
> fix_aspect=True is the default.  (I verified that specifying 
> fix_aspect=True does not change the behavior).  So, I still think that 
> there's a bug here.  If I specify fix_aspect=False, then no white 
> spaces appear when I maximize the figure, but the aspect ratio is 
> messed up.  It would be really great if there were some way to get a 
> large plot without fouling up the aspect ratio.  Yours, Phillip
Philip:  Sorry, I meant to say fix_aspec=False in my previous email.  
You can't preserve the aspect ratio of the map and not have white space 
appear when you resize the figure in that example.  You can get a larger 
figure by modifying the figsize argument to plt.figure - just be sure to 
maintain the correct aspect ratio (10:7.5).

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Dr. David Kirkby wrote:
> Michael Droettboom wrote:
>> A colleague of mine also suggested an alternative workaround that is 
>> almost humorously simple.  Define both the C and C++ compilers to be 
>> "CC" when building matplotlib.  That is, set the environment variable 
>> "CC" to "CC" and "CXX" to "CC".  Distutils will then use the C++ 
>> compiler for everything (which for matplotlib we get lucky and it 
>> just works).
>>
>> Mike
>
> As I understand it, C++ compilers do not generate as efficient 
> binaries as C compilers do, so there would be a loss of speed I think. 
> How much I do not know.
>
> That seems more of a hack than a real solution to the problem, though 
> in some cases, hacks are the best choice.
>
> I know nothing about mathplotlib, other than it presented issues on 
> Solaris. If it not CPU/memory intensive, then I suspect the 
> performance penalty of using a C++ compiler to compile C could would 
> not be significant.
It's mostly C++ anyway, with the exception of some of the font 
conversion, contouring and the (mostly obsolete) Gdk extension.  I 
suspect it makes very little difference.

Mike
>
> David Kirkby.
>
>
>
>> Michael Droettboom wrote:
>>> I've attached patches against Python 2.5 and 2.6 to that bug.  
>>> Neither is significantly different from the original patch.
>>>
>>> http://bugs.python.org/issue1222585
>>>
>>> Once doing that, you'll also need to make the following change to 
>>> matplotlib so that the correct C++ runtime libraries are used.  Once 
>>> I figure out how to correctly detect the compiler being used, I'll 
>>> make this change in the matplotlib SVN repository.  (This is 
>>> non-trivial, since distutils doesn't have a Sun compiler 
>>> specialization -- it uses the "generic" Unix compiler support for 
>>> both gcc and Sun Studio.)
>>>
>>> Mike
>>>
>>> Index: setupext.py
>>> ===================================================================
>>> --- setupext.py (revision 7979)
>>> +++ setupext.py (working copy)
>>> @@ -221,7 +221,7 @@
>>>  if sys.platform == 'win32' and win32_compiler == 'msvc':
>>>      std_libs = []
>>>  else:
>>> -    std_libs = ['stdc++', 'm']
>>> +    std_libs = ['m', 'Crun', 'Cstd']
>>>
>>>  def has_pkgconfig():
>>>      if has_pkgconfig.cache is not None:
>>>
>>>
>>> Michael Droettboom wrote:
>>>  
>>>> This is a years-old known bug in distutils (which it looks like 
>>>> you've already commented on...).  I've looked at it many times over 
>>>> those years, and it's really very difficult to fix from outside 
>>>> without terrible monkey-patching hacks that are certain to break on 
>>>> as many systems as they fix.  We just may be forced to deal with it 
>>>> at this point, though.  (FWIW, we run Solaris here, too, but we 
>>>> build matplotlib on gcc).  I'll comment on that bug as well and see 
>>>> if we can get some movement on it.
>>>>
>>>> In the meantime, I'll investigate whether the scons work by David 
>>>> Cournapeau resolves this problem.  See here:
>>>>
>>>>    http://github.com/cournape/matplotlib/tree/scons_build
>>>>
>>>> Mike
>>>>
>>>> Dr. David Kirkby wrote:
>>>>     
>>>>> I was trying to build matplotlib 0.99.0 as part of Sage
>>>>>
>>>>> http://www.sagemath.org/
>>>>>
>>>>> on a Sun Blade 2000 workstation running Solaris 10 update 7, using 
>>>>> the Sun Studio compiler version 12.1 (not gcc).
>>>>>
>>>>> CC and CXX were defined properly as C and C++ compilers, but it 
>>>>> would appear that the C compiler is being called to compile the 
>>>>> file src/ft2font.cpp, which is of course a C++ file.
>>>>>
>>>>> You might get away with this with gcc, but the Sun C compiler will 
>>>>> not compile C++ code.
>>>>>
>>>>> Here's the error I get:
>>>>>
>>>>>
>>>>> /opt/xxxsunstudio12.1/bin/cc -DNDEBUG -O -xcode=pic32 
>>>>> -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API 
>>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/lib/python2.6/site-packages/numpy/core/include 
>>>>> -I/usr/sfw/include -I/usr/sfw/include/freetype2 
>>>>> -I/usr/local/include -I. 
>>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/ 
>>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/python2.6 
>>>>> -c src/ft2font.cpp -o build/temp.solaris-2.10-sun4u-2.6/src/ft2font.o
>>>>> cc: No valid input files specified, no output generated
>>>>> error: command '/opt/xxxsunstudio12.1/bin/cc' failed with exit 
>>>>> status 1
>>>>>
>>>>> This is recorded in the Sage trac as:
>>>>>
>>>>> http://trac.sagemath.org/sage_trac/ticket/7028
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 
>>>>> 2008 30-Day trial. Simplify your report design, integration and 
>>>>> deployment - and focus on what you do best, core application 
>>>>> coding. Discover what's new with
>>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>             
>>>>       
>>>
>>>   
>>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> A colleague of mine also suggested an alternative workaround that is 
> almost humorously simple.  Define both the C and C++ compilers to be 
> "CC" when building matplotlib.  That is, set the environment variable 
> "CC" to "CC" and "CXX" to "CC".  Distutils will then use the C++ 
> compiler for everything (which for matplotlib we get lucky and it just 
> works).
> 
> Mike

As I understand it, C++ compilers do not generate as efficient binaries as C 
compilers do, so there would be a loss of speed I think. How much I do not know.

That seems more of a hack than a real solution to the problem, though in some 
cases, hacks are the best choice.

I know nothing about mathplotlib, other than it presented issues on Solaris. If 
it not CPU/memory intensive, then I suspect the performance penalty of using a 
C++ compiler to compile C could would not be significant.

David Kirkby.



> Michael Droettboom wrote:
>> I've attached patches against Python 2.5 and 2.6 to that bug.  Neither 
>> is significantly different from the original patch.
>>
>> http://bugs.python.org/issue1222585
>>
>> Once doing that, you'll also need to make the following change to 
>> matplotlib so that the correct C++ runtime libraries are used.  Once I 
>> figure out how to correctly detect the compiler being used, I'll make 
>> this change in the matplotlib SVN repository.  (This is non-trivial, 
>> since distutils doesn't have a Sun compiler specialization -- it uses 
>> the "generic" Unix compiler support for both gcc and Sun Studio.)
>>
>> Mike
>>
>> Index: setupext.py
>> ===================================================================
>> --- setupext.py (revision 7979)
>> +++ setupext.py (working copy)
>> @@ -221,7 +221,7 @@
>>  if sys.platform == 'win32' and win32_compiler == 'msvc':
>>      std_libs = []
>>  else:
>> -    std_libs = ['stdc++', 'm']
>> +    std_libs = ['m', 'Crun', 'Cstd']
>>
>>  def has_pkgconfig():
>>      if has_pkgconfig.cache is not None:
>>
>>
>> Michael Droettboom wrote:
>>  
>>> This is a years-old known bug in distutils (which it looks like 
>>> you've already commented on...).  I've looked at it many times over 
>>> those years, and it's really very difficult to fix from outside 
>>> without terrible monkey-patching hacks that are certain to break on 
>>> as many systems as they fix.  We just may be forced to deal with it 
>>> at this point, though.  (FWIW, we run Solaris here, too, but we build 
>>> matplotlib on gcc).  I'll comment on that bug as well and see if we 
>>> can get some movement on it.
>>>
>>> In the meantime, I'll investigate whether the scons work by David 
>>> Cournapeau resolves this problem.  See here:
>>>
>>>    http://github.com/cournape/matplotlib/tree/scons_build
>>>
>>> Mike
>>>
>>> Dr. David Kirkby wrote:
>>>      
>>>> I was trying to build matplotlib 0.99.0 as part of Sage
>>>>
>>>> http://www.sagemath.org/
>>>>
>>>> on a Sun Blade 2000 workstation running Solaris 10 update 7, using 
>>>> the Sun Studio compiler version 12.1 (not gcc).
>>>>
>>>> CC and CXX were defined properly as C and C++ compilers, but it 
>>>> would appear that the C compiler is being called to compile the file 
>>>> src/ft2font.cpp, which is of course a C++ file.
>>>>
>>>> You might get away with this with gcc, but the Sun C compiler will 
>>>> not compile C++ code.
>>>>
>>>> Here's the error I get:
>>>>
>>>>
>>>> /opt/xxxsunstudio12.1/bin/cc -DNDEBUG -O -xcode=pic32 
>>>> -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API 
>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/lib/python2.6/site-packages/numpy/core/include 
>>>> -I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/local/include 
>>>> -I. 
>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/ 
>>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/python2.6 
>>>> -c src/ft2font.cpp -o build/temp.solaris-2.10-sun4u-2.6/src/ft2font.o
>>>> cc: No valid input files specified, no output generated
>>>> error: command '/opt/xxxsunstudio12.1/bin/cc' failed with exit status 1
>>>>
>>>> This is recorded in the Sage trac as:
>>>>
>>>> http://trac.sagemath.org/sage_trac/ticket/7028
>>>>
>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>>>> 30-Day trial. Simplify your report design, integration and 
>>>> deployment - and focus on what you do best, core application coding. 
>>>> Discover what's new with
>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>             
>>>       
>>
>>   
> 

Jeff Whitaker wrote:
> Phillip M. Feldman wrote:
>> Jeff Whitaker wrote:
>>> Dr. Phillip M. Feldman wrote:
>>>> The basemap demo `cubed_sphere.py` contains the following line of 
>>>> code:
>>>>
>>>>    fig.subplots_adjust(bottom=0, left=0, right=1, top=0, wspace=0, 
>>>> hspace=0)
>>>>
>>>> >From the documentation, it would appear that `wspace=0` should 
>>>> remove all
>>>> horizontal space between the subplots.  But, this isn't what 
>>>> happens.  (I
>>>> tried to insert an image, but this feature of Nabble appears to be 
>>>> broken).
>>>>   
>>> Phillip:  Do you see any white space between the unfolded faces of 
>>> the cube on the cubed_sphere plot?  If not, then that command is 
>>> working as expected.
>>>
>>> -Jeff
>> Jeff:
>>
>> (I posted this same message via Nabble, but it doesn't seem to be 
>> getting through).
>>
>> I have some further information: I just tried it again, and realized 
>> that if I use the original figure size and don't maximize the figure 
>> window, there are no white spaces. I don't see the white spaces 
>> unless I maximize the figure window. Maximizing the figure window 
>> should change the overall size of the image, but everything should 
>> scale together, so this is definitely a bug.
>>
>> Phillip
> Philip:  It's not really a bug - but a "feature" of this particular 
> example.  For the white space to disappear, the figure must have 
> exactly the same aspect ratio as the map projection.  It's set that 
> way in the example, but if you change but maximizing the window 
> Basemap tries to maintain the aspect ratio of the map and leaves some 
> whitespace.  To get rid of the whitespace, at the expensive of messing 
> up the aspect ratio of the map when you resize, set fix_aspect=True 
> when initializing the basemap instance (for basemap >= 0.99.4).
>
> -Jeff
>
Jeff: According to the documentation (in 
http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html), 
fix_aspect=True is the default.  (I verified that specifying 
fix_aspect=True does not change the behavior).  So, I still think that 
there's a bug here.  If I specify fix_aspect=False, then no white spaces 
appear when I maximize the figure, but the aspect ratio is messed up.  
It would be really great if there were some way to get a large plot 
without fouling up the aspect ratio.  Yours, Phillip

A colleague of mine also suggested an alternative workaround that is 
almost humorously simple.  Define both the C and C++ compilers to be 
"CC" when building matplotlib.  That is, set the environment variable 
"CC" to "CC" and "CXX" to "CC".  Distutils will then use the C++ 
compiler for everything (which for matplotlib we get lucky and it just 
works).

Mike


Michael Droettboom wrote:
> I've attached patches against Python 2.5 and 2.6 to that bug.  Neither 
> is significantly different from the original patch.
>
> http://bugs.python.org/issue1222585
>
> Once doing that, you'll also need to make the following change to 
> matplotlib so that the correct C++ runtime libraries are used.  Once I 
> figure out how to correctly detect the compiler being used, I'll make 
> this change in the matplotlib SVN repository.  (This is non-trivial, 
> since distutils doesn't have a Sun compiler specialization -- it uses 
> the "generic" Unix compiler support for both gcc and Sun Studio.)
>
> Mike
>
> Index: setupext.py
> ===================================================================
> --- setupext.py (revision 7979)
> +++ setupext.py (working copy)
> @@ -221,7 +221,7 @@
>  if sys.platform == 'win32' and win32_compiler == 'msvc':
>      std_libs = []
>  else:
> -    std_libs = ['stdc++', 'm']
> +    std_libs = ['m', 'Crun', 'Cstd']
>
>  def has_pkgconfig():
>      if has_pkgconfig.cache is not None:
>
>
> Michael Droettboom wrote:
>   
>> This is a years-old known bug in distutils (which it looks like you've 
>> already commented on...).  I've looked at it many times over those 
>> years, and it's really very difficult to fix from outside without 
>> terrible monkey-patching hacks that are certain to break on as many 
>> systems as they fix.  We just may be forced to deal with it at this 
>> point, though.  (FWIW, we run Solaris here, too, but we build matplotlib 
>> on gcc).  I'll comment on that bug as well and see if we can get some 
>> movement on it.
>>
>> In the meantime, I'll investigate whether the scons work by David 
>> Cournapeau resolves this problem.  See here:
>>
>>    http://github.com/cournape/matplotlib/tree/scons_build
>>
>> Mike
>>
>> Dr. David Kirkby wrote:
>>   
>>     
>>> I was trying to build matplotlib 0.99.0 as part of Sage
>>>
>>> http://www.sagemath.org/
>>>
>>> on a Sun Blade 2000 workstation running Solaris 10 update 7, using the Sun 
>>> Studio compiler version 12.1 (not gcc).
>>>
>>> CC and CXX were defined properly as C and C++ compilers, but it would appear 
>>> that the C compiler is being called to compile the file src/ft2font.cpp, which 
>>> is of course a C++ file.
>>>
>>> You might get away with this with gcc, but the Sun C compiler will not compile 
>>> C++ code.
>>>
>>> Here's the error I get:
>>>
>>>
>>> /opt/xxxsunstudio12.1/bin/cc -DNDEBUG -O -xcode=pic32 
>>> -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API 
>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/lib/python2.6/site-packages/numpy/core/include 
>>> -I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/local/include -I. 
>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/ 
>>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/python2.6 -c 
>>> src/ft2font.cpp -o build/temp.solaris-2.10-sun4u-2.6/src/ft2font.o
>>> cc: No valid input files specified, no output generated
>>> error: command '/opt/xxxsunstudio12.1/bin/cc' failed with exit status 1
>>>
>>> This is recorded in the Sage trac as:
>>>
>>> http://trac.sagemath.org/sage_trac/ticket/7028
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>>> trial. Simplify your report design, integration and deployment - and focus on 
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>   
>>>     
>>>       
>>   
>>     
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Folks,
   I want to use the full screen width in plots,
but it looks as though the size of the screen window is clipped somewhere ?

import pylab as pl
for h in (4,):
     for w in (8, 10, 12):
         fig = pl.figure( figsize=(w,h) )
         pl.plot( range(10) )  # widths 10, 12 display the same, ~ 8.5
         pl.title( "%d x %d ?"% (w,h) )
         pl.savefig( "tmp/%d-%d.png"% (w,h) )  # ok, as given

pl.show()

backend: Qt4Agg
matplotlib-0.99.1.1-py2.5-macosx10.5.dmg
python 2.5.1
Qt 4.4.3
mac ppc 10.4.11


(Is there an overview of the clipping / fitting sequence in the doc ?)

Thanks, cheers
   -- denis

Hello everyone,

I am trying to use matplotlib to plot several bar charts inside a for loop
the problem is that I get the first one, but once I close it I cannot plot
anymore.
I still get the window but no image appear and eventually python crashes.

Here is my code:
[code]
def plot(self):
        xCoord = []
        yCoord = []
        xCoordP = []
        yCoordP = []
        pylab.Figure()
        for i in xrange(self.length-self.length/2):
            if i==0 or i%self.size==0:
                xCoordP.append(i)
                yCoordP.append(self.counts[i])
            else:
                xCoord.append(i)
                yCoord.append(self.counts[i])
        bar1, = pylab.subplot(211)
        pylab.bar(xCoord,yCoord,color='blue')
        pylab.bar(xCoordP,yCoordP,color='red')
        xCoord = []
        yCoord = []
        xCoordP = []
        yCoordP = []
        for i in xrange(self.length/2,self.length):
            if (i+1)%self.size==0:
                xCoordP.append(i-self.length/2)
                yCoordP.append(self.counts[i])
            else:
                xCoord.append(i-self.length/2)
                yCoord.append(self.counts[i])
        bar2, = pylab.subplot(212)
        pylab.bar(xCoord,yCoord,color='blue')
        pylab.bar(xCoordP,yCoordP,color='red')
        pylab.show()
.
.
.
.
for matches,value,n,k in self.lsResults:
    self.plot()
[/code]


Thank you in advance for any help.

Christoph, you were right about the lack of SSE2 support. CPU-Z says that my laptop has only SSE support.

However, when I downloaded your build and installed it, I still have the same problem.

Thanks for all your help on this.

Dilip.



----- Original Message ----
From: Christoph Gohlke <cg...@uc...>
To: matplotlib-users <mat...@li...>
Sent: Mon, November 23, 2009 11:43:35 PM
Subject: Re: [Matplotlib-users] Unable to import matplotlib.pylab in Windows

Should have asked this before: Does your computer's CPU have SSE2 
extensions? You can use CPU-Z <http://www.cpuid.com/>.

It is OK that Dependency Walker does not find MSVCR90.DLL and 
MSVCP90.DLL for a PYD extension. The extension will use whatever 
VC90.CRT python26.dll uses at runtime.

I am not able to reproduce your problem using a fresh Windows XP SP3, 
Python 2.6.4, numpy 1.3.0, matplotlib 0.99.1 installation in VirtualPC.

If you don't mind, would you try installing 
<matplotlib-0.99.1.1.win32-py2.6.exe> from 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. This build has 
SSE2 disabled and a manifest for VC90.CRT embedded, which explicitly 
specifies the VC90.CRT to use.

Christoph

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users



      

Hi Xavier,

I'm sorry. As I don't know a great deal about the nuts and bolts of matplotlib, I don't think I'm well enough equipped to answer your question. Perhaps someone else on this list can help out?


Regards,
-- Damon

--------------------------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.m...@wa...

On 23 Nov 2009, at 21:00, Xavier Gnata wrote:

> Hi,
> 
> Well when you plot, imshow or whatever is matplotlib related, the axes do scale *automatically*.
> Why should it be different with quiver?
> 
> I do reproduce your error with axis('tight')
> 
> 
> Xavier
> 
>> Hi Xavier (cc list),
>> 
>> It may be a bug, however I do not know what the default behaviour 'should' be. You could do:
>> 
>> lims = [-4, 4, -4, 4]
>> axis(lims)
>> 
>> after calling quiver to see the whole arrow. I did notice that calling
>> 
>> axis('tight')
>> 
>> threw the following error
>> 
>> /Users/Damon/python/lib/matplotlib/axes.py:2038: UserWarning: Attempting to set identical xmin==xmax results in singular transformations; automatically expanding.  xmin=1.0, xmax=1.0
>>   warnings.warn('Attempting to set identical xmin==xmax results in singular transformations; automatically expanding.  xmin=%s, xmax=%s'%(xmin, xmax))
>> /Users/Damon/python/lib/matplotlib/axes.py:2212: UserWarning: Attempting to set identical ymin==ymax results in singular transformations; automatically expanding.  ymin=1.0, ymax=1.0
>>   warnings.warn('Attempting to set identical ymin==ymax results in singular transformations; automatically expanding.  ymin=%s, ymax=%s'%(ymin, ymax))
>> 
>> is this correct, or is it a bug? I'm using "ipython -pylab" with the MacOSX backend. I was expecting axis('tight') would scale the axes so I could see the whole arrow.
>> 
>> 
>> Regards,
>> -- Damon
>> 
>> --------------------------
>> Damon McDougall
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> CV4 7AL
>> d.m...@wa...
>> 
>> On 22 Nov 2009, at 21:34, Xavier Gnata wrote:
>> 
>>   
>>> Hi,
>>> 
>>> RTFM...indeed it works.
>>> However, the axis do not scale accordingly:
>>> 
>>> quiver([1],[1],[2],[2], angles='xy', scale_units='xy', scale=1) on a TkAgg backend produce a plot with:
>>> In [11]: axis()
>>> Out[11]:
>>> (0.94000000000000006,
>>> 1.0600000000000001,
>>> 0.94000000000000006,
>>> 1.0600000000000001)
>>> 
>>> The display area scales the same way as it does using quiver([1],[1],[2],[2]) (without any other args).
>>> It looks like a bug.
>>> 
>>> Xavier
>>> 
>>> 
>>>     
>>>> Hi Xavier,
>>>> 
>>>> You can pass some handy keyword arguments to fix that. Use the following:
>>>> 
>>>> quiver([1],[1],[1.2],[1.2], angles='xy', scale_units='xy', scale=1)
>>>> 
>>>> Hope that helps :)
>>>> 
>>>> 
>>>> Regards,
>>>> -- Damon
>>>> 
>>>> --------------------------
>>>> Damon McDougall
>>>> Mathematics Institute
>>>> University of Warwick
>>>> Coventry
>>>> CV4 7AL
>>>> d.m...@wa...
>>>> 
>>>> On 22 Nov 2009, at 16:37, Xavier Gnata wrote:
>>>> 
>>>> 
>>>>       
>>>>> Hi,
>>>>> 
>>>>> I woud like to draw a vector field using pylab.
>>>>> quivert looks nice but it sould not scale the arrows to fit my use-case.
>>>>> quiver([1],[1],[1.2],[1.2]) does plot a nice arrow but the head of the
>>>>> arrow is not at (1.2,1.2).
>>>>> Is there a way to plot a list of arrows *without* any scaling?
>>>>> 
>>>>> Xavier
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>>>> trial. Simplify your report design, integration and deployment - and focus on
>>>>> what you do best, core application coding. Discover what's new with
>>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>> 
>>>>>         
>>>> 
>>>>       
>>>     
>>   
> 

Dr. David Kirkby wrote:
> Well, on SPARC, the Sun compilers are better than gcc, so there really is an 
> advantage to getting this sorted out.
>   

numscons should support the Sun Studio compiler.

> I do not know SCons myself, but I do know that in the Sage project, SCons has 
> caused many issues. Whether it is a fault of SCons, or the way people write the 
> code for SCons, I do not know.
>   

That's because scons is a terrible tool for a full packaging solution:
at the moment, it is really just a (quite good) make replacement. But
numscons does not have this problem, as it reuses distutils for all the
packaging, and handles compilers in its own way.

I am pretty sure it will be easier to fix whatever numscons issues crop
up while trying to build matplotlib than building it from scratch or
worse, trying to fix distutils.

cheers,

David

Michael Droettboom wrote:
> This is a years-old known bug in distutils (which it looks like you've 
> already commented on...).  I've looked at it many times over those 
> years, and it's really very difficult to fix from outside without 
> terrible monkey-patching hacks that are certain to break on as many 
> systems as they fix.  We just may be forced to deal with it at this 
> point, though.  (FWIW, we run Solaris here, too, but we build matplotlib 
> on gcc).  I'll comment on that bug as well and see if we can get some 
> movement on it.
> 
> In the meantime, I'll investigate whether the scons work by David 
> Cournapeau resolves this problem.  See here:
> 
>   http://github.com/cournape/matplotlib/tree/scons_build
> 
> Mike


Well, on SPARC, the Sun compilers are better than gcc, so there really is an 
advantage to getting this sorted out.

I do not know SCons myself, but I do know that in the Sage project, SCons has 
caused many issues. Whether it is a fault of SCons, or the way people write the 
code for SCons, I do not know.

I know recently someone changed a package that was using SCons, and stripped it 
all out. There is some code I need to fix, and I will take the same course of 
action. It seems more trouble than it is worth to me.

Dave


> Dr. David Kirkby wrote:
>> I was trying to build matplotlib 0.99.0 as part of Sage
>>
>> http://www.sagemath.org/
>>
>> on a Sun Blade 2000 workstation running Solaris 10 update 7, using the 
>> Sun Studio compiler version 12.1 (not gcc).
>>
>> CC and CXX were defined properly as C and C++ compilers, but it would 
>> appear that the C compiler is being called to compile the file 
>> src/ft2font.cpp, which is of course a C++ file.
>>
>> You might get away with this with gcc, but the Sun C compiler will not 
>> compile C++ code.
>>
>> Here's the error I get:
>>
>>
>> /opt/xxxsunstudio12.1/bin/cc -DNDEBUG -O -xcode=pic32 
>> -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API 
>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/lib/python2.6/site-packages/numpy/core/include 
>> -I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/local/include 
>> -I. 
>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/ 
>> -I/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/local/include/python2.6 
>> -c src/ft2font.cpp -o build/temp.solaris-2.10-sun4u-2.6/src/ft2font.o
>> cc: No valid input files specified, no output generated
>> error: command '/opt/xxxsunstudio12.1/bin/cc' failed with exit status 1
>>
>> This is recorded in the Sage trac as:
>>
>> http://trac.sagemath.org/sage_trac/ticket/7028
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>> 30-Day trial. Simplify your report design, integration and deployment 
>> - and focus on what you do best, core application coding. Discover 
>> what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>   
> 

Should have asked this before: Does your computer's CPU have SSE2 
extensions? You can use CPU-Z <http://www.cpuid.com/>.

It is OK that Dependency Walker does not find MSVCR90.DLL and 
MSVCP90.DLL for a PYD extension. The extension will use whatever 
VC90.CRT python26.dll uses at runtime.

I am not able to reproduce your problem using a fresh Windows XP SP3, 
Python 2.6.4, numpy 1.3.0, matplotlib 0.99.1 installation in VirtualPC.

If you don't mind, would you try installing 
<matplotlib-0.99.1.1.win32-py2.6.exe> from 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. This build has 
SSE2 disabled and a manifest for VC90.CRT embedded, which explicitly 
specifies the VC90.CRT to use.

Christoph

OK, I did the check that you mentioned (deleted the entire directory C:\Python26 before reinstalling Python). That didn't help.

I ran Dependency Walker on _path.pyd and got the following:

First, it lists the four DLLs that it did not find: MSVCR90.DLL, MSVCP90.DLL, DWMAPI.DLL, EFSADU.DLL.

Further down, I see the following entry:
c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL

and I did verify that the file is present at that location.

The location is somewhat different from what you have shown below. Does that matter?
I don't know why the same file MSVCR90.DLL shows up first in the "not found" category and then later with the proper location.

For a different data point, in a Windows Vista installation, Python 2.6 + numpy 1.3.0 + matplotlib 0.99.1 works fine and I do not have this problem. The problem seems to be restricted to Windows XP.

Dilip.


----- Original Message ----
From: Christoph Gohlke <cg...@uc...>
To: matplotlib-users <mat...@li...>
Sent: Mon, November 23, 2009 2:55:51 PM
Subject: Re: [Matplotlib-users] Unable to import matplotlib.pylab in Windows

Please check if there are python26.dll or "Microsoft.VC90.CRT.manifest" 
files left in your Python directory. If yes, remove those files.

If that does not help, run Dependency Walker on python26.dll (should be 
in your system folder), enable "Full Paths" view and report the 
MSVCR90.DLL path. It should be 
<c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.DLL>

I assume the missing DWMAPI.DLL and EFSADU.DLL dependencies come from 
IE7/8 and can be ignored.

Christoph

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users



      

Yes.
import numpy, matplotlib
works fine.

import matplotlib.pylab
does not work.

Thanks,
Dilip.

----- Original Message ----
From: Alan G Isaac <ala...@gm...>
To: mat...@li...
Sent: Mon, November 23, 2009 2:56:55 PM
Subject: Re: [Matplotlib-users] Unable to import matplotlib.pylab in Windows

Just to be clear:
import numpy, matplotlib
works fine?

Alan Isaac


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users



      

On 11/23/2009 4:33 PM, John Hunter wrote:
> Take a look at the table demo:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/table_demo.html
>    

All posted versions (PNG, hi res PNG, PDF) are improperly clipped.

fwiw,
Alan Isaac