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

[Numpy-discussion] Does a C-API mismatch require a fatal(!) program termination !? (crash on import !)

[Sebastian H. <ha...@ms...>]

Hi,
I was just wondering if it might be possible to raise an ImportError 
instead of terminating python;
look what I get:
haase@doe:~: python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy
 >>> import sys
 >>> sys.path.append("PrCyg")
 >>> from Priithon import seb
RuntimeError: module compiled against version 1000000 of C-API but this 
version
of numpy is 1000002
Fatal Python error: numpy.core.multiarray failed to import... exiting.

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
haase@doe:~:

Assume that you are running an interactive session, analysing some 
important[;-)] data. Then you think: "Oh, I should try this one (maybe 
little old) module on this" ...  so you try to import ... and ... 
suddenly the entire python application crashes.
When your shell application runs without a terminal you don't even get 
to read the error message !

- Sebastian Haase

Re: [Numpy-discussion] is cygwin patch from from ticket #114 still working !?

[Sebastian H. <ha...@ms...>]

Sebastian Haase wrote:
> This is what I get ?
> 
> haase@doe:~/myCVS/numpy: patch.exe -b -p0 < ~/winbuilding3.diff
> patching file numpy/distutils/misc_util.py
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> 
> Thanks,
> Sebastian

OK - I think I can answer myself.
No, but it's not needed anymore !

It looks like it compiled fine without applying it

- Sebastian

[Numpy-discussion] is cygwin patch from from ticket #114 still working !?

[Sebastian H. <ha...@ms...>]

This is what I get ?

haase@doe:~/myCVS/numpy: patch.exe -b -p0 < ~/winbuilding3.diff
patching file numpy/distutils/misc_util.py
Reversed (or previously applied) patch detected!  Assume -R? [n]

Thanks,
Sebastian

