Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

[Travis Oliphant]

mg wrote:
> Hello,
>
> I just download the newly Python-2.5 and Numpy-1.0rc1 and all work fine 
> on Linux-x86 32 and 64bit platforms.
> Now, I try to compile the both distributions on WindowsXP with 
> VisualStudio2003. No problem to compile Python-2.5, but i have some 
> troubles with Numpy-1.0rc1 and I didn't find any help in the provided 
> setup.py. So, does someone can tell me how to do it?
>
>   
I don't use VisualStudio2003 on Windows to compile NumPy (I use mingw).  
Tim Hochberg once used a microsoft compiler to compile a previous 
version of NumPy and some things had to be fixed to make it work.  I'm 
not sure if some in-compatibilities have crept in since then or not.  
But, I'd sure like to resolve it if they have.

So, please post what problems you are having.  You may be the first 
person to try a microsoft compiler with Python 2.5

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] compiling ATLAS for numpy

[Emanuele Olivetti]

Hi,
I'm installing numpy on a 2 cpus intel pentium 4 Linux box. I'm installing BLAS 
and
LAPACK from sources too and I need to tune compiler flags. Here is the 
question: which
are the proper flags for compiling LAPACK? Inside lapack.tgz make.inc.LINUX 
says:
OPTS = -funroll-all-loops -fno-f2c -O3
instead on scipy.org[0] it's suggested:
OPTS = -O2

I assume that using -O3 and unrolling loops should have definitely better 
performance
that just -O2 but I'm wondering if the speedy options can be a problem for 
current
numpy release (numpy-1.0rc1). Is it safe to use '-funroll-all-loops -fno-f2c 
-O3'?

Thanks in advance for answers,

Emanuele

[0]: http://scipy.org/Installing_SciPy

P.S.: my GCC is v3.4.5


-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] compiling ATLAS for numpy

[Emanuele Olivetti]

Ops, sorry for the misleding subject: I wrote ATLAS but I meant LAPACK :)

Emanuele Olivetti wrote:
> Hi,
> I'm installing numpy on a 2 cpus intel pentium 4 Linux box. I'm installing 
> BLAS and
> LAPACK from sources too and I need to tune compiler flags. Here is the 
> question: which
> are the proper flags for compiling LAPACK? Inside lapack.tgz make.inc.LINUX 
> says:
> OPTS = -funroll-all-loops -fno-f2c -O3
> instead on scipy.org[0] it's suggested:
> OPTS = -O2
...

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Release candidate 2.0 will come out mid-week next week

[Francesc Altet]

El dc 27 de 09 del 2006 a les 21:17 -0600, en/na Travis Oliphant va
escriure:
> Hi all,
> 
> I'd like to release numpy 1.0rc2 on about October 5 of next week.   
> Then, the release of numpy 1.0 official should happen on Monday, October 
> 17.   Please try and get all fixes and improvements in before then.  
> Backward-incompatible changes are not acceptable at this point (unless 
> they are minor or actually bug-fixes). I think NumPy has been cooking 
> long enough.  Any remaining problems can be fixed with maintenance 
> releases.  When 1.0 comes out, we will make a 1.0 release branch where 
> bug-fixes should go as well as on the main trunk (I'd love for a way to 
> do that automatically).

In order to reduce the overhead of commiting bug fixes in both trunk and
the 1.0 branch, you may want to delay the making of the 1.0 branch as
much as possible. Eventually, when you have to start changes that
properly belongs to trunk, then it's time to create the branch, but
meanwhile you can save yourself quite a few syncronization work.

Anyway, it is my pleasure to help finding bugs for NumPy!

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



-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] storage order and concatenate

[David Cournapeau]

Hi,

I noticed a behaviour which I found counter-intuitive at least when 
using concatenate. I have a function which takes a numpy array of rank 2 
as input, let's say foo(in):

a= N.randn((10, 2))
foo(a)

To test a ctype implementation of foo against the python version, my 
test has something like

X1  = N.linspace(-2, 2, 10)[:, N.newaxis]
X2  = N.linspace(-1, 3, 10)[:, N.newaxis]
a= N.concatenate(([X1, X2]), 1)

which has Fortran storage (column major order), where as creating a as

a   = N.zeros((10, 2))
a[:,0] = N.linspace(-2, 2, 10)
a[:,1] = N.linspace(-1, 3, 10)

has C storage (row major order).

What are the rules concerning storage with numpy ? I thought it was 
always C, except if stated explicitly. I can obviously understand why 
concatenate gives a Fortran order from an implementation point of view, 
but this looks kind of strange to me,

David

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] return value of negative power

[Stefan van der Walt]

Hi all,

Currently, the power function returns '0' for negative powers of
integers:

In [1]: N.power(3,-2)
Out[1]: 0

(or, more confusingly)

In [1]: N.power(a,b)
Out[1]: 0

which is almost certainly not the answer you want.  Two possible
solutions may be to upcast the input to float before calculation, or
to return nan.

This would be consistent with a function like sqrt:

In [10]: N.sqrt(3)
Out[10]: 1.7320508075688772

In [11]: N.sqrt(-3)
Out[11]: nan

Does anyone have an opinion on whether the change is necessary, and if
so, on which one would work best?

Regards
Stéfan

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] compiling ATLAS for numpy

[Hanno Klemm]

Emanuele, 

the scipy compiler flags under 

http://www.scipy.org/Installing_SciPy/BuildingGeneral

work well. However, if you happen to have to use gcc 3.2.3 (e.g. often
in Redhat Enterprise editions present), you have to turn off
optimization, otherwise lapack doesn't build properly.

The correct build flags are then 
OPTS = -m64 -fPIC
(at least that's what worked for me)

Regards,
Hanno

Emanuele Olivetti <[EMAIL PROTECTED]> said:

> Ops, sorry for the misleding subject: I wrote ATLAS but I meant
LAPACK :)
> 
> Emanuele Olivetti wrote:
> > Hi,
> > I'm installing numpy on a 2 cpus intel pentium 4 Linux box. I'm
installing BLAS and
> > LAPACK from sources too and I need to tune compiler flags. Here is
the question: which
> > are the proper flags for compiling LAPACK? Inside lapack.tgz
make.inc.LINUX says:
> > OPTS = -funroll-all-loops -fno-f2c -O3
> > instead on scipy.org[0] it's suggested:
> > OPTS = -O2
> ...
> 
>
-
> 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
> Numpy-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 



-- 
Hanno Klemm
[EMAIL PROTECTED]



-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] storage order and concatenate

[Travis Oliphant]

David Cournapeau wrote:
> Hi,
>
>
> What are the rules concerning storage with numpy ? 
The rule is that a numpy array has "strides" which specify how many 
bytes to skip to get to the next element in the array.   That's the 
internal model.  There are no hard and fast rules about storage order.  
Internally, C-order is as good as Fortran-order (except the array 
iterator gives special preference to C-order and all functions for which 
the order can be specified (like zeros) default to C-order).

Thus, the storage order is whatever the strides say it is.  Now, there 
are flags that keep track of whether or not the strides agree with the 2 
recognized special cases of "Fortran-order" (first-index varies the 
fastest) or "C-order" (last-index varies the fastest).  But, this is 
only for convenience.   Very few functions actually require a 
specification of storage order.  Those that allow it default to "C-order".

You can't think of a NumPy array has having a particular storage order 
unless you explicitly request it.  One of the most common ways that 
Fortran-order arrays show up, for example is when a C-order array is 
transposed.  A transpose operation does nothing except flip the strides 
(and therefore the flags) of the array.  This is what is happening in 
concatenate (using axis=1) to give you a Fortran-order array.  
Bascially, code equivalent to the following is being run:  
concatenate([X1.T, X2.T]).T

In the second example, you explicitly create the array (and therefore 
the strides) as C-order and then fill it (so it doesn't change on you).  
The first example used array calculations which don't guarantee the 
storage order. 

This is all seamless to the user until you have to interface with 
extension code.  Ideally, you write compiled code that deals with 
strided arrays.  If you can't, then you request an array of the required 
storage-order. 

By the way, for interfacing with ctypes, check out the 
ctypeslib.ndpointer class-creation function for flag checking and the 
require function for automatic conversion of an array to specific 
requirements.

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] lexsort segfault sorting strings

[eric]

I've been using the new record arrays and lexsort from numpy quite a lot 
lately.  Very cool stuff.

Using the nightly egg for numpy from here (I believe it is up to date...):

http://code.enthought.com/enstaller/eggs/numpy-nightly-py2.4-win32.egg


I get segfaults when using lexsort on character arrays.  A lot of my 
columns in record arrays are string based, so sorting the arrays based 
on these columns would be really handy.

Here is an example that crashes for me.

C:\wrk\mt\trunk\src\lib\mt\statement\tests>python
Python 2.4.3 - Enthought Edition 1.0.0 (#69, Aug  2 2006, 12:09:59) [MSC 
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> from numpy import lexsort
 >>> lst = [1,2,3]
 >>> lexsort((lst,))
array([0, 1, 2])
 >>> lst = ['abc','cde','fgh']
 >>> lexsort((lst,))


Do others see this?

I've opened a ticket at:
http://projects.scipy.org/scipy/numpy/ticket/298

thanks,
eric

-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

[Tim Hochberg]

Travis Oliphant wrote:
> mg wrote:
>   
>> Hello,
>>
>> I just download the newly Python-2.5 and Numpy-1.0rc1 and all work fine 
>> on Linux-x86 32 and 64bit platforms.
>> Now, I try to compile the both distributions on WindowsXP with 
>> VisualStudio2003. No problem to compile Python-2.5, but i have some 
>> troubles with Numpy-1.0rc1 and I didn't find any help in the provided 
>> setup.py. So, does someone can tell me how to do it?
>>
>>   
>> 
> I don't use VisualStudio2003 on Windows to compile NumPy (I use mingw).  
> Tim Hochberg once used a microsoft compiler to compile a previous 
> version of NumPy and some things had to be fixed to make it work.  I'm 
> not sure if some in-compatibilities have crept in since then or not.  
> But, I'd sure like to resolve it if they have.
>
> So, please post what problems you are having.  You may be the first 
> person to try a microsoft compiler with Python 2.5
>   
It was VS2003 that I used to compile numpy. However, I switched boxes a 
while ago and I haven't got around to trying to compile on the new box, 
I've just been using the released builds. So I'm not much help at the 
moment. Things are clearing up a little bit here, so maybe I can carve 
some time out to get things set up to compile in the next couple days. 
If so I'll let you know what I find.

-tim

> -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
> Numpy-discussion@lists.sourceforge.net
> 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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

[mg]

Unfortunately, no Windows-x86 or Windows-x86-64bit Numpy-1.0rc1 
installer are available on SourceForge yet. So the only current solution 
for us is to compile it.
Moreover, our generic C++ framework is compiled with VisualStudio on 
Windows-native and we compile all additions to it with the same 
compiler, if compilation is needed.
Indeed, we have observed that Visual C++ is still the closest to a 
"default" or "native" compiler for windows platform, like gcc is for 
linuxwell at least that's our experience when using other commercial 
(or open-source, think python whose provide visual project files) 
softwares requiring rebuilding/relinking.
Use MinGW for Numpy means risk some un-compatibilities between Numpy and 
our framework (and even Python) or migrate all our development 
environment  from Visual Studio to MinGW. this is not really an option 
for the near or mean furture
If some of you have good experiences for linking (static or dynamic) 
libraries compiled with mixed compilers (especially mingw and visual), 
knowing that our libraries contains C++, C and fortran code, we could 
consider this as a temprary option for numpy, but for convenience we 
would ultimately prefer to use only 1 compiler to avoid a double 
maintenance of building tools
Then, I wonder if the compilation of Numpy with Visual-Studio-2003 (or 
2005) is scheduled ?

For your information, this is the standard output and the standard error 
of the compilation of Numpy-1.0rc1 with Visual Studio 2003:

 >>> command line >>>
python setup.py build 1>stdout.txt 2>stderr.txt

 >>> stdout.txt >>>

F2PY Version 2_3198
blas_opt_info:
blas_mkl_info:
  libraries mkl,vml,guide not found in c:\Program Files\python\dist\src\lib
  libraries mkl,vml,guide not found in C:\
  NOT AVAILABLE

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
  libraries ptf77blas,ptcblas,atlas not found in c:\Program 
Files\python\dist\src\lib
  libraries ptf77blas,ptcblas,atlas not found in C:\
  NOT AVAILABLE

atlas_blas_info:
  libraries f77blas,cblas,atlas not found in c:\Program 
Files\python\dist\src\lib
  libraries f77blas,cblas,atlas not found in C:\
  NOT AVAILABLE

blas_info:
  libraries blas not found in c:\Program Files\python\dist\src\lib
  libraries blas not found in C:\
  NOT AVAILABLE

blas_src_info:
  NOT AVAILABLE

  NOT AVAILABLE

lapack_opt_info:
lapack_mkl_info:
mkl_info:
  libraries mkl,vml,guide not found in c:\Program Files\python\dist\src\lib
  libraries mkl,vml,guide not found in C:\
  NOT AVAILABLE

  NOT AVAILABLE

atlas_threads_info:
Setting PTATLAS=ATLAS
  libraries ptf77blas,ptcblas,atlas not found in c:\Program 
Files\python\dist\src\lib
  libraries lapack_atlas not found in c:\Program Files\python\dist\src\lib
  libraries ptf77blas,ptcblas,atlas not found in C:\
  libraries lapack_atlas not found in C:\
numpy.distutils.system_info.atlas_threads_info
  NOT AVAILABLE

atlas_info:
  libraries f77blas,cblas,atlas not found in c:\Program 
Files\python\dist\src\lib
  libraries lapack_atlas not found in c:\Program Files\python\dist\src\lib
  libraries f77blas,cblas,atlas not found in C:\
  libraries lapack_atlas not found in C:\
numpy.distutils.system_info.atlas_info
  NOT AVAILABLE

lapack_info:
  libraries lapack not found in c:\Program Files\python\dist\src\lib
  libraries lapack not found in C:\
  NOT AVAILABLE

lapack_src_info:
  NOT AVAILABLE

  NOT AVAILABLE

running build
running config_fc
running build_src
building py_modules sources
building extension "numpy.core.multiarray" sources
Generating build\src.win32-2.5\numpy\core\config.h
No module named msvccompiler in numpy.distutils, trying from distutils..
0
Could not locate executable g77
Could not locate executable f77
Could not locate executable gfortran
Could not locate executable f95
customize GnuFCompiler
Could not locate executable f77
Executable f77 does not exist
Could not locate executable f77
Executable f77 does not exist
Could not locate executable f77
Executable f77 does not exist
Could not locate executable ifort
Could not locate executable ifc
Could not locate executable ifort
Could not locate executable efort
Could not locate executable efc
Could not locate executable ifort
Could not locate executable efort
Could not locate executable efc
customize IntelVisualFCompiler
Could not locate executable ifl
Executable ifl does not exist
customize AbsoftFCompiler
Could not locate executable f90
Executable f90 does not exist
customize CompaqVisualFCompiler
Could not locate executable DF
Executable DF does not exist
customize IntelItaniumVisualFCompiler
Could not locate executable efl
Executable efl does not exist
customize Gnu95FCompiler
Could not locate executable f95
Executable f95 does not exist
Could not locate executable f95
Executable f95 does not exist
Could not locate executable f95
Executable f95 does not exist
customize G95FCompiler
Could not locate executable g95
Executable g95 does not exist
customize GnuFCompiler
Could not locate executable f77
Executable f

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

[Tim Hochberg]

Tim Hochberg wrote:
> Travis Oliphant wrote:
>> mg wrote:
>>  
>>> Hello,
>>>
>>> I just download the newly Python-2.5 and Numpy-1.0rc1 and all work 
>>> fine on Linux-x86 32 and 64bit platforms.
>>> Now, I try to compile the both distributions on WindowsXP with 
>>> VisualStudio2003. No problem to compile Python-2.5, but i have some 
>>> troubles with Numpy-1.0rc1 and I didn't find any help in the 
>>> provided setup.py. So, does someone can tell me how to do it?
>>>
>>>   
>> I don't use VisualStudio2003 on Windows to compile NumPy (I use 
>> mingw).  Tim Hochberg once used a microsoft compiler to compile a 
>> previous version of NumPy and some things had to be fixed to make it 
>> work.  I'm not sure if some in-compatibilities have crept in since 
>> then or not.  But, I'd sure like to resolve it if they have.
>>
>> So, please post what problems you are having.  You may be the first 
>> person to try a microsoft compiler with Python 2.5
>>   
> It was VS2003 that I used to compile numpy. However, I switched boxes 
> a while ago and I haven't got around to trying to compile on the new 
> box, I've just been using the released builds. So I'm not much help at 
> the moment. Things are clearing up a little bit here, so maybe I can 
> carve some time out to get things set up to compile in the next couple 
> days. If so I'll let you know what I find.
FWIW, I just got svn head to compile cleanly against Python *2.4* with 
VS2003. Later today I will try compiling against 2.5

-tim




-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] 32/64-bit machines, integer arrays and python ints

[Bill Spotz]

I am wrapping code using swig and extending it to use numpy.

One class method I wrap (let's call it myElements()) returns an array  
of ints, and I convert it to a numpy array with

 PyArray_SimpleNew(1,n,'i');

I obtain the data pointer, fill in the values and return it as the  
method return argument.

In python, it is common to want to loop over this array and treat its  
elements as integers:

 for row in map.myElements():
 matrix.setElements(row, [row-1,row,row+1], [-1.0,2.0,-1.0])

On a 32-bit machine, this has worked fine, but on a 64-bit machine, I  
get a type error:

 TypeError: in method 'setElements', argument 2 of type 'int'

because row is a .

It would be nice if I could get the integer conversion to work  
automatically under the covers, but I'm not exactly sure how to make  
that work.

** Bill Spotz  **
** Sandia National Laboratories  Voice: (505)845-0170  **
** P.O. Box 5800 Fax:   (505)284-5451  **
** Albuquerque, NM 87185-0370Email: [EMAIL PROTECTED] **




-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] return value of negative power

[Tim Hochberg]

Stefan van der Walt wrote:
> Hi all,
>
> Currently, the power function returns '0' for negative powers of
> integers:
>
> In [1]: N.power(3,-2)
> Out[1]: 0
>
> (or, more confusingly)
>
> In [1]: N.power(a,b)
> Out[1]: 0
>
> which is almost certainly not the answer you want.  Two possible
> solutions may be to upcast the input to float before calculation, or
> to return nan.
>   
Returning nan seems silly. There really is a result, or rather two 
possible results on a tad more sensible than the other. If we were going 
to punt it makes more sense to raise an exception, but I doubt that's 
necessary. In addition, nan is really a floating point value; if we're 
going to return a floating point value, not an integer, we might as well 
return the actual result.

> This would be consistent with a function like sqrt:
>
> In [10]: N.sqrt(3)
> Out[10]: 1.7320508075688772
>
> In [11]: N.sqrt(-3)
> Out[11]: nan
>
> Does anyone have an opinion on whether the change is necessary, and if
> so, on which one would work best?
>   
This is a complicated tangle of worms. First off there's both "a**b" and 
"power(a, b)". These don't necessarily need to work the same. In fact 
they already differ somewhat in that a**b does some optimization when b 
is a small scalar that power does not (I think anyway -- haven't looked 
at this a while). However, if having them differ in any significant way 
is likely to be quite confusing, so it should be only be considered if 
there's some compelling reason to support multiple behaviors here.

There is a solution that is, IMO, simple obvious and not quite right. 
That is to return floats if the b contains any negative numbers while 
returning integers otherwise. That sounds appealing at first, but will 
cause confusion and memory blow ups when one suddenly has all of ones 
arrays become floats because somewhere or other a negative value crept 
into an exponent. It's fine for the return type to depend on the types 
of the arguments, it's not so good for it to depends on the values. This 
restriction gets a little weaker once future division arrives since ints 
and floats will be closer to indistinguishable, but it still has some 
force. On the other hand, this is consistent with the rest of Python's 
behavior.

Another path is to just always return floats from power. One down side 
of this is that we lose the ability to do true integer powers, which is 
sometimes useful. A second downside is that it introduces a 
inconsistency with Python's scalar 'x**y'.  One way to finesse both of 
these issues is to make numpy.power consistent with math.pow; that is, 
it returns floating point values when passed integers. At the same time, 
make a**b consistent with the python's '**' operator in that any 
negative exponents trigger a floating point return values. This isn't 
perfect, but it's as close to a self consistent solution as I can think of.

That's my two cents.

-tim





-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] how to compile numpy with visual-studio-2003?

[Tim Hochberg]

Tim Hochberg wrote:
> Tim Hochberg wrote:
>   
>> Travis Oliphant wrote:
>> 
>>> mg wrote:
>>>  
>>>   
 Hello,

 I just download the newly Python-2.5 and Numpy-1.0rc1 and all work 
 fine on Linux-x86 32 and 64bit platforms.
 Now, I try to compile the both distributions on WindowsXP with 
 VisualStudio2003. No problem to compile Python-2.5, but i have some 
 troubles with Numpy-1.0rc1 and I didn't find any help in the 
 provided setup.py. So, does someone can tell me how to do it?

   
 
>>> I don't use VisualStudio2003 on Windows to compile NumPy (I use 
>>> mingw).  Tim Hochberg once used a microsoft compiler to compile a 
>>> previous version of NumPy and some things had to be fixed to make it 
>>> work.  I'm not sure if some in-compatibilities have crept in since 
>>> then or not.  But, I'd sure like to resolve it if they have.
>>>
>>> So, please post what problems you are having.  You may be the first 
>>> person to try a microsoft compiler with Python 2.5
>>>   
>>>   
>> It was VS2003 that I used to compile numpy. However, I switched boxes 
>> a while ago and I haven't got around to trying to compile on the new 
>> box, I've just been using the released builds. So I'm not much help at 
>> the moment. Things are clearing up a little bit here, so maybe I can 
>> carve some time out to get things set up to compile in the next couple 
>> days. If so I'll let you know what I find.
>> 
> FWIW, I just got svn head to compile cleanly against Python *2.4* with 
> VS2003. Later today I will try compiling against 2.5
>
>   
OK. SVN head compiles out of the box and passes all tests for me under 
both Python2.4 and Python2.5.

My stderr output includes all of the same warnings about not being able 
to find ATLAS, BLAS and LAPACK that mg's does, but not "ERROR: Failed to 
test configuration".

The stdout output also looks similar except for the error at the end. (I 
can send you the entire stderr/stdout output privately if you like).

One thing I did notice is that your Python appears to be in a 
nonstandard location: \Program Files\python\dist\src instead of the 
standard \Python25, or at least that's where it's looking for things. 
Perhaps this is confusing either distutils or some of numpy's addons to 
distutils and causing it to misplace python25.lib. At least that's my 
best (and only) guess at the moment.

-tim




-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] 32/64-bit machines, integer arrays and python ints

[Travis Oliphant]

Bill Spotz wrote:
> I am wrapping code using swig and extending it to use numpy.
>
> One class method I wrap (let's call it myElements()) returns an array  
> of ints, and I convert it to a numpy array with
>
>  PyArray_SimpleNew(1,n,'i');
>   

You should probably use NPY_INT instead of 'i' for the type-code.  
> I obtain the data pointer, fill in the values and return it as the  
> method return argument.
>
> In python, it is common to want to loop over this array and treat its  
> elements as integers:
>
>  for row in map.myElements():
>  matrix.setElements(row, [row-1,row,row+1], [-1.0,2.0,-1.0])
>
> On a 32-bit machine, this has worked fine, but on a 64-bit machine, I  
> get a type error:
>
>  TypeError: in method 'setElements', argument 2 of type 'int'
>
> because row is a .
>
> It would be nice if I could get the integer conversion to work  
> automatically under the covers, but I'm not exactly sure how to make  
> that work.
>   

Yeah, It can be confusing, at first.  You just have to make sure you are 
matching the right c-data-types. I'm not quite sure what the problem 
here is given your description, because I don't know what setElements 
expects.  

My best guess, is that it is related to the fact that a Python int uses 
the 'long' c-type.   Thus, you should very likely be using 
PyArray_SimpleNew(1, n, NPY_LONG) instead of int so that your integer 
array always matches what Python is using as integers.

The other option is to improve your converter in setElements so that it 
can understand any of the array scalar integers and not just the default 
Python integer.  

The reason this all worked on 32-bit systems is probably the array 
scalar corresponding to NPY_INT is a sub-class of the Python integer.  
It can't be on a 64-bit platform because of binary incompatibility of 
the layout.

Hope that helps.


-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] 32/64-bit machines, integer arrays and python ints

[Bill Spotz]

On Sep 28, 2006, at 12:03 PM, Travis Oliphant wrote:

> The other option is to improve your converter in setElements so  
> that it
> can understand any of the array scalar integers and not just the  
> default
> Python integer.

I think this may be the best approach.

This may be something worthwhile to put in the numpy.i interface  
file: a set of typemaps that handle a set of basic conversions for  
those array scalar types for which it makes sense.  I'll look into it.

** Bill Spotz  **
** Sandia National Laboratories  Voice: (505)845-0170  **
** P.O. Box 5800 Fax:   (505)284-5451  **
** Albuquerque, NM 87185-0370Email: [EMAIL PROTECTED] **




-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] 32/64-bit machines, integer arrays and python ints

[Travis Oliphant]

Bill Spotz wrote:

>On Sep 28, 2006, at 12:03 PM, Travis Oliphant wrote:
>
>  
>
>>The other option is to improve your converter in setElements so  
>>that it
>>can understand any of the array scalar integers and not just the  
>>default
>>Python integer.
>>
>>
>
>I think this may be the best approach.
>
>This may be something worthwhile to put in the numpy.i interface  
>file: a set of typemaps that handle a set of basic conversions for  
>those array scalar types for which it makes sense.  I'll look into it.
>  
>
That's a good idea.Notice that there are some routines for making 
your life easier here. 

You should look at the tp_int function for the gentype array (it 
converts scalars to arrays).  You call the "__int__" special method of 
the scalar to convert it to a Python integer.  You should first check to 
see that it is an integer scalar PyArray_IsScalar(obj, Integer) because 
the "__int__" method coerces to an integer if it is a float (but maybe 
you want that behavior).

There are other functions in the C-API that return the data directly 
from the scalar --- check them out.  The macros in arrayscalar.h are 
useful.

-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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion