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

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

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

I also find the int behavior of these functions strange.

+1 float default (or double)

--bb

On 6/30/06, Tim Leslie <tim...@gm...> wrote:
>
> On 6/30/06, Keith Goodman <kwg...@gm...> wrote:
> > On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> > > A rather minor issue, but I would just like to make sure
> > > that a policy decision was made not to move to a float
> > > default for identity(), ones(), zeros(), and empty().
> > > (I leave aside arange().)
> > >
> > > I see the argument for a change to be 3-fold:
> > > 1. It is easier to introduce people to numpy if
> > >    default data types are all float.  (I teach,
> > >    and I want my students to use numpy.)
> > > 2. It is a better match to languages from which
> > >    users are likely to migrate (e.g., GAUSS or
> > >    Matlab).
> > > 3. In the uses I am most familiar with, float is
> > >    the most frequently desired data type.  (I guess
> > >    this may be field specific, especially for empty().)
> >
> > I vote float.
>
> +1 float
>
> Tim
>
>

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Sasha <nd...@ma...>]

I vote for no change.  It will be a major backward compatibility
headache with applications that rely on integer arrays breaking in
mysterious ways. If float wins, I hope there will be a script to
update old code. Detecting single argument calls to these functions is
probably not very hard.

On 6/29/06, Keith Goodman <kwg...@gm...> wrote:
> On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> > On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> > > Please make any comments or voice major concerns
> >
> > A rather minor issue, but I would just like to make sure
> > that a policy decision was made not to move to a float
> > default for identity(), ones(), zeros(), and empty().
> > (I leave aside arange().)
> >
> > I see the argument for a change to be 3-fold:
> > 1. It is easier to introduce people to numpy if
> >    default data types are all float.  (I teach,
> >    and I want my students to use numpy.)
> > 2. It is a better match to languages from which
> >    users are likely to migrate (e.g., GAUSS or
> >    Matlab).
> > 3. In the uses I am most familiar with, float is
> >    the most frequently desired data type.  (I guess
> >    this may be field specific, especially for empty().)
>
> I vote float.
>
> 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] Time for beta1 of NumPy 1.0

[Tim L. <tim...@gm...>]

On 6/30/06, Keith Goodman <kwg...@gm...> wrote:
> On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> > A rather minor issue, but I would just like to make sure
> > that a policy decision was made not to move to a float
> > default for identity(), ones(), zeros(), and empty().
> > (I leave aside arange().)
> >
> > I see the argument for a change to be 3-fold:
> > 1. It is easier to introduce people to numpy if
> >    default data types are all float.  (I teach,
> >    and I want my students to use numpy.)
> > 2. It is a better match to languages from which
> >    users are likely to migrate (e.g., GAUSS or
> >    Matlab).
> > 3. In the uses I am most familiar with, float is
> >    the most frequently desired data type.  (I guess
> >    this may be field specific, especially for empty().)
>
> I vote float.

+1 float

Tim

>
> 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] Time for beta1 of NumPy 1.0

[Keith G. <kwg...@gm...>]

On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> > Please make any comments or voice major concerns
>
> A rather minor issue, but I would just like to make sure
> that a policy decision was made not to move to a float
> default for identity(), ones(), zeros(), and empty().
> (I leave aside arange().)
>
> I see the argument for a change to be 3-fold:
> 1. It is easier to introduce people to numpy if
>    default data types are all float.  (I teach,
>    and I want my students to use numpy.)
> 2. It is a better match to languages from which
>    users are likely to migrate (e.g., GAUSS or
>    Matlab).
> 3. In the uses I am most familiar with, float is
>    the most frequently desired data type.  (I guess
>    this may be field specific, especially for empty().)

I vote float.

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

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

On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:=20
> Please make any comments or voice major concerns=20

A rather minor issue, but I would just like to make sure=20
that a policy decision was made not to move to a float=20
default for identity(), ones(), zeros(), and empty().
(I leave aside arange().)

I see the argument for a change to be 3-fold:
1. It is easier to introduce people to numpy if
   default data types are all float.  (I teach,
   and I want my students to use numpy.)
2. It is a better match to languages from which
   users are likely to migrate (e.g., GAUSS or
   Matlab).
3. In the uses I am most familiar with, float is
   the most frequently desired data type.  (I guess
   this may be field specific, especially for empty().)

Cheers,
Alan Isaac

[Numpy-discussion] Time for beta1 of NumPy 1.0

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

I think it's time for the first beta-release of NumPy 1.0

I'd like to put it out within 2 weeks.  Please make any comments or 
voice major concerns so that the 1.0 release series can be as stable as 
possible.

-Travis

Re: [Numpy-discussion] Core dump in numpy 0.9.6

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

Robert Lupton wrote:
> Here's an easy coredump:
> 
> x = numpy.arange(10, dtype="f"); y = numpy.array(len(x), dtype="F");  
> y.imag += x
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.

This bug does not appear to exist in recent versions. Please try the latest 
release (and preferably, the current SVN) before reporting bugs.

-- 
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

[Numpy-discussion] Core dump in numpy 0.9.6

[Robert L. <rh...@as...>]

Here's an easy coredump:

x = numpy.arange(10, dtype="f"); y = numpy.array(len(x), dtype="F");  
y.imag += x

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
PyArray_CompareLists (l1=0x0, l2=0x1841618, n=1) at numpy/core/src/ 
multiarraymodule.c:132
132                     if (l1[i] != l2[i]) return 0;
(gdb) where
#0  PyArray_CompareLists (l1=0x0, l2=0x1841618, n=1) at numpy/core/ 
src/multiarraymodule.c:132
#1  0x02a377d8 in PyUFunc_GenericFunction (self=0x538d40,  
args=0x2db3c88, mps=0xbfffd9c8) at numpy/core/src/ufuncobject.c:968
#2  0x02a39210 in ufunc_generic_call (self=0x538d40, args=0x2db3c88)  
at numpy/core/src/ufuncobject.c:2635
#3  0x000243bc in PyObject_CallFunction (callable=0x538d40,  
format=0x0) at Objects/abstract.c:1756
#4  0x0001f8cc in PyNumber_InPlaceAdd (v=0x565800, w=0x572540) at  
Objects/abstract.c:740

				R

[Numpy-discussion] python spherepack wrapper

[Jeff W. <js...@fa...>]

Hi All:  For those of you who have a need for spherical harmonic 
transforms in python, I've updated my spherepack 
(http://www.cisl.ucar.edu/css/software/spherepack/) wrapper for numpy.  
Docs at 
http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/spharm.html.  
If you have numpy and a fortran compiler supported by numpy.f2py, all 
you need to do is run 'python setup.py install'.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

[Numpy-discussion] We *will* move the mailing list to scipy.org

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

With a vote of 14 to 2 (and about 400 hundred implicit "I don't care one way or 
the other"), the new ads, and the recent problems with Sourceforge bouncing or 
delaying GMail messages, I intend to move the mailing list from Sourceforge to 
scipy.org in short order.

If you have strong objections to this move, this is your last chance to voice them.

-- 
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] incorporating C/C++ code

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

Christopher Barker wrote:
> Louis Cordier wrote:
>   
>>> At this point I would not use SWIG or Instant.
>>>       
>
> In general, SWIG makes sense if you have a substantial existing library 
> that you need access to, and particularly if that library is evolving 
> and needs to be used directly from C/C++ code as well.
>
> If you are writing C/C++ code specifically to be used as a python 
> extension, pyrex and boost::python are good choices. There was a Numeric 
> add-on to boost::python at one point, I don't know if anyone has 
> modified it for numpy.
>
>   
>> I was wondering if there where any issues with say using Psyco
>> with NumPy ?  http://psyco.sourceforge.net/
>>     
>
> Psyco knows nothing of numpy arrays, and thus can only access them as 
> generic Python objects -- so it won't help.
>
> A couple years ago, someone wrote a micro-Numeric package that used 
> python arrays as the base storage, and ran it with psyco with pretty 
> impressive results.
That might have been me. At least I have done this at least once. I even 
still have the code lying around if anyone wants to play with it. No 
guarantee that it hasn't succumbed to bit rot though.

>  What that tells me is that if psyco could be taught 
> to understand numpy arrays, (or at least the generic array interface) it 
> could work well. It would be a lot of work, however.
>   
There's another problem as well. Psyco only really knows about 2 things. 
Integers (C longs actually) and python objects (pointers).  Well, I 
guess that it also knows about arrays of integers/objects as well. It 
does not know how to handle floating point numbers directly. In fact, 
the way it handles floating point numbers is to break them into two 
32-bit chunks and store them as two integers. When one needs to operate 
on the float these two integers need to be retrieved, reassembled, 
operated on and then stuck back into two integers again. As a result, 
psyco is never going to be super fast for floating point, even if it 
learned about numeric arrays. In principle, it could learn about floats, 
but it would require a major rejiggering. As I understand it, Armin has 
no plans to do much more with Psyco other than bug fixes, instead 
working on PyPy. However, Psyco technology will likely go into PyPy 
(which I've mostly lost track of), so it's possible that down the road 
fast numeric stuff could be doable in PyPy.


-tim

Re: [Numpy-discussion] incorporating C/C++ code

[Philip A. <pa...@eo...>]

Christopher Barker writes:

 > If you are writing C/C++ code specifically to be used as a python 
 > extension, pyrex and boost::python are good choices. There was a Numeric 
 > add-on to boost::python at one point, I don't know if anyone has 
 > modified it for numpy.

Yes, I've been migrating my extensions to numpy and will put up a new
num_util.h version on the site
(http://www.eos.ubc.ca/research/clouds/num_util.html) this weekend
(it's about a 10 line diff).  When I get a chance I'm also planning to
add a page to the scipy wiki so we can see the same extension wrapped
with boost, swig, f2py and pyrex. -- Phil

Re: [Numpy-discussion] Sourceforge and gmail [was: Re: Recarray attributes writeable]

[David H. <dav...@gm...>]

Is it possible that gmail mails get through when they are sent by *l
ists.sourceforge.net
*while they are blocked when the outgoing server is gmail.com ?

My situation is that I can't post a new discussion to the list, although
replies seem to get through.

David

2006/6/16, Robert Kern <rob...@gm...>:
>
> Robert Kern wrote:
> > Erin Sheldon wrote:
> >
> >>Hi everyone -
> >>
> >>(this is my fourth try in the last 24 hours to post this.
> >>Apparently, the gmail smtp server is in the blacklist!!
> >>this is bad).
> >
> > I doubt it since that's where my email goes through.
>
> And of course that's utterly bogus since I usually use GMane. Apologies.
>
> However, *this* is a real email to numpy-discussion.
>
> --
> 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
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] incorporating C/C++ code

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

Louis Cordier wrote:
>> At this point I would not use SWIG or Instant.

In general, SWIG makes sense if you have a substantial existing library 
that you need access to, and particularly if that library is evolving 
and needs to be used directly from C/C++ code as well.

If you are writing C/C++ code specifically to be used as a python 
extension, pyrex and boost::python are good choices. There was a Numeric 
add-on to boost::python at one point, I don't know if anyone has 
modified it for numpy.

> I was wondering if there where any issues with say using Psyco
> with NumPy ?  http://psyco.sourceforge.net/

Psyco knows nothing of numpy arrays, and thus can only access them as 
generic Python objects -- so it won't help.

A couple years ago, someone wrote a micro-Numeric package that used 
python arrays as the base storage, and ran it with psyco with pretty 
impressive results. What that tells me is that if psyco could be taught 
to understand numpy arrays, (or at least the generic array interface) it 
could work well. It would be a lot of work, however.

-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] min/max not exported in "from numpy import *"

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

Travis Oliphant wrote:
> Well, Numeric had the sum function long before Python introduced one.  
> NumPy adopted Numeric's sum function as well. 

Yet another reason to NEVER use "import *"

-CHB



-- 
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...

[Numpy-discussion] Bug in digitize function

[David H. <dav...@gm...>]

Hi,

Here is something I noticed with digitize() that I guess would qualify as a
small but annoying bug.

In [165]: x = rand(10); bin = linspace(x.min(), x.max(), 10); print x.min();
print bin[0]; digitize(x,bin)
0.0925030184144
0.0925030184144
Out[165]: array([2, 9, 5, 9, 6, 1, 1, 1, 4, 5])

In [166]: x = rand(10); bin = linspace(x.min(), x.max(), 10); print x.min();
print bin[0]; digitize(x,bin)
0.0209738428066
0.0209738428066
Out[166]: array([ 5,  2,  8,  3,  0,  8,  9,  6, 10,  9])

Sometimes, the smallest number in x is counted in the first bin, and
sometimes, it is counted as an outlier (bin number = 0). Moreover, creating
the bin with
bin = linspace(x.min()-eps, x.max(), 10) doesn't seem to solve the problem
if eps is too small (ie 1./2**32). So basically, you can have

In [186]: x.min()>bin[0]
Out[186]: True
and yet digitize() considers x.min() as an outlier.

And to actually do something constructive, here is a docstring for digitize
"""Given an array of values and bin edges, digitize(values, bin_edges)
returns the index of the bin each value fall into.

The first bin has index 1, and the last bin has the index n, where n is the
number of bins.
Values smaller than the inferior edge are assigned index 0, while values
larger than the superior edge are assigned index n+1.
"""

Cheers,

David
P.S. Many mails I send don't make it to the list. Is it gmail related ?

Re: [Numpy-discussion] incorporating C/C++ code

[Louis C. <lco...@po...>]

>> For heavy number crunching I would like to include C and/or C++ functions
>> in my NumPy programs. They should have/give NumPy arrays as input/output.
>> On http://www.scipy.org/Topical_Software I find several suggestions to wrap
>> C/C++ code: SWIG, weave, Pyrex, Instant, ... but it's quite difficult for me
>> to have an idea which one I can/should use.
>>
> This is my personal preference order:
>
> 1) If you can write Fortran code --- do it and use f2py
>
> 2) If you have well-encapsulated functions to call then use
>    either weave or ctypes (both are very nice).
>
> 3) PyRex is a great option for writing a custom extension module
>    that needs a lot of capability built in.
>
> At this point I would not use SWIG or Instant.
>
> So, if Fortran is out for you, then install scipy (or install weave
> separately) and start with weave  http://www.scipy.org/Weave


Now since we are on the topic ;)

I was wondering if there where any issues with say using Psyco
with NumPy ?  http://psyco.sourceforge.net/

Then those number crunching code could still be in Python at least.
Anyone have some benchmarks/comments ?

Regards, Louis.

-- 
Louis Cordier <lco...@po...> cell: +27721472305
Point45 Entertainment (Pty) Ltd. http://www.point45.org

Re: [Numpy-discussion] incorporating C/C++ code

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

Joris De Ridder wrote:
> Hi,
>
> For heavy number crunching I would like to include C and/or C++ functions
> in my NumPy programs. They should have/give NumPy arrays as input/output. 
> On http://www.scipy.org/Topical_Software I find several suggestions to wrap
> C/C++ code: SWIG, weave, Pyrex, Instant, ... but it's quite difficult for me
> to have an idea which one I can/should use.
>   
This is my personal preference order:

1) If you can write Fortran code --- do it and use f2py

2) If you have well-encapsulated functions to call then use
    either weave or ctypes (both are very nice).

3) PyRex is a great option for writing a custom extension module
    that needs a lot of capability built in.

At this point I would not use SWIG or Instant.

So, if Fortran is out for you, then install scipy (or install weave 
separately) and start with weave  http://www.scipy.org/Weave

If you can compile your C/C++ functions as a shared-library, then 
check-out ctypes as well.

-Travis










> So, a few questions:
>
> Any suggestion for which package I should use? Does this heavily depend
> for which purpose I want to use it?
>
> Where can I find the docs for Weave? I find several links on the internet
> pointing to http://www.scipy.org/documentation/weave for more info,
> but there is nothing anymore.
>
> Thanks in advance,
> Joris
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
> 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] trouble on tru64

[N S. <nor...@gm...>]

Thank you for your reply.
The "config.h" is the following.
I hope it will be helpful.

Shimizu

/* #define SIZEOF_SHORT 2 */
/* #define SIZEOF_INT 4 */
/* #define SIZEOF_LONG 8 */
/* #define SIZEOF_FLOAT 4 */
/* #define SIZEOF_DOUBLE 8 */
#define SIZEOF_LONG_DOUBLE 16
#define SIZEOF_PY_INTPTR_T 8
/* #define SIZEOF_LONG_LONG 8 */
#define SIZEOF_PY_LONG_LONG 8
/* #define CHAR_BIT 8 */
#define MATHLIB m
#define HAVE_LONGDOUBLE_FUNCS
#define HAVE_FLOAT_FUNCS
#define HAVE_LOG1P
#define HAVE_EXPM1
#define HAVE_INVERSE_HYPERBOLIC
#define HAVE_INVERSE_HYPERBOLIC_FLOAT
#define HAVE_INVERSE_HYPERBOLIC_LONGDOUBLE
#define HAVE_ISNAN
#define HAVE_RINT



2006/6/30, Travis Oliphant <oli...@ie...>:
> N Shimizu wrote:
> > Hi everyone,
> >
> > I tried to build numpy 0.9.8 on compaq alpha tru64 UNIX v5.1 with gcc 4.0.2,
> >
> > but I encounterd the compilation trouble.
> >
>
> Thanks for the test.   This looks like a configuration problem.
> Could you post the config.h file that is generated when you run python
> setup.py
>
> It should be found in
>
> build/src.<platform>-<version>/numpy/core/config.h
>
> I don't think we've got the right set of configurations going for that
> platform.    Basically, we need to know if it has certain float and long
> versions of standard math functions (like floorf and floorl).
>
> It looks like the configuration code detected that it didn't have these
> functions but then during compilation, the functions that NumPy created
> were already defined causing the error.
>
> If we can first get a valid config.h file for your platform, then we can
> figure out how to generate it during build time.
>
> -Travis
>
>

Re: [Numpy-discussion] min/max not exported in "from numpy import *"

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

Zhang Le wrote:
>> I'm going to take a wild-ass guess and suggest that was a concious decision
>> by the authors.  Shadowing builtins is generally a no-no.  You just need to
>> be explicit instead of implicit:
>>
>>     from numpy import min, max
>>     
> I see. But why by default sum is exported? Is that a wise decision?
>   
Well, Numeric had the sum function long before Python introduced one.  
NumPy adopted Numeric's sum function as well. 

-Travis

Re: [Numpy-discussion] trouble on tru64

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

N Shimizu wrote:
> Hi everyone,
>
> I tried to build numpy 0.9.8 on compaq alpha tru64 UNIX v5.1 with gcc 4.0.2,
>   
> but I encounterd the compilation trouble.
>   

Thanks for the test.   This looks like a configuration problem.     
Could you post the config.h file that is generated when you run python 
setup.py

It should be found in

build/src.<platform>-<version>/numpy/core/config.h

I don't think we've got the right set of configurations going for that 
platform.    Basically, we need to know if it has certain float and long 
versions of standard math functions (like floorf and floorl). 

It looks like the configuration code detected that it didn't have these 
functions but then during compilation, the functions that NumPy created 
were already defined causing the error.

If we can first get a valid config.h file for your platform, then we can 
figure out how to generate it during build time.

-Travis

[Numpy-discussion] trouble on tru64

[N S. <nor...@gm...>]

Hi everyone,

I tried to build numpy 0.9.8 on compaq alpha tru64 UNIX v5.1 with gcc 4.0.2,
but I encounterd the compilation trouble.
The error message is the following.

Do you have any suggestion?

Thank you in advance.
Shimizu.


numpy/core/src/umathmodule.c.src: In function 'nc_floor_quotl':
numpy/core/src/umathmodule.c.src:600: warning: implicit declaration of
function 'floorl'
numpy/core/src/umathmodule.c.src:600: warning: incompatible implicit
declaration of built-in fu
nction 'floorl'
....
numpy/core/src/umathmodule.c.src: In function 'LONGDOUBLE_floor_divide':
numpy/core/src/umathmodule.c.src:1050: warning: incompatible implicit
declaration of built-in f
unction 'floorl'
numpy/core/src/umathmodule.c.src: In function 'CLONGDOUBLE_absolute':
numpy/core/src/umathmodule.c.src:1319: warning: incompatible implicit
declaration of built-in f
unction 'sqrtl'
....

build/src.osf1-V5.1-alpha-2.4/numpy/core/__umath_generated.c: At top level:
build/src.osf1-V5.1-alpha-2.4/numpy/core/__umath_generated.c:15:
error: 'acosl' undeclared here
 (not in a function)
build/src.osf1-V5.1-alpha-2.4/numpy/core/__umath_generated.c:18:
error: 'acoshf' undeclared her
e (not in a function)
...

Re: [Numpy-discussion] incorporating C/C++ code

[Rob H. <ro...@ho...>]

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

Joris De Ridder wrote:
> Hi,
> 
> For heavy number crunching I would like to include C and/or C++ functions
> in my NumPy programs. They should have/give NumPy arrays as input/output. 
> On http://www.scipy.org/Topical_Software I find several suggestions to wrap
> C/C++ code: SWIG, weave, Pyrex, Instant, ... but it's quite difficult for me
> to have an idea which one I can/should use.
> 
> So, a few questions:
> 
> Any suggestion for which package I should use? Does this heavily depend
> for which purpose I want to use it?

Wrapping C/C++ code is only necessary if the C/C++ code is pre-existing.
I have thusfar only incorporated C code into Numeric python programs by
writing the code natively as a python extension.

Any kind of wrapping will carry a penalty. If you write a python
extension in C you have all the flexibility you need.

Rob Hooft

- --
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEo/8XH7J/Cv8rb3QRAm40AJ0YoTy653HP0FWmRN4/zuTFruDwUwCfTgrV
4zfSl3GVT8mneL60zzr2zeY=
=JQrM
-----END PGP SIGNATURE-----

[Numpy-discussion] incorporating C/C++ code

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

Hi,

For heavy number crunching I would like to include C and/or C++ functions
in my NumPy programs. They should have/give NumPy arrays as input/output. 
On http://www.scipy.org/Topical_Software I find several suggestions to wrap
C/C++ code: SWIG, weave, Pyrex, Instant, ... but it's quite difficult for me
to have an idea which one I can/should use.

So, a few questions:

Any suggestion for which package I should use? Does this heavily depend
for which purpose I want to use it?

Where can I find the docs for Weave? I find several links on the internet
pointing to http://www.scipy.org/documentation/weave for more info,
but there is nothing anymore.

Thanks in advance,
Joris


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

Re: [Numpy-discussion] min/max not exported in "from numpy import *"

[Jeff W. <js...@fa...>]

Zhang Le wrote:
>> I'm going to take a wild-ass guess and suggest that was a concious decision
>> by the authors.  Shadowing builtins is generally a no-no.  You just need to
>> be explicit instead of implicit:
>>
>>     from numpy import min, max
>>     
> I see. But why by default sum is exported? Is that a wise decision?
>
> In [1]: from numpy import *
>
> In [2]: help sum
> ------> help(sum)
> Help on function sum in module numpy.core.oldnumeric:
>
> sum(x, axis=0, dtype=None)
> ...
>
> Zhang Le
>
>   

Zhang:  The reason max and min are not imported by 'from numpy import *' 
is because there are no such functions in numpy.  They are ndarray 
methods now (a.max(), a.min()), there is also a maximum and minium 
function which behaves somewhat differently.  There is still a sum 
function as you have discovered, and it will clobber the builtin.  
Another good reason not to use 'from numpy import *'

-Jeff


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg