Matthew Brett | 31 Oct 08:16 2014
Picon

ndimage reflect mode

Hi,

Sorry if this is a dumb question, but I just noticed some behavior of
scipy.ndimage that surprised me:

In [63]: oned = np.arange(1, 10, dtype=float)
In [64]: scipy.ndimage.affine_transform(oned, [1], [-2], mode='reflect')
Out[64]: array([ 2.,  1.,  1.,  2.,  3.,  4.,  5.,  6.,  7.])

OK so far.  But this I was surprised by:

In [68]: scipy.ndimage.affine_transform(oned, [1], [-2 - 1e-15], mode='reflect')
Out[68]: array([ 2.,  1.,  2.,  2.,  3.,  4.,  5.,  6.,  7.])

Why did the third value turn from a 1 into a 2?  I am missing something obvious?

Matthew
Fernando Perez | 28 Oct 19:09 2014
Picon

[ANN] Python for Scientific Computing conference in Boulder, CO; April'15

Hi folks,

a colleague from NCAR in Boulder just sent me this link about a conference they are organizing in the spring:


I figured this might be of interest to many on these lists.  The actual call isn't up yet, so if you're interested, watch that site for an upcoming call when they post it (I'm not directly involved, just passing the message along).

Cheers

f

--
Fernando Perez ( <at> fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Yuxiang Wang | 28 Oct 02:48 2014

Documentation page on API

(Sorry about sending this to the wrong list, scipy-user instead of
scipy-dev, before; apologize to those who saw this twice)

Hi all,

I was reading through the link
(http://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing-functions-from-scipy)
and it mentioned that the first form is
preferred over the second one under most circumstances:

# first form
from scipy import stats
stats.lomax(...)

# second form
from scipy.stats import distributions
distributions.lomax(...)

I honestly think the second form is far more frequently used in the
examples given in the document, for example:

http://docs.scipy.org/doc/scipy/reference/tutorial/special.html
http://docs.scipy.org/doc/scipy/reference/tutorial/integrate.html
http://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html
http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html
http://docs.scipy.org/doc/scipy/reference/tutorial/fftpack.html

Would you think it'd be better to update this link?

-Shawn
Sturla Molden | 27 Oct 00:32 2014
Picon

Travis?

I posted a WIP PR to SciPy but there is no Travis build.

https://github.com/scipy/scipy/pull/4104

Do we use Travis on SciPy?

(I should remember, but I don't.)

Sturla
Robert Lucente - Pipeline | 21 Oct 03:47 2014
Picon

thLib

Other Python signal processing resources that might be of interest

1)	Python for Signal Processing by Unpingco, José
2)	Gavish, Noam (https://github.com/noamg/signal_processing)
3)	Think DSP by Allen B Downey
(http://greenteapress.com/thinkdsp/index.html)

-----Original Message-----
From: scipy-dev-bounces <at> scipy.org [mailto:scipy-dev-bounces <at> scipy.org] On
Behalf Of scipy-dev-request <at> scipy.org
Sent: Monday, October 20, 2014 1:00 PM
To: scipy-dev <at> scipy.org
Subject: SciPy-Dev Digest, Vol 132, Issue 23

Send SciPy-Dev mailing list submissions to
	scipy-dev <at> scipy.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mail.scipy.org/mailman/listinfo/scipy-dev
or, via email, send a message with subject or body 'help' to
	scipy-dev-request <at> scipy.org

You can reach the person managing the list at
	scipy-dev-owner <at> scipy.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of SciPy-Dev digest..."

Today's Topics:

   1. thLib (Haslwanter Thomas)
   2. extended scipy.sparse.linalg LinearOperator interface
      (Lars Buitinck)

----------------------------------------------------------------------

Message: 1
Date: Sun, 19 Oct 2014 22:15:12 +0200
From: Haslwanter Thomas <Thomas.Haslwanter <at> fh-linz.at>
Subject: [SciPy-Dev] thLib
To: "scipy-dev <at> scipy.org" <scipy-dev <at> scipy.org>
Message-ID:
	
<1CFD8CBC30E0454B9DFAADEB36AD1739B05CE50D2B <at> LNZEXCHANGE001.linz.fhooe.at>
	
Content-Type: text/plain; charset="us-ascii"

Over the last few years, I have created a collection of tools that comprise
functions for

-          Working with quaternions and rotation matrices

-          Analyzing signals from inertial sensors and video systems

-          Working with sound

-          Signal processing

-          Interactive data analysis

They are available from pypi as the package "thLib".
More info is available under http://work.thaslwanter.at/thLib/html/

I would be grateful for any kind of feedback.

Thomas Haslwanter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.scipy.org/pipermail/scipy-dev/attachments/20141019/ca88b148/atta
chment-0001.html 

------------------------------

Message: 2
Date: Mon, 20 Oct 2014 17:53:36 +0200
From: Lars Buitinck <larsmans <at> gmail.com>
Subject: [SciPy-Dev] extended scipy.sparse.linalg LinearOperator
	interface
To: scipy-dev <at> scipy.org
Message-ID:
	<CAKz-xUcZxf2Zd2T+_qykycoBbNMLGrA5rpEAXnL4ZMbNw2izQg <at> mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi all,

[TL;DR I want to extend scipy.sparse.linalg.LinearOperator and I'm looking
for current usage patterns.]

To solve a few problems that I and others [1,2] encountered with the
scipy.sparse.linalg LinearOperator interface, I decided to expand and
refactor it. In a nutshell:

* Linear operators cannot be transposed. They do have an rmatvec that
implements A^H * x, but no matrix-matrix multiplication version of same, so
this has be implemented as a loop.
* While a lot of subclasses exist in various parts of scipy.sparse.linalg,
there was no documentation on how to roll your own operator by subclassing.
Instead you have to call the constructor with a few functions, which become
the methods on the custom operator.
This doesn't scale if we want to add more methods.
* The current implementation uses monkey-patching, causing memory leaks due
to reference cycles and making the code hard to read.

I've already submitted an early PR [3] with the main parts of my proposal:

* LinearOperator is now an abstract base class. An overloaded __new__ makes
sure you can still call the constructor with the old calling conventions; it
returns a subclass.
* Subclassing is possible (and documented): you must provide a method
_matvec and optionally a few more. These get used to implement the public
matvec method, which uses _matvec but adds input validation boilerplate (the
"template method pattern").
* An "adjoint" method is added, and can be overridden by supplying an
_adjoint method, to return the Hermitian adjoint (conjugate transpose) of a
linear operator. This obviates the need for an rmatmat method.

There's been discussion lately about merging in parts of PyOperators.
I decided not to wait for this to happen, but I did have a look at their
documentation and used some API conventions to make a later merge easier (or
at least be compatible).

I'd like feedback on this, and especially on the issue of backward
compatibility with the current code. In particular, I'm not sure if the
possibility to subclass LinearOperator has ever been advertised and/or
exploited in third-party code. If it was, then we have to deal with that.

To be sure, the currently common idioms to construct a linear operator,

    A = aslinearoperator(X)  # ndarray or sparse matrix X

and

    A = LinearOperator(matvec=some_callable, shape=some_tuple)

still work and all current tests still pass.

So I'd like to ask you:

* Is my proposal useful?
* How was this API used in third-party code?

TIA,
Lars

[1] https://github.com/scipy/scipy/pull/4073
[2] https://github.com/scipy/scipy/pull/4074
[3] https://github.com/scipy/scipy/pull/4087

------------------------------

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev

End of SciPy-Dev Digest, Vol 132, Issue 23
******************************************
Lars Buitinck | 20 Oct 17:53 2014
Picon

extended scipy.sparse.linalg LinearOperator interface

Hi all,

[TL;DR I want to extend scipy.sparse.linalg.LinearOperator and I'm
looking for current usage patterns.]

To solve a few problems that I and others [1,2] encountered with the
scipy.sparse.linalg LinearOperator interface, I decided to expand and
refactor it. In a nutshell:

* Linear operators cannot be transposed. They do have an rmatvec that
implements A^H * x, but no matrix-matrix multiplication version of
same, so this has be implemented as a loop.
* While a lot of subclasses exist in various parts of
scipy.sparse.linalg, there was no documentation on how to roll your
own operator by subclassing. Instead you have to call the constructor
with a few functions, which become the methods on the custom operator.
This doesn't scale if we want to add more methods.
* The current implementation uses monkey-patching, causing memory
leaks due to reference cycles and making the code hard to read.

I've already submitted an early PR [3] with the main parts of my proposal:

* LinearOperator is now an abstract base class. An overloaded __new__
makes sure you can still call the constructor with the old calling
conventions; it returns a subclass.
* Subclassing is possible (and documented): you must provide a method
_matvec and optionally a few more. These get used to implement the
public matvec method, which uses _matvec but adds input validation
boilerplate (the "template method pattern").
* An "adjoint" method is added, and can be overridden by supplying an
_adjoint method, to return the Hermitian adjoint (conjugate transpose)
of a linear operator. This obviates the need for an rmatmat method.

There's been discussion lately about merging in parts of PyOperators.
I decided not to wait for this to happen, but I did have a look at
their documentation and used some API conventions to make a later
merge easier (or at least be compatible).

I'd like feedback on this, and especially on the issue of backward
compatibility with the current code. In particular, I'm not sure if
the possibility to subclass LinearOperator has ever been advertised
and/or exploited in third-party code. If it was, then we have to deal
with that.

To be sure, the currently common idioms to construct a linear operator,

    A = aslinearoperator(X)  # ndarray or sparse matrix X

and

    A = LinearOperator(matvec=some_callable, shape=some_tuple)

still work and all current tests still pass.

So I'd like to ask you:

* Is my proposal useful?
* How was this API used in third-party code?

TIA,
Lars

[1] https://github.com/scipy/scipy/pull/4073
[2] https://github.com/scipy/scipy/pull/4074
[3] https://github.com/scipy/scipy/pull/4087
Haslwanter Thomas | 19 Oct 22:15 2014
Picon

thLib

Over the last few years, I have created a collection of tools that comprise functions for

 

-          Working with quaternions and rotation matrices

-          Analyzing signals from inertial sensors and video systems

-          Working with sound

-          Signal processing

-          Interactive data analysis

 

They are available from pypi as the package “thLib”.

More info is available under http://work.thaslwanter.at/thLib/html/

 

I would be grateful for any kind of feedback.

 

Thomas Haslwanter

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Noam Gavish | 18 Oct 23:35 2014
Picon

Advice on an open source signal processing package

Hey,


I'm an Israeli undergrad student, new to the open source community. I've noted that Scipy might benefit from a solid signal processing toolbox, and have began writing one.
The package presents a natural interface for signals, and simplifies signal processing code.

This package emerged from research in the LEIsec lab in Tel-Aviv University and is supposed to be a one stop shop for DSP in python. I think that as the module matures, if adoption is positive, it can possibly become part of SciPy.

Your advice about the API, design, existing python signal processing resources, and roadmap for this module would be sincerely appreciated.
(Note that the inner implementation at the moment is basic, until the interface is decided)

source: https://github.com/noamg/signal_processing
ipython notebook example:  http://nbviewer.ipython.org/github/noamg/signal_processing/blob/master/code_examples/find_pulses.ipynb

Best,
Noam Gavish

--

- - -
If you walk the footsteps of a stranger
You will learn things you never knew you never knew
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Nils Wagner | 12 Oct 18:39 2014

make latex failure


Attachment (scipy-ref.log.gz): application/x-gzip, 128 KiB
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Robert Lucente - Pipeline | 12 Oct 00:03 2014
Picon

Re: scipy.optimize.anneal - deprecation

Did not hear back. Not sure how to interpret that. Would really like to know why anneal was deprecated and why recommend basin hopping which won’t apply for discrete optimization. I realize that simulated annealing requires a lot of tweeking.

 

From: Robert Lucente - Pipeline [mailto:rlucente <at> pipeline.com]
Sent: Tuesday, September 30, 2014 9:45 PM
To: 'scipy-dev <at> scipy.org'
Cc: Robert Gmail Backup 1 Lucente Gmail Backup 1 (robert.backup.lucente <at> gmail.com)
Subject: scipy.optimize.anneal - deprecation

 

Hi everyone,

 

I am a newbie to open source and so I am not sure what the appropriate tribal norms are. So, if the “To” emailing is too broad, I apologize ahead of time. Please let me know if there is a more appropriate mailing list.

 

I am also a newbie to Python. I haven’t gotten much past the hello world stage.

 

However, as I am poking around, simulated annealing got my attention because of a project that I am tangentially involved w/. As usual, I love “open source” because well, it is open. I can look at code and know exactly what is going on.

I was surprised to learn that scipy.optimize.anneal is being deprecated. It is a “standard” mathematical optimization technique which is used. Also, there is a decent amount of literature on it. For some references, refer to the blog “Simulated Annealing (SA) for Mathematical Optimization.” The recommendation seems to be to use basinhopping. Unfortunately, it assumes “smooth scalar function”. Unfortunately, this smoothness does not apply in my case.

I am sure that the deprecation of anneal was given a lot of thought. Is that documented anywhere or would someone be willing to share why it was deprecated?

 

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
Sturla Molden | 11 Oct 14:53 2014
Picon

Use vecLibFort instead of Accelerate?

There is a library called vecLibFort that re-exports all the BLAS and
LAPACK symbols in Accelerate with gfortran ABI:

https://github.com/mcg1969/vecLibFort

For scipy.linalg vecLibFort would solve several issues:

- Special wrappers for Accelerate would no longer be needed and can be
removed from the source.

- For the new Cython layer, the fortranname bug in f2py would go away – the
wrappers are no longer needed.

- The sgemv AVX segfault in Mavericks is corrected for by calling sgemm
when data are not 32 byte aligned.

Sturla

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev <at> scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev

Gmane