numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Re: indexing problem

[Ryan K. <rya...@gm...>]

At the risk of sounding silly, can you explain to me in simple terms
why s**2 is less accurate than s*s.  I can sort of intuitively
appreciate that that would be true, but but might like just a little
more detail.

Thanks,

Ryan

On 2/13/06, Tim Hochberg <tim...@co...> wrote:
>
> >>
> >>Ryan Krauss wrote:
> >>
> >>
> >>
> >>>This may only be a problem for ridiculously large numbers.  I actually
> >>>meant to be dealing with these values:
> >>>
> >>>In [75]: d
> >>>Out[75]:
> >>>array([   246.74011003,    986.96044011,   2220.66099025,   3947.84176=
044,
> >>>        6168.50275068,   8882.64396098,  12090.26539133,  15791.367041=
74,
> >>>       19985.94891221,  24674.01100272])
> >>>
> >>>In [76]: s=3Dd[-1]*1.0j
> >>>
> >>>In [77]: s
> >>>Out[77]: 24674.011002723393j
> >>>
> >>>In [78]: type(s)
> >>>Out[78]: <type 'complex128scalar'>
> >>>
> >>>In [79]: s**2
> >>>Out[79]: (-608806818.96251547+7.4554869875188623e-08j)
> >>>
> >>>So perhaps the previous difference of 26 orders of magnitude really
> >>>did mean that the imaginary part was negligibly small, that just got
> >>>obscured by the fact that the real part was order 1e+135.
> >>>
> >>>On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
> >>>
> >>>
>
> I got myself all tied up in a knot over this because I couldn't figure
> out how multiplying two purely complex numbers was going to result in
> something with a complex portion. Since I couldn't find the complex
> routines my imagination went wild: perhaps, I thought, numpy uses the
> complex multiplication routine that uses 3 multiplies instead of the
> more straightforward one that uses 4 multiples, etc, etc. None of these
> panned out, and of course they all evaporated when I got pointed to the
> code that implements this which is pure vanilla.  All the time I was
> overlooking the obvious:
>
> Ryan is using s**2, not s*s.
>
> So the obvious answer, is that he's just seeing normal error in the
> function that is implementing pow.
>
> If this is inacuracy is problem, I'd just replace s**2 with s*s. It will
> probably be both faster and more accurate anyway
>
> Foolishly,
>
> -tim
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] NumPy Glossary: a request for review

[Christopher B. <Chr...@no...>]

Sasha wrote:
> I updated the "broadcasting" entry. I don't think examples belong to a
> glossary. I think a glossary should be more like a quick reference
> rather than a tutorial.  Unfortunately the broadcasting is one of
> those concepts that will never be clear without examples.

Then a wiki page on broadcasting may be in order, and the glossary could 
link to it.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] Re: indexing problem

[Tim H. <tim...@co...>]

>>
>>Ryan Krauss wrote:
>>
>>    
>>
>>>This may only be a problem for ridiculously large numbers.  I actually
>>>meant to be dealing with these values:
>>>
>>>In [75]: d
>>>Out[75]:
>>>array([   246.74011003,    986.96044011,   2220.66099025,   3947.84176044,
>>>        6168.50275068,   8882.64396098,  12090.26539133,  15791.36704174,
>>>       19985.94891221,  24674.01100272])
>>>
>>>In [76]: s=d[-1]*1.0j
>>>
>>>In [77]: s
>>>Out[77]: 24674.011002723393j
>>>
>>>In [78]: type(s)
>>>Out[78]: <type 'complex128scalar'>
>>>
>>>In [79]: s**2
>>>Out[79]: (-608806818.96251547+7.4554869875188623e-08j)
>>>
>>>So perhaps the previous difference of 26 orders of magnitude really
>>>did mean that the imaginary part was negligibly small, that just got
>>>obscured by the fact that the real part was order 1e+135.
>>>
>>>On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
>>>      
>>>

I got myself all tied up in a knot over this because I couldn't figure 
out how multiplying two purely complex numbers was going to result in 
something with a complex portion. Since I couldn't find the complex 
routines my imagination went wild: perhaps, I thought, numpy uses the 
complex multiplication routine that uses 3 multiplies instead of the 
more straightforward one that uses 4 multiples, etc, etc. None of these 
panned out, and of course they all evaporated when I got pointed to the 
code that implements this which is pure vanilla.  All the time I was 
overlooking the obvious:

Ryan is using s**2, not s*s.

So the obvious answer, is that he's just seeing normal error in the 
function that is implementing pow.

If this is inacuracy is problem, I'd just replace s**2 with s*s. It will 
probably be both faster and more accurate anyway

Foolishly,

-tim

Re: [Numpy-discussion] Re: indexing problem

[Tim H. <tim...@co...>]

Travis Oliphant wrote:

> Tim Hochberg wrote:
>
>>
>> I've been trying to look into the problem described below, but I just 
>> can't find where complex multiplication is being done (all the other 
>> multiplication, but not complex). Could someone with a grasp of the 
>> innards of numpy please point me in the right direction?
>
>
> Look in the build directory for __umath_generated.c.  In there you 
> will see that multiplication for complex numbers is done using 
> PyUFunc_FF_F and friends (i.e. using a generic interface for wrapping 
> a "scalar" function).   The scalar function wrapped into a ufunc 
> vectorized function is given in multiply_data.  In that file you 
> should see it present as nc_prodf, nc_prod, nc_prodl.
>
> nc_prod and friends are implemented in umathmodule.c.src


Thanks Travis, it would have taken me a while to track them down. As it 
turns out I was going off on the wrong track as I'll report in my next 
message.

-tim

Re: [Numpy-discussion] String array equality test does not broadcast

[Russel H. <ru...@ap...>]

OK, Thanks.
Russel

> Equality testing on string arrays does not work (equality testing  
> uses ufuncs internally which are not supported generally for  
> flexible arrays).   You must use chararray's.
>
> Thus,
>
> sta.view(chararray) == stb.view(chararray)
>
> Or create chararray's from the beginning:
>
> sta = char.array(['abc','def','ghi'])
> stb = char.array(['abc','jkl','ghi'])
>
> Char arrays are a special subclass of the ndarray that give arrays  
> all the methods of strings (and unicode) elements and allow (rich)  
> comparison operations.
>
> -Travis
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Re: indexing problem

[Travis O. <oli...@ee...>]

Tim Hochberg wrote:

>
> I've been trying to look into the problem described below, but I just 
> can't find where complex multiplication is being done (all the other 
> multiplication, but not complex). Could someone with a grasp of the 
> innards of numpy please point me in the right direction?

Look in the build directory for __umath_generated.c.  In there you will 
see that multiplication for complex numbers is done using PyUFunc_FF_F 
and friends (i.e. using a generic interface for wrapping a "scalar" 
function).   The scalar function wrapped into a ufunc vectorized 
function is given in multiply_data.  In that file you should see it 
present as nc_prodf, nc_prod, nc_prodl.

nc_prod and friends are implemented in umathmodule.c.src

-Travis

Re: [Numpy-discussion] String array equality test does not broadcast

[Travis O. <oli...@ee...>]

Russel Howe wrote:

> I am converting some numarray code to numpy and I noticed this behavior:
>
> >>> from numpy import *
> >>> sta=array(['abc', 'def', 'ghi'])
> >>> stb=array(['abc', 'jkl', 'ghi'])
> >>> sta==stb
> False
>
> I expected the same as this:
> >>> a1=array([1,2,3])
> >>> a2=array([1,4,3])
> >>> a1==a2
> array([True, False, True], dtype=bool)
>
> I am trying to figure out how to fix this now...


Equality testing on string arrays does not work (equality testing uses 
ufuncs internally which are not supported generally for flexible 
arrays).   You must use chararray's.

Thus,

sta.view(chararray) == stb.view(chararray)

Or create chararray's from the beginning:

sta = char.array(['abc','def','ghi'])
stb = char.array(['abc','jkl','ghi'])

Char arrays are a special subclass of the ndarray that give arrays all 
the methods of strings (and unicode) elements and allow (rich) 
comparison operations.

-Travis

Re[4]: [Numpy-discussion] dtype names and titles

[Alan G I. <ai...@am...>]

On Mon, 13 Feb 2006, Francesc Altet apparently wrote: 
> My point is that I think that keys in arrays for accessing 
> fields should be unique
> But of course I think that having both names and titles is 
> a good thing. 

OK.  We're in agreement then.

Thanks,
Alan

Re: [Numpy-discussion] Re: indexing problem

[Tim H. <tim...@co...>]

I've been trying to look into the problem described below, but I just 
can't find where complex multiplication is being done (all the other 
multiplication, but not complex). Could someone with a grasp of the 
innards of numpy please point me in the right direction?

Thanks,

-tim

Ryan Krauss wrote:

>This may only be a problem for ridiculously large numbers.  I actually
>meant to be dealing with these values:
>
>In [75]: d
>Out[75]:
>array([   246.74011003,    986.96044011,   2220.66099025,   3947.84176044,
>         6168.50275068,   8882.64396098,  12090.26539133,  15791.36704174,
>        19985.94891221,  24674.01100272])
>
>In [76]: s=d[-1]*1.0j
>
>In [77]: s
>Out[77]: 24674.011002723393j
>
>In [78]: type(s)
>Out[78]: <type 'complex128scalar'>
>
>In [79]: s**2
>Out[79]: (-608806818.96251547+7.4554869875188623e-08j)
>
>So perhaps the previous difference of 26 orders of magnitude really
>did mean that the imaginary part was negligibly small, that just got
>obscured by the fact that the real part was order 1e+135.
>
>On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
>  
>
>>I am having a problem with indexing an array and not getting the
>>expected scalar behavior for complex128scalar:
>>
>>In [44]: c
>>Out[44]:
>>array([  3.31781200e+06,   2.20157529e+13,   1.46088259e+20,
>>         9.69386754e+26,   6.43248601e+33,   4.26835585e+40,
>>         2.83232045e+47,   1.87942136e+54,   1.24711335e+61,
>>         8.27537526e+67])
>>
>>In [45]: s=c[-1]*1.0j
>>
>>In [46]: type(s)
>>Out[46]: <type 'complex128scalar'>
>>
>>In [47]: s**2
>>Out[47]: (-6.848183561893313e+135+8.3863291020365108e+119j)
>>
>>In [48]: s=8.27537526e+67*1.0j
>>
>>In [49]: type(s)
>>Out[49]: <type 'complex'>
>>
>>In [50]: s**2
>>Out[50]: (-6.8481835693820068e+135+0j)
>>
>>Why does result 47 have a non-zero imaginary part?
>>
>>Ryan
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>  
>

Re: [Numpy-discussion] matplotlib

[John H. <jdh...@ac...>]

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Actually, a little creative use of sys._getframe() can
    Fernando> tell you that, in some instances (if the import was done


Which is why I wrote "as far as I know..." because in real life almost
nothing is impossible in python if you are willing to get in and
inspect and modify the stack.  

    Fernando> But I seriously doubt matplotlib goes to such unpleasant
    Fernando> extremes in this case :)

No, we'll leave that kind of magic to you and the ipython crew :-)

JDH

Re: [Numpy-discussion] matplotlib

[Fernando P. <Fer...@co...>]

John Hunter wrote:
>>>>>>"Bill" == Bill Baxter <wb...@gm...> writes:
> 
> 
>     Bill> from numpy import * was the only line missing, called before
>     Bill> the rest.  It seems to work fine if I use from pylab import
>     Bill> * instead of import pylab as g
> 
>     Bill> And actually if I do both in this order: import pylab as g
>     Bill> from pylab import *
> 
>     Bill> Seems as if there's some
>     Bill> initialization code that only gets run with the 'from pylab
>     Bill> import *' version.
> 
> As far as I know that is a python impossibility, unless perhaps you do
> some deep dark magic that is beyond my grasp.  pylab doesn't know how
> it is imported.

Actually, a little creative use of sys._getframe() can tell you that, in some 
instances (if the import was done via pure python and the source can be found 
via inspect, it will fail for extension code and if inspect runs into 
trouble).  If you _really_ want, you can also use dis.dis() on the frame above 
you and analyze the bytecode.

But I seriously doubt matplotlib goes to such unpleasant extremes in this case :)

Cheers,

f

ps - for the morbidly curious, here's how to do this:

planck[import_tricks]> cat all.py
from trick import *

planck[import_tricks]> cat mod.py
import trick

planck[import_tricks]> cat trick.py
import sys,dis

f = sys._getframe(1)
print f.f_code
print dis.dis(f.f_code)

planck[import_tricks]> python all.py
<code object ? at 0x4006c7a0, file "all.py", line 1>
   1           0 LOAD_CONST               0 (('*',))
               3 IMPORT_NAME              0 (trick)
               6 IMPORT_STAR
               7 LOAD_CONST               1 (None)
              10 RETURN_VALUE
None

planck[import_tricks]> python mod.py
<code object ? at 0x4006c7a0, file "mod.py", line 1>
   1           0 LOAD_CONST               0 (None)
               3 IMPORT_NAME              0 (trick)
               6 STORE_NAME               0 (trick)
               9 LOAD_CONST               0 (None)
              12 RETURN_VALUE
None


####

Since the code object has a file path and line number, you could fetch that 
and look at the source directly instead of dealing with the bytecode.

Re: [Numpy-discussion] dtype names and titles

[Christopher H. <ch...@st...>]

N. Volbers wrote:
> 
> By the way, is there an easy way to access a field vector by its index? 
> Right now I retrieve the field name from dtype.fields[-1][index] and 
> then return the 'column' by using myarray[name].


Travis,

Perhaps we could add a field method to recarray like numarray's? This 
would allow access by both field name and "column" index.  This would be 
nice for people who are using this convention and are making the switch 
from numarray.

Chris

[Numpy-discussion] String array equality test does not broadcast

[Russel H. <ru...@ap...>]

I am converting some numarray code to numpy and I noticed this behavior:

 >>> from numpy import *
 >>> sta=array(['abc', 'def', 'ghi'])
 >>> stb=array(['abc', 'jkl', 'ghi'])
 >>> sta==stb
False

I expected the same as this:
 >>> a1=array([1,2,3])
 >>> a2=array([1,4,3])
 >>> a1==a2
array([True, False, True], dtype=bool)

I am trying to figure out how to fix this now...

[Numpy-discussion] Re: indexing problem

[Ryan K. <rya...@gm...>]

This may only be a problem for ridiculously large numbers.  I actually
meant to be dealing with these values:

In [75]: d
Out[75]:
array([   246.74011003,    986.96044011,   2220.66099025,   3947.84176044,
         6168.50275068,   8882.64396098,  12090.26539133,  15791.36704174,
        19985.94891221,  24674.01100272])

In [76]: s=3Dd[-1]*1.0j

In [77]: s
Out[77]: 24674.011002723393j

In [78]: type(s)
Out[78]: <type 'complex128scalar'>

In [79]: s**2
Out[79]: (-608806818.96251547+7.4554869875188623e-08j)

So perhaps the previous difference of 26 orders of magnitude really
did mean that the imaginary part was negligibly small, that just got
obscured by the fact that the real part was order 1e+135.

On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
> I am having a problem with indexing an array and not getting the
> expected scalar behavior for complex128scalar:
>
> In [44]: c
> Out[44]:
> array([  3.31781200e+06,   2.20157529e+13,   1.46088259e+20,
>          9.69386754e+26,   6.43248601e+33,   4.26835585e+40,
>          2.83232045e+47,   1.87942136e+54,   1.24711335e+61,
>          8.27537526e+67])
>
> In [45]: s=3Dc[-1]*1.0j
>
> In [46]: type(s)
> Out[46]: <type 'complex128scalar'>
>
> In [47]: s**2
> Out[47]: (-6.848183561893313e+135+8.3863291020365108e+119j)
>
> In [48]: s=3D8.27537526e+67*1.0j
>
> In [49]: type(s)
> Out[49]: <type 'complex'>
>
> In [50]: s**2
> Out[50]: (-6.8481835693820068e+135+0j)
>
> Why does result 47 have a non-zero imaginary part?
>
> Ryan
>

[Numpy-discussion] indexing problem

[Ryan K. <rya...@gm...>]

I am having a problem with indexing an array and not getting the
expected scalar behavior for complex128scalar:

In [44]: c
Out[44]:
array([  3.31781200e+06,   2.20157529e+13,   1.46088259e+20,
         9.69386754e+26,   6.43248601e+33,   4.26835585e+40,
         2.83232045e+47,   1.87942136e+54,   1.24711335e+61,
         8.27537526e+67])

In [45]: s=3Dc[-1]*1.0j

In [46]: type(s)
Out[46]: <type 'complex128scalar'>

In [47]: s**2
Out[47]: (-6.848183561893313e+135+8.3863291020365108e+119j)

In [48]: s=3D8.27537526e+67*1.0j

In [49]: type(s)
Out[49]: <type 'complex'>

In [50]: s**2
Out[50]: (-6.8481835693820068e+135+0j)

Why does result 47 have a non-zero imaginary part?

Ryan

Re: [Numpy-discussion] matplotlib

[Ryan K. <rya...@gm...>]

The point of the numerix setting in the rc file is that matplotlib
can't tell you what is the best numerical package to use for your
problem.

On 2/13/06, Bill Baxter <wb...@gm...> wrote:
> Ah, ok.  You're right.  Doing from pylab import * was actually just
> overwriting the definition of array and rand() to be those from Numeric,
> which pylab was picking to use by default.   I guess my expectation was t=
hat
> pylab would default to using the best numerical package installed.
>
> With "numerix : numpy" in my ~/.matplotlib/matplotlibrc file, it seems to=
 be
> working properly now.
>
> Thanks for the help!
>
> --bb
>
> On 2/14/06, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Bill" =3D=3D Bill Baxter <wb...@gm...> writes:
> >
> >     Bill> from numpy import * was the only line missing, called before
> >     Bill> the rest.  It seems to work fine if I use from pylab import
> >     Bill> * instead of import pylab as g
> >
> >     Bill> And actually if I do both in this order: import pylab as g
> >     Bill> from pylab import *
> >
> >     Bill> Seems as if there's some
> >     Bill> initialization code that only gets run with the 'from pylab
> >     Bill> import *' version.
> >
> > As far as I know that is a python impossibility, unless perhaps you do
> > some deep dark magic that is beyond my grasp.  pylab doesn't know how
> > it is imported.
> >
> > Are you sure you have your numerix set properly?  I suggest creating
> > two free standing scripts, one with the problem and one without, and
> > running both with --verbose-helpful to make sure that your settings
> > are what you think they are.  If you verify that numerix is set
> > properly and still see the problem, I would like to see both scripts
> > in case it is exposing a problem with matplotlib.
> >
> > Of course, doing multiple import * commands is a recipe for long term
> > pain, especially with packages that have so much overlapping namespace
> > and numpy/scipy/pylab.
> >
> > JDH
> >
>
>
>

Re: [Numpy-discussion] matplotlib

[Bill B. <wb...@gm...>]

Ah, ok.  You're right.  Doing from pylab import * was actually just
overwriting the definition of array and rand() to be those from Numeric,
which pylab was picking to use by default.   I guess my expectation was tha=
t
pylab would default to using the best numerical package installed.

With "numerix : numpy" in my ~/.matplotlib/matplotlibrc file, it seems to b=
e
working properly now.

Thanks for the help!

--bb

On 2/14/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Bill" =3D=3D Bill Baxter <wb...@gm...> writes:
>
>     Bill> from numpy import * was the only line missing, called before
>     Bill> the rest.  It seems to work fine if I use from pylab import
>     Bill> * instead of import pylab as g
>
>     Bill> And actually if I do both in this order: import pylab as g
>     Bill> from pylab import *
>
>     Bill> Seems as if there's some
>     Bill> initialization code that only gets run with the 'from pylab
>     Bill> import *' version.
>
> As far as I know that is a python impossibility, unless perhaps you do
> some deep dark magic that is beyond my grasp.  pylab doesn't know how
> it is imported.
>
> Are you sure you have your numerix set properly?  I suggest creating
> two free standing scripts, one with the problem and one without, and
> running both with --verbose-helpful to make sure that your settings
> are what you think they are.  If you verify that numerix is set
> properly and still see the problem, I would like to see both scripts
> in case it is exposing a problem with matplotlib.
>
> Of course, doing multiple import * commands is a recipe for long term
> pain, especially with packages that have so much overlapping namespace
> and numpy/scipy/pylab.
>
> JDH
>

Re: [Numpy-discussion] matplotlib

[John H. <jdh...@ac...>]

>>>>> "Bill" == Bill Baxter <wb...@gm...> writes:

    Bill> from numpy import * was the only line missing, called before
    Bill> the rest.  It seems to work fine if I use from pylab import
    Bill> * instead of import pylab as g

    Bill> And actually if I do both in this order: import pylab as g
    Bill> from pylab import *

    Bill> Seems as if there's some
    Bill> initialization code that only gets run with the 'from pylab
    Bill> import *' version.

As far as I know that is a python impossibility, unless perhaps you do
some deep dark magic that is beyond my grasp.  pylab doesn't know how
it is imported.

Are you sure you have your numerix set properly?  I suggest creating
two free standing scripts, one with the problem and one without, and
running both with --verbose-helpful to make sure that your settings
are what you think they are.  If you verify that numerix is set
properly and still see the problem, I would like to see both scripts
in case it is exposing a problem with matplotlib.

Of course, doing multiple import * commands is a recipe for long term
pain, especially with packages that have so much overlapping namespace
and numpy/scipy/pylab.

JDH

Re: [Numpy-discussion] matplotlib

[Bill B. <wb...@gm...>]

from numpy import *

was the only line missing, called before the rest.
It seems to work fine if I use
     from pylab import *
instead of
     import pylab as g

And actually if I do both in this order:
     import pylab as g
     from pylab import *

then plot() and g.plot() both do the right thing (no truncating of floats).
Seems as if there's some initialization code that only gets run with the
'from pylab import *' version.

--bb

On 2/14/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Bill" =3D=3D Bill Baxter <wb...@gm...> writes:
>
>     Bill> Anyone know if matplotlib is supposed to work with the new
>     Bill> NumPy or if there is work afoot to make it work?  It seems
>     Bill> to truncate all numpy.array and numpy.matrix inputs to
>     Bill> integer values:
>
> You're script as posted is incomplete
>
>     import matplotlib
>     matplotlib.interactive(True)
>     matplotlib.use('WXAgg')
>     import matplotlib.pylab as g
>
>     g.plot(rand(5),rand(5),'bo')
>
> where for example is rand coming from?  My guess is you have an import
> statement you are not showing us.
>
> If you are using a recent numpy and matplotlib, and set numerix to
> numpy in your matplotlib rc file (~/.matplotlib/matplotlibrc)
> everything should work if you get your array symbols from pylab, numpy
> or matplotlib.numerix (all of which will get their symbols from
> numpy....)
>
> JDH
>

Re: [Numpy-discussion] matplotlib

[John H. <jdh...@ac...>]

>>>>> "Bill" == Bill Baxter <wb...@gm...> writes:

    Bill> Anyone know if matplotlib is supposed to work with the new
    Bill> NumPy or if there is work afoot to make it work?  It seems
    Bill> to truncate all numpy.array and numpy.matrix inputs to
    Bill> integer values:

You're script as posted is incomplete

    import matplotlib
    matplotlib.interactive(True)
    matplotlib.use('WXAgg')
    import matplotlib.pylab as g

    g.plot(rand(5),rand(5),'bo')

where for example is rand coming from?  My guess is you have an import
statement you are not showing us.

If you are using a recent numpy and matplotlib, and set numerix to
numpy in your matplotlib rc file (~/.matplotlib/matplotlibrc)
everything should work if you get your array symbols from pylab, numpy
or matplotlib.numerix (all of which will get their symbols from
numpy....)

JDH

Re: [Numpy-discussion] matplotlib

[Bill B. <wb...@gm...>]

I've got 0.86.2.  It looks like if I do 'import pylab as g' it doesn't work=
,
but 'from pylab import *' does for some reason.
--bb

On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
>
> What version are you using?  I know that CVS matplotlib works with
> numpy and I think the latest releases do as well.  I think the current
> version is 0.86.2
>
> On 2/13/06, Bill Baxter <wb...@gm...> wrote:
> > Anyone know if matplotlib is supposed to work with the new NumPy or if
> there
> > is work afoot to make it work?
> > It seems to truncate all numpy.array and numpy.matrix inputs to integer
> > values:
> >
> >     import matplotlib
> >      matplotlib.interactive(True)
> >      matplotlib.use('WXAgg')
> >      import matplotlib.pylab as g
> >
> >     g.plot(rand(5),rand(5),'bo')
> >
> > just puts a dot at (0,0), while this
> >
> >     g.plot(rand(5)*10,rand(5)*10,'bo')
> >
> > generates a plot of 5 points but all at integer coordinates.
> >
> >
> > --bb
> >
>



--
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380

Re: [Numpy-discussion] matplotlib

[Ryan K. <rya...@gm...>]

What version are you using?  I know that CVS matplotlib works with
numpy and I think the latest releases do as well.  I think the current
version is 0.86.2

On 2/13/06, Bill Baxter <wb...@gm...> wrote:
> Anyone know if matplotlib is supposed to work with the new NumPy or if th=
ere
> is work afoot to make it work?
> It seems to truncate all numpy.array and numpy.matrix inputs to integer
> values:
>
>     import matplotlib
>      matplotlib.interactive(True)
>      matplotlib.use('WXAgg')
>      import matplotlib.pylab as g
>
>     g.plot(rand(5),rand(5),'bo')
>
> just puts a dot at (0,0), while this
>
>     g.plot(rand(5)*10,rand(5)*10,'bo')
>
> generates a plot of 5 points but all at integer coordinates.
>
>
> --bb
>

[Numpy-discussion] matplotlib

[Bill B. <wb...@gm...>]

Anyone know if matplotlib is supposed to work with the new NumPy or if ther=
e
is work afoot to make it work?
It seems to truncate all numpy.array and numpy.matrix inputs to integer
values:

    import matplotlib
    matplotlib.interactive(True)
    matplotlib.use('WXAgg')
    import matplotlib.pylab as g

    g.plot(rand(5),rand(5),'bo')

just puts a dot at (0,0), while this

    g.plot(rand(5)*10,rand(5)*10,'bo')

generates a plot of 5 points but all at integer coordinates.


--bb

Re: Re[2]: [Numpy-discussion] dtype names and titles

[Francesc A. <fa...@ca...>]

El dl 13 de 02 del 2006 a les 08:35 -0500, en/na Alan G Isaac va
escriure:
> >> Is anybody actually using both names and titles?=20
>=20
> On Mon, 13 Feb 2006, Francesc Altet apparently wrote:=20
> > Not me.=20
>=20
> Is the "title" the appropriate storage for the "displayname"
> for fields that are to be plotted?  Or not?

Uh, yes. Perhaps I messed up things. Of course it is interesting to have
both a name and a title. What I tried to mean is that accessing fields
by *both* names and titles might introduce confusion. For example,
allowing:

>>> mydata =3D [(1,1), (2,4), (3,9)]

>>> mytype =3D {'names': ['col1','col2'], 'formats':['i2','f4'],'titles':
['col 2', 'col 1']}
>>> b =3D numpy.array( mydata, dtype=3Dmytype)
>>> b
array([(1, 1.0), (2, 4.0), (3, 9.0)], dtype=3D(void,6))
>>> b['col1']
array([1, 2, 3], dtype=3Dint16)
>>> b['col 2']
array([1, 2, 3], dtype=3Dint16)

seems quite strange to me. My point is that I think that keys in arrays
for accessing fields should be unique, and thus, I'd remove the last
sentence as a valid one.

But of course I think that having both names and titles is a good thing.
Sorry for the confusion.

Cheers,

--=20
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   C=E1rabos Coop. V.   Enjoy Data
 "-"

Re[2]: [Numpy-discussion] dtype names and titles

[Alan G I. <ai...@am...>]

>> Is anybody actually using both names and titles? 

On Mon, 13 Feb 2006, Francesc Altet apparently wrote: 
> Not me. 

Is the "title" the appropriate storage for the "displayname"
for fields that are to be plotted?  Or not?

Thanks,
Alan Isaac