[Numpy-discussion] (no subject)

[Jean-Baptiste Rudant]

http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html";> 
http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Jean-Baptiste Rudant]

http://dmjmultimedia.com/components/com_jcomments/tpl/default/jrklre.html";>
 http://dmjmultimedia.com/components/com_jcomments/tpl/default/jrklre.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Jean-Baptiste Rudant]

http://donnamaui.com/images/uploads/_thumbs/fjgvkd.html";> 
http://donnamaui.com/images/uploads/_thumbs/fjgvkd.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Jean-Baptiste Rudant]

http://alumnos.digicap.cl/images/rmngl.html";> 
http://alumnos.digicap.cl/images/rmngl.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Andre Martel]

What would be the best way to remove the maximum from a cube and "collapse" the 
remaining elements along the z-axis ?
For example, I want to reduce Cube to NewCube:


>>> Cube
array([[[  13,   2,   3,  42],
    [  5, 100,   7,   8],
    [  9,   1,  11,  12]],

   [[ 25,   4,  15,   1],
    [ 17,  30,   9,  20],
    [ 21,   2,  23,  24]],

   [[ 1,   2,  27,  28],
    [ 29,  18,  31,  32],
    [ -1,   3,  35,   4]]])


NewCube

array([[[  13,   2,   3,  1],
    [  5, 30,   7,   8],
    [  9,   1,  11,  12]],

   [[ 1,   2,  15,  28],
    [ 17,  18,  9,  20],
    [ -1,   2,  23,   4]]])

I tried with argmax() and then roll() and delete() but these
all work on 1-D arrays only. Thanks.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Alex Ter-Sarkissov]

hi, the question is probably very silly, but can't get my head around it

Say I have an NxM numerical array. What I want is to obtain the row and
column number of the smallest value(kinda like find command in Matlab). I
use something like where(min(array_name)), but keep getting the error
message. I'd be glad if any1 could have any suggestions in this regard.

cheers,

Alex
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Alex Ter-Sarkissov]

I got a problem running NumPy in Eclipse. I recently installed PyDev, but
after downloading NumPy the installation attempt failed since python 2.6 was
not found. I've installed Python 2.7. Do I need to replace it with Python
2.6?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Hänel Nikolaus Valentin]

Hi,

I would like to make a sanity test to check that calling the same
function with different parameters actually gives different results.

I am currently using::

try:
npt.assert_almost_equal(numpy_result, result)
except AssertionError:
assert True
else:
assert False

But maybe you have a better way? I couldn't find a 'assert_not_equal'
and the above just feels stupid.

thanks for your advice.

V-

-- 
Valentin Hänel
Scientific Software Developer
Blue Brain Project http://bluebrain.epfl.ch/
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Debashish Saha]

basic difference between the commands:
import numpy as np
from numpy import *
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Carl Canuck]

Hello,

I'm new to numpy, and I'm a stuck on my first real project with it.

I am trying to take the rfft of a numpy array, like this:
>>> my_rfft = numpy.fft.rfft(my_numpy_array)

and replace the amplitudes that can be obtained with:

>>> my_amplitudes = numpy.abs(my_rfft)

with amplitudes from an arbitrary numpy array's rFFT, which is to then be
converted back using numpy.fft.irfft .  Alternately, some future plans will
involve having to modify individual array element amplitudes directly based
on other parameters.  I would think that modifying and re-synthesizing
signals using FFT is a fairly common use-case, but my attempts at Googling
example code have been fruitless.

I'm not sure if my rudimentary knowledge of FFT is failing me, or if I'm
just not understanding how numpy represents and exposes the data, but I
would really appreciate any help I can get :)

/carl/
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Matthew Brett]

Hi,

I'm sorry if I missed something obvious - but is there a vectorized
way to look for None in an array?

In [3]: a = np.array([1, 1])

In [4]: a == object()
Out[4]: array([False, False], dtype=bool)

In [6]: a == None
Out[6]: False

(same for object arrays),

Thanks a lot,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[jennifer stone]

Hello,
This is Jennifer Stupensky. I would like to contribute to NumPy this GSoC.
What are the potential projects that can be taken up within the scope of
GSoC? Thanks a lot in anticipation
Regards
Jennifer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Petr Viktorin]

Hello,
Over at Python-ideas, there is a thread [0] about the following discrepancy:

>>> numpy.array(float('inf')) // 1
inf
>>> float('inf') // 1
nan

There are reasons for either result, but I believe it would be very
nice if either Python or Numpy changed, so they would give the same
value.
If any of you have reasons to defend Numpy's (or Python's) choice, or
otherwise want to chime in, please post there.

Thanks,
Petr Viktorin


[0] https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Ioan-Alexandru Lazar]

Hello everyone,

I'm currently planning to use a Python-based infrastructure for our HPC
project.
I've previously used NumPy and SciPy for basic scientific computing tasks,
but
performance hasn't been quite an issue for me until now. At the moment I'm
not too
sure as to what to do next though, and I was hoping that someone with more
experience in performance-related issues could point me to a way out of this.

The trouble lays in the following piece of code:

===
w = 2 * math.pi * f
M = A - (1j*w*E)
n = M.shape[1]
B1 = numpy.zeros(n)
B2 = numpy.zeros(n)
B1[n-2] = 1.0
B2[n-1] = 1.0
-> slow part starts here
umfpack.numeric(M)
x1 = umfpack.solve( um.UMFPACK_A, M, B1, autoTranspose = False)
x2 = umfpack.solve( um.UMFPACK_A, M, B2, autoTranspose = False)
solution = scipy.array([ [ x1[n-2], x2[n-2] ], [ x1[n-1], x2[n-1] ]])
return solution


This isn't really too much -- it's generating a small
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[David J Strozzi]

Hi,

[You may want to edit the numpy homepage numpy.scipy.org to tell 
people they must subscribe to post, and adding a link to 
http://www.scipy.org/Mailing_Lists]


Many of you probably know of the interpreter yorick by Dave Munro. As 
a Livermoron, I use it all the time.  There are some built-in 
functions there, analogous to but above and beyond numpy's sum() and 
diff(), which are quite useful for common operations on gridded data. 
Of course one can write their own, but maybe they should be cleanly 
canonized?

For instance:

x = linspace(0,10,10)
y = sin(x)

It is common, say when integrating y(x), to take "point-centered" 
data and want to zone-center it:

I = sum(zcen(y)*diff(x))

def zcen(x): return 0.5*(x[0:-1]+x[1:])

Besides zcen, yorick has builtins for "point centering", "un-zone 
centering," etc.  Also, due to its slick syntax you can give these 
things as array "indexes":

x(zcen), y(dif), z(:,sum,:)


Just some thoughts,
David Strozzi
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[frank wang]

Hi,
 
In my work, I want to implement a fir filter with an input array. Since 
performing the filter on each input sample is slow, are there fast way to 
perform the fir filter operation?  Are there ways to convert input into an 
array and perform the array multipication?
 
Thanks
 
Frank
_
When your life is on the go—take your life with you.
http://clk.atdmt.com/MRT/go/115298558/direct/01/___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Bandler, Derek]

Hi,

I would like to get information on the software licenses for numpy &
numeric.  On the sourceforge home for the packages, the listed license
is OSI-Approved Open Source  .
Is it possible to get more information on this?  A copy of the document
would be useful.  Thank you.
Best regards,
Derek Bandler 

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[gzhu]

Hi Nadav,

The code is attached at the end. There is probably still bugs in there
but it does not prevent me from showing the difficulity.

If you look at the inner loop below, you will see that vector v is
updated element by element. The new value of v[i] depends on the new
value of v[i-1] and the old value of v[i+1]. Updating an element
involves the new values of the already updated elements and the old
values of the rest of the elements that we have yet to update. This
makes vectorization difficult.


for i in range(1,N-1):
temp[i]=(1-w)*v[i]+w/D[i]*(q[i]-L[i-1]*v[i-1]-U[i]*v[i+1])
err += (temp[i]-v[i])**2
v[i]=temp[i]

Thanks,
Geoffrey

Complete code here;

def sor(v, L, D, U ,q, tol, w):
'''solve M*v=q. return v.
L, D, U are the sub-diagonal, diagonal, and super-diagonal of the
matrix M.

'''

err=999
N=D.shape[0] #number of elements
temp=empty(N)
while err> tol :
err=0
temp[0]=(1-w)*v[0]+w/D[0]*(q[0]-U[0]*v[1])
err += (temp[0]-v[0])**2
v[0]=temp[0]

for i in range(1,N-1):
temp[i]=(1-w)*v[i]+w/D[i]*(q[i]-L[i-1]*v[i-1]-U[i]*v[i+1])
err += (temp[i]-v[i])**2
v[i]=temp[i]

temp[N-1]=(1-w)*v[N-1]+w/D[N-1]*(q[N-1]-L[N-2]*v[N-2])
err += (temp[N-1]-v[N-1])**2
v[N-1]=temp[N-1]
return v
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nadav Horesh
Sent: Friday, February 16, 2007 8:52 AM
To: Discussion of Numerical Python
Subject: RE: [Numpy-discussion] Numpy and iterative procedures

At first glance it doesn't look hard to, at least, avoid looping over i,
by replacing [i] by [:-2], [i+1] by [1:-1] and [i+2] by [2:]. But I
might be wrong. Can you submit the piece of code with at least the most
internal loop?

   Nadav.

-Original Message-
From:   [EMAIL PROTECTED] on behalf of Geoffrey Zhu
Sent:   Thu 15-Feb-07 18:32
To: Discussion of Numerical Python
Cc: 
Subject:Re: [Numpy-discussion] Numpy and iterative procedures

Thanks Chuck.
 
I am trying to use Successive Over-relaxation to solve linear equations
defined by M*v=q. 
 
There are several goals:
 
1. Eventually (in production) I need it to be fast.
2. I am playing with the guts of the algorithm for now, to see how it
works. that means i need some control for now.
3. Even in production, there is a chance i'd like to have the ability to
tinker with the algorithm. 
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Charles R
Harris
Sent: Thursday, February 15, 2007 10:11 AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Numpy and iterative procedures





On 2/15/07, Geoffrey Zhu <[EMAIL PROTECTED]> wrote: 

Hi,

I am new to numpy. I'd like to know if it is possible to code efficient
iterative procedures with numpy.

Specifically, I have the following problem.

M is an N*N matrix. Q is a N*1 vector. V is an N*1 vector I am trying 
to 
find iteratively from the initial value V_0. The procedure is simply to
calculate

V_{n+1}[i]=3D1/M[I,i]*(q[i]-
(M[i,1]*v_{n+1}[1]+M[I,2]*v_{n+1}[2]+..+M[i,i-1]*v_{n+1}[i-1]) -
(M[I,i+1]*v_{n}[i+1]+M[I,i+2]*v_{n}[i+2]+..+M[I,N]*v_{n}[N])) 

I do not see that this is something that can esaily be vectorized, is
it?


I think it would be better if you stated what the actual problem is. Is
it a differential equation, for instance. That way we can determine what
the problem class is and what algorithms are available to solve it. 

Chuck



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] (no subject)

[Saumyajit Dey]

Hi,

This is Saumyajit Dey and I am looking forward to start contributing to
NumPy.

I have never contributed to any open source projects before so I would want
to know some tips and guidelines to start contributing.

Regards,
Saumyajit

Saumyajit Dey
Junior Undergraduate Student:
Department of Computer Science and Engineering
National Institute of Technology
Warangal (NITW), India
Cell: +91-8885847028
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[mark florisson]

Could someone please ban this person from the mailing list, he keeps
sending spam.

On 6 April 2012 12:41, Jean-Baptiste Rudant  wrote:

> http://alumnos.digicap.cl/images/rmngl.html
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Pierre Haessig]

Le 06/04/2012 14:06, mark florisson a écrit :
> Could someone please ban this person from the mailing list, he keeps
> sending spam.
I was about to ask the same thing.

In the mean time, I googled the name of this gentleman and found a
possible match with a person working for the French national institute
for statistics (INSEE). I've tried to forge a valid email address from
his name and the INSEE domain name to warn him about his spamming Yahoo
address. I'll see if the email comes back as "Undelivered" or not...

-- 
Pierre



signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Ognen Duzlevski]

On Fri, Apr 6, 2012 at 7:06 AM, mark florisson wrote:

> Could someone please ban this person from the mailing list, he keeps
> sending spam.
>
> On 6 April 2012 12:41, Jean-Baptiste Rudant  wrote:
>
>> http://alumnos.digicap.cl/images/rmngl.html
>>
>>
They should be gone now.
Ognen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Tony Yu]

On Fri, Apr 20, 2012 at 2:15 PM, Andre Martel wrote:

> What would be the best way to remove the maximum from a cube and
> "collapse" the remaining elements along the z-axis ?
> For example, I want to reduce Cube to NewCube:
>
> >>> Cube
> array([[[  13,   2,   3,  42],
> [  5, 100,   7,   8],
> [  9,   1,  11,  12]],
>
>[[ 25,   4,  15,   1],
> [ 17,  30,   9,  20],
> [ 21,   2,  23,  24]],
>
>[[ 1,   2,  27,  28],
> [ 29,  18,  31,  32],
> [ -1,   3,  35,   4]]])
>
> NewCube
>
> array([[[  13,   2,   3,  1],
> [  5, 30,   7,   8],
> [  9,   1,  11,  12]],
>
>[[ 1,   2,  15,  28],
> [ 17,  18,  9,  20],
> [ -1,   2,  23,   4]]])
>
> I tried with argmax() and then roll() and delete() but these
> all work on 1-D arrays only. Thanks.
>
>
Actually, those commands do work with n-dimensional arrays, but you'll have
to specify the axis (the default for all these functions is `axis=None`
which tell the function to operate on flattened the arrays). If you don't
care about the order of the "collapse", you can just do a simple sort (and
drop the last---i.e. max---sub-array):

>>> np.sort(cube, axis=0)[:2]

If you need to keep the order, you can probably use some combination of
`np.argsort` and `np.choose`.

Cheers,
-Tony
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[eat]

Hi,

On Fri, Apr 20, 2012 at 9:15 PM, Andre Martel wrote:

> What would be the best way to remove the maximum from a cube and
> "collapse" the remaining elements along the z-axis ?
> For example, I want to reduce Cube to NewCube:
>
> >>> Cube
> array([[[  13,   2,   3,  42],
> [  5, 100,   7,   8],
> [  9,   1,  11,  12]],
>
>[[ 25,   4,  15,   1],
> [ 17,  30,   9,  20],
> [ 21,   2,  23,  24]],
>
>[[ 1,   2,  27,  28],
> [ 29,  18,  31,  32],
> [ -1,   3,  35,   4]]])
>
> NewCube
>
> array([[[  13,   2,   3,  1],
> [  5, 30,   7,   8],
> [  9,   1,  11,  12]],
>
>[[ 1,   2,  15,  28],
> [ 17,  18,  9,  20],
> [ -1,   2,  23,   4]]])
>
> I tried with argmax() and then roll() and delete() but these
> all work on 1-D arrays only. Thanks.
>
Perhaps it would be more straightforward to process via 2D-arrays, like:
In []: C
Out[]:
array([[[ 13,   2,   3,  42],
[  5, 100,   7,   8],
[  9,   1,  11,  12]],
   [[ 25,   4,  15,   1],
[ 17,  30,   9,  20],
[ 21,   2,  23,  24]],
   [[  1,   2,  27,  28],
[ 29,  18,  31,  32],
[ -1,   3,  35,   4]]])
In []: C_in= C.reshape(3, -1).copy()
In []: ndx= C_in.argmax(0)
In []: C_out= C_in[:2, :]
In []: C_out[:, ndx== 0]= C_in[1:, ndx== 0]
In []: C_out[1, ndx== 1]= C_in[2, ndx== 1]
In []: C_out.reshape(2, 3, 4)
Out[]:
array([[[13,  2,  3,  1],
[ 5, 30,  7,  8],
[ 9,  1, 11, 12]],
   [[ 1,  2, 15, 28],
[17, 18,  9, 20],
[-1,  2, 23,  4]]])

My 2 cents,
-eat

>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Skipper Seabold]

On Wed, Mar 2, 2011 at 5:25 PM, Alex Ter-Sarkissov  wrote:
> hi, the question is probably very silly, but can't get my head around it
>
> Say I have an NxM numerical array. What I want is to obtain the row and
> column number of the smallest value(kinda like find command in Matlab). I
> use something like where(min(array_name)), but keep getting the error
> message. I'd be glad if any1 could have any suggestions in this regard.
>

In [1]: import numpy as np

In [2]: A = np.random.randn(10,10)

In [3]: np.where(A==np.min(A))
Out[3]: (array([5]), array([3]))

Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Robert Kern]

On Wed, Mar 2, 2011 at 16:25, Alex Ter-Sarkissov  wrote:
> hi, the question is probably very silly, but can't get my head around it
>
> Say I have an NxM numerical array. What I want is to obtain the row and
> column number of the smallest value(kinda like find command in Matlab). I
> use something like where(min(array_name)), but keep getting the error
> message. I'd be glad if any1 could have any suggestions in this regard.

[~]
|15> A = np.random.random([3,5])

[~]
|16> i = A.min(axis=1).argmin()

[~]
|17> j = A.min(axis=0).argmin()

[~]
|18> A[i,j]
0.0065380564732848701

[~]
|19> A.min()
0.0065380564732848701

-- 
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
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Till Stensitzki]

Alex Ter-Sarkissov  gmail.com> writes:

> 
> hi, the question is probably very silly, but can't get my head around itSay
> I have an NxM numerical array. What I want is to obtain the row and
> column number of the smallest value(kinda like find command in Matlab).
> I use something like where(min(array_name)), but keep getting the error
> message. I'd be glad if any1 could have any suggestions in this 
regard.cheers,Alex   
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion  scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


In [24]: a=np.random.rand(3,3)

In [25]: a
Out[25]: 
array([[ 0.77163699,  0.92324147,  0.20572183],
   [ 0.75230562,  0.06454533,  0.23930423],
   [ 0.9312196 ,  0.62750468,  0.02125804]])

In [26]: np.unravel_index(a.argmin(),a.shape)
Out[26]: (2, 2)


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Marcel Blattner]

...for example:

A = np.random.rand(5,5)

In [366]: A
Out[366]:
array([[ 0.36380049,  0.26440478,  0.8515609 ,  0.07893608,  0.48084575],
   [ 0.71133527,  0.90912083,  0.14812865,  0.23223621,  0.49983985],
   [ 0.51668793,  0.73303799,  0.18620246,  0.52968823,  0.51904697],
   [ 0.3988893 ,  0.60350318,  0.63808109,  0.38470785,  0.48923821],
   [ 0.02427049,  0.80382225,  0.42494655,  0.8986108 ,  0.39879547]])

In [367]: np.nonzero(A==np.min(A))
Out[367]: (array([4]), array([0]))


And this may be of interest for you:
http://www.scipy.org/NumPy_for_Matlab_Users

cheers
Marcel



On Wed, Mar 2, 2011 at 11:25 PM, Alex Ter-Sarkissov wrote:

> hi, the question is probably very silly, but can't get my head around it
>
> Say I have an NxM numerical array. What I want is to obtain the row and
> column number of the smallest value(kinda like find command in Matlab). I
> use something like where(min(array_name)), but keep getting the error
> message. I'd be glad if any1 could have any suggestions in this regard.
>
> cheers,
>
> Alex
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Olivier Delalleau]

Sounds like you need to re-download NumPy, but the version for Python 2.7.

-=- Olivier

2011/10/3 Alex Ter-Sarkissov 

> I got a problem running NumPy in Eclipse. I recently installed PyDev, but
> after downloading NumPy the installation attempt failed since python 2.6 was
> not found. I've installed Python 2.7. Do I need to replace it with Python
> 2.6?
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Olivier Delalleau]

Not sure if there's a better way, but you can do it with

assert not numpy.allclose(numpy_result, result)

-=- Olivier

2012/1/20 Hänel Nikolaus Valentin 

> Hi,
>
> I would like to make a sanity test to check that calling the same
> function with different parameters actually gives different results.
>
> I am currently using::
>
>try:
>npt.assert_almost_equal(numpy_result, result)
>except AssertionError:
>assert True
>else:
>assert False
>
> But maybe you have a better way? I couldn't find a 'assert_not_equal'
> and the above just feels stupid.
>
> thanks for your advice.
>
> V-
>
> --
> Valentin Hänel
> Scientific Software Developer
> Blue Brain Project http://bluebrain.epfl.ch/
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Hänel Nikolaus Valentin]

* Olivier Delalleau  [120120]:
> Not sure if there's a better way, but you can do it with
> 
> assert not numpy.allclose(numpy_result, result)

Okay, thats already better than what I have.

thanks

V-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Brett Olsen]

The namespace is different.  If you want to use numpy.sin(), for
example, you would use:

import numpy as np
np.sin(angle)

or

from numpy import *
sin(angle)

I generally prefer the first option because then I don't need to worry
about multiple imports writing on top of each other (i.e., having test
functions in several modules, and then accidentally using the wrong
one).

~Brett

On Mon, Feb 6, 2012 at 1:21 PM, Debashish Saha  wrote:
> basic difference between the commands:
> import numpy as np
> from numpy import *
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Cera, Tim]

> I am trying to take the rfft of a numpy array, like this:
 my_rfft = numpy.fft.rfft(my_numpy_array)
>
> and replace the amplitudes that can be obtained with:
>
 my_amplitudes = numpy.abs(my_rfft)
>
> with amplitudes from an arbitrary numpy array's rFFT, which is to then be
> converted back using numpy.fft.irfft .  Alternately, some future plans will
> involve having to modify individual array element amplitudes directly based
> on other parameters.  I would think that modifying and re-synthesizing
> signals using FFT is a fairly common use-case, but my attempts at Googling
> example code have been fruitless.

I have FFT transform filter in my tidal analysis package.   See
http://sourceforge.net/apps/mediawiki/tappy/index.php?title=CompareTidalFilters
for a comparison and short description.

See my function below.  My earlier self made some poor variable name
choices.  The 'low_bound' variable is actually where frequencies
greater are set to zero ('factor[freq > low_bound] = 0.0'), then
factor is ramped from 0 at 'low_bound' to 1 at 'high_bound'.  To
filter out tidal signals if your water elevations are hourly then
'low_bound' = 1/30.0 and 'high_bound' = 1/40.0.  Having this gradual
change in the frequency domain rather than an abrupt change makes a
better filter.

def fft_lowpass(nelevation, low_bound, high_bound):
 """ Performs a low pass filter on the nelevation series.
 low_bound and high_bound specifies the boundary of the filter.
 """
 import numpy.fft as F
 if len(nelevation) % 2:
 result = F.rfft(nelevation, len(nelevation))
 else:
 result = F.rfft(nelevation)
 freq = F.fftfreq(len(nelevation))[:len(nelevation)/2]
 factor = np.ones_like(result)
 factor[freq > low_bound] = 0.0

 sl = np.logical_and(high_bound < freq, freq < low_bound)

 a = factor[sl]
 # Create float array of required length and reverse
 a = np.arange(len(a) + 2).astype(float)[::-1]

 # Ramp from 1 to 0 exclusive
 a = (a/a[0])[1:-1]

 # Insert ramp into factor
 factor[sl] = a

 result = result * factor
 print 'result=', len(result)
 relevation = F.irfft(result, len(nelevation))
 print 'result=', len(relevation)
 return relevation


Kindest regards,
Tim
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Carl Canuck]

Hi Tim,

Brilliant!  Many thanks...  I think this is exactly what I need, I owe you
a beer (or other beverage of your choice).

I'm now going to lock myself in the basement until I can work out an
implementation of this for my use-case :)

/Carl


On Tue, Sep 3, 2013 at 9:05 PM, Cera, Tim  wrote:

> > I am trying to take the rfft of a numpy array, like this:
>  my_rfft = numpy.fft.rfft(my_numpy_array)
> >
> > and replace the amplitudes that can be obtained with:
> >
>  my_amplitudes = numpy.abs(my_rfft)
> >
> > with amplitudes from an arbitrary numpy array's rFFT, which is to then be
> > converted back using numpy.fft.irfft .  Alternately, some future plans
> will
> > involve having to modify individual array element amplitudes directly
> based
> > on other parameters.  I would think that modifying and re-synthesizing
> > signals using FFT is a fairly common use-case, but my attempts at
> Googling
> > example code have been fruitless.
>
> I have FFT transform filter in my tidal analysis package.   See
>
> http://sourceforge.net/apps/mediawiki/tappy/index.php?title=CompareTidalFilters
> for a comparison and short description.
>
> See my function below.  My earlier self made some poor variable name
> choices.  The 'low_bound' variable is actually where frequencies
> greater are set to zero ('factor[freq > low_bound] = 0.0'), then
> factor is ramped from 0 at 'low_bound' to 1 at 'high_bound'.  To
> filter out tidal signals if your water elevations are hourly then
> 'low_bound' = 1/30.0 and 'high_bound' = 1/40.0.  Having this gradual
> change in the frequency domain rather than an abrupt change makes a
> better filter.
>
> def fft_lowpass(nelevation, low_bound, high_bound):
>  """ Performs a low pass filter on the nelevation series.
>  low_bound and high_bound specifies the boundary of the filter.
>  """
>  import numpy.fft as F
>  if len(nelevation) % 2:
>  result = F.rfft(nelevation, len(nelevation))
>  else:
>  result = F.rfft(nelevation)
>  freq = F.fftfreq(len(nelevation))[:len(nelevation)/2]
>  factor = np.ones_like(result)
>  factor[freq > low_bound] = 0.0
>
>  sl = np.logical_and(high_bound < freq, freq < low_bound)
>
>  a = factor[sl]
>  # Create float array of required length and reverse
>  a = np.arange(len(a) + 2).astype(float)[::-1]
>
>  # Ramp from 1 to 0 exclusive
>  a = (a/a[0])[1:-1]
>
>  # Insert ramp into factor
>  factor[sl] = a
>
>  result = result * factor
>  print 'result=', len(result)
>  relevation = F.irfft(result, len(nelevation))
>  print 'result=', len(relevation)
>  return relevation
>
>
> Kindest regards,
> Tim
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Warren Weckesser]

On Fri, Nov 22, 2013 at 4:23 PM, Matthew Brett wrote:

> Hi,
>
> I'm sorry if I missed something obvious - but is there a vectorized
> way to look for None in an array?
>
> In [3]: a = np.array([1, 1])
>
> In [4]: a == object()
> Out[4]: array([False, False], dtype=bool)
>
> In [6]: a == None
> Out[6]: False
>
> (same for object arrays),
>



Looks like using a "scalar array" that holds the value None will work:

In [8]: a
Out[8]: array([[1, 2], 'foo', None], dtype=object)

In [9]: a == np.array(None)
Out[9]: array([False, False,  True], dtype=bool)

Warren



> Thanks a lot,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Robert Kern]

On Fri, Nov 22, 2013 at 9:23 PM, Matthew Brett 
wrote:
>
> Hi,
>
> I'm sorry if I missed something obvious - but is there a vectorized
> way to look for None in an array?
>
> In [3]: a = np.array([1, 1])
>
> In [4]: a == object()
> Out[4]: array([False, False], dtype=bool)
>
> In [6]: a == None
> Out[6]: False

[~]
|1> x = np.array([1, None, 2], dtype=object)

[~]
|2> np.equal(x, None)
array([False,  True, False], dtype=bool)

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Matthew Brett]

Hi,

Thanks both - very helpful,

Matthew

On 11/22/13, Robert Kern  wrote:
> On Fri, Nov 22, 2013 at 9:23 PM, Matthew Brett 
> wrote:
>>
>> Hi,
>>
>> I'm sorry if I missed something obvious - but is there a vectorized
>> way to look for None in an array?
>>
>> In [3]: a = np.array([1, 1])
>>
>> In [4]: a == object()
>> Out[4]: array([False, False], dtype=bool)
>>
>> In [6]: a == None
>> Out[6]: False
>
> [~]
> |1> x = np.array([1, None, 2], dtype=object)
>
> [~]
> |2> np.equal(x, None)
> array([False,  True, False], dtype=bool)
>
> --
> Robert Kern
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Charles R Harris]

Hi Jennifer,


On Sat, Jan 18, 2014 at 11:48 AM, jennifer stone
wrote:

> Hello,
> This is Jennifer Stupensky. I would like to contribute to NumPy this GSoC.
> What are the potential projects that can be taken up within the scope of
> GSoC? Thanks a lot in anticipation
> Regards
>

What are your interests and experience? If you use numpy, are there things
you would like to fix, or enhancements you would like to see?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[jennifer stone]

> >What are your interests and experience? If you use numpy, are there things
> >you would like to fix, or enhancements you would like to see?
>
> Chuck
>
>
 I am an undergraduate student with CS as major and have interest in Math
and Physics. This has led me to use NumPy and SciPy to work on innumerable
cases involving special polynomial functions and polynomials like Legendre
polynomials, Bessel Functions and so on. So, The packages are closer known
to me from this point of view. I have a* few proposals* in mind. But I
don't have any idea if they are acceptable within the scope of GSoC
1. Many special functions and polynomials are neither included in NumPy nor
on SciPy.. These include Ellipsoidal Harmonic Functions (lames function),
Cylindrical Harmonic function. Scipy at present supports only spherical
Harmonic function.
Further, why cant we extend SciPy  to incorporate* Inverse Laplace
Transforms*? At present Matlab has this amazing function *ilaplace* and
SymPy does have *Inverse_Laplace_transform* but it would be better to
incorporate all in one package. I mean SciPy does have function to evaluate
laplace transform

After having written this, I feel that this post should have been sent to
SciPy
but as a majority of contributors are the same I proceed.
Please suggest any other possible projects, as I would like to continue
with SciPy or NumPy, preferably NumPy as I have been fiddling with its
source code for a month now and so am pretty comfortable with it.

As for my experience, I have known C for past 4 years and have been a
python lover for past 1 year. I am pretty new to open source communities,
started before a manth and a half.

regards
Jennifer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Charles R Harris]

On Tue, Jan 21, 2014 at 9:26 AM, jennifer stone wrote:

>
> >What are your interests and experience? If you use numpy, are there things
>> >you would like to fix, or enhancements you would like to see?
>>
>> Chuck
>>
>>
>  I am an undergraduate student with CS as major and have interest in Math
> and Physics. This has led me to use NumPy and SciPy to work on innumerable
> cases involving special polynomial functions and polynomials like Legendre
> polynomials, Bessel Functions and so on. So, The packages are closer known
> to me from this point of view. I have a* few proposals* in mind. But I
> don't have any idea if they are acceptable within the scope of GSoC
> 1. Many special functions and polynomials are neither included in NumPy
> nor on SciPy.. These include Ellipsoidal Harmonic Functions (lames
> function), Cylindrical Harmonic function. Scipy at present supports only
> spherical Harmonic function.
> Further, why cant we extend SciPy  to incorporate* Inverse Laplace
> Transforms*? At present Matlab has this amazing function *ilaplace* and
> SymPy does have *Inverse_Laplace_transform* but it would be better to
> incorporate all in one package. I mean SciPy does have function to evaluate
> laplace transform
>
> After having written this, I feel that this post should have been sent to
> SciPy
> but as a majority of contributors are the same I proceed.
> Please suggest any other possible projects, as I would like to continue
> with SciPy or NumPy, preferably NumPy as I have been fiddling with its
> source code for a month now and so am pretty comfortable with it.
>
> As for my experience, I have known C for past 4 years and have been a
> python lover for past 1 year. I am pretty new to open source communities,
> started before a manth and a half.
>
>
It does sound like scipy might be a better match, I don't think anyone
would complain if you cross posted. Both scipy and numpy require GSOC
candidates to have a pull request accepted as part of the application
process. I'd suggest implementing a function not currently in scipy that
you think would be useful. That would also help in finding a mentor for the
summer. I'd also suggest getting familiar with cython.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Stéfan van der Walt]

On Tue, 21 Jan 2014 21:56:17 +0530, jennifer stone wrote:
>  I am an undergraduate student with CS as major and have interest in Math
> and Physics. This has led me to use NumPy and SciPy to work on innumerable
> cases involving special polynomial functions and polynomials like Legendre
> polynomials, Bessel Functions and so on. So, The packages are closer known
> to me from this point of view. I have a* few proposals* in mind. But I
> don't have any idea if they are acceptable within the scope of GSoC
> 1. Many special functions and polynomials are neither included in NumPy nor
> on SciPy.. These include Ellipsoidal Harmonic Functions (lames function),
> Cylindrical Harmonic function. Scipy at present supports only spherical
> Harmonic function.

SciPy's spherical harmonics are very inefficient if one is only interested in
computing one specific order.  I'd be so happy if someone would work on that!

Stéfan

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Charles R Harris]

On Tue, Jan 21, 2014 at 9:46 AM, Charles R Harris  wrote:

>
>
>
> On Tue, Jan 21, 2014 at 9:26 AM, jennifer stone 
> wrote:
>
>>
>> >What are your interests and experience? If you use numpy, are there
>>> things
>>> >you would like to fix, or enhancements you would like to see?
>>>
>>> Chuck
>>>
>>>
>>  I am an undergraduate student with CS as major and have interest in Math
>> and Physics. This has led me to use NumPy and SciPy to work on innumerable
>> cases involving special polynomial functions and polynomials like Legendre
>> polynomials, Bessel Functions and so on. So, The packages are closer known
>> to me from this point of view. I have a* few proposals* in mind. But I
>> don't have any idea if they are acceptable within the scope of GSoC
>> 1. Many special functions and polynomials are neither included in NumPy
>> nor on SciPy.. These include Ellipsoidal Harmonic Functions (lames
>> function), Cylindrical Harmonic function. Scipy at present supports only
>> spherical Harmonic function.
>> Further, why cant we extend SciPy  to incorporate* Inverse Laplace
>> Transforms*? At present Matlab has this amazing function *ilaplace* and
>> SymPy does have *Inverse_Laplace_transform* but it would be better to
>> incorporate all in one package. I mean SciPy does have function to evaluate
>> laplace transform
>>
>> After having written this, I feel that this post should have been sent to
>> SciPy
>> but as a majority of contributors are the same I proceed.
>> Please suggest any other possible projects, as I would like to continue
>> with SciPy or NumPy, preferably NumPy as I have been fiddling with its
>> source code for a month now and so am pretty comfortable with it.
>>
>> As for my experience, I have known C for past 4 years and have been a
>> python lover for past 1 year. I am pretty new to open source communities,
>> started before a manth and a half.
>>
>>
> It does sound like scipy might be a better match, I don't think anyone
> would complain if you cross posted. Both scipy and numpy require GSOC
> candidates to have a pull request accepted as part of the application
> process. I'd suggest implementing a function not currently in scipy that
> you think would be useful. That would also help in finding a mentor for the
> summer. I'd also suggest getting familiar with cython.
>
>
I don't see you on github yet, are you there? If not, you should set up an
account to work in. See the developer guide
for some pointers.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Ralf Gommers]

On Tue, Jan 21, 2014 at 5:46 PM, Charles R Harris  wrote:

>
>
>
> On Tue, Jan 21, 2014 at 9:26 AM, jennifer stone 
> wrote:
>
>>
>> >What are your interests and experience? If you use numpy, are there
>>> things
>>> >you would like to fix, or enhancements you would like to see?
>>>
>>> Chuck
>>>
>>>
>>  I am an undergraduate student with CS as major and have interest in Math
>> and Physics. This has led me to use NumPy and SciPy to work on innumerable
>> cases involving special polynomial functions and polynomials like Legendre
>> polynomials, Bessel Functions and so on. So, The packages are closer known
>> to me from this point of view. I have a* few proposals* in mind. But I
>> don't have any idea if they are acceptable within the scope of GSoC
>> 1. Many special functions and polynomials are neither included in NumPy
>> nor on SciPy.. These include Ellipsoidal Harmonic Functions (lames
>> function), Cylindrical Harmonic function. Scipy at present supports only
>> spherical Harmonic function.
>>
>

> Further, why cant we extend SciPy  to incorporate* Inverse Laplace
>> Transforms*? At present Matlab has this amazing function *ilaplace* and
>> SymPy does have *Inverse_Laplace_transform* but it would be better to
>> incorporate all in one package. I mean SciPy does have function to evaluate
>> laplace transform
>>
>
Scipy doesn't have a function for the Laplace transform, it has only a
Laplace distribution in scipy.stats and a Laplace filter in scipy.ndimage.
An inverse Laplace transform would be very welcome I'd think - it has real
world applications, and there's no good implementation in any open source
library as far as I can tell. It's probably doable, but not the easiest
topic for a GSoC I think. From what I can find, the paper "Numerical
Transform Inversion Using Gaussian Quadrature" from den Iseger contains
what's considered the current state of the art algorithm. Browsing that
gives a reasonable idea of the difficulty of implementing `ilaplace`.


> After having written this, I feel that this post should have been sent to
>> SciPy
>> but as a majority of contributors are the same I proceed.
>> Please suggest any other possible projects,
>>
>
You can have a look at https://github.com/scipy/scipy/pull/2908/files for
ideas. Most of the things that need improving or we really think we should
have in Scipy are listed there. Possible topics are not restricted to that
list though - it's more important that you pick something you're interested
in and have the required background and coding skills for.

Cheers,
Ralf


as I would like to continue with SciPy or NumPy, preferably NumPy as I have
>> been fiddling with its source code for a month now and so am pretty
>> comfortable with it.
>>
>> As for my experience, I have known C for past 4 years and have been a
>> python lover for past 1 year. I am pretty new to open source communities,
>> started before a manth and a half.
>>
>>
> It does sound like scipy might be a better match, I don't think anyone
> would complain if you cross posted. Both scipy and numpy require GSOC
> candidates to have a pull request accepted as part of the application
> process. I'd suggest implementing a function not currently in scipy that
> you think would be useful. That would also help in finding a mentor for the
> summer. I'd also suggest getting familiar with cython.
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[jennifer stone]

Both scipy and numpy require GSOC

> candidates to have a pull request accepted as part of the application
> process. I'd suggest implementing a function not currently in scipy that
> you think would be useful. That would also help in finding a mentor for the
> summer. I'd also suggest getting familiar with cython.
>
> Chuck
>

Thanks a lot for the heads-up. I am yet to be familiarized with Cython and
it indeed is playing a crucial role especially in the 'special' module

>
> I don't see you on github yet, are you there? If not, you should set up an
> account to work in. See the developer guide
> for some pointers.
>
> Chuck
>
I am present on github but the profile at present is just a mark of humble
mistakes of a beginner to open-sourcing, The id is
https://github.com/jennystone.
I hope to build upon my profile.

Jennifer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[jennifer stone]

Scipy doesn't have a function for the Laplace transform, it has only a
> Laplace distribution in scipy.stats and a Laplace filter in scipy.ndimage.
> An inverse Laplace transform would be very welcome I'd think - it has real
> world applications, and there's no good implementation in any open source
> library as far as I can tell. It's probably doable, but not the easiest
> topic for a GSoC I think. From what I can find, the paper "Numerical
> Transform Inversion Using Gaussian Quadrature" from den Iseger contains
> what's considered the current state of the art algorithm. Browsing that
> gives a reasonable idea of the difficulty of implementing `ilaplace`.


A brief scanning through the paper "Numerical Transform Inversion Using
Gaussian Quadrature" from den Iseger does indicate the complexity of the
algorithm. But GSoC project or not, can't we work on it, step by step? As I
would love to see a contender for Matlab's ilaplace on open source front!!

>
> You can have a look at https://github.com/scipy/scipy/pull/2908/files for
> ideas. Most of the things that need improving or we really think we should
> have in Scipy are listed there. Possible topics are not restricted to that
> list though - it's more important that you pick something you're interested
> in and have the required background and coding skills for.
>

Thanks a lot for the roadmap. Of the options provided, I found the
'Cython'ization of Cluster great. Would it be possible to do it as the
Summer project if I spend the month learning Cython?

Regards
Janani



> Cheers,
> Ralf
>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Ralf Gommers]

On Thu, Jan 23, 2014 at 11:58 PM, jennifer stone
wrote:

>
>
>
>
> Scipy doesn't have a function for the Laplace transform, it has only a
>> Laplace distribution in scipy.stats and a Laplace filter in scipy.ndimage.
>> An inverse Laplace transform would be very welcome I'd think - it has real
>> world applications, and there's no good implementation in any open source
>> library as far as I can tell. It's probably doable, but not the easiest
>> topic for a GSoC I think. From what I can find, the paper "Numerical
>> Transform Inversion Using Gaussian Quadrature" from den Iseger contains
>> what's considered the current state of the art algorithm. Browsing that
>> gives a reasonable idea of the difficulty of implementing `ilaplace`.
>
>
> A brief scanning through the paper "Numerical Transform Inversion Using
> Gaussian Quadrature" from den Iseger does indicate the complexity of the
> algorithm. But GSoC project or not, can't we work on it, step by step? As I
> would love to see a contender for Matlab's ilaplace on open source front!!
>

Yes, it would be quite nice to have. So if you're interested, by all means
give it a go. An issue for a GSoC will be how to maximize the chance of
success - typically merging smaller PRs frequently helps a lot in that
respect, but we can't merge an ilaplace implementation step by step.


> You can have a look at https://github.com/scipy/scipy/pull/2908/files for
>> ideas. Most of the things that need improving or we really think we should
>> have in Scipy are listed there. Possible topics are not restricted to that
>> list though - it's more important that you pick something you're
>> interested
>> in and have the required background and coding skills for.
>>
>
> Thanks a lot for the roadmap. Of the options provided, I found the
> 'Cython'ization of Cluster great. Would it be possible to do it as the
> Summer project if I spend the month learning Cython?
>

There are a couple of things to consider. Your proposal should be neither
too easy nor too ambitious for one summer. Cythonizing cluster is probably
not enough for a full summer of work, especially if you can re-use some
Cython code that David WF or other people already have. So some new
functionality can be added to your proposal. The other important point is
that you need to find a mentor. Cluster is one of the smaller modules that
doesn't see a lot of development and most of the core devs may not know so
well. A good proposal may help find an interested mentor. I suggest you
start early with a draft proposal, and iterate a few times based on
feedback on this list.

You may want to have a look at your email client settings by the way, your
replies seem to start new threads.

Cheers,
Ralf


> Regards
> Janani
>
>
>
>> Cheers,
>> Ralf
>>
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Benjamin Root]

My vote is that NumPy is correct here. I see no reason why
>>> float('inf') / 1
and
>>> float('inf') // 1

should return different results.

Ben Root


On Thu, Sep 18, 2014 at 12:31 PM, Petr Viktorin  wrote:

> Hello,
> Over at Python-ideas, there is a thread [0] about the following
> discrepancy:
>
> >>> numpy.array(float('inf')) // 1
> inf
> >>> float('inf') // 1
> nan
>
> There are reasons for either result, but I believe it would be very
> nice if either Python or Numpy changed, so they would give the same
> value.
> If any of you have reasons to defend Numpy's (or Python's) choice, or
> otherwise want to chime in, please post there.
>
> Thanks,
> Petr Viktorin
>
>
> [0]
> https://mail.python.org/pipermail/python-ideas/2014-September/029365.html
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Chris Barker]

Well,

First of all, numpy and the python math module have a number of differences
when it comes to handling these kind of special cases -- and I think that:

1) numpy needs to do what makes the most sense for numpy and NOT mirror the
math lib.

2) the use-cases of the math lib and numpy are different, so they maybe
_should_ have different handling of this kind of thing.

3) I'm not sure that the core devs think these kinds of issues are "wrong"
'enough to break backward compatibility in subtle ways.

But it's a fun topic in any case, and maybe numpy's behavior could be
improved.

> My vote is that NumPy is correct here. I see no reason why
> >>> float('inf') / 1
> and
> >>> float('inf') // 1
>
> should return different results.
>

Well, one argument is that "floor division" is supposed to return an
integer value, and that inf is NOT an integer value. The integral part of
infinity doesn't exist and thus is Not a Number.

You also get some weird edge cases around the mod operator.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Jonathan Helmus]

On 09/18/2014 12:01 PM, Chris Barker wrote:

Well,

First of all, numpy and the python math module have a number of 
differences when it comes to handling these kind of special cases -- 
and I think that:


1) numpy needs to do what makes the most sense for numpy and NOT 
mirror the math lib.


2) the use-cases of the math lib and numpy are different, so they 
maybe _should_ have different handling of this kind of thing.


3) I'm not sure that the core devs think these kinds of issues are 
"wrong" 'enough to break backward compatibility in subtle ways.


But it's a fun topic in any case, and maybe numpy's behavior could be 
improved.


My vote is that NumPy is correct here. I see no reason why
>>> float('inf') / 1
and
>>> float('inf') // 1

should return different results.


Well, one argument is that "floor division" is supposed to return an 
integer value, and that inf is NOT an integer value. The integral part 
of infinity doesn't exist and thus is Not a Number.




But nan is not an integer value either:

>>> float('inf') // 1
nan
>>> int(float('inf') // 1)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: cannot convert float NaN to integer

Perhaps float('inf') // 1 should raise a ValueError directly since there 
is no proper way perform the floor division on infinity.


- Jonathan Helmus


You also get some weird edge cases around the mod operator.

-Chris

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Petr Viktorin]

On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus  wrote:
> On 09/18/2014 12:01 PM, Chris Barker wrote:
>
> Well,
>
> First of all, numpy and the python math module have a number of differences
> when it comes to handling these kind of special cases -- and I think that:
>
> 1) numpy needs to do what makes the most sense for numpy and NOT mirror the
> math lib.

Sure.

> 2) the use-cases of the math lib and numpy are different, so they maybe
> _should_ have different handling of this kind of thing.

If you have a reason for the difference, I'd like to hear it.

> 3) I'm not sure that the core devs think these kinds of issues are "wrong"
> 'enough to break backward compatibility in subtle ways.

I'd be perfectly fine with it being documented and tested (in CPython)
as either a design mistake or design choice.

> But it's a fun topic in any case, and maybe numpy's behavior could be
> improved.
>>
>> My vote is that NumPy is correct here. I see no reason why
>> >>> float('inf') / 1
>> and
>> >>> float('inf') // 1
>>
>> should return different results.
>
>
> Well, one argument is that "floor division" is supposed to return an integer
> value, and that inf is NOT an integer value. The integral part of infinity
> doesn't exist and thus is Not a Number.
>
>
> But nan is not an integer value either:
>
 float('inf') // 1
> nan
 int(float('inf') // 1)
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: cannot convert float NaN to integer
>
> Perhaps float('inf') // 1 should raise a ValueError directly since there is
> no proper way perform the floor division on infinity.

inf not even a *real* number; a lot of operations don't make
mathematical sense on it. But most are defined anyway, and quite
sanely.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Chris Barker]

On Thu, Sep 18, 2014 at 10:44 AM, Petr Viktorin  wrote:

> > 2) the use-cases of the math lib and numpy are different, so they maybe
> > _should_ have different handling of this kind of thing.
>
> If you have a reason for the difference, I'd like to hear it.


For one, numpy does array operations, and you really don't want a
ValueError (or any Exception) raised when perhaps only one value in a huge
array has an issue.

The other is that numpy users are potentially more sophisticated with
regard to numeric computing issues, and in any case, need to prioritize
different things -- like performance over safety.


> > But nan is not an integer value either:
>

I meant conceptually.

sure -- it's not any number at all -- a NaN can be arrived at many ways,
all it means something happened for which there was not an appropriate
numerical answer -- even inf or -inf. So, the question is:

is the integer part of inf infinity? or it undefined, and therefor NaN ?

I can't image a use case where it would matter, which is probably why numpy
returns inf.


> Perhaps float('inf') // 1 should raise a ValueError directly since there
> is
> > no proper way perform the floor division on infinity.
>

not in numpy  for sure -- but I don't see the point in the math lib either,
let the NaN propagate and deal with later if you need to -- that's what
they are for.


- Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Jonathan Helmus]

On 09/18/2014 12:44 PM, Petr Viktorin wrote:
> On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus  wrote:
>> On 09/18/2014 12:01 PM, Chris Barker wrote:
>>
>> Well,
>>
>> First of all, numpy and the python math module have a number of differences
>> when it comes to handling these kind of special cases -- and I think that:
>>
>> 1) numpy needs to do what makes the most sense for numpy and NOT mirror the
>> math lib.
> Sure.
>
>> 2) the use-cases of the math lib and numpy are different, so they maybe
>> _should_ have different handling of this kind of thing.
> If you have a reason for the difference, I'd like to hear it.
>
>> 3) I'm not sure that the core devs think these kinds of issues are "wrong"
>> 'enough to break backward compatibility in subtle ways.
> I'd be perfectly fine with it being documented and tested (in CPython)
> as either a design mistake or design choice.
>
>> But it's a fun topic in any case, and maybe numpy's behavior could be
>> improved.
>>> My vote is that NumPy is correct here. I see no reason why
>> float('inf') / 1
>>> and
>> float('inf') // 1
>>> should return different results.
>>
>> Well, one argument is that "floor division" is supposed to return an integer
>> value, and that inf is NOT an integer value. The integral part of infinity
>> doesn't exist and thus is Not a Number.
>>
>>
>> But nan is not an integer value either:
>>
> float('inf') // 1
>> nan
> int(float('inf') // 1)
>> Traceback (most recent call last):
>>File "", line 1, in 
>> ValueError: cannot convert float NaN to integer
>>
>> Perhaps float('inf') // 1 should raise a ValueError directly since there is
>> no proper way perform the floor division on infinity.
> inf not even a *real* number; a lot of operations don't make
> mathematical sense on it. But most are defined anyway, and quite
> sanely.

But in IEEE-754 inf is a valid floating point number (where-as NaN is 
not) and has well defined arithmetic, specifically inf / 1 == inf and 
RoundToIntergral(inf) == inf.  In the numpy example, the 
numpy.array(float('inf')) statement creates an array containing a 
float32 or float64 representation of inf.  After this I would expect a 
floor division to return inf since that is what IEEE-754 arithmetic 
specifies.

For me the question is if the floor division should also perform a cast 
to an integer type. Since inf cannot be represented in most common 
integer formats this should raise an exception.  Since // does not 
normally perform a cast, for example type(float(5) // 2) == float, the 
point is mute.

The real question is if Python floats follows IEEE-754 arithmetic or 
not.  If they do not what standard are they going to follow?

 - Jonathan Helmus
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Ian Henriksen]

On Thu, Sep 18, 2014 at 1:30 PM, Jonathan Helmus  wrote:

> On 09/18/2014 12:44 PM, Petr Viktorin wrote:
> > On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus 
> wrote:
> >> On 09/18/2014 12:01 PM, Chris Barker wrote:
> >>
> >> Well,
> >>
> >> First of all, numpy and the python math module have a number of
> differences
> >> when it comes to handling these kind of special cases -- and I think
> that:
> >>
> >> 1) numpy needs to do what makes the most sense for numpy and NOT mirror
> the
> >> math lib.
> > Sure.
> >
> >> 2) the use-cases of the math lib and numpy are different, so they maybe
> >> _should_ have different handling of this kind of thing.
> > If you have a reason for the difference, I'd like to hear it.
> >
> >> 3) I'm not sure that the core devs think these kinds of issues are
> "wrong"
> >> 'enough to break backward compatibility in subtle ways.
> > I'd be perfectly fine with it being documented and tested (in CPython)
> > as either a design mistake or design choice.
> >
> >> But it's a fun topic in any case, and maybe numpy's behavior could be
> >> improved.
> >>> My vote is that NumPy is correct here. I see no reason why
> >> float('inf') / 1
> >>> and
> >> float('inf') // 1
> >>> should return different results.
> >>
> >> Well, one argument is that "floor division" is supposed to return an
> integer
> >> value, and that inf is NOT an integer value. The integral part of
> infinity
> >> doesn't exist and thus is Not a Number.
> >>
> >>
> >> But nan is not an integer value either:
> >>
> > float('inf') // 1
> >> nan
> > int(float('inf') // 1)
> >> Traceback (most recent call last):
> >>File "", line 1, in 
> >> ValueError: cannot convert float NaN to integer
> >>
> >> Perhaps float('inf') // 1 should raise a ValueError directly since
> there is
> >> no proper way perform the floor division on infinity.
> > inf not even a *real* number; a lot of operations don't make
> > mathematical sense on it. But most are defined anyway, and quite
> > sanely.
>
> But in IEEE-754 inf is a valid floating point number (where-as NaN is
> not) and has well defined arithmetic, specifically inf / 1 == inf and
> RoundToIntergral(inf) == inf.  In the numpy example, the
> numpy.array(float('inf')) statement creates an array containing a
> float32 or float64 representation of inf.  After this I would expect a
> floor division to return inf since that is what IEEE-754 arithmetic
> specifies.
>
> For me the question is if the floor division should also perform a cast
> to an integer type. Since inf cannot be represented in most common
> integer formats this should raise an exception.  Since // does not
> normally perform a cast, for example type(float(5) // 2) == float, the
> point is mute.
>
> The real question is if Python floats follows IEEE-754 arithmetic or
> not.  If they do not what standard are they going to follow?
>
>  - Jonathan Helmus
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

Agreed. It's definitely best to follow the IEEE conventions. That will be
the most commonly expected behavior, especially in ambiguous cases like
this.
-Ian Henriksen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Sebastian Walter]

On Wed, May 13, 2009 at 10:18 PM, David J Strozzi  wrote:
> Hi,
>
> [You may want to edit the numpy homepage numpy.scipy.org to tell
> people they must subscribe to post, and adding a link to
> http://www.scipy.org/Mailing_Lists]
>
>
> Many of you probably know of the interpreter yorick by Dave Munro. As
> a Livermoron, I use it all the time.

Never heard of it... what does it do? By the sound of it, yorick is an
interpreted language like Python.

> There are some built-in
> functions there, analogous to but above and beyond numpy's sum() and
> diff(), which are quite useful for common operations on gridded data.
> Of course one can write their own, but maybe they should be cleanly
> canonized?
>
> For instance:
>
> x = linspace(0,10,10)
> y = sin(x)
>
> It is common, say when integrating y(x), to take "point-centered"
> data and want to zone-center it:
>
> I = sum(zcen(y)*diff(x))
>
> def zcen(x): return 0.5*(x[0:-1]+x[1:])
>
> Besides zcen, yorick has builtins for "point centering", "un-zone
> centering," etc.  Also, due to its slick syntax you can give these
> things as array "indexes":
>
> x(zcen), y(dif), z(:,sum,:)
>
>
> Just some thoughts,
> David Strozzi
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[David Cournapeau]

frank wang wrote:
> Hi,
>  
> In my work, I want to implement a fir filter with an input array.
> Since performing the filter on each input sample is slow, are there
> fast way to perform the fir filter operation?  Are there ways to
> convert input into an array and perform the array multipication?

look at scipy.signal.lfilter,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Greg Willden]

Hi Derek,
Like all Free & Open Source Software (FOSS) projects the license is
distributed with the source code.
There is a file called LICENSE.txt in the numpy tar archive.
Here are the contents of that file.

Copyright (c) 2005, NumPy Developers
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

   * Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

   * Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided
  with the distribution.

   * Neither the name of the NumPy Developers nor the names of any
  contributors may be used to endorse or promote products derived
  from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Greg

On 12/19/06, Bandler, Derek <[EMAIL PROTECTED]> wrote:


 Hi,

I would like to get information on the software licenses for numpy &
numeric.  On the sourceforge home for the packages, the listed license is
*OSI-Approved Open Source*.  Is it possible to get more information on
this?  A copy of the document would be useful.  Thank you.

Best regards,
Derek Bandler

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion






--
Linux.  Because rebooting is for adding hardware.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Robert Kern]

Bandler, Derek wrote:
> Hi,
> 
> I would like to get information on the software licenses for numpy &
> numeric.  On the sourceforge home for the packages, the listed license
> is _OSI-Approved Open Source_
> .  Is it possible to get
> more information on this?  A copy of the document would be useful. 
> Thank you.

They are both BSD-like licenses.

http://projects.scipy.org/scipy/numpy/browser/trunk/LICENSE.txt
http://projects.scipy.org/scipy/scipy/browser/trunk/LICENSE.txt

-- 
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
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Nadav Horesh]

It looks like you encountered a fundamental short come of numpy (or in fact any 
similar system like octave, matlab etc...): The dependence on values calculated 
in previous iteration can not vectorize easily. If you have an access to C 
compiler, I urge you to write (at least) the inner loop with pyrex  or a 
similar package that can easily link C code with numpy. It would help you a lot 
to realize these kind of algorithms with a reasonable execution time without 
loosing much of the python's benefits.

  Nadav


-Original Message-
From:   [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent:   Fri 16-Feb-07 18:34
To: numpy-discussion@scipy.org
Cc: 
Subject:[Numpy-discussion] (no subject)

Hi Nadav,

The code is attached at the end. There is probably still bugs in there
but it does not prevent me from showing the difficulty.

If you look at the inner loop below, you will see that vector v is
updated element by element. The new value of v[i] depends on the new
value of v[i-1] and the old value of v[i+1]. Updating an element
involves the new values of the already updated elements and the old
values of the rest of the elements that we have yet to update. This
makes vectorization difficult.


for i in range(1,N-1):
temp[i]=(1-w)*v[i]+w/D[i]*(q[i]-L[i-1]*v[i-1]-U[i]*v[i+1])
err += (temp[i]-v[i])**2
v[i]=temp[i]

Thanks,
Geoffrey

Complete code here;

def sor(v, L, D, U ,q, tol, w):
'''solve M*v=q. return v.
L, D, U are the sub-diagonal, diagonal, and super-diagonal of the
matrix M.

'''

err=999
N=D.shape[0] #number of elements
temp=empty(N)
while err> tol :
err=0
temp[0]=(1-w)*v[0]+w/D[0]*(q[0]-U[0]*v[1])
err += (temp[0]-v[0])**2
v[0]=temp[0]

for i in range(1,N-1):
temp[i]=(1-w)*v[i]+w/D[i]*(q[i]-L[i-1]*v[i-1]-U[i]*v[i+1])
err += (temp[i]-v[i])**2
v[i]=temp[i]

temp[N-1]=(1-w)*v[N-1]+w/D[N-1]*(q[N-1]-L[N-2]*v[N-2])
err += (temp[N-1]-v[N-1])**2
v[N-1]=temp[N-1]
return v
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nadav Horesh
Sent: Friday, February 16, 2007 8:52 AM
To: Discussion of Numerical Python
Subject: RE: [Numpy-discussion] Numpy and iterative procedures

At first glance it doesn't look hard to, at least, avoid looping over i,
by replacing [i] by [:-2], [i+1] by [1:-1] and [i+2] by [2:]. But I
might be wrong. Can you submit the piece of code with at least the most
internal loop?

   Nadav.

-Original Message-
From:   [EMAIL PROTECTED] on behalf of Geoffrey Zhu
Sent:   Thu 15-Feb-07 18:32
To: Discussion of Numerical Python
Cc: 
Subject:Re: [Numpy-discussion] Numpy and iterative procedures

Thanks Chuck.
 
I am trying to use Successive Over-relaxation to solve linear equations
defined by M*v=q. 
 
There are several goals:
 
1. Eventually (in production) I need it to be fast.
2. I am playing with the guts of the algorithm for now, to see how it
works. that means i need some control for now.
3. Even in production, there is a chance i'd like to have the ability to
tinker with the algorithm. 
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Charles R
Harris
Sent: Thursday, February 15, 2007 10:11 AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Numpy and iterative procedures





On 2/15/07, Geoffrey Zhu <[EMAIL PROTECTED]> wrote: 

Hi,

I am new to numpy. I'd like to know if it is possible to code efficient
iterative procedures with numpy.

Specifically, I have the following problem.

M is an N*N matrix. Q is a N*1 vector. V is an N*1 vector I am trying 
to 
find iteratively from the initial value V_0. The procedure is simply to
calculate

V_{n+1}[i]=3D1/M[I,i]*(q[i]-
(M[i,1]*v_{n+1}[1]+M[I,2]*v_{n+1}[2]+..+M[i,i-1]*v_{n+1}[i-1]) -
(M[I,i+1]*v_{n}[i+1]+M[I,i+2]*v_{n}[i+2]+..+M[I,N]*v_{n}[N])) 

I do not see that this is something that can esaily be vectorized, is
it?


I think it would be better if you stated what the actual problem is. Is
it a differential equation, for instance. That way we can determine what
the problem class is and what algorithms are available to solve it. 

Chuck



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Paul Hobson]

Saumyajit,

Numpy's source code is hosted on Github. You can find the contributing
guides there:
https://github.com/numpy/numpy/blob/master/CONTRIBUTING.md

-paul

On Tue, Apr 26, 2016 at 2:35 AM, Saumyajit Dey <
dsaumya...@student.nitw.ac.in> wrote:

> Hi,
>
> This is Saumyajit Dey and I am looking forward to start contributing to
> NumPy.
>
> I have never contributed to any open source projects before so I would
> want to know some tips and guidelines to start contributing.
>
> Regards,
> Saumyajit
>
> Saumyajit Dey
> Junior Undergraduate Student:
> Department of Computer Science and Engineering
> National Institute of Technology
> Warangal (NITW), India
> Cell: +91-8885847028
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Saumyajit Dey]

​Thanks a lot, Paul for the reply.

I will​ look into the contribution guidelines. Also could you please
suggest some good reading resources for getting to know more about NumPy.

Regards,
Saumyajit

Saumyajit Dey
Junior Undergraduate Student:
Department of Computer Science and Engineering
National Institute of Technology
Warangal (NITW), India
Cell: +91-8885847028

On Tue, Apr 26, 2016 at 9:35 PM, Paul Hobson  wrote:

> Saumyajit,
>
> Numpy's source code is hosted on Github. You can find the contributing
> guides there:
> https://github.com/numpy/numpy/blob/master/CONTRIBUTING.md
>
> -paul
>
> On Tue, Apr 26, 2016 at 2:35 AM, Saumyajit Dey <
> dsaumya...@student.nitw.ac.in> wrote:
>
>> Hi,
>>
>> This is Saumyajit Dey and I am looking forward to start contributing to
>> NumPy.
>>
>> I have never contributed to any open source projects before so I would
>> want to know some tips and guidelines to start contributing.
>>
>> Regards,
>> Saumyajit
>>
>> Saumyajit Dey
>> Junior Undergraduate Student:
>> Department of Computer Science and Engineering
>> National Institute of Technology
>> Warangal (NITW), India
>> Cell: +91-8885847028
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Maniteja Nandana]

Hi,

Welcome! It would be a good exercise to look at the documentation and
tutorial for Numpy at http://docs.scipy.org/doc/

Also the lectures at the lectures at www.scipy-lectures.org might be a
interesting introduction to scientific python in numpy stack.

Hope it helps.

Happy learning !

Cheers,
Maniteja.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Saumyajit Dey]

Hi,

Thanks a lot for the reply. I am looking into the documentation already.
Also is there any guide as to how the source code of Numpy is organised?

For example, when i write

np.power(2,3)


​what is the workflow in terms of functions in different modules being
called?​

​Regards,
Saumyajit​

Saumyajit Dey
Junior Undergraduate Student:
Department of Computer Science and Engineering
National Institute of Technology
Warangal (NITW), India
Cell: +91-8885847028

On Wed, Apr 27, 2016 at 6:05 PM, Maniteja Nandana <
maniteja.modesty...@gmail.com> wrote:

> Hi,
>
> Welcome! It would be a good exercise to look at the documentation and
> tutorial for Numpy at http://docs.scipy.org/doc/
>
> Also the lectures at the lectures at www.scipy-lectures.org might be a
> interesting introduction to scientific python in numpy stack.
>
> Hope it helps.
>
> Happy learning !
>
> Cheers,
> Maniteja.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Sebastian Berg]

On Mi, 2016-04-27 at 22:11 +0530, Saumyajit Dey wrote:
> Hi,
> 
> Thanks a lot for the reply. I am looking into the documentation
> already. Also is there any guide as to how the source code of Numpy
> is organised?
> 
> For example, when i write 
> 
> > np.power(2,3) 
> what is the workflow in terms of functions in different modules being
> called?
> 

No, there is not much. There are different paths/possibilities,
sometimes even intermingled. These are some:

1. Pure python functions, e.g. np.stack, np.delete, ...
   They are not hard to find/figure out (though some details may be),
   frankly, I usually just use the ?? magic in ipython.
2. Python shims for attributes, attributes usually go to the
   methods.c in numpy/core/src/multiarray
3. General C-Functions (Reshape, etc.) are usually in some specialized
   file in numpy/core/src/multiarray but wrapped by
   multiarraymodule.c, so you can backtrace from there. The exact calls
   can get pretty complex (even call back to python).
4. One important category (also tricky) are ufuncs. They form their own
   building block in the code base. The whole interplay of things is
   quite complex, so unless you need something specific I would be
   happy to understand all the things they can do for you and that
   they wrap C-functions working on a single axis in some sense.
   (code in numpy/core/src/umath)

Frankly, I often just "git grep ..." to find the right place to look
for something. It is not impossible to understand the logic behind the
files and what calls what, but I would claim it is usually faster to
grep for it if you are interested in something specific. There are some
more arcane things, such as code generations, but that is easier to ask
for/figure out for a specific problem. Things such as what happens when
a ufunc is called, and how the ufunc is created in the first place are
non-trivial.

NumPy has a few rather distinct building blocks. Ufuncs, the iterator,
general C-based shape/container functions, general python functions,
linear algebra, fft, polynoms, 

I would argue that finding something that interests you and trying to
figure that out and asking us about it explicitly is probably best.
Honestly, I think all of us devs have at least two things in the above
list we know almost nothing about. E.g. you don't need to understand
details of the FFT implementation unless you want to actually change
something there.

There are some "easy issues" marked in the git issue list, which may be
worth a shot if you like to just dive in. You could poke at one you
find interesting and then ask us (we might have tagged something as
"easy" but I would not guarantee all of them are, sometimes there are
unexpected difficulties or it is easy if you already know where to
look).

- Sebastian



> Regards,
> Saumyajit
> 
> Saumyajit Dey
> Junior Undergraduate Student:
> Department of Computer Science and Engineering
> National Institute of Technology
> Warangal (NITW), India
> Cell: +91-8885847028
> 
> On Wed, Apr 27, 2016 at 6:05 PM, Maniteja Nandana <
> maniteja.modesty...@gmail.com> wrote:
> > Hi,
> > Welcome! It would be a good exercise to look at the documentation
> > and tutorial for Numpy at http://docs.scipy.org/doc/
> > Also the lectures at the lectures at www.scipy-lectures.org might
> > be a interesting introduction to scientific python in numpy stack.
> > Hope it helps.
> > Happy learning !
> > Cheers,
> > Maniteja.
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > 
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion