matplotlib-users Mailing List for matplotlib

I finally committed this fix.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello list,
I am trying to run the "histogram_demo_extended.py" on my mac 10.5.
I installed matplotlib through the scisoft package.
The normal hist command works fine but when I tried to use "align" or 
"histtype" keyward I get this kind of error:

[Macintosh-2:~/optional/examples/pylab_examples] nino% 
./histogram_demo_extended.py                                 
Traceback (most recent call last):
  File "./histogram_demo_extended.py", line 15, in <module>
    n, bins, patches = P.hist(x, 50, normed=1, histtype='stepfilled')
  File 
"/scisoft/i386/library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/pyplot.py", 
line 1633, in hist
    ret =  gca().hist(*args, **kwargs)
  File 
"/scisoft/i386/library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/axes.py", 
line 5064, in hist
    p.update(kwargs)
  File 
"/scisoft/i386/library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/artist.py", 
line 394, in update
    raise AttributeError('Unknown property %s'%k)
AttributeError: Unknown property histtype

Can someone give me any advice?
Thanks a lot in advance.

nino

-- 

Antonino Cucchiara
PhD candidate
Department of Astronomy&Astrophysics
Penn State University
website: www.astro.psu.edu/~cucchiara/

Hi,

How can I plot numbers on the x and y axes in scientific notation?
 I have very large values on the y axis which I'd like to show as 1e9 and
not 1 followed by 9 zeros.

Hi,

Thanks a lot to all of you for your help. This looks very promising. I will test it on Monday.

Regards, Marjolaine.

>>> Michael Droettboom <md...@st...> 09/05/08 7:54 PM >>>
You could do something like:

def bitget(value, bit_number):
    return (value & (1 << bit_number)) != 0

which will return True or False for the given bit number, and this 
function works on numpy arrays.  (Bits are numbered base-0 -- I don't 
know if that matches matlab).

Hope that helps,
Mike

Marjolaine Rouault wrote:
> Hi,
>
> I was wondering if python has the equivalent of the matlab bitget.m function.
>
> I have a large 2 dimensional variable of type uint32 which I must convert to binaries and then find if bit 23 of the binary for each point is 0 or 1. The matlab bitget function is ideal for that but I can't find much in python. The only thing I found was binary_repr which converts to a sting and can only be used for 1 point at a time.
>
> Any suggestions?
>
> Thanks, Marjolaine.
>
>   

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



-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

dmitrey wrote:
> Eric Firing wrote:
>> dmitrey wrote:
>>> hi all,
>>> matplotlib says it's similar to MATLAB's plot tool, however, using 
>>> plot(..., 'p') plots pentagram instead of star. It makes my (Python 
>>> scikits.openopt) graphic output of numerical convergence look uglier 
>>> than MATLAB version.
>>>
>>> So is plotting a star intended to be ever implemented?
>> Dmitrey,
>>
>> It was easy, so I added a 5-point star to the set of available markers 
>> in svn.  Use plot(..., '*').  'p' was already taken, and '*' seems 
>> more mnemonic--I would never think of 'p' as indicating a star.
>>
>> Eric
> Thank you, currently I'm using scatter (it will take a time while all 
> users will have the matplotlib version with '*' available).
> 
> There is unclear parameter in scatter docstring, could you explain what 
> does it mean:
> 
>   *s*:
>    size in points^2.  It is a scalar or an array of the same
>    length as *x* and *y*.
> 
> so what does it mean "size in points^2"?

It means the area of the circle circumscribing the marker, with that 
area measured in units of points squared. The strange choice of s as a 
measure of area instead of radius or diameter is for compatibility with 
Matlab.

Eric


> 
> Regards, D.

Ah, Ich verstehe now.  I'll try RGBA-ing it; in the meantime, let me know if the colormapping conversion gets changed to 32 bit.  Thanks again!

DG

--- On Sat, 9/6/08, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: Re: [Matplotlib-users] imshow size limitations?
> To: d_l...@ya...
> Cc: mat...@li...
> Date: Saturday, September 6, 2008, 3:13 PM
> David Goldsmith wrote:
> > Thanks, Eric!
> > 
> > --- On Sat, 9/6/08, Eric Firing
> <ef...@ha...> wrote:
> > 
> > -- snip OP --
> > 
> >> It looks to me like you simply ran out of
> memory--this is
> >> not an imshow 
> >> problem as such.  Your array is about 1e8
> elements, and as
> >> floats that 
> >> would be close to a GB--just for that array alone.
>  Do you
> > 
> > Well, I anticipated that, so I do initialize the
> storage for the numpy array as numpy.uint8 and have
> confirmed that the data in the array returned by the
> function which creates it remains numpy.uint8, so it should
> "only" be ~100MB (indeed, the .na file into which
> I tofile it is 85,430 KB, just as it should be for a 10800 x
> 8100 array of uint8 elements).  And the ax.imshow statement
> doesn't (directly) cause the crash (but I don't know
> that it isn't making either a float copy or an in-place
> conversion of the array).  So, AFAIK, right up until the
> statement:
> > 
> > canvas.print_figure('HiResHex')
> > 
> > the data being imaged are all numpy.uint8 type.
> 
> Yes, but it looks to me like they are still getting
> color-mapped, and 
> this requires conversion to numpy.float.  This may be a bad
> aspect of 
> the mpl design, but it is quite deeply embedded.  I suspect
> the best we 
> could do would be to use float32 instead of float64;
> certainly for color 
> mapping one does not need 64 bits.
> 
> Using numpy.uint8 helps only if you are specifying RGBA
> directly, 
> bypassing the colormapping.
> 
> > 
> >> really need 
> >> all that resolution?  
> > 
> > Well, there's the rub: I fancy myself a fractal
> "artist" and I have
> > access to an HP DesignJet 500ps plotter with a maximum
> resolution of
> > 1200 x 600 dpi. For the size images I'm trying to
> make (I'm hoping to go
> > even bigger than 36" x 27", but I figured
> that as a good starting point)
> > even I regard _that_ resolution as too much - I was
> thinking of 300 x
> > 300 dpi (which is its "normal" resolution)
> as certainly worthy of giving
> > a try. :-)
> 
> >> If you do, you will probably have to
> >> get a much 
> >> more capable machine.  
> > 
> > Possible, but I was hoping to generate at least one
> "proof" first to determine how hard I'd need
> to try.
> > 
> >> Otherwise, you need to knock down
> >> the size of 
> >> that array before trying to plot or otherwise
> manipulate
> >> it.
> > 
> > Forgive me, but I'd like a more detailed
> explanation as to why: I
> > have
> > ample (~35 GB, just on my built-in disc, much more
> than that on external
> > discs) harddisc space - isn't there some way to
> leverage that?
> 
> I don't know enough about virtual memory
> implementations--especially on 
> Win or Mac--to say.  In practice, I suspect you would find
> that as soon 
> as you are doing major swapping during a calculation, you
> will thrash 
> the disk until you run out of patience.
> 
> 
> >> With respect to imshow, probably you can get it to
> handle
> >> larger images 
> > 
> > Again, imshow doesn't appear to be the culprit
> (contrary to my
> > original subject line), rather it would appear to be
> > canvas.print_figure. (While I'm on the subject of
> canvas.print_figure,
> > isn't there some way for MPL to "splash"
> the image directly to the
> > screen, without first having to write to a file? I
> didn't ask this
> > before because I did eventually want to write the
> image to a file, but I
> > would prefer to do so only after I've had a look
> at it.)
> 
> It is imshow in the sense that most of the action in mpl
> doesn't happen 
> when you call imshow or plot or whatever--they just set
> things up.  The 
> real work is done in the backend when you display with
> show() or write 
> to a file.
> 
> 
> >> if you feed them in as NxMx4 numpy.uint8 RGBA
> arrays--but I
> >> doubt this 
> >> is going to be enough, or the right approach, for
> your
> >> present situation.
> > 
> > Right: I don't see how that would be better than
> having a single 8
> > bit
> > datum at each point w/ color being determined from a
> color map (which is
> > how I'd prefer to do it anyway).
> 
> The way it is better is that it avoids a major operation,
> including the 
> generation of the double-precision array.  The rgba array
> can go 
> straight to agg.
> 
> Eric
> 
> 
> > Thanks again,
> > 
> > DG
> >> Eric
> >>
> >>> Platform Details: MPL 0.91.2 (sorry, I
> didn't
> >> realize I was running such an old version, maybe I
> just need
> >> to upgrade?), Python 2.5.2, Windows XP 2002 SP3,
> 504MB
> >> physical RAM, 1294MB VM Page size (1000MB init.,
> 5000MB max)
> >>> Thanks!
> >>>
> >>> DG