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

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)

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

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

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

[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 encu...@gmail.com 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/ORR(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 stdin, line 1, in module
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/ORR(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 mailto: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 jjhel...@gmail.com 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 stdin, line 1, in module
 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 encu...@gmail.com 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/ORR(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 jjhel...@gmail.com 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 stdin, line 1, in module
 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 jjhel...@gmail.com wrote:

 On 09/18/2014 12:44 PM, Petr Viktorin wrote:
  On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus jjhel...@gmail.com
 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 stdin, line 1, in module
  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)

[Ralf Gommers]

On Thu, Jan 23, 2014 at 11:58 PM, jennifer stone
jenny.stone...@gmail.comwrote:





 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)

[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
 http://docs.scipy.org/doc/numpy/dev/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 Tue, Jan 21, 2014 at 5:46 PM, Charles R Harris charlesr.har...@gmail.com
 wrote:




 On Tue, Jan 21, 2014 at 9:26 AM, jennifer stone 
 jenny.stone...@gmail.comwrote:


 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]

 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 jenny.stone...@gmail.comwrote:


 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 charlesr.har...@gmail.com
 wrote:




 On Tue, Jan 21, 2014 at 9:26 AM, jennifer stone 
 jenny.stone...@gmail.comwrote:


 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
http://docs.scipy.org/doc/numpy/dev/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)

[Charles R Harris]

Hi Jennifer,


On Sat, Jan 18, 2014 at 11:48 AM, jennifer stone
jenny.stone...@gmail.comwrote:

 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)

[Matthew Brett]

Hi,

Thanks both - very helpful,

Matthew

On 11/22/13, Robert Kern robert.k...@gmail.com wrote:
 On Fri, Nov 22, 2013 at 9:23 PM, Matthew Brett matthew.br...@gmail.com
 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)

[Warren Weckesser]

On Fri, Nov 22, 2013 at 4:23 PM, Matthew Brett matthew.br...@gmail.comwrote:

 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 matthew.br...@gmail.com
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)

[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 t...@cerazone.net 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)

[eat]

Hi,

On Fri, Apr 20, 2012 at 9:15 PM, Andre Martel soucoupevola...@yahoo.comwrote:

 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)

[Tony Yu]

On Fri, Apr 20, 2012 at 2:15 PM, Andre Martel soucoupevola...@yahoo.comwrote:

 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)

[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 boogalo...@yahoo.fr 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 markflorisso...@gmail.comwrote:

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

 On 6 April 2012 12:41, Jean-Baptiste Rudant boogalo...@yahoo.fr 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)

[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 silid...@gmail.com 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)

[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 valentin.hae...@epfl.ch

 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 sh...@keba.be [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)

[Olivier Delalleau]

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

-=- Olivier

2011/10/3 Alex Ter-Sarkissov ater1...@gmail.com

 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)

[Till Stensitzki]

Alex Ter-Sarkissov ater1980 at 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 at 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 ater1...@gmail.comwrote:

 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)

[Skipper Seabold]

On Wed, Mar 2, 2011 at 5:25 PM, Alex Ter-Sarkissov ater1...@gmail.com 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 ater1...@gmail.com 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)

[Sebastian Walter]

On Wed, May 13, 2009 at 10:18 PM, David J Strozzi stroz...@llnl.gov 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)

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

[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.
license
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.
/license

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_
 file:///softwaremap/trove_list.php?form_cat=14.  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