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

Re: [Numpy-discussion] BUG!

[Tom D. <tom...@al...>]

I reported this bug a whle ago and it was fixed to the best of my knowledge

On 11/10/05, Sune Rastad Bahn <ba...@at...> wrote:
> Dear devs,
>
> Thanks a lot for a very nice and extremely useful python module.
> I recommend all my colleagues to try you package whenever they ask for a
> matlab like environment. This week one of these friends came by me and sh=
owed
> me a bug in RandomArray.
>
> try the following
>
> python -c "from RandomArray import *;
> seed(1874764637, 1152239787);print randint(0,1000)"
>
> and notice how the result is the upper limit (1000)
> even though the documentation clearly states that the number should be
> strictly below 1000.
>
> My guess is that this is an issue with the underlying ranlib library, but
> perhaps someone can clarify?
>
> best,
> Sune
>
> --
> Software Application Manager
> Sune Rastad Bahn
> Phone:  +45 35 320 638
> Mobile: +45 23 455 997
> Email: ba...@at...
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Yet another problem in CVS numarray

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

A Dijous 10 Novembre 2005 18:54, Todd Miller va escriure:
> So you're still seeing it?  Does the attached work for you?

Nope.

> Keep in mind,  anonymous CVS lags on Source Forge.

Oh yes. I forgot about this :-/. I'll try it again tomorrow...

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

Re: [Numpy-discussion] Yet another problem in CVS numarray

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

Francesc Altet wrote:

>Ups, I've made a cvs update and not luck yet:
>
>  
>
>>>>import numarray; numarray.__version__
>>>>        
>>>>
>'1.4.2'
>  
>
>>>>import Numeric; Numeric.__version__
>>>>        
>>>>
>'24.1'
>  
>
>>>>num=Numeric.array([1,2,3,4])
>>>>numarray.array(num)
>>>>        
>>>>
>array([1, 2, 3, 4])
>  
>
>>>>num2=num[::2]
>>>>numarray.array(num2)
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 380, 
>in array
>    a = a.astype(type)
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 867, 
>in astype
>    return self.copy()
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 927, 
>in copy
>    c = _gen.NDArray.copy(self)
>  File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724, in 
>copy
>    arr._itemsize)
>numarray.libnumarray.error: copy4bytes: access beyond buffer. offset=11 
>buffersize=8
>
>I've made a rm -rf of old numarray extension, and rebuild everything
>from scratch.
>
>Regards,
>
>A Dijous 10 Novembre 2005 17:47, vàreu escriure:
>  
>
>>Francesc Altet wrote:
>>    
>>
>>>El dv 04 de 11 del 2005 a les 15:35 -0500, en/na Todd Miller va
>>>
>>>escriure:
>>>      
>>>
>>>>This turned out to be a problem with the way numarray handles Numeric's
>>>>multi-segment buffer protocol.   I worked around this by implementing
>>>>David Cooke's __array_struct__ array interface for numarray.
>>>>        
>>>>
>>>Did you commit the changes in CVS? I'm getting the same problems with
>>>
>>>the current CVS version:
>>>      
>>>
>>>>>>Numeric.__version__
>>>>>>            
>>>>>>
>>>'24.1'
>>>
>>>      
>>>
>>>>>>import numarray
>>>>>>numarray.__version__
>>>>>>            
>>>>>>
>>>'1.4.2'
>>>
>>>      
>>>
>>>>>>num=Numeric.array([1,2,3,4])
>>>>>>numarray.array(num)
>>>>>>            
>>>>>>
>>>array([1, 2, 3, 4])
>>>
>>>      
>>>
>>>>>>num2=num[::2]
>>>>>>numarray.array(num2)
>>>>>>            
>>>>>>
>>>Traceback (most recent call last):
>>> File "<stdin>", line 1, in ?
>>> File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>>>380, in array
>>>   a = a.astype(type)
>>> File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>>>867, in astype
>>>   return self.copy()
>>> File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>>>927, in copy
>>>   c = _gen.NDArray.copy(self)
>>> File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724,
>>>in copy
>>>   arr._itemsize)
>>>numarray.libnumarray.error: copy4bytes: access beyond buffer. offset=11
>>>buffersize=8
>>>      
>>>

So you're still seeing it?  Does the attached work for you?

Keep in mind,  anonymous CVS lags on Source Forge.

