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

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

[Scott R. <sr...@nr...>]

On Tuesday 19 September 2006 14:46, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > What are the possible values of
> > arr.dtype.kind ?
> >
> > It seems that signed and unsigned are considered to be the same
> > "kind"
> >
> >>>> arr=N.arange(10,dtype=N.uint)
> >>>> arr.dtype.kind
> >
> > 'i'
> >
> >>>> arr.dtype.itemsize
> >
> > 8
> > (OK - this is just showing off our amd64 linux ;-) )
> >
> > How can I distinguish signed from unsigned without having to list all
> > possible cases explicitly ?
>
> Hmm....  This is a problem.   There is a 'u' kind for unsigned
> integers.
>
> On my system I get 'u' when running the code you just gave.
>
> Can anybody on a 64-bit system confirm?

I'm on 64-bit Debian:

In [11]: arr=N.arange(10,dtype=N.uint)

In [12]: arr.dtype.kind
Out[12]: 'u'

In [13]: arr.dtype.itemsize
Out[13]: 4

In [14]: arr=N.arange(10,dtype=N.long)

In [15]: arr.dtype.kind
Out[15]: 'i'

In [16]: arr.dtype.itemsize
Out[16]: 8


Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] Resolution of tickets.

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

Charles R Harris wrote:
> Question,
>
> How does one mark a ticket as fixed? I don't see this field in the 
> ticket views I get, is there a list of accepted fixers?
>
You have to be logged in to the Trac site.  If you have SVN write access 
you should be able to log in.  Then there is a "resolution" section at 
the very bottom.

-Travis

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

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

Sebastian Haase wrote:
> Hi,
> What are the possible values of 
> arr.dtype.kind ?
>
> It seems that signed and unsigned are considered to be the same "kind" 
>   
>>>> arr=N.arange(10,dtype=N.uint)
>>>> arr.dtype.kind
>>>>         
> 'i'
>   
>>>> arr.dtype.itemsize
>>>>         
> 8
> (OK - this is just showing off our amd64 linux ;-) )
>
> How can I distinguish signed from unsigned without having to list all possible 
> cases explicitly ?
>
>
>   
Hmm....  This is a problem.   There is a 'u' kind for unsigned integers.  

On my system I get 'u' when running the code you just gave.

Can anybody on a 64-bit system confirm?

-Travis

Re: [Numpy-discussion] [MMTK] Re: Fwd: Collection.findTransformation() never stops

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

Konrad Hinsen wrote:
> On Sep 19, 2006, at 5:11, Dr. Seth Olsen wrote:
>
>   
>> Bill's answer to my inquiry about the problem I'm having with  
>> Collection.findTransformation() (and also, incidentally, with the  
>> dgesvd call in Subspace.getBasis(), has convinced me that I can no  
>> long use MMTK without changing some of the code over to numpy.  I  
>> have already been able to determine that invoking  
>> numpy.oldnumeric.alter_code1.convertall() over the MMTK directory  
>> tree is not the answer.  Has anyone on either of these lists ever  
>> tried this before and, if so, can it be done (without destroying my  
>> sanity)?
>>     
>
> Adapting MMTK to NumPy is likely to be a major effort, in particular  
> for the C modules. 
Well,  I got both ScientificPython and MMTK to compile and import using 
the steps outlined on http://www.scipy.org/Porting_to_NumPy  in about 1 
hour (including time to fix alter_code1 to make the process even easier).

C-modules are actually easier to port because the Numeric C-API is 
totally supported.

> A lot ot testing would also be required. If anyone  
> wants to tackle this, 
> I'd be happy to see the results. 
Great.  I can totally understand people not having the time, but it is 
fantastic to hear that the willingness to accept patches is there.

I was able to install ScientificPython and MMTK for NumPy on my system 
using the patches provided on that page.    Is there a test suite that 
can be run? 

Users of MMTK could really help out here.


-Travis

Re: [Numpy-discussion] max argmax combo

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

On 9/19/06, Francesc Altet <fa...@ca...> wrote:
>
> A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure:
> > On 9/19/06, Francesc Altet <fa...@ca...> wrote:
> > > A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure:
> > > > I note that argsort also produces indexes that are hard to use in
> the
> > > > ndim>1 case.
> > >
> > > Perhaps it is worth to mention here that I've always liked to have a
> > > sort()
> > > and argsort() functionality merged in one shot function (or method).
> > > Having
> > > both separated implies two sorts, while if I'd have such a combo
> > > available,
> > > the resulting operation would take quite less time.
> >
> > Do you want both the indexes and index sorted array returned, or just
> sort
> > the array using indexes, i.e., something like
> >
> > a.sort(kind="quicksort", method="indirect")
>
> Uh, I don't understand what do you mean by "sort the array using indexes",
> sorry.
>
> What I'd like is to get the indexes and the sorted array returned. Or,
> another
> option could be getting the sorted indexes returned and a sort of the
> array
> done in-place (which is surely faster).


Don't know about the faster part, it depends on the architecture and the
size of the elements being swapped. It is the fact that the new quicksort
does 1/2 as many swaps together with the type specific code that makes it
faster than the original numpy version. The overhead in the current indirect
sorts comes mostly from the indirect references to array elements in the
innermost loop and it is quite possible that doing swaps on both the indexes
and the array would be a bigger hit than the current argsort followed by a
suitable take type function.

Lexsort is another function that would benefit from what we are discussing.

Chuck

Re: [Numpy-discussion] what's the difference between npy_intp and size_t?

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

Martin Wiechert wrote:
> Hi list,
>
> Please forgive my ignorance: Is there any difference between npy_intp and 
> size_t. Aren't both "ints just big enough to be safe with pointer arithmetics 
> even on 64 bit architectures?".
>   

size_t is unsigned
npy_intp is signed

It is basically the same as Py_ssize_t (which is not available until 
Python 2.5).  

-Travis

Re: [Numpy-discussion] Numpy fails to build with Python 2.5

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

William Grant wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> mg wrote:
>   
>> Hi,
>>
>> I have the same problem with Python-2.5 and Python-2.6a with which i can 
>> not compile Numpy-1.0b5 and Numpy from svn. (I suppose your version of 
>> Scipy is based on one of these Numpy.)
>> I posted my problem yesterday. The answer from Travis was it will be 
>> corrected in Numpy-1.0rc1 which will come soon.
>>
>> regards,
>> Mathieu.
>>     
>
> Yes, numpy 1.0b5 is the one... Approximately how soon is soon? Before or
> after the 28th?
>   
Before.    It was supposed to come out this weekend.  It will be today 
or tomorrow.

-Travis

Re: [Numpy-discussion] Resolution of tickets.

[Robert K. <rob...@gm...>]

Charles R Harris wrote:
> Question,
> 
> How does one mark a ticket as fixed? I don't see this field in the 
> ticket views I get, is there a list of accepted fixers?

Indeed there is. charris is on that list. charris208 is not. Forget your 
password?  :-)

Talk to me offlist about which username you want to continue with.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] max argmax combo

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

A Dimarts 19 Setembre 2006 19:21, Charles R Harris va escriure:
> On 9/19/06, Francesc Altet <fa...@ca...> wrote:
> > A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure:
> > > I note that argsort also produces indexes that are hard to use in the
> > > ndim>1 case.
> >
> > Perhaps it is worth to mention here that I've always liked to have a
> > sort()
> > and argsort() functionality merged in one shot function (or method).
> > Having
> > both separated implies two sorts, while if I'd have such a combo
> > available,
> > the resulting operation would take quite less time.
>
> Do you want both the indexes and index sorted array returned, or just sort
> the array using indexes, i.e., something like
>
> a.sort(kind=3D"quicksort", method=3D"indirect")

Uh, I don't understand what do you mean by "sort the array using indexes",=
=20
sorry.

What I'd like is to get the indexes and the sorted array returned. Or, anot=
her=20
option could be getting the sorted indexes returned and a sort of the array=
=20
done in-place (which is surely faster).=20

Regards,

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

Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

[Albert S. <fu...@gm...>]

Hello all

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] On Behalf Of Sebastian Haase
> Sent: 19 September 2006 19:24
> To: Discussion of Numerical Python
> Subject: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?
> 
> Hi,
> What are the possible values of
> arr.dtype.kind ?
> 
> It seems that signed and unsigned are considered to be the same "kind"
> >>> arr=N.arange(10,dtype=N.uint)
> >>> arr.dtype.kind
> 'i'
> >>> arr.dtype.itemsize
> 8
> (OK - this is just showing off our amd64 linux ;-) )
> 
> How can I distinguish signed from unsigned without having to list all
> possible
> cases explicitly ?

How about sctypes?

In [16]: numpy.sctypes.keys()
Out[17]: ['int', 'float', 'uint', 'complex', 'others']

So this should work:

sometype in numpy.sctypes['uint']
sometype in numpy.sctypes['int']

Cheers,

Albert

[Numpy-discussion] Resolution of tickets.

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

Question,

How does one mark a ticket as fixed? I don't see this field in the ticket
views I get, is there a list of accepted fixers?

Chuck

[Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?

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

Hi,
What are the possible values of 
arr.dtype.kind ?

It seems that signed and unsigned are considered to be the same "kind" 
>>> arr=N.arange(10,dtype=N.uint)
>>> arr.dtype.kind
'i'
>>> arr.dtype.itemsize
8
(OK - this is just showing off our amd64 linux ;-) )

How can I distinguish signed from unsigned without having to list all possible 
cases explicitly ?

Thanks,
Sebastian Haase

Re: [Numpy-discussion] max argmax combo

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

On 9/19/06, Francesc Altet <fa...@ca...> wrote:
>
> A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure:
> > I note that argsort also produces indexes that are hard to use in the
> > ndim>1 case.
>
> Perhaps it is worth to mention here that I've always liked to have a
> sort()
> and argsort() functionality merged in one shot function (or method).
> Having
> both separated implies two sorts, while if I'd have such a combo
> available,
> the resulting operation would take quite less time.


Do you want both the indexes and index sorted array returned, or just sort
the array using indexes, i.e., something like

a.sort(kind="quicksort", method="indirect")

IIRC, the old numeric argsort actually did something like this under the
covers but discarded the sorted array.

One can easily stablish kind of a pattern for situations where this could
> happen: in all the 'arg*()' functions. Perhaps I'm wrong in my count, but
> there appear to be only three of such functions in NumPy, namely, argmax,
> argmin and argsort. Adding three additional 'combos' doesn't seem a lot to
> my
> mind, but it can be just 'too much' for more common sense minds.


Chuck

Re: [Numpy-discussion] [MMTK] Re: Fwd: Collection.findTransformation() never stops

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

Konrad Hinsen wrote:
> MMTK works fine with Numeric 23.x (and probably many other versions),  
> so I don't see a pressing need to change to NumPy.

Pressing is in the eye of the beholder.

However: I don't think we should underestimate the negative impact of 
the Numeric/numarray split on the usability and perception of the 
community. Also the impact on how much work has been done to accommodate 
it. If you consider matplotlib alone:

Effort to write the "numerix" compatibility layer
Effort to support problems people have with incompatibility
Effort to build binaries that support all the packages
Effort to do extra testing to determine whether a given problem is 
caused by a different numerix back-end.

This really adds up!

Because of this, it IS a pressing need to get as much stuff converted as 
possible.

In addition, as I understand it, MMTK was NOT working fine for the OP. 
this is also the case for a variety of other codes that depend on 
Numeric. As robust as they (and Numeric) might be, when you need to run 
something on a new platform (OS-X - Intel comes to mind), or use a new 
LAPACK, or whatever, there are going to be (and have been) issues that 
need to be addressed. No one is maintaining Numeric, so it makes much 
more sense to put your effort into porting to numpy, rather than trying 
to fix or work around Numeric issues.

This is also a great time to get help with porting issues -- see Travis' 
recent message.

-Chris

PS: this really highlights the strength of having good unit tests: as 
far as i can tell, it's really not that much work to do the port -- the 
work is in the testing. Comprehensive units tests would make that part 
trivial too.


-- 
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] max argmax combo

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

A Dimarts 19 Setembre 2006 07:18, Charles R Harris va escriure:
> I note that argsort also produces indexes that are hard to use in the
> ndim>1 case.

Perhaps it is worth to mention here that I've always liked to have a sort()=
=20
and argsort() functionality merged in one shot function (or method). Having=
=20
both separated implies two sorts, while if I'd have such a combo available,=
=20
the resulting operation would take quite less time.

One can easily stablish kind of a pattern for situations where this could=20
happen: in all the 'arg*()' functions. Perhaps I'm wrong in my count, but=20
there appear to be only three of such functions in NumPy, namely, argmax,=20
argmin and argsort. Adding three additional 'combos' doesn't seem a lot to =
my=20
mind, but it can be just 'too much' for more common sense minds.

Cheers,

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

Re: [Numpy-discussion] [MMTK] Re: Fwd: Collection.findTransformation() never stops

[Konrad H. <kon...@la...>]

On Sep 19, 2006, at 5:11, Dr. Seth Olsen wrote:

> Bill's answer to my inquiry about the problem I'm having with =20
> Collection.findTransformation() (and also, incidentally, with the =20
> dgesvd call in Subspace.getBasis(), has convinced me that I can no =20
> long use MMTK without changing some of the code over to numpy.  I =20
> have already been able to determine that invoking =20
> numpy.oldnumeric.alter_code1.convertall() over the MMTK directory =20
> tree is not the answer.  Has anyone on either of these lists ever =20
> tried this before and, if so, can it be done (without destroying my =20=

> sanity)?

Adapting MMTK to NumPy is likely to be a major effort, in particular =20
for the C modules. A lot ot testing would also be required. If anyone =20=

wants to tackle this, I'd be happy to see the results. Personally, I =20
don't expect to find time for this soon.

MMTK works fine with Numeric 23.x (and probably many other versions), =20=

so I don't see a pressing need to change to NumPy.

Konrad.
--
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Mol=E9culaire, CNRS Orl=E9ans
Synchrotron Soleil - Division Exp=E9riences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: hi...@cn...
---------------------------------------------------------------------

[Numpy-discussion] what's the difference between npy_intp and size_t?

[Martin W. <mar...@gm...>]

Hi list,

Please forgive my ignorance: Is there any difference between npy_intp and 
size_t. Aren't both "ints just big enough to be safe with pointer arithmetics 
even on 64 bit architectures?".

Thanks,
Martin.

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

[Piotr L. S <lus...@cs...>]

Seth,

this problem is most likely related to LAPACK's SLAMCH and DLAMCH
routines. If these routines get translated with f2c the compiler can
optimize things away and create infinite loops. This functions get
called when you start using singular and eigenvalue routines. It's 
because Fortran 77 didn't have a way to specify "volatile" storage. 

In any case, you can avoid the problem by linking different
SLAMCH and DLAMCH routines. I'm attaching two possible
impementations that use C99 and Fortran 95. Probably you'll have to
ensure that name mangling occurs correctly (rename slamch to slamch_
and dlamch to dlamch_).

Piotr

On Tuesday 19 September 2006 03:26, Dr. Seth Olsen wrote:
> Hi Travis,
>
> I would very happily accept the Scientific and MMTK patches.  Thank
> you very much for the offer.
>
> I hadn't thought much about it until very recently, when the advent
> of a new IT structure in our laboratory forced me to upgrade my
> existing software. It was then that it became obvious that the LAPACK
> routines called by Numeric and MMTK were refusing to work.  I've
> spent the day trying to wrestle with the problem (I am by no means an
> expert).  I finally decided to get around the problems by altering
> the problem-solving routines in MMTK by using routines from numpy and
> then immediately applying a=Numeric.array( a.tolist()), which has
> stopped my script from gagging (although I have still to demonstrate
> to myself that everything is working).  The uses to which I apply
> MMTK usually mean that the matrices in question are pretty small, so
> I don't have to worry too much about speed.
>
> I was suprised to note, however, that a straightforward application
> of F2PY to some fresh downloaded LAPACK F77 code did not work, and
> sent my machine into a similar endless whirr as I had seen at the
> beginning of the day. Apparently there's something sinister going
> on...
>
> Cheers,
>
> Seth
>
> On 9/19/06, Travis Oliphant <oli...@ie...> wrote:
> > Dr. Seth Olsen wrote:
> > > Hi Bill,
> > >
> > > MMTK has not made the conversion over to the new numpy module. 
> > > It is built against the old Numeric code, and the word from its
> > > developers is that changing to numpy cannot be a priority now.
> >
> > My suggestion is to *kindly* put pressure on them.
> >
> > I've spent at least a hundred hours making it easy for people to
> > port Numeric and Numarray-built code to NumPy.    Because of this,
> > I'm a little bit frustrated by this kind of response.  I understand
> > it will take time for people to migrate, but it really does not
> > take that long to port code to use NumPy.
> >
> > I've offered to do it for any open source code.   In fact, I just
> > spent 30 minutes and ported both Scientific Python and MMTK to use
> > numpy. I'll send you a patch if you want.     It is true, that the
> > result needs to be better tested, but I'm confident that any errors
> > which might remain in the compatibility layer will be easily
> > fixable (and we need people who are willing to do the tests to fix
> > them).
> >
> > I'd rather not do this, but if necessary we can easily create an
> > SVN tree of third-party packages ported to use NumPy if the
> > package-owners are not willing to do it.   Keeping Numeric packages
> > around except for legacy systems will only make things harder.
> >
> > I'll repeat the same offer I've made before:  I will gladly give my
> > book and my help to any open source library author who will make
> > porting to NumPy a priority for their package.  Note, however, my
> > (free) ports to use NumPy do not use any "numerix-style" layer. 
> > The library is converted to work with NumPy alone.  In other words,
> > I won't spend any more "spare" time supporting 3 array packages.
> >
> > Best regards,
> >
> > -Travis
> >
> >
> > -------------------------------------------------------------------
> >------ Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys -- and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=
> >DEVDEV _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy fails to build with Python 2.5

[Pearu P. <pea...@gm...>]

On 9/19/06, William Grant <wil...@ub...> wrote:
> mg wrote:
> > Hi,
> >
> > I have the same problem with Python-2.5 and Python-2.6a with which i can
> > not compile Numpy-1.0b5 and Numpy from svn. (I suppose your version of
> > Scipy is based on one of these Numpy.)
> > I posted my problem yesterday. The answer from Travis was it will be
> > corrected in Numpy-1.0rc1 which will come soon.
> >
> > regards,
> > Mathieu.
>
> Yes, numpy 1.0b5 is the one... Approximately how soon is soon? Before or
> after the 28th?

I have the corresponding fixed compiler errors in numpy svn.

Regards,
Pearu

Re: [Numpy-discussion] Numpy fails to build with Python 2.5

[William G. <wil...@ub...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

mg wrote:
> Hi,
> 
> I have the same problem with Python-2.5 and Python-2.6a with which i can 
> not compile Numpy-1.0b5 and Numpy from svn. (I suppose your version of 
> Scipy is based on one of these Numpy.)
> I posted my problem yesterday. The answer from Travis was it will be 
> corrected in Numpy-1.0rc1 which will come soon.
> 
> regards,
> Mathieu.

Yes, numpy 1.0b5 is the one... Approximately how soon is soon? Before or
after the 28th?

Thanks,

William Grant.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFD9W8rbS+qZ0dQCURAk+7AKDkQSnrzs6SIYBmJc3QW9j48Zpu7QCePsqU
AnLTk9YQzYAD/Ps/3JIBEU8=
=QU5m
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] Numpy fails to build with Python 2.5

[mg <mg....@la...>]

Hi,

I have the same problem with Python-2.5 and Python-2.6a with which i can 
not compile Numpy-1.0b5 and Numpy from svn. (I suppose your version of 
Scipy is based on one of these Numpy.)
I posted my problem yesterday. The answer from Travis was it will be 
corrected in Numpy-1.0rc1 which will come soon.

regards,
Mathieu.

William Grant wrote:
> Hi,
>
> I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it
> currently cannot happen as numpy doesn't build with Python 2.5. I note
> that changeset 3109
> (http://projects.scipy.org/scipy/numpy/changeset/3109#file1) is meant to
> give 2.5 compatibility, but it is those bits which seem to break it. The
> end of the build log with the errors can be found at
> http://people.ubuntu.com.au/~fujitsu/numpy_error.txt.
>
> Has anybody got any ideas on how to fix this? A number of Ubuntu users
> want scipy 0.5.1, but that can't happen while it won't build with Python
> 2.5.
>
> Thanks,
>
> William Grant.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>   

[Numpy-discussion] Numpy fails to build with Python 2.5

[William G. <wil...@ub...>]

Hi,

I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it
currently cannot happen as numpy doesn't build with Python 2.5. I note
that changeset 3109
(http://projects.scipy.org/scipy/numpy/changeset/3109#file1) is meant to
give 2.5 compatibility, but it is those bits which seem to break it. The
end of the build log with the errors can be found at
http://people.ubuntu.com.au/~fujitsu/numpy_error.txt.

Has anybody got any ideas on how to fix this? A number of Ubuntu users
want scipy 0.5.1, but that can't happen while it won't build with Python
2.5.

Thanks,

William Grant.

Re: [Numpy-discussion] feasability study to migrate from numarray to numpy

[Nils W. <nw...@ia...>]

mg wrote:
> I forget a last question,
>
> We currently advise a High Performance Platform for our customers 
> (Opteron cluster) where our applications are linked with GOTO blas library.
>
> I found in the Numpy distribution the file site.cfg, used to specify the 
> BLAS to used at the link time. (It could be an interesting feature for 
> us.) I noted some configuration variables have names depending on the 
> name of the chosen BLAS library. So, my question is: is GOTO is 
> supported or is it easy for us to add it? I wonder too if the string 
> "[atlas]" written in site.cfg is used or not ?
>
> thanks,
> Mathieu.
>   
There is a ticket concerning your inquiry.

http://projects.scipy.org/scipy/numpy/ticket/73

Nils

> Travis Oliphant wrote:
>   
>> mg wrote:
>>   
>>     
>>> Hi all,
>>>
>>> I am doing a feseability study to migrate our Python based FEM 
>>> applications from Numarray to Numpy.
>>>
>>> First, I tried to install Numpy from Python-2.4 on linux-x86, 
>>> linux-86-64bit. So, all work fine. Great! Moreover, I change easily the 
>>> BLAS linked libraries. I tried with ATLAS and GOTO. Great again!
>>>
>>> Second, I try to do the same think on windows-x86 without success. So my 
>>> first question is: is Numpy-1.0b5 has been tested and is supported on 
>>> Windows?
>>>   
>>>     
>>>       
>> Yes, it should work.  Builds for windows were provided.   But, perhaps 
>> there are configuration issues for your system that we are not handling 
>> correctly.
>>
>>   
>>     
>>> Third, I tried to install Numpy from Python-2.5, which is our standard 
>>> Python, on linux-x86... and the compilation stopped during the 
>>> compilation of core/src/multiarraymodule.c. So my second question is: is 
>>> there a workaround or is the porting to Python2.5 is yet schedule?
>>>   
>>>     
>>>       
>> There was a problem with Python 2.5 and NumPy 1.0 that is fixed in SVN.  
>> Look for NumPy 1.0rc1 to come out soon.
>>   
>>     
>>> My third question is: is the tool to migrate the numarray based Python 
>>> scripts (numpy.numarray.alter_code1) work fine? (I suppose yes...)
>>>   
>>>     
>>>       
>> It needs more testing.  It would be great if you could help us find and 
>> fix bugs in it.   I don't have a lot of numarray code to test.
>>   
>>     
>>> We have created a lot of bindings in order to pilote our generic-C++ 
>>> framework with Python scripts. So, about the Numpy API, is it widely 
>>> different than the Numarray API? (We will order the Numpy Guide too.)
>>>   
>>>     
>>>       
>> It is more similar to the Numeric C-API.  However, the numarray C-API is 
>> completely supported by including numpy/libnumarray.h so you should be 
>> able to convert your C code very easily.   Any problems encountered 
>> should be noted and we'll get them fixed.
>>   
>>     
>>> To not duplicate large numerical memory arrays, Numarray allows to 
>>> aliasing the memory of some bindings with arrays from Numarray, and we 
>>> have used this feature intensively. So, I wonder if it is currently 
>>> supported (or even scheduled)?
>>>     
>>>       
>> I'm pretty sure the answer is yes (because the Numarray C-API is 
>> supported), though I'm not exactly sure what you mean.  Do you mean that 
>> you have memory created in the C/C++ framework and then you have an 
>> array use that memory for it's data area?  If that is what you mean, 
>> then the answer is definitely yes.
>>
>>
>> -Travis
>>
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@li...
>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>   
>>     
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>   

 

Re: [Numpy-discussion] feasability study to migrate from numarray to numpy

[mg <mg....@la...>]

I forget a last question,

We currently advise a High Performance Platform for our customers 
(Opteron cluster) where our applications are linked with GOTO blas library.

I found in the Numpy distribution the file site.cfg, used to specify the 
BLAS to used at the link time. (It could be an interesting feature for 
us.) I noted some configuration variables have names depending on the 
name of the chosen BLAS library. So, my question is: is GOTO is 
supported or is it easy for us to add it? I wonder too if the string 
"[atlas]" written in site.cfg is used or not ?

thanks,
Mathieu.

Travis Oliphant wrote:
> mg wrote:
>   
>> Hi all,
>>
>> I am doing a feseability study to migrate our Python based FEM 
>> applications from Numarray to Numpy.
>>
>> First, I tried to install Numpy from Python-2.4 on linux-x86, 
>> linux-86-64bit. So, all work fine. Great! Moreover, I change easily the 
>> BLAS linked libraries. I tried with ATLAS and GOTO. Great again!
>>
>> Second, I try to do the same think on windows-x86 without success. So my 
>> first question is: is Numpy-1.0b5 has been tested and is supported on 
>> Windows?
>>   
>>     
> Yes, it should work.  Builds for windows were provided.   But, perhaps 
> there are configuration issues for your system that we are not handling 
> correctly.
>
>   
>> Third, I tried to install Numpy from Python-2.5, which is our standard 
>> Python, on linux-x86... and the compilation stopped during the 
>> compilation of core/src/multiarraymodule.c. So my second question is: is 
>> there a workaround or is the porting to Python2.5 is yet schedule?
>>   
>>     
> There was a problem with Python 2.5 and NumPy 1.0 that is fixed in SVN.  
> Look for NumPy 1.0rc1 to come out soon.
>   
>> My third question is: is the tool to migrate the numarray based Python 
>> scripts (numpy.numarray.alter_code1) work fine? (I suppose yes...)
>>   
>>     
> It needs more testing.  It would be great if you could help us find and 
> fix bugs in it.   I don't have a lot of numarray code to test.
>   
>> We have created a lot of bindings in order to pilote our generic-C++ 
>> framework with Python scripts. So, about the Numpy API, is it widely 
>> different than the Numarray API? (We will order the Numpy Guide too.)
>>   
>>     
> It is more similar to the Numeric C-API.  However, the numarray C-API is 
> completely supported by including numpy/libnumarray.h so you should be 
> able to convert your C code very easily.   Any problems encountered 
> should be noted and we'll get them fixed.
>   
>> To not duplicate large numerical memory arrays, Numarray allows to 
>> aliasing the memory of some bindings with arrays from Numarray, and we 
>> have used this feature intensively. So, I wonder if it is currently 
>> supported (or even scheduled)?
>>     
> I'm pretty sure the answer is yes (because the Numarray C-API is 
> supported), though I'm not exactly sure what you mean.  Do you mean that 
> you have memory created in the C/C++ framework and then you have an 
> array use that memory for it's data area?  If that is what you mean, 
> then the answer is definitely yes.
>
>
> -Travis
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>   

Re: [Numpy-discussion] feasability study to migrate from numarray to numpy

[mg <mg....@la...>]

Hi Travis,

First, thanks for your answer.

I just download the source of Numpy from the SVN and recompile the 
package from Python-2.5 and 2.6a (from svn)... and it still crashes. So 
I do not investigate the compilation on Windows. So, may I have to wait 
the release 1.0rc0 of Numpy?

About the migration of our python scripts, we can keep contact to help 
you to test the transcription tool. It is a good idea.

About the Numpy API, we prefer to use the native C-Numpy-API in our 
code. I think it will offer more flexibilities in our generic C++ 
framework, particularly in our main object (named Field) which use the 
aliasing memory feature. Nevertheless, the first step of our migration 
could be using the numarray interface before using the native interface. 
It could be another test for you.

Finally, your description of what i call "aliasing memory" is good. So 
it is a very good point for us that it is supported.

Best regards,
- Mathieu


Travis Oliphant wrote:
> mg wrote:
>   
>> Hi all,
>>
>> I am doing a feseability study to migrate our Python based FEM 
>> applications from Numarray to Numpy.
>>
>> First, I tried to install Numpy from Python-2.4 on linux-x86, 
>> linux-86-64bit. So, all work fine. Great! Moreover, I change easily the 
>> BLAS linked libraries. I tried with ATLAS and GOTO. Great again!
>>
>> Second, I try to do the same think on windows-x86 without success. So my 
>> first question is: is Numpy-1.0b5 has been tested and is supported on 
>> Windows?
>>   
>>     
> Yes, it should work.  Builds for windows were provided.   But, perhaps 
> there are configuration issues for your system that we are not handling 
> correctly.
>
>   
>> Third, I tried to install Numpy from Python-2.5, which is our standard 
>> Python, on linux-x86... and the compilation stopped during the 
>> compilation of core/src/multiarraymodule.c. So my second question is: is 
>> there a workaround or is the porting to Python2.5 is yet schedule?
>>   
>>     
> There was a problem with Python 2.5 and NumPy 1.0 that is fixed in SVN.  
> Look for NumPy 1.0rc1 to come out soon.
>   
>> My third question is: is the tool to migrate the numarray based Python 
>> scripts (numpy.numarray.alter_code1) work fine? (I suppose yes...)
>>   
>>     
> It needs more testing.  It would be great if you could help us find and 
> fix bugs in it.   I don't have a lot of numarray code to test.
>   
>> We have created a lot of bindings in order to pilote our generic-C++ 
>> framework with Python scripts. So, about the Numpy API, is it widely 
>> different than the Numarray API? (We will order the Numpy Guide too.)
>>   
>>     
> It is more similar to the Numeric C-API.  However, the numarray C-API is 
> completely supported by including numpy/libnumarray.h so you should be 
> able to convert your C code very easily.   Any problems encountered 
> should be noted and we'll get them fixed.
>   
>> To not duplicate large numerical memory arrays, Numarray allows to 
>> aliasing the memory of some bindings with arrays from Numarray, and we 
>> have used this feature intensively. So, I wonder if it is currently 
>> supported (or even scheduled)?
>>     
> I'm pretty sure the answer is yes (because the Numarray C-API is 
> supported), though I'm not exactly sure what you mean.  Do you mean that 
> you have memory created in the C/C++ framework and then you have an 
> array use that memory for it's data area?  If that is what you mean, 
> then the answer is definitely yes.
>
>
> -Travis
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>