headers
antonv | 1 Jan 21:38
Picon
Favicon
Gravatar

Re: Plotting NOAA data...


So my beginner saga continues with another question:
I am trying to create a custom colormap using ListedColormap. The custom
color map is for a range of values between 0 and 20 while the data in my
file is between 0 and 8. Now my issue is that when plotting the graph the
colormap is using the 0 to 8 values from the file. How can I force it to use
all the 21 values in the colormap?

Thanks,
Anton

Jeff Whitaker wrote:
> 
> antonv wrote:
>> Hey Jeff,
>>
>> I've got it sorted out a bit now. You're right the data was an output
>> from
>> Degrib and I had the option to output the csv's with or without data in
>> the
>> land areas. As before I was using a program that was placing the pixels
>> in
>> an image based on the X and Y columns it didn't create an issue. That was
>> an
>> easy fix by switching the option in the Degrib export.
>>
>> Also by looking at your example I realized the way the contourf function
>> requests the Z data and by just reshaping the array I was able to make
>> all
>> the stuff work properly. Numpy is amazing by the way! I had no idea how
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Droettboom | 2 Jan 16:24

Re: Fuzzy plots of ode solutions

This is a very good test to have -- we should add it to backend_driver.py.

FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
property to control when to bevel vs. miter when the mode is set to 
"miter".  (Though the default threshold appears to be different.)  I 
didn't look into Ps, but it may have a similar configuration.

Agg also has a miter limit (which is not currently settable from 
Python), but it reverts to what it calls "smart" beveling, rather than 
regular beveling when below that limit.  It does, however, have another 
miter mode called "miter_join_revert" which doesn't do smart beveling.  
(Try the "conv_stroke" example in the Agg source).  In fact, it has this 
comment associated with it (agg_math_stroke.h:275):

    // For the compatibility with SVG, PDF, etc,
    // we use a simple bevel join instead of
    // "smart" bevel

I think there is an argument to be made that we should use this mode 
instead in the Agg backend, to be consistent with PDF and SVG (see patch 
below).

On a higher level, however, I am a bit concerned about this miter limit 
concept.  It seems a bit dangerous for scientific plots: there is a 
large change in the look of the corner after only a small change in 
angle around the miter limit threshold.  It may make the data appear to 
have large changes where in fact the changes are small.  This seems like 
an argument of "bevel" or "round" as the default line join (it is 
currently "miter").  I also like the idea of "round" join keeping the 
corner close to the actual data point.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Firing | 2 Jan 18:37
Favicon
Gravatar

Re: Fuzzy plots of ode solutions

Michael Droettboom wrote:
> This is a very good test to have -- we should add it to backend_driver.py.
> 
> FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
> property to control when to bevel vs. miter when the mode is set to 
> "miter".  (Though the default threshold appears to be different.)  I 
> didn't look into Ps, but it may have a similar configuration.
> 
> Agg also has a miter limit (which is not currently settable from 
> Python), but it reverts to what it calls "smart" beveling, rather than 
> regular beveling when below that limit.  It does, however, have another 
> miter mode called "miter_join_revert" which doesn't do smart beveling.  
> (Try the "conv_stroke" example in the Agg source).  In fact, it has this 
> comment associated with it (agg_math_stroke.h:275):
> 
>     // For the compatibility with SVG, PDF, etc,
>     // we use a simple bevel join instead of
>     // "smart" bevel
> 
> I think there is an argument to be made that we should use this mode 
> instead in the Agg backend, to be consistent with PDF and SVG (see patch 
> below).
> 
> On a higher level, however, I am a bit concerned about this miter limit 
> concept.  It seems a bit dangerous for scientific plots: there is a 
> large change in the look of the corner after only a small change in 
> angle around the miter limit threshold.  It may make the data appear to 
> have large changes where in fact the changes are small.  This seems like 
> an argument of "bevel" or "round" as the default line join (it is 
> currently "miter").  I also like the idea of "round" join keeping the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Droettboom | 2 Jan 18:59

Re: Fuzzy plots of ode solutions

Eric Firing wrote:
> Michael Droettboom wrote:
>> This is a very good test to have -- we should add it to 
>> backend_driver.py.
>>
>> FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
>> property to control when to bevel vs. miter when the mode is set to 
>> "miter".  (Though the default threshold appears to be different.)  I 
>> didn't look into Ps, but it may have a similar configuration.
>>
>> Agg also has a miter limit (which is not currently settable from 
>> Python), but it reverts to what it calls "smart" beveling, rather 
>> than regular beveling when below that limit.  It does, however, have 
>> another miter mode called "miter_join_revert" which doesn't do smart 
>> beveling.  (Try the "conv_stroke" example in the Agg source).  In 
>> fact, it has this comment associated with it (agg_math_stroke.h:275):
>>
>>     // For the compatibility with SVG, PDF, etc,
>>     // we use a simple bevel join instead of
>>     // "smart" bevel
>>
>> I think there is an argument to be made that we should use this mode 
>> instead in the Agg backend, to be consistent with PDF and SVG (see 
>> patch below).
>>
>> On a higher level, however, I am a bit concerned about this miter 
>> limit concept.  It seems a bit dangerous for scientific plots: there 
>> is a large change in the look of the corner after only a small change 
>> in angle around the miter limit threshold.  It may make the data 
>> appear to have large changes where in fact the changes are small.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simson Garfinkel | 2 Jan 22:40
Picon
Favicon

TypeError: image has incorrect type (should be uint8)

Hi. I found a bug in the macos backend.

I get this error when I turn on log plotting on the Y axes; it doesn't  
happen when I turn off log plotting. It also doesn't happen when I use  
agg.pdf driver.

Is this a well-known problem, or should I put together a little demo  
that demonstrates it?

Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/figure.py", line 772, in draw
     for a in self.axes: a.draw(renderer)
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axes.py", line 1601, in draw
     a.draw(renderer)
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axis.py", line 710, in draw
     tick.draw(renderer)
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axis.py", line 193, in draw
     self.label1.draw(renderer)
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/text.py", line 502, in draw
     ismath=ismath)
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/backends/backend_macosx.py", line  
120, in draw_text
     self._draw_mathtext(gc, x, y, s, prop, angle)
   File "/Librrks/Python.framework/Versions/2.6/lib/python2.6/site-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luis Saavedra | 3 Jan 10:20
Picon
Gravatar

strtod dilemma

Hi list,

When the 'pylab' module is loaded the function 'strtod' does not work well.

I suppose that this is not new: 
http://www.python.org/search/hypermail/python-1994q2/0750.html

and the question is: any solution?

In this linkit exists a better description of the problem:

http://mbdynsimsuite.sourceforge.net/build_mbdyn_bindings.html

regards, Luis.

------------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Mauro Cavalcanti | 3 Jan 14:02
Picon

Customizing MPL backends

Dear ALL,

Is there any way to ***exclude*** (make invlsible) one of more of the
standard buttons which are displayed in the toolbar (either the
"Classic" or the "Toolbar2") of the MPL backends?

Thanks in advance for any assistance you can provide!

Best regards,

--

-- 
Dr. Mauro J. Cavalcanti
Ecoinformatics Studio
P.O. Box 46521, CEP 20551-970
Rio de Janeiro, RJ, BRASIL
E-mail: maurobio@...
Web: http://studio.infobio.net
Linux Registered User #473524 * Ubuntu User #22717
"Life is complex. It consists of real and imaginary parts."

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Michael Droettboom | 3 Jan 15:15

Re: strtod dilemma

Luis Saavedra wrote:
> Hi list,
>
> When the 'pylab' module is loaded the function 'strtod' does not work well.
>   
Can you elaborate on how it doesn't work?
> I suppose that this is not new: 
> http://www.python.org/search/hypermail/python-1994q2/0750.html
>
> and the question is: any solution?
>   
There's a solution in that link: use one of the many alternatives that 
are known to be more consistent across various versions of UNIX.
> In this linkit exists a better description of the problem:
>
> http://mbdynsimsuite.sourceforge.net/build_mbdyn_bindings.html
>   
I think this is not a matplotlib-specific problem, but a Python one, 
since Python provides its own strtod definition -- in an apparent 
attempt to get around its differences on different platforms.  If you 
grep over the matplotlib source code, "strtod" isn't even there.

Cheers,
Mike

------------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
antonv | 3 Jan 18:21
Picon
Favicon
Gravatar

csv2rec column names


Hi all,

I have a lot of csv files to process, all of them with the same number of
columns. The only issue is that each file has a unique column name for the
fourth column. 

All the csv2rec examples I found are using the r.column_name format to
access the data in that column which is of no use for me because of the
unique names. Is there a way to access that data using the column number? I
bet this should be something simple but I cannot figure it out...

Thanks in advance,
Anton
--

-- 
View this message in context: http://www.nabble.com/csv2rec-column-names-tp21267055p21267055.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Permalink | Reply | 9 comments |
headers
Patrick Marsh | 3 Jan 18:28
Picon
Gravatar

Re: csv2rec column names

I'm not sure what you are needing it for, but I would suggest looking
into numpy's loadtxt function.  You can use this to load the csv data
into numpy arrays and pass the resulting arrays arround.

-Patrick

On Sat, Jan 3, 2009 at 11:21 AM, antonv <vasilescu_anton@...> wrote:
>
> Hi all,
>
> I have a lot of csv files to process, all of them with the same number of
> columns. The only issue is that each file has a unique column name for the
> fourth column.
>
> All the csv2rec examples I found are using the r.column_name format to
> access the data in that column which is of no use for me because of the
> unique names. Is there a way to access that data using the column number? I
> bet this should be something simple but I cannot figure it out...
>
> Thanks in advance,
> Anton
> --
> View this message in context: http://www.nabble.com/csv2rec-column-names-tp21267055p21267055.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@...
(Continue reading)

Permalink | Reply | 6 comments |

Gmane