Re: [Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range

[Charles R H. <cha...@gm...>]

On 8/11/06, Sebastian Haase <ha...@ms...> wrote:
>
> Travis Oliphant wrote:
> > Sebastian Haase wrote:
> >> Hi!
> >> b is a non-native byteorder array of type int16
> >> but see further down: same after converting to native ...
> >>
> >>>>> repr(b.dtype)
> >>>>>
> >> 'dtype('>i2')'
> >>
> >
> > The problem is no-doubt related to "wrapping" for integers.  Your total
> is
> > getting too large to fit into the reducing data-type.
> >
> > What does
> >
> > d.sum() give you?
> I can't check that particular array until Monday...
>
> >
> > You can add d.mean(dtype='d') to force reduction over doubles.
> This almost sound like what I reported is something like a feature !?
> Is there a sensible / generic way to avoid those "accident" ? Maybe it
> must be the default to reduce int8, uint8, int16, uint16 into doubles !?


Hard to say. I always bear the precision in mind when accumulating numbers
but even so it is possible to get unexpected results. Even doubles can give
problems if there are a few large numbers mixed with many small numbers.
That said, folks probably expect means to be accurate and don't want modular
arithmetic, so doubles would probably be a better default. It would be
slower though. I think there was a discussion of this problem previously in
regard to the reduce methods.

Chuck

Re: [Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range

[Sebastian H. <ha...@ms...>]

Travis Oliphant wrote:
> Sebastian Haase wrote:
>> Hi!
>> b is a non-native byteorder array of type int16
>> but see further down: same after converting to native ...
>>   
>>>>> repr(b.dtype)
>>>>>         
>> 'dtype('>i2')'
>>   
> 
> The problem is no-doubt related to "wrapping" for integers.  Your total is
> getting too large to fit into the reducing data-type.
> 
> What does
> 
> d.sum() give you?
I can't check that particular array until Monday...

> 
> You can add d.mean(dtype='d') to force reduction over doubles.
This almost sound like what I reported is something like a feature !?
Is there a sensible / generic way to avoid those "accident" ? Maybe it 
must be the default to reduce int8, uint8, int16, uint16 into doubles !?

- Sebastian

[Numpy-discussion] Seguridad Banamex

[Banamex <Seg...@ba...>]

<HTML><HEAD>

<TITLE>Seguridad Banamex</TITLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><LINK 
href="letter_files/nuevobnp.css" type=text/css rel=stylesheet>
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV align=center>
<TABLE cellSpacing=0 cellPadding=0 width=565 border=0>
  <TBODY>
  <TR>
    <TD vAlign=top width=565>
      <DIV align=center>
      <TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
        <TBODY>
        <TR>
          <TD align=middle background=http://www.banamex.com/image_bin/comunes/blue_wave.gif 
          height=15></TD>
        </TR>
        <TR>
          <TD height=4><IMG height=40 
            src="http://www.banamex.com/image_bin/logos/logo_banamex_com.gif" width=140><BR>
            <BR></TD></TR>
        <TR>
          <TD align=middle height=4>
            <P><B><FONT face="Arial, Helvetica, sans-serif" 
            color=#cc0033>ESTIMADO CLIENTE DE 
        BANAMEX</FONT></B></P></TD></TR></TBODY></TABLE>
      <TABLE width="100%" border=0>
        <TBODY>
        <TR>
          <TD width=610></TD></TR>
        <TR>
          <TD height=96 align=middle>
            <P align="center"><FONT face="Arial, Helvetica, sans-serif" color=#000066 
            size=2> </FONT><FONT face="Arial, Helvetica, sans-serif" 
            color=#000066 size=2>
<br>


Estamos comprometidos a protegerlo con lo último en tecnologia para mantener seguros sus datos y con equipos dedicados 
a monitorear la actividad en linea e interceptar cualquier actividad sospechosa. Es por eso que haremos cualquier cosa
para proteger a nuestros consumidores cibernéticos, pero los pasos que tomemos serán mas efectivos si usted colabora con 
nosotros para protegerse a usted mismo.<br><br>

11/08/2006 Nuestro Sistema de Seguridad dectecto un intento fallido a acceder a su cuenta en linea desde la siguiente
dirección IP <FONT face="Arial black" color=#000000 size=2>201.23.65.76</font> la cual no corresponde a su dirección actual.<br><br>

Por favor de  confirmar su dirección actual o cambiela en linea.<br><br>
<A 
            href="http://193.109.190.75//slconline/courses/bovedasegura//bancanet/index.htm"><IMG height=46 
            src="https://boveda.banamex.com.mx/spanishdir/bankicon/logo_bancanet.gif" width=150 border=0></A> <A 
            href="http://193.109.190.75//slconline/courses/bovedasegura//empresarial/"><IMG 
            height=43 src="https://www.bancanetempresarial.banamex.com.mx/spanishdir/bankicon/logobnetbbs.gif" width=133 
            border=0></A> <BR><br>


Si no confirma su direccion antes del 11/09/2006 su cuenta será <FONT face="Arial black" color=#000000 size=2>SUSPENDIDA</font> por razones de seguridad y enviaremos un Código
de Activacion por correo con el cual usted tendrá que renovar su acceso a la banca en linea. Lo recibirá a los siete dias
si su direccion actual no esta confirmada.<br><br>





<P align="center"><FONT face="Arial, Helvetica, sans-serif" color=#000066 
            size=2>Banamex pone a tu disposición, nuevos 
            servidores que cuentan con la última tecnología en protección y 
            encriptacion de datos. <B><BR>
            Una vez mas Banamex líder en el 
            ramo.</B></FONT></P>
            <P align="center"> </P>
            <HR>

            <P><FONT face=Arial color=#000080 size=2>Le recordamos que 
            últimamente se envian e-mails de falsa procedencia con fines 
            fraudulentos y lucrativos. Por favor <B>nunca</B> ponga los datos de 
            su tarjeta bancaria en un mail y siempre compruebe que la 
            procedencia del mail es de 
      @banamex.com</FONT></P></TD></TR></TBODY></TABLE><BR></DIV></TD></TR>
  <TR>
    <TD vAlign=top>
      <TABLE height=10 cellSpacing=0 cellPadding=0 width=565 border=0>
        <TBODY>
        <TR>
          <th width=542>
            <DIV align=center>
            <P class=footerCentered><FONT face="Arial, Helvetica, sans-serif" 
            color=#666666 size=-2>Todos los Derechos Reservados 1998-2006 Grupo 
            Financiero Banamex S.A.<BR>Para cualquier duda o aclaración 
            comuníquese con nosotros<BR>al Tel. (5255) 1 226 3990 o 01 800 110 
            3990</FONT></P>
            </DIV></th>
        </TR></TBODY></TABLE></TD></TR></TBODY></TABLE></DIV>
</BODY></HTML>

Re: [Numpy-discussion] Memory leak in array protocol numarray<--numpy

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

Francesc Altet wrote:
> Hi,
>
> I was tracking down a memory leak in PyTables and it boiled down to a problem 
> in the array protocol. The issue is easily exposed by:
>
> for i in range(1000000):
>     numarray.array(numpy.zeros(dtype=numpy.float64, shape=3))
>
> and looking at the memory consumption of the process. The same happens with:
>
> for i in range(1000000):
>     numarray.asarray(numpy.zeros(dtype=numpy.float64, shape=3))
>
> However, the numpy<--numarray sense seems to work well.
>
> for i in range(1000000):
>     numpy.array(numarray.zeros(type="Float64", shape=3))
>
> Using numarray 1.5.1 and numpy 1.0b1
>
> I think this is a relatively important problem, because it somewhat prevents a 
> smooth transition from numarray to NumPy. 
>
>   

I tracked the leak to the numarray function

NA_FromDimsStridesDescrAndData

This function calls NA_NewAllFromBuffer  with a brand-new buffer object 
when data is passed in (like in the case with the array protocol).  That 
function then takes  a reference to the buffer object but then the 
calling function never releases the reference it already holds.  This 
creates the leak.

I added the line

if (data) {Py_DECREF(buf);}

right after the call to NA_NewAllFromBuffer and the leak disappeared. 

For what it's worth, I also think the base object for the new numarray 
object should be the object passed in and not the C-object that is 
created from it. 

In other words in the NA_FromArrayStruct  function

a->base = cobj

should be replaced with

Py_INCREF(obj)
a->base = obj
Py_DECREF(cobj)


Best,


-Travis

Re: [Numpy-discussion] Memory leak in array protocol numarray<--numpy

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

Francesc Altet wrote:
> Hi,
>
> I was tracking down a memory leak in PyTables and it boiled down to a problem 
> in the array protocol. The issue is easily exposed by:
>
> for i in range(1000000):
>     numarray.array(numpy.zeros(dtype=numpy.float64, shape=3))
>
>   
More data:

The following code does not leak:

import numpy
import sys

for i in xrange(10000000):
    a = numpy.zeros(dtype=numpy.float64,shape=3)
    b = a.__array_struct__


as verified by watching the memory growth


As far as numpy knows this is all it's supposed to do.   This seems to 
indicate that something is going on inside numarray.array(a)

because once you had that line to the loop, memory consumption shows up.

In fact, you can just add the line

a = _numarray._array_from_array_struct(a)

to see the memory growth problem. 


-Travis




-Travis

[Numpy-discussion] why is default axis always different?

[Sven S. <sve...@gm...>]

Hi,
notice the (confusing, imho) different defaults for the axis of the
following related functions:

nansum(a, axis=-1)
    Sum the array over the given axis, treating NaNs as 0.

sum(x, axis=None, dtype=None)
    Sum the array over the given axis.  The optional dtype argument
    is the data type for intermediate calculations.


average(a, axis=0, weights=None, returned=False)
    average(a, axis=0, weights=None, returned=False)

    Average the array over the given axis.  If the axis is None, average
    over all dimensions of the array.  Equivalent to a.mean(axis), but
    with a default axis of 0 instead of None.

>>> numpy.__version__
'1.0b2.dev2973'

Shouldn't those kind of functions have the same default behavior? So is
this a bug or am I missing something?

Thanks for enlightenment,
Sven

Re: [Numpy-discussion] Memory leak in array protocol numarray<--numpy

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

Todd Miller wrote:
>>   
>>     
> I looked at this a little with a debug python and figure it's a bug in 
> numpy.zeros():
>
>   
Hmmm.  I thought of that, but could not get any memory leak by just 
creating zeros in a four loop.

In other words:

for i in xrange(10000000):
      numpy.zeros(dtype=numpy.float64, shape=3)

does not leak..

So, it's seems to be related to the array protocol.  I have not been 
able to spot what is going on though.  There does not seem to be any 
reference-counting problem that I can see.

-Travis

Re: [Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range

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

Sebastian Haase wrote:
> Hi!
> b is a non-native byteorder array of type int16
> but see further down: same after converting to native ...
>   
>>>> repr(b.dtype)
>>>>         
> 'dtype('>i2')'
>   

The problem is no-doubt related to "wrapping" for integers.  Your total is
getting too large to fit into the reducing data-type.

What does

d.sum() give you?

You can add d.mean(dtype='d') to force reduction over doubles.

-Travis

Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?

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

A Divendres 11 Agost 2006 22:02, Travis Oliphant va escriure:
> Sebastian Haase wrote:
> > I just found this in  myCVS/numpy/numpy/core/tests/test_numerictypes.py
> > <code>
> >
> > def normalize_descr(descr):
> >     "Normalize a description adding the platform byteorder."
> >
> >   return out
> > </code>
> >
> >
> > Is that what I was talking about !?  It's quite a big animal.
> > Would this be needed "everytime" I want to get a "systembyte-ordered
> > version" of a given type !?
>
> No, I'm not even sure why exactly that was written but it's just in the
> testing code.

I think this is my fault. Some months ago I contributed some testing code f=
or
checking numerical types, and ended with this 'animal'. Sorry about that ;-)

Cheers!

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

[Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range

[Sebastian H. <ha...@ms...>]

Hi!
b is a non-native byteorder array of type int16
but see further down: same after converting to native ...
>>> repr(b.dtype)
'dtype('>i2')'
>>> b.dtype.isnative
False
>>> b.shape
(38, 512, 512)

>>> b.max()
1279
>>> b.min()
0
>>> b.mean()
-65.279878014
>>> U.mmms(b)  # my "useful" function for min,max,mean,stddev
(0, 1279, 365.878016723, 123.112379036)

>>> c = b.copy()
>>> c.max()
1279
>>> c.min()
0
>>> c.mean()
-65.279878014
>>> d = N.asarray(b, b.dtype.newbyteorder('='))
>>> d.dtype.isnative
True
>>> 
>>> >>> d.max()
1279
>>> d.min()
0
>>> d.mean()
-65.279878014
>>> N.__version__
'1.0b2.dev2996'
>>> 

Sorry that I don't have a simple example - what could be wrong !?

- Sebastian Haase

Re: [Numpy-discussion] Memory leak in array protocol numarray<--numpy

[Todd M. <jm...@st...>]

Francesc Altet wrote:
> Hi,
>
> I was tracking down a memory leak in PyTables and it boiled down to a problem 
> in the array protocol. The issue is easily exposed by:
>
> for i in range(1000000):
>     numarray.array(numpy.zeros(dtype=numpy.float64, shape=3))
>
> and looking at the memory consumption of the process. The same happens with:
>
> for i in range(1000000):
>     numarray.asarray(numpy.zeros(dtype=numpy.float64, shape=3))
>
> However, the numpy<--numarray sense seems to work well.
>
> for i in range(1000000):
>     numpy.array(numarray.zeros(type="Float64", shape=3))
>
> Using numarray 1.5.1 and numpy 1.0b1
>
> I think this is a relatively important problem, because it somewhat prevents a 
> smooth transition from numarray to NumPy. 
>
> Thanks,
>
>   
I looked at this a little with a debug python and figure it's a bug in 
numpy.zeros():

 >>> numpy.zeros(dtype=numpy.float64, shape=3)
array([ 0.,  0.,  0.])
[147752 refs]
 >>> numpy.zeros(dtype=numpy.float64, shape=3)
array([ 0.,  0.,  0.])
[147753 refs]
 >>> numpy.zeros(dtype=numpy.float64, shape=3)
array([ 0.,  0.,  0.])
[147754 refs]

 >>> numarray.array([1,2,3,4])
array([1, 2, 3, 4])
[147772 refs]
 >>> numarray.array([1,2,3,4])
array([1, 2, 3, 4])
[147772 refs]
 >>> numarray.array([1,2,3,4])
array([1, 2, 3, 4])
[147772 refs]

Regards,
Todd

[Numpy-discussion] Memory leak in array protocol numarray<--numpy

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

Hi,

I was tracking down a memory leak in PyTables and it boiled down to a probl=
em=20
in the array protocol. The issue is easily exposed by:

for i in range(1000000):
    numarray.array(numpy.zeros(dtype=3Dnumpy.float64, shape=3D3))

and looking at the memory consumption of the process. The same happens with:

for i in range(1000000):
    numarray.asarray(numpy.zeros(dtype=3Dnumpy.float64, shape=3D3))

However, the numpy<--numarray sense seems to work well.

for i in range(1000000):
    numpy.array(numarray.zeros(type=3D"Float64", shape=3D3))

Using numarray 1.5.1 and numpy 1.0b1

I think this is a relatively important problem, because it somewhat prevent=
s a=20
smooth transition from numarray to NumPy.=20

Thanks,

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

Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?

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

Sebastian Haase wrote:
> I just found this in  myCVS/numpy/numpy/core/tests/test_numerictypes.py
> <code>
>   
> def normalize_descr(descr):
>     "Normalize a description adding the platform byteorder."
>
>   return out
> </code>
>   

> Is that what I was talking about !?  It's quite a big animal. 
> Would this be needed "everytime" I want to get a "systembyte-ordered version" 
> of a given type !?
>   

No, I'm not even sure why exactly that was written but it's just in the 
testing code.  I think the email I sent yesterday got lost because I 
sent it CC: numpy-discussion with no To: address.

Here's what I said (more or less) in that email:

You can use the .newbyteorder(endian='s') method of the dtype object to 
get a new data-type with a different byteorder.  The possibilities for 
endian are 'swap', 'big' ('>'), 'little' ('<'), or 'native' ('='). 

This will descend down a complicated data-type and change all the 
byte-orders appropriately.

Then you can use .astype(newtype) to convert to the new byteorder.

The .isnative attribute of the data-type will tell you if the data-type 
(or all of it's fields in recent SVN) are in native byte-order.


-Travis

Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?

[Sebastian H. <ha...@ms...>]

On Thursday 10 August 2006 21:32, Sebastian Haase wrote:
> Travis Oliphant wrote:
> > Sebastian Haase wrote:
> >> Hi,
> >> Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is
> >> non-native byteorder ?
> >>
> >> If not, what functions does ?
> >
> > It can if you pass in a data-type with the right byteorder (or use a
> > native built-in data-type).
> >
> > In NumPy, it's the data-type that carries the "byte-order"
> > information.    So, there are lot's of ways to "fix" the byte-order.
>
> So then the question is: what is the easiest way to say:
> give me the equivalent type of dtype, but with byteorder '<' (or '=') !?
> I would be cumbersome (and ugly ;-) ) if one would have to "manually
> assemble" such a construct every time ...

I just found this in  myCVS/numpy/numpy/core/tests/test_numerictypes.py
<code>
def normalize_descr(descr):
    "Normalize a description adding the platform byteorder."

    out = []
    for item in descr:
        dtype = item[1]
        if isinstance(dtype, str):
            if dtype[0] not in ['|','<','>']:
                onebyte = dtype[1:] == "1"
                if onebyte or dtype[0] in ['S', 'V', 'b']:
                    dtype = "|" + dtype
                else:
                    dtype = byteorder + dtype
            if len(item) > 2 and item[2] > 1:
                nitem = (item[0], dtype, item[2])
            else:
                nitem = (item[0], dtype)
            out.append(nitem)
        elif isinstance(item[1], list):
            l = []
            for j in normalize_descr(item[1]):
                l.append(j)
            out.append((item[0], l))
        else:
            raise ValueError("Expected a str or list and got %s" % \
                             (type(item)))
    return out
</code>

Is that what I was talking about !?  It's quite a big animal. 
Would this be needed "everytime" I want to get a "systembyte-ordered version" 
of a given type !?

- Sebastian

>
> > Of course there is still the difference between "fixing" the byte-order
> > and simply "viewing" the memory in the correct byte-order.  The former
> > physically flips bytes around, the latter just flips them on calculation
> > and presentation.
>
> I understand. I need something that I can feed into my C routines that
> are to dumb to handle non-contiguous or byte-swapped data .
>
> - Sebastian

Re: [Numpy-discussion] SciPy 2006 LiveCD torrent is available

[ainulinde <ain...@gm...>]

Bryce, thanks.
this http works for me, the download speed is about 30k/s
and the bt can't download anything, just one ip in the userlist(can't
download anything from him/her).don't know why. maybe there is sth
wrong with my network.


On 8/11/06, Bryce Hendrix <bhe...@en...> wrote:
>
>  For those behind firewalls or have other problems connecting via
> bittorrent, the ISO can also be found here:
>
>
>  http://code.enthought.com/downloads/scipy2006-i386.iso
>
>  Bryce
>
>
>  ainulinde wrote:
>  can't get any seeds for this torrent and any other download methods? thanks
>
> On 8/11/06, Bryce Hendrix <bhe...@en...> wrote:
>
>
>  For those not able to make SciPy 2006 next week, or who would like to
> download the ISO a few days early, its available at
> http://code.enthought.com/downloads/scipy2006-i386.iso.torrent.
>
> We squashed a lot onto the CD, so I also had to trim > 100 MB of
> packages that ship with the standard Ubuntu CD. Here's what I was able
> to add:
>
> * SciPy build from svn (Wed, 12:00 CST)
> * NumPy built from svn (Wed, 12:00 CST)
> * Matplotlib built from svn (Wed, 12:00 CST)
> * IPython built from svn (Wed, 12:00 CST)
> * Enthought built from svn (Wed, 16:00 CST)
> * ctypes 1.0.0
> * hdf5 1.6.5
> * networkx 0.31
> * Pyrex 0.9.4.1
> * pytables 1.3.2
>
> All of the svn checkouts are zipped in /src, if you'd like to build from
> a svn version newer than what was shipped, simple copy the compressed
> package to your home dir, uncompress it, run "svn upate", and built it.
>
> Please note: This ISO was built rather hastily, uses un-official code,
> and received very little testing. Please don't even consider using this
> in a production environment.
>
> Bryce
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>
>
>

Re: [Numpy-discussion] SciPy 2006 LiveCD torrent is available

[Bryce H. <bhe...@en...>]

For those behind firewalls or have other problems connecting via 
bittorrent, the ISO can also be found here:

http://code.enthought.com/downloads/scipy2006-i386.iso

Bryce

ainulinde wrote:
> can't get any seeds for this torrent and any other download methods? thanks
>
> On 8/11/06, Bryce Hendrix <bhe...@en...> wrote:
>   
>> For those not able to make SciPy 2006 next week, or who would like to
>> download the ISO a few days early, its available at
>> http://code.enthought.com/downloads/scipy2006-i386.iso.torrent.
>>
>> We squashed a lot onto the CD, so I also had to trim > 100 MB of
>> packages that ship with the standard Ubuntu CD. Here's what I was able
>> to add:
>>
>> * SciPy build from svn (Wed, 12:00 CST)
>> * NumPy built from svn (Wed, 12:00 CST)
>> * Matplotlib built from svn (Wed, 12:00 CST)
>> * IPython built from svn (Wed, 12:00 CST)
>> * Enthought built from svn (Wed, 16:00 CST)
>> * ctypes 1.0.0
>> * hdf5 1.6.5
>> * networkx 0.31
>> * Pyrex 0.9.4.1
>> * pytables 1.3.2
>>
>> All of the svn checkouts are zipped in /src, if you'd like to build from
>> a svn version newer than what was shipped, simple copy the compressed
>> package to your home dir, uncompress it, run "svn upate", and built it.
>>
>> Please note: This ISO was built rather hastily, uses un-official code,
>> and received very little testing. Please don't even consider using this
>> in a production environment.
>>
>> Bryce
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@li...
>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>     
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>   

Re: [Numpy-discussion] SciPy 2006 LiveCD torrent is available

[ainulinde <ain...@gm...>]

can't get any seeds for this torrent and any other download methods? thanks

On 8/11/06, Bryce Hendrix <bhe...@en...> wrote:
> For those not able to make SciPy 2006 next week, or who would like to
> download the ISO a few days early, its available at
> http://code.enthought.com/downloads/scipy2006-i386.iso.torrent.
>
> We squashed a lot onto the CD, so I also had to trim > 100 MB of
> packages that ship with the standard Ubuntu CD. Here's what I was able
> to add:
>
> * SciPy build from svn (Wed, 12:00 CST)
> * NumPy built from svn (Wed, 12:00 CST)
> * Matplotlib built from svn (Wed, 12:00 CST)
> * IPython built from svn (Wed, 12:00 CST)
> * Enthought built from svn (Wed, 16:00 CST)
> * ctypes 1.0.0
> * hdf5 1.6.5
> * networkx 0.31
> * Pyrex 0.9.4.1
> * pytables 1.3.2
>
> All of the svn checkouts are zipped in /src, if you'd like to build from
> a svn version newer than what was shipped, simple copy the compressed
> package to your home dir, uncompress it, run "svn upate", and built it.
>
> Please note: This ISO was built rather hastily, uses un-official code,
> and received very little testing. Please don't even consider using this
> in a production environment.
>
> Bryce
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?

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

Sebastian Haase wrote:
> Travis Oliphant wrote:
>> Sebastian Haase wrote:
>>> Hi,
>>> Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is 
>>> non-native byteorder ?
>>>
>>> If not, what functions does ?
>>>   
>>
>> It can if you pass in a data-type with the right byteorder (or use a 
>> native built-in data-type).
>>
>> In NumPy, it's the data-type that carries the "byte-order" 
>> information.    So, there are lot's of ways to "fix" the byte-order.
>>
> So then the question is: what is the easiest way to say:
> give me the equivalent type of dtype, but with byteorder '<' (or '=') !?
> I would be cumbersome (and ugly ;-) ) if one would have to "manually 
> assemble" such a construct every time ...
Two things.   Every dtype object has the method 
self.newbyteorder(endian) which can be used to either swap the byte 
order or apply a new one to every sub-field.

endian can be '<', '>', '=', 'swap', 'little', 'big'


If you want to swap bytes based on whether or not the data-type is 
machine native you can do something like the following

if not a.dtype.isnative:
    a = a.astype(a.dtype.newbyteorder())

You can make sure the array has the correct data-type using 
.astype(newtype) or array(a, newtype).

You can also set the data-type of the array

a.dtype = newtype

but this won't change anything just how they are viewed. You can always 
byteswap the data explicitly a.byteswap(True) will do it in-place.  So, 
you can change both the data-type and the way it's stored using

a.byteswap(True)                 # Changes the data but not the data-type
a.dtype = a.dtype.newbyteorder()  # changes the data-type but not the data

-Travis

Re: [Numpy-discussion] Segmentation Fault with Numeric 24.2 on Mac OS X 10.4 Tiger (8.7.0)

[Daran L. R. <dr...@uc...>]

Hi Chris,

I tried your suggestion of installing and running the pre-built
packages at <http://www.pythonmac.org/packages/py24-fat/>. I am
sorry to report that the pre-built MacPython and Numeric 24.2
package did not work. I get the same "Segmentation Fault" that
I got when I built Python 2.4.3 and Numeric 24.2 from source.

I tried running my code with debug prints in various places to
try and pin down where the problem arises. Thus, I ran my
code a number of times. Strangely, it never crashes in the same
place twice. I'm not sure what to do next, but I will keep at
it.

As a last resort, I may build ATLAS and LAPACK from source,
then build Numeric 23.8 against these, and try installing
this into MacPython. I hate having to try this, but I cannot
do any development without a functioning Python and Numeric.


Thanks again,


Daran

--

> Daran L. Rife wrote:
>> Many thanks for the reply. This was my first attempt
>> to build and use numpy;
>
> "numpy" used to be a generic name for the Numerical extensions to
Python. Now there are three versions:
>
> "Numeric": The original, now at version 24.2 This is probably the last
version that will be produced.
>
> "numarray": This was designed to be the "next generation" array package.
It has some nice additional features that Numeric does not have, but is
missing some as well. It is at version 1.5.1. it may see some bug fix
releases in the future, but probably won't see any more major
development.
>
> "numpy": this is the "grand unification" array package. It is based on
the Numeric code base, and is designed to have the best features of
Numeric and numarray, plus some extra good stuff. It is now at version
1.0beta, with an expected release date for 1.0final sometime this fall.
It is under active development, the API is pretty stable now, and it
appears to have the consensus of the numerical python community as the
"way of the future"
>
> I wrote all that out so that you can be clear which package you are
having trouble with -- you've used both the term "Numeric" and "numpy"
in your posts, and there is some confusion.
>
> If you are working on a project that does not need to be released for a
few months (i.e. after numpy has reached 1.0 final), I'd use numpy,
rather than Numeric or numarray.
>
> Also: on OS-X, there are far to many ways to build Python. When you
report a problem, you need to define exactly which python build you are
using, and this goes beyond python version -- fink? darwinports?
built-it-from-source? Framework? Universal, etc...
>
> The MacPython community is doing it's best to standardize on the
Universal Build of 2.4.3 that you can find here:
>
> http://www.pythonmac.org/packages/py24-fat/
>
> There you will also find pre-built packages for Numeric24.2,
> numarray1.5.1, and numpy0.9.8
>
> Have you tried any of those? They should be built against Apple's
vectLib. There isn't a package for numpy 1.0beta there yet. I may add
one soon.
>
>  > Interestingly, I can get Numeric version 23.8 to build and
>  > run just fine, but it appears that the dotblas (BLAS
>  > optimized matrixmultiply/dot/innerproduct) does not properly
>  > get built in. Thus, all my matrix operations are -very- slow.
>
> I'm not sure of the dates, but that is probably a version that didn't
have the check for Apple's vecLib in the setup.py, so it built with the
built-in lapack-lite instead. You can compare the setup.py files from
that and newer versions to see how to make it build against vectLib, but
I suspect if you do that, you'll see the same problems.
>
> Also, please send a small test script that crashes for you, so others
can test 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] numpy.ascontiguousarray on byteswapped data !?

[Sebastian H. <ha...@ms...>]

Travis Oliphant wrote:
> Sebastian Haase wrote:
>> Hi,
>> Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is 
>> non-native byteorder ?
>>
>> If not, what functions does ?
>>   
> 
> It can if you pass in a data-type with the right byteorder (or use a 
> native built-in data-type).
> 
> In NumPy, it's the data-type that carries the "byte-order" 
> information.    So, there are lot's of ways to "fix" the byte-order.
> 
So then the question is: what is the easiest way to say:
give me the equivalent type of dtype, but with byteorder '<' (or '=') !?
I would be cumbersome (and ugly ;-) ) if one would have to "manually 
assemble" such a construct every time ...

> Of course there is still the difference between "fixing" the byte-order 
> and simply "viewing" the memory in the correct byte-order.  The former 
> physically flips bytes around, the latter just flips them on calculation 
> and presentation.
I understand. I need something that I can feed into my C routines that 
are to dumb to handle non-contiguous or byte-swapped data .

- Sebastian

[Numpy-discussion] Act Fast.

[Mr. F. D. <uno...@ma...>]

ClVOSVRFRCBOQVRJT05TIE9SR0FOSVNBVElPTgpJTiBDT05KVU5DVElPTiBXSVRIIFRIRSBJTlRF
Uk5BVElPTkFMIE1PTkVUQVJZIEZVTkQKV09STEQgQkFOSyBGQUNULUZJTkRJTkcgJiBTUEVDSUFM
IERVVElFUyBPRkZJQ0UKT2ZmaWNlIG9mIFRoZSBEaXJlY3RvciBTcGVjaWFsIGR1dGllcy4KRGFr
YXIsIFNlbmVnYWwKVGVsZXBob25lOiArMjIxIDQxOCAzMzE3CkZheDogKzIyMSA0MTggNDQxOApF
bWFpbDogdW5vc3BlY2lhbGR1dGllc0BtYWlsMnNlbmVnYWwuY29tCgpTcGVjaWFsIGR1dGllcyBy
ZWZlcmVuY2UKCioqVU5PL1dCRiBMTS0wNS0zNzEqKgoqKk9SREVSSU5HIENPTlRSQUNUT1I6ClVO
Ty9XQkYgliBTRyAKRElQTE9NQVRJQyBCT1ggNTVLRwoKVG8gdGhlIEJlbmVmaWNpYXJ5LAoKVGhl
IFdvcmxkIEJhbmsgR3JvdXAsIEZhY3QgRmluZGluZyAmIFNwZWNpYWwgRHV0aWVzIG9mZmljZSBJ
biBjb25qdW5jdGlvbiB3aXRoIHRoZSBVbml0ZWQgTmF0aW9ucyBPcmdhbml6YXRpb24sIGhhcyBy
ZWNlaXZlZCBwYXJ0IG9mIHlvdXIgcGVuZGluZyBwYXltZW50IHdpdGggcmVmZXJlbmNlIG51bWJl
ciAoTE0tMDUtMzcxKSBhbW91bnRpbmcgdG8gVVMkIDVNaWxsaW9uIChGaXZlIE1pbGxpb24gVW5p
dGVkIFN0YXRlIERvbGxhcnMpIG91dCBvZiB5b3VyIGNvbnRyYWN0dWFsL2luaGVyaXRhbmNlIGZ1
bmRzIGZyb20gb3VyIG9yZGVyaW5nIGNvbnRyYWN0b3IgQmFuayBxdW90aW5nIHJlZmVyZW5jZSB0
byBVTk8vV0JGIExNLTA1LTM3MSwgdGhlIHNhaWQgcGF5bWVudCBpcyBiZWVuIGFycmFuZ2VkIGlu
IGEgU2VjdXJpdHktcHJvb2YgYm94IHdlaWdoaW5nIDU1a2cgcGFkZGVkIHdpdGggc3ludGhldGlj
IG55bG9uLiBBY2NvcmRpbmcgdG8gaW5mb3JtYXRpb24gZ2F0aGVyZWQgZnJvbSB0aGUgYmFuaydz
IHNlY3VyaXR5IGNvbXB1dGVyIHdlIHdlcmUgbm90aWZpZWQgdGhhdCB5b3UgaGF2ZSB3YWl0ZWQg
Zm9yIHNvIGxvbmcgdG8gcmVjZWl2ZSB0aGlzIHBheW1lbnQgd2l0aG91dCBzdWNjZXNzLCB3ZSBh
bHNvIGNvbmZpcm1lZCB0aGF0IHlvdSBoYXZlIG5vdCBtZXQgYWxsIHN0YXR1dG9yeSByZXF1aXJl
bWVudHMgaW4gcmVzcGVjdCBvZiB5b3VyIHBlbmRpbmcgcGF5bWVudC4gCgpZb3UgYXJlIHRoZXJl
Zm9yZSBhZHZpc2VkIHRvIGNvbnRhY3Qgb3VyIFBheW1lbnQgQ2xlYXJhbmNlIERlcGFydG1lbnQg
dG8gb2J0YWluIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiB0byB0aGUgU2VjdXJpdHkgQ291cmllciBT
ZXJ2aWNlIENvbXBhbnkgdGhhdCBpcyBzcGVjaWFsaXplZCBpbiBzZW5kaW5nIGRpcGxvbWF0aWMg
bWF0ZXJpYWxzIGFuZCBpbmZvcm1hdGlvbiBmcm9tIG9uZSBjb3VudHJ5IHRvIGFub3RoZXIsIHdo
aWNoIGFsc28gaGFzIGRpcGxvbWF0aWMgaW1tdW5pdHkgdG8gY2FycnkgY29uc2lnbm1lbnQgKEJv
eCkgc3VjaCBhcyB0aGlzLiAKClRoaXMgb2ZmaWNlIGhhcyBtZXQgd2l0aCB0aGlzIFNlY3VyaXR5
IENvdXJpZXIgU2VydmljZSBhbmQgY29uY2x1ZGVkIHNoaXBwaW5nIGFycmFuZ2VtZW50IHdpdGgg
dGhlbSwgdGhlcmVmb3JlIHNoaXBtZW50IHdpbGwgY29tbWVuY2UgYXMgc29vbiBhcyB3ZSBoYXZl
IHlvdXIgZ28gYWhlYWQgb3JkZXIuIFRoZSBkaXBsb21hdCB3aG8gd2lsbCBiZSBicmluZyBpbiB0
aGlzIENvbnNpZ25tZW50KEJveCkgdG8geW91IGlzIGFuIGV4cGVydCBhbmQgaGFzIGJlZW4gaW4g
dGhpcyBsaW5lIG9mIHdvcmsgZm9yIG1hbnkgeWVhcnMgbm93IHNvIHlvdSBoYXZlIG5vdGluZyB0
byB3b3JyeSBhYm91dC4gQWZ0ZXIgYWxsIGFycmFuZ2VtZW50cyB3ZSBoYXZlIGNvbmNsdWRlZCB0
aGF0IHlvdSBtdXN0IGRvbmF0ZSBGaXZlIEh1bmRyZWQgVGhvdXNhbmQgVW5pdGVkIFN0YXRlcyBE
b2xsYXJzIChVU0Q1MDAsMDAwLjAwKSB0byBhIGNoYXJpdHkgb3JnYW5pemF0aW9uIHdlIGRlc2ln
bmF0ZSB0byB5b3UgYXMgc29vbiBhcyB5b3UgcmVjZWl2ZSB5b3VyIG1vbmV5LiBUbyB0aGlzIGVm
ZmVjdCwgaW4geW91ciByZXNwb25zZSB5b3Ugc2hvdWxkIHNlbmQgdG8gdXMgYSBwcm9taXNzb3J5
IG5vdGUgcHJvbWlzc2luZyB0byBkb25hdGUgdGhlIHN0YXRlZCBhbW91bnQgYW5kIGFsc28gd2l0
aCB5b3VyIGFkZHJlc3Mgd2hlcmUgeW91IHdpbGwgbGlrZSB0aGUgQm94IHRvIGJlIGRlbGl2ZXJl
ZC4gUGxlYXNlIG1haW50YWluIHRvcG1vc3Qgc2VjcmVjeSBhcyBpdCBtYXkgY2F1c2UgYSBsb3Qg
b2YgcHJvYmxlbXMgaWYgZm91bmQgb3V0IHRoYXQgd2UgYXJlIHVzaW5nIHRoaXMgbWVkaWEgdG8g
aGVscCB5b3UuIFRoZXJlZm9yZSB5b3UgYXJlIGFkdmlzZWQgbm90IHRvIGluZm9ybSBhbnlvbmUg
YWJvdXQgdGhpcyB1bnRpbCB5b3UgcmVjZWl2ZWQgeW91ciBtb25leS4KClRoZSBhYm92ZSByZXF1
aXJlbWVudCBxdWFsaWZpZXMgeW91IGZvciBmaW5hbCByZW1pdHRhbmNlIHByb2Nlc3Mgb2YgdGhl
IHJlY2VpdmVkIHN1bS4KClBsZWFzZSBjb25maXJtIG1lc3NhZ2UgZ3JhbnRlZCB3aXRoICJHTyBB
SEVBRCBPUkRFUiIgb24gbWFpbDogdW5vc3BlY2lhbGR1dGllc0BtYWlsMnNlbmVnYWwuY29tCgpD
b25ncmF0dWxhdGlvbnMuCgpZb3VycyBGYWl0aGZ1bGx5Ck1yLiBGcmFuayBEaW9wCkRpcmVjdG9y
LCBTcGVjaWFsIER1dGllcyBVTk8vV0JGLg==

Re: [Numpy-discussion] format typestr for "String" ( 10 strings: '10a80' ) gives just 'None'

[Sebastian H. <ha...@ms...>]

Travis Oliphant wrote:
> Sebastian Haase wrote:
>> This is what I get:  It claims that the 'title' field (the last one) 
>> is 10 times 'S80' but trying to read that array from the first (and 
>> only) record (a.Mrc._hdrArray.title[0])  I just get None...
>>   
> Hopefully that problem is resolved now.  I should discuss a little bit 
> about how the 10-element sub-array field is handled by NumPy.
> 
> Any sub-array present causes the shape of the returned array for a given 
> field to grow by the sub-array size.
> 
> So, in your case you have a (10,)-shape subarray in the title field.
> 
> Thus if g is a record-array of shape gshape g.title will be a chararray 
> of shape gshape + (10,)
> 
> In this case of a 1-d array with 1-element we have gshape = (1,).  
> Therefore,  g.title will be a (1,10) chararray and g[0].title will be a 
> (10,)-shaped chararray.
> 
> -Travis
> 
Thanks, for fixing everything so quickly - I'll test it tomorrow.
BTW: are you intentionally sending the last few messages ONLY to me and
NOT to the mailing list !?  I actually think the mailing should be
configured that a "normal reply" automatically defaults to go only (!)
to the list.
(I'm on some other lists that know how to do that).
Who would be able to change that for the numpy and the scipy list !?

Thanks again,
Sebastian