>>This turned out to be  a bug in numarray buffer size determination...
>>striding wasn't accounted for so the buffer appeared to be too small.
>>It's fixed now in CVS.  There's still a backward compatibility problem
>>for old Numerics which don't implement __array_struct__ and get
>>multi-segment buffers through __array_data__.
>>
>>Regards,
>>Todd
>>    
>>
>
>  
>

Re: [Numpy-discussion] Yet another problem in CVS numarray

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

Ups, I've made a cvs update and not luck yet:

>>> import numarray; numarray.__version__
'1.4.2'
>>> import Numeric; Numeric.__version__
'24.1'
>>> num=3DNumeric.array([1,2,3,4])
>>> numarray.array(num)
array([1, 2, 3, 4])
>>> num2=3Dnum[::2]
>>> numarray.array(num2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 38=
0,=20
in array
    a =3D a.astype(type)
  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 86=
7,=20
in astype
    return self.copy()
  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 92=
7,=20
in copy
    c =3D _gen.NDArray.copy(self)
  File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724, in=
=20
copy
    arr._itemsize)
numarray.libnumarray.error: copy4bytes: access beyond buffer. offset=3D11=20
buffersize=3D8

I've made a rm -rf of old numarray extension, and rebuild everything
from scratch.

Regards,

A Dijous 10 Novembre 2005 17:47, v=E0reu escriure:
> Francesc Altet wrote:
> >El dv 04 de 11 del 2005 a les 15:35 -0500, en/na Todd Miller va
> >
> >escriure:
> >>This turned out to be a problem with the way numarray handles Numeric's
> >>multi-segment buffer protocol.   I worked around this by implementing
> >>David Cooke's __array_struct__ array interface for numarray.
> >
> >Did you commit the changes in CVS? I'm getting the same problems with
> >
> >the current CVS version:
> >>>>Numeric.__version__
> >
> >'24.1'
> >
> >>>>import numarray
> >>>>numarray.__version__
> >
> >'1.4.2'
> >
> >>>>num=3DNumeric.array([1,2,3,4])
> >>>>numarray.array(num)
> >
> >array([1, 2, 3, 4])
> >
> >>>>num2=3Dnum[::2]
> >>>>numarray.array(num2)
> >
> >Traceback (most recent call last):
> >  File "<stdin>", line 1, in ?
> >  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
> >380, in array
> >    a =3D a.astype(type)
> >  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
> >867, in astype
> >    return self.copy()
> >  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
> >927, in copy
> >    c =3D _gen.NDArray.copy(self)
> >  File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724,
> >in copy
> >    arr._itemsize)
> >numarray.libnumarray.error: copy4bytes: access beyond buffer. offset=3D11
> >buffersize=3D8
>
> This turned out to be  a bug in numarray buffer size determination...
> striding wasn't accounted for so the buffer appeared to be too small.
> It's fixed now in CVS.  There's still a backward compatibility problem
> for old Numerics which don't implement __array_struct__ and get
> multi-segment buffers through __array_data__.
>
> Regards,
> Todd

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

Re: [Numpy-discussion] Yet another problem in CVS numarray

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

Francesc Altet wrote:

>El dv 04 de 11 del 2005 a les 15:35 -0500, en/na Todd Miller va
>escriure:
>  
>
>>This turned out to be a problem with the way numarray handles Numeric's 
>>multi-segment buffer protocol.   I worked around this by implementing 
>>David Cooke's __array_struct__ array interface for numarray.
>>    
>>
>
>Did you commit the changes in CVS? I'm getting the same problems with
>the current CVS version:
>
>  
>
>>>>Numeric.__version__
>>>>        
>>>>
>'24.1'
>  
>
>>>>import numarray
>>>>numarray.__version__
>>>>        
>>>>
>'1.4.2'
>  
>
>>>>num=Numeric.array([1,2,3,4])
>>>>numarray.array(num)
>>>>        
>>>>
>array([1, 2, 3, 4])
>  
>
>>>>num2=num[::2]
>>>>numarray.array(num2)
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>380, in array
>    a = a.astype(type)
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>867, in astype
>    return self.copy()
>  File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line
>927, in copy
>    c = _gen.NDArray.copy(self)
>  File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724,
>in copy
>    arr._itemsize)
>numarray.libnumarray.error: copy4bytes: access beyond buffer. offset=11
>buffersize=8
>  
>
This turned out to be  a bug in numarray buffer size determination... 
striding wasn't accounted for so the buffer appeared to be too small.  
It's fixed now in CVS.  There's still a backward compatibility problem 
for old Numerics which don't implement __array_struct__ and get 
multi-segment buffers through __array_data__.

Regards,
Todd

Re: [Numpy-discussion] BUG!

[Bruce S. <bso...@gm...>]

Hi,
This appears to occur in numarray (1.3.3) but not Numeric (24.0b2). If you
provide the shape of the array then this does not occur.

Also, please note that your other email illustrates the well known problem
of using computer clock as a seed - the computer clock does not change
sufficiently fast enough so the seed remains the same.

Regards
Bruce



On 11/10/05, Sune Rastad Bahn <ba...@at... > wrote:
>
> Dear devs,
>
> Thanks a lot for a very nice and extremely useful python module.
> I recommend all my colleagues to try you package whenever they ask for a
> matlab like environment. This week one of these friends came by me and
> showed
> me a bug in RandomArray.
>
> try the following
>
> python -c "from RandomArray import *;
> seed(1874764637, 1152239787);print randint(0,1000)"
>
> and notice how the result is the upper limit (1000)
> even though the documentation clearly states that the number should be
> strictly below 1000.
>
> My guess is that this is an issue with the underlying ranlib library, but
> perhaps someone can clarify?
>
> best,
> Sune
>
> --
> Software Application Manager
> Sune Rastad Bahn
> Phone: +45 35 320 638
> Mobile: +45 23 455 997
> Email: ba...@at...
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Writing/reading a numeric array to a file

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

A Dijous 10 Novembre 2005 13:34, Niklas Volbers va escriure:
> > I think you should take a look at PyTables for more elegant solutions.
>
> I wasn't sure if it will stay compatible to scipy_core, because right now
> it uses numarray.  But from what you said I am sure that eventually
> pytables might also switch to scipy_core.

Just to make things clear, PyTables uses numarray at its core, yes,
but it does support Numeric also by doing conversions in the fastest
way available (in fact, many people uses PyTables just for keeping
Numeric arrays, with good results). Still, a copy in memory is needed
for numarray-->Numeric conversions (not for the Numeric-->numarray
way), but that will change very soon, after the array protocol
implementation in numarray (and Numeric) stabilizes.

The next step will be to offer support for scipy.core by using the
array protocol as well. And finally, we plan (probably with the
introduction of PyTables 2) to switch from numarray to scipy.core when
the later would be stable enough, but always with support of the triad
of numarray, Numeric and scipy.core, at least for a few years.

Nevertheless, you must be aware that PyTables does require the HDF5
libraries [1], so, if what you want is to get rid of the maximum of
dependencies, PyTables might be effectively overkill for you.

[1] http://hdf.ncsa.uiuc.edu/HDF5/

Cheers,

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

Re: [Numpy-discussion] Writing/reading a numeric array to a file

[Arnd B. <arn...@we...>]

On Thu, 10 Nov 2005, Niklas Volbers wrote:

>
> First of all, thanks for your answers.
>
> Travis Oliphant <oli...@ee...> schrieb am 09.11.05 20:23:16:
>
> > What unneeded functionality is there.  SciPy Core is just a Numeric
> > replacement.  It does not NEED Atlas, it just uses it if you have it ---
> > exactly the same as Numeric and numarray.
> > It is a misconception to say scipy core needs any thing else but Python
> > installed.   So, let's not let that rumor kill convergence to a single
> > package.
>
> I am sorry for this faulty assumption of mine which you have now clarified.
>
> I had assumed that ATLAS was needed, just because scipy_core would
> not build on my system w/o a prior install of these libraries.
>
> With the knowledge, that it _should_ work, I have just retried to build
> scipy_core 0.4.2 on my rather fresh installation of Slackware Linux
> 10.2 (python 2.4.1) and still couldn't get it to build.  I have
> attached the log files out.txt and err.txt to this e-mail, which I got
> by typing
>
> $ python setup.py build 1>out.txt 2>err.txt
>
> in the scipy_core main directory.  The two files are compressed into a
> single tar.gz archive (5k), because I do not know if 60k attachments are
> o.k. on this list.
>
> Maybe you can help me solve my problem?

Did you try a recent check out?
With Travis' speed of coding scipy_core version 0.4.2.1252
seems pretty old to me

I tested
In [95]: scipy.__core_version__
Out[95]: '0.4.3.1440'
this morning without problems.

Best,

Arnd

Re: [Numpy-discussion] Writing/reading a numeric array to a file

[Niklas V. <Mit...@we...>]

First of all, thanks for your answers.

Travis Oliphant <oli...@ee...> schrieb am 09.11.05 20:23:16:

> What unneeded functionality is there.  SciPy Core is just a Numeric 
> replacement.  It does not NEED Atlas, it just uses it if you have it --- 
> exactly the same as Numeric and numarray. 
> It is a misconception to say scipy core needs any thing else but Python 
> installed.   So, let's not let that rumor kill convergence to a single 
> package.

I am sorry for this faulty assumption of mine which you have now clarified.

I had assumed that ATLAS was needed, just because scipy_core would 
not build on my system w/o a prior install of these libraries.  

With the knowledge, that it _should_ work, I have just retried to build 
scipy_core 0.4.2 on my rather fresh installation of Slackware Linux 
10.2 (python 2.4.1) and still couldn't get it to build.  I have
attached the log files out.txt and err.txt to this e-mail, which I got
by typing

$ python setup.py build 1>out.txt 2>err.txt

in the scipy_core main directory.  The two files are compressed into a
single tar.gz archive (5k), because I do not know if 60k attachments are 
o.k. on this list.

Maybe you can help me solve my problem?

> > (4) What solutions do you use to save/load data to files?
> 
> SciPy core arrays have tofile methods and a fromfile function.  They are 
> raw reading and writing --- nothing fancy.   You need to use Pickling if 
> you want to recognize endian-ness among platforms.  What is your 
> opposition to Pickling?

From how I understood pickling, it converts the python objects to a binary
representation.  What I want is a data representation that is independent
of python.  Anyway, I now have a few possibilities to explore besides
netcdf (with the alternative file formats FITS and with pytables, i.e. HDF5,
 proposed here).

> I think you should take a look at PyTables for more elegant solutions.

I wasn't sure if it will stay compatible to scipy_core, because right now it
uses numarray.  But from what you said I am sure that eventually pytables
might also switch to scipy_core.

Best regards, and thanks for your efforts,

Niklas.


______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!		
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

Re: [Numpy-discussion] Writing/reading a numeric array to a file

[Arnd B. <arn...@we...>]

On Thu, 10 Nov 2005, Joris De Ridder wrote:

> On Wednesday 09 November 2005 20:21, Travis Oliphant wrote:
>
> > SciPy core arrays have tofile methods and a fromfile function.  They are
> > raw reading and writing --- nothing fancy.   You need to use Pickling if
> > you want to recognize endian-ness among platforms.  What is your
> > opposition to Pickling?
> >
> > I think you should take a look at PyTables for more elegant solutions.
>
>
> The read_array and write_array of the old scipy.io are very handy.
> Any chance that they will be incorporated somehow in the new scipy?
> PyTables is powerful but perhaps a bit overkill if you just want to
> read or write a few columns in ascii format.

They are already there in newscipy
(as most of the other routines from "old" scipy).

Best, Arnd

Re: [Numpy-discussion] Writing/reading a numeric array to a file

[Joris De R. <jo...@st...>]

On Wednesday 09 November 2005 20:21, Travis Oliphant wrote:

> SciPy core arrays have tofile methods and a fromfile function.  They are 
> raw reading and writing --- nothing fancy.   You need to use Pickling if 
> you want to recognize endian-ness among platforms.  What is your 
> opposition to Pickling?
> 
> I think you should take a look at PyTables for more elegant solutions.


The read_array and write_array of the old scipy.io are very handy.
Any chance that they will be incorporated somehow in the new scipy?
PyTables is powerful but perhaps a bit overkill if you just want to 
read or write a few columns in ascii format.

Joris

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Numpy-discussion] BUG!

[Sune R. B. <ba...@at...>]

Dear devs,

Thanks a lot for a very nice and extremely useful python module.
I recommend all my colleagues to try you package whenever they ask for a 
matlab like environment. This week one of these friends came by me and showed 
me a bug in RandomArray.

try the following

python -c "from RandomArray import *;
seed(1874764637, 1152239787);print randint(0,1000)"

and notice how the result is the upper limit (1000)
even though the documentation clearly states that the number should be 
strictly below 1000.

My guess is that this is an issue with the underlying ranlib library, but 
perhaps someone can clarify?

best,
Sune

-- 
Software Application Manager
Sune Rastad Bahn
Phone:  +45 35 320 638
Mobile: +45 23 455 997
Email: ba...@at...

[Numpy-discussion] Bug or feature?

[Sune R. B. <ba...@at...>]

Dear devs,

Thanks a lot for a very nice and extremely useful python module.
I recommend all my colleagues to try you package whenever they ask for a 
matlab like environment. This week one of these friends came by me with an 
oddity relating to the RandomArray module.

try the following on your linux command prompt:

while true;
do python -c "from RandomArray import *;seed();print randint(100000)";
done

and check the output. I get a steadily but slowly decreasing series of 
numbers. e.g:

4013
4013
4012
4012
4012
4012
4012
4012
4012
4012
4010
4010
4010

According to the documentation seed() should initiatilize from the system 
clock. If one checks the seed (using get_seed) it turns out to be the case 
indeed, but that it is only very slowly changing (once a second), and only on 
the second seed. e.g

python -c "from RandomArray import *;seed();print get_seed()"

(113161, 3079)
(113161, 3079)
(113161, 3080)
(113161, 3080)
(113161, 3080)
(113161, 3080)

My best guess is that this is the cause for the behavior seen above.

This could be filed as a feature, but I believe it is not the behavior people 
would expect. At least the documentation should emphasize 

that two runs started within a short time ( upto 1s) will give the exact same 
result (experts on pseudo random numbers will know this, but the length of 
the time 1sec is surprisingly long).

that the first random number is slowly varying (strongly correlated) with time 
(this is more surprising). One fix is to take one randomnumber and throw 
away, since the second number is not correlated with time (except from noted 
above).

Best,
Sune




-- 
Software Application Manager
Sune Rastad Bahn
Phone:  +45 35 320 638
Mobile: +45 23 455 997
Email: ba...@at...

[Numpy-discussion] Python egg support in Numeric 24.2 in CVS

[David M. C. <co...@ph...>]

I've added support to Numeric to allow a Python egg [1] to be made  
easily. Basically, run

$ python setup.py bdist_egg

and an .egg file should be laid in dist/, which you can install with  
easy_install. This will only work if you have setuptools installed.   
I've taken steps so that usual 'setup.py build; setup.py install'  
will still install Numeric the old way (with a .pth file).

The header files for Numeric are now also installed in a package  
Numeric_headers, which contains a function get_numeric_include().  
This returns the directory in which the headers are installed in, so  
you can use it in your setup.py. The docstring for the function  
explains how to use it. It's modelled after get_scipy_include() in  
scipy.base. This way, the header files are included in the egg, and  
can be used.

I'd appreciate it if someone with eggperience (Robert?) could take a  
look at it before Travis collects Numeric for 24.2.

[1] http://peak.telecommunity.com/DevCenter/PythonEggs

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Numeric3.0 - Currently available under scipy/base as version 0.4.1 (Windows)

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

Colin J. Williams wrote:

>
> I have a package based on subclassing numarray, which is working 
> satisfactorily, and am looking at the possibility of transferring the 
> package to work under the revised Numeric.
>
> My feeling is that the transfer is probably feasible but that it would 
> be premature to work on it at this time.

That's unfortunate.  The more feedback we get early on about 
subclassing, the better. 

>
> One of the problems is the cluttered namespace, through the use of 
> "from X import *".  This is a style which is deprecated, see page 401 
> of Alex Martelli's /Python in a Nutshell/.

You will have to be more specific about what you think is wrong.  What 
namespace is "cluttered" exactly.   Just because use is made of from X 
import * in one module does not mean everything is "cluttered".  SciPy 
Core makes use of the __all__ variables to control what gets imported 
and usually only specific functions are imported as necessary.  

> Another problem, at this stage, is that many doc strings are missing 
> and that some which exist are a little cryptic.

I would submit there are more docstrings then Numeric had.   Jump in and 
help.   The water is fine.

>
> I would like to take another look when the next win32 binaries are 
> available.

There has been much improvement since the last beta.  I'm trying to 
track down some remaining memory leaks before releasing new windows 
binaries.    The SVN code is always available for check out and it is 
quite easy to build.   We could always use more build testers to make 
sure building is going as smoothly as we believe it is.

>
> Some further thoughts on the present state of Numeric3.0 are available 
> here <http://www3.sympatico.ca/cjw/scipy1/>.


Most of your comments have more to do with differences between builtin 
types and Python classes than anything about scipy.    The type-class 
chasm has shrunken of late, but there are still remaining issues.     
These are Python issues that I believe are of little concern.

I will comment on your issues that are not related to the above comment:


      Use of package __init__.py to create namespace.

If the epydoc and pydoc tools are not respecting the __init__.py code 
then I would say they are broken.    Using the __init__.py this way 
frees the user from having to understand every little detail of the 
package structure (which could also change as better organization is 
obtained in the future).


      Use of the from X import Y style

Please give more support here.  Just because one Python user advocates 
against it is not sufficient argument.  There is an argument to be made 
for avoiding attribute lookups by importing the names directly in this 
fashion.


      *Methods vs functions*

I agree that methods and functions are somewhat redundant.  However, the 
functions are still needed both to support lists and especially for 
back-wards compatibility. Your example using take is odd (perhaps it's a 
bug in an old release).  I get consistent behavior.   One problem is you 
define a 1-d array in one case and a 2-d array in another.  Of course 
the answers will be different.   

One difference is that the default axis argument is different.  The old 
functions have exactly the same default axis argument as they always 
did, while the methods have a default of None for the axis (which means 
treat the array as flat).


      Lack of basic information in the doc strings

Your examples are all class constructors.  First of all, there is no 
special __init__  method for the ndarray because __new__ takes care of 
it.    Second of all, the new method does need better documentation.  
I'm not sure where to put it, though.   The array_new function is placed 
in the TypeObject of the array type.   The __new__ attribute is pasted 
on by PyTypeReady.  I'm not sure how to give a docstring as well. 

I suspect the proper thing to do is place the information in the 
docstring for the Type Object.


-Travis

Re: [Numpy-discussion] Writing/reading a numeric array to a file

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

N. Volbers wrote:

> (2) Does it make sense to still use numarray? I know Travis would say 
> "use scipy_core". However, for me this would provide much unneeded 
> functionality and I have not yet found an easy way to install 
> scipy_core (it seems to require ATLAS and such, which are not so easy 
> to install if you don't have it prepackaged).  And after all, my goal 
> is to cut down dependencies...
>
What unneeded functionality is there.  SciPy Core is just a Numeric 
replacement.  It does not NEED Atlas, it just uses it if you have it --- 
exactly the same as Numeric and numarray. 

It is a misconception to say scipy core needs any thing else but Python 
installed.   So, let's not let that rumor kill convergence to a single 
package.

>
> (4) What solutions do you use to save/load data to files?

SciPy core arrays have tofile methods and a fromfile function.  They are 
raw reading and writing --- nothing fancy.   You need to use Pickling if 
you want to recognize endian-ness among platforms.  What is your 
opposition to Pickling?

I think you should take a look at PyTables for more elegant solutions.

-Travis

[Numpy-discussion] Numeric CVS __array_struct__ interface is broken on 64 bit platforms

[Andrew S. <str...@as...>]

Hi,

A couple bugs have been reported (including mine last night) which
indicate a problem with the following bit of code in
Numerical/Src/arrayobject.c (near line 2200) on 64 bit platforms.  I
think it'll be a lot faster for someone else to fix it, so I'll leave it
at this for now.

    if (strcmp(name, "__array_struct__") == 0) {
        PyArrayInterface *inter;
        inter = (PyArrayInterface *)malloc(sizeof(PyArrayInterface));
        inter->version = 2;
        inter->nd = self->nd;
        if ((inter->nd == 0) || (sizeof(int) == sizeof(Py_intptr_t))) {
            inter->shape = (Py_intptr_t *)self->dimensions;
            inter->strides = (Py_intptr_t *)self->strides;
        }
	else {
	    int i;
	    for (i=0; i<self->nd; i++) {
		inter->shape[i] = self->dimensions[i];
		inter->strides[i] = self->strides[i];
	    }
	}

[Numpy-discussion] Numeric3.0 - Currently available under scipy/base as version 0.4.1 (Windows)

[Colin J. W. <cj...@sy...>]

I have a package based on subclassing numarray, which is working 
satisfactorily, and am looking at the possibility of transferring the 
package to work under the revised Numeric.

My feeling is that the transfer is probably feasible but that it would 
be premature to work on it at this time.

One of the problems is the cluttered namespace, through the use of "from 
X import *".  This is a style which is deprecated, see page 401 of Alex 
Martelli's /Python in a Nutshell/.

Another problem, at this stage, is that many doc strings are missing and 
that some which exist are a little cryptic.

I would like to take another look when the next win32 binaries are 
available.

Some further thoughts on the present state of Numeric3.0 are available 
here <http://www3.sympatico.ca/cjw/scipy1/>.

Colin W,

Re: [Numpy-discussion] Writing/reading a numeric array to a file

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

N. Volbers wrote:

> Hello everyone,
>
> I have been using Numeric and/or numarray for a while now and I now I 
> have a question concerning the reading and writing data to a file.
>
> Until now I had used pycdf, which is an interface to the netcdf 
> library, to save and load my numeric arrays.  However, since my 
> application already has too many dependencies, I would like to cut 
> down on these two and replace the saving and loading by a method 
> intrinisc to Numeric or numarray.
> Pickling is not an alternative to me, because I need to have a 
> representation that can be read by other programs (and yet is faster 
> than ASCII). NetCDF was a good choice for that, but I would really 
> like to not depend on it.
>
> So my questions are:
>
> (1) Are the numarray functions 'fromfile' and 'tofile' 100% portable 
> among platforms, i.e. do they automatically recognize endian-ness and 
> such?

No.   But depending on how general a solution you need here,  this can 
be fairly easy (i.e. for numerical arrays only).

> (2) Does it make sense to still use numarray? 

Absolutely...  numarray works with records and memory mapping now.   But 
you also need to keep a shrewd eye on scipy newcore and recognize that 
it will most probably replace numarray over the course of the next year 
or two as it becomes sufficiently complete and stable to do so.

There are smart things to do now if you want to use numarray:

a. Use the Numeric-compatible C-API as much as possible.

b. Keep an eye on the introduction of newcore compatible typenames 
(int32 vs Int32), keywords (dtype vs. type), and attributes and use 
those as you write new code in numarray.

c. Use the array protocol.

> I know Travis would say "use scipy_core". However, for me this would 
> provide much unneeded functionality and I have not yet found an easy 
> way to install scipy_core (it seems to require ATLAS and such, which 
> are not so easy to install if you don't have it prepackaged).  And 
> after all, my goal is to cut down dependencies...
>
> (3) Let me restate question (2): Will numarray still be maintained?

numarray will be maintained at STScI until (a) newcore is ready to 
replace it or (b) our budget gets cut to the point that we cannot and no 
one else is interested.  Neither of those is guaranteed to happen,  but 
(a) looks likely to us.  STScI has the same problems with installation 
and dependencies so they'll have to be solved before we use newcore either.

> Or is it also deprecated?  What would you advice someone who just 
> needs the array interface?

Pay careful attention to the __array_struct__ attribute described here: 

http://numeric.scipy.org/array_interface.html

It's the easiest and best performing method to interface from C.  To 
interface from Python you have to use more of the protocol.

> And of course,
>
> (4) What solutions do you use to save/load data to files?

numarray was written to support astronomical data processing.  The 
dominant data format in astronomy is called FITS.  STScI has another 
package called PyFITS which is built on numarray and exposes the FITS 
format to Python.

Regards,
Todd

[Numpy-discussion] Writing/reading a numeric array to a file

[N. V. <mit...@we...>]

Hello everyone,

I have been using Numeric and/or numarray for a while now and I now I 
have a question concerning the reading and writing data to a file.

Until now I had used pycdf, which is an interface to the netcdf library, 
to save and load my numeric arrays.  However, since my application 
already has too many dependencies, I would like to cut down on these two 
and replace the saving and loading by a method intrinisc to Numeric or 
numarray. 

Pickling is not an alternative to me, because I need to have a 
representation that can be read by other programs (and yet is faster 
than ASCII). NetCDF was a good choice for that, but I would really like 
to not depend on it.

So my questions are:

(1) Are the numarray functions 'fromfile' and 'tofile' 100% portable 
among platforms, i.e. do they automatically recognize endian-ness and such?

(2) Does it make sense to still use numarray? I know Travis would say 
"use scipy_core". However, for me this would provide much unneeded 
functionality and I have not yet found an easy way to install scipy_core 
(it seems to require ATLAS and such, which are not so easy to install if 
you don't have it prepackaged).  And after all, my goal is to cut down 
dependencies...

(3) Let me restate question (2): Will numarray still be maintained? Or 
is it also deprecated?  What would you advice someone who just needs the 
array interface?

And of course,

(4) What solutions do you use to save/load data to files?


I would deeply appreciate any help on this subject,

Niklas Volbers.

[Numpy-discussion] initializing new ufuncs

[Stefan K. <pon...@ya...>]

Hi,

I'm writing some new ufuncs, and I'm wondering where I can insert some
initialization and finalization code for each ufunc invocation.  I can
see where it would go in the generated code, but I don't know how to do
it through the code generation API.

thanks,
Stefan Kuzminski


		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: [Numpy-discussion] Final release of Numeric is actually 24.1

[<kh...@ce...>]

On 08.11.2005, at 09:11, Francesc Altet wrote:

> Well, I would like to migrate PyTables to scipy.core in the medium  
> term.
> My plan to not bother the users is to start supporting scipy.base by
> using the array protocol. That means that, although numarray will  
> still
...

> I really think that the array protocol (that already is supported in
> latest Numeric and numarray, bar some small issues) is a Good Thing  
> (tm)
> to consider, specially for the developers.

True, but it doesn't solve my problem (I think). Users of my code  
don't see much of an array interface, it's hidden behind application- 
oriented abstraction layers. That also means that users don't care  
much if I use Numeric, numarray, or scipy.core, as long as there are  
no installation problems.

However, my code is necessarily tied to one specific array package  
because it creates all of its arrays. It also does lots of array  
operations that go beyond the array protocol. So I have lots of  
dependencies on the chosen array package in many different modules.

My problem is handling the transition period while I test scipy.core  
and while scipy.core stabilizes. I expect to make releases of my  
packages during that time, so I need to keep a code base that works  
with Numeric. Doing development on two code bases in parallel seems  
like asking for trouble.

Konrad.
--
------------------------------------------------------------------------ 
-------
Konrad Hinsen
Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: kh...@ce...
------------------------------------------------------------------------ 
-------

Re: [Numpy-discussion] Final release of Numeric is actually 24.1

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

El dl 07 de 11 del 2005 a les 15:50 +0100, en/na kh...@ce... va
escriure:
> Has anyone actually done this for a non-trivial package? What stops =20
> me from even trying scipy.core is the large number of incompatible =20
> changes, even though they are mostly superficial.

Well, I would like to migrate PyTables to scipy.core in the medium term.
My plan to not bother the users is to start supporting scipy.base by
using the array protocol. That means that, although numarray will still
be at the core, users will be able to send and retrieve scipy.core
objects into the library with almost native speed (thanks to the array
protocol). When scipy.core eventually matures enough, I'll put it at the
core of PyTables, while still supporting numarray and Numeric, and the
users will (hopefully) hardly notice the change, becuase they will be
able to use whatever numeric library they want, and the migration will
be up to them.

I really think that the array protocol (that already is supported in
latest Numeric and numarray, bar some small issues) is a Good Thing (tm)
to consider, specially for the developers.

Cheers,

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

Re: [Numpy-discussion] Numeric 24.1 tar ball and CVS were not consistent

[Andrew S. <str...@as...>]

Hi Travis,

The bug I reported[1] was originally detected with the Numeric 24.1 tar 
ball, but then I "upgraded" to CVS just to be sure that it hadn't been 
fixed.

[1]: http://www.scipy.net/pipermail/scipy-dev/2005-November/003883.html

So, I don't think the issue has been fixed.  Let me know if you need 
more detailed logs, test output, whatever.

Cheers!
Andrew

Travis Oliphant wrote:
> 
> I just updated the CVS of Numeric with changes that went into the 
> Numeric 24.1 release but were (unfortunately) not committed to CVS.  
> These changes are likely responsible for the test failures that people 
> have experienced when testing scipy with CVS versions of Numeric.
> 
> Sorry about --- too many things to think about apparently...
> 
> -Travis
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Numeric 24.1 tar ball and CVS were not consistent

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

I just updated the CVS of Numeric with changes that went into the 
Numeric 24.1 release but were (unfortunately) not committed to CVS.  
These changes are likely responsible for the test failures that people 
have experienced when testing scipy with CVS versions of Numeric.

Sorry about --- too many things to think about apparently...

-Travis