[Numpy-discussion] f2py and Fortran STOP statement issue

2013-11-20 Thread Pearu Peterson 
Hi,

The issue with wrapping Fortran codes that contain STOP statements has been
raised several times in past with no good working solution proposed.

Recently the issue was raised again in f2py issues. Since the user was
filling to test out few ideas with positive results, I decided to describe
the outcome (a working solution) in the following wikipage:

  https://code.google.com/p/f2py/wiki/FAQ2ed

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

Re: [Numpy-discussion] strange runtimes of numpy fft

2013-11-20 Thread Henry Gomersall 
On 20/11/13 19:56, Chris Barker wrote:
> On Wed, Nov 20, 2013 at 3:06 AM, Henry Gomersall  > wrote:
>
> Yes, this didn't occur to me as an option, mostly because I'm keen for a
> commercial FFTW license myself and it would gall me somewhat if I
> couldn't gain the same benefit from my own code as others.
>
> So, given that, if anyone has an FFTW license and is keen for decent
> Python wrappers, I'd be more than happy to discuss a sub-license to FFTW
> in exchange for a more liberal (say MIT) license for pyFFTW.
>
>
>
> OT, and IANAL, but  I think what you'd want to do is dual-licence
> pyFFTW. Heck, you could even charge for a commercially-licenced version,
> as it would only be useful to folks that were already paying for
> a commercially-licenced FFTW

Apologies for the continued OT... I _have_ considered a commercial 
license, but so far, no knowledge of who might be interested. Again, not 
being a lawyer, I'm not even sure if this is clear cut and I can do it 
without a license myself (I think the GPL gets very confusing when it 
comes to runtime linking with some implementation of a published API, 
and interpreted languages make it even more so).

So, I'll put this out there, if anyone has a need for python wrappers 
for a commercial FFTW, please get in touch. All options considered. :)

Cheers,

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

Re: [Numpy-discussion] strange runtimes of numpy fft

2013-11-20 Thread Chris Barker 
On Wed, Nov 20, 2013 at 3:06 AM, Henry Gomersall  wrote:

> Yes, this didn't occur to me as an option, mostly because I'm keen for a
>  commercial FFTW license myself and it would gall me somewhat if I
> couldn't gain the same benefit from my own code as others.
>
> So, given that, if anyone has an FFTW license and is keen for decent
> Python wrappers, I'd be more than happy to discuss a sub-license to FFTW
> in exchange for a more liberal (say MIT) license for pyFFTW.
>


OT, and IANAL, but  I think what you'd want to do is dual-licence pyFFTW.
Heck, you could even charge for a commercially-licenced version, as it
would only be useful to folks that were already paying for
a commercially-licenced FFTW

-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] ANN: Bokeh 0.3 released

2013-11-20 Thread Bryan Van de Ven 
I am pleased to announce the release of Bokeh 0.3! Bokeh is a Python 
interactive visualization library for large datasets that natively uses the 
latest web technologies. Its goal is to provide elegant, concise construction 
of novel graphics in the style of Protovis/D3, while delivering 
high-performance interactivity over large data to thin clients.

If you are using Anaconda, you can install through conda:

conda install bokeh

Alternatively you can install from PyPI using pip:

pip install bokeh

This release was largely an internal refactor to merge the BokehJS and Bokeh 
projects into one repository, and to greatly improve and simplify the BokehJS 
coffee script build process. Additionally, this release also includes a number 
of bug and stability fixes, and some enhancements. See the CHANGELOG for full 
details. 

Many new examples were added including a reproduction of Burtin's Antibiotics, 
and examples of animation using the Bokeh plot server inside IPython notebooks. 
ColorBrewer palettes were also added on the python side. Finally, the user 
guide has been flushed out and will continually be updated as features and API 
changes are made. Check out the full documentation and interactive gallery at

http://bokeh.pydata.org

The release of Bokeh 0.4 is planned for early January. Some notable features to 
be included are:

* Integrate Abstract Rendering into bokeh server
* Better grid-based layout system; use Cassowary.js for layout solver
* Tool Improvements (pan always on, box zoom always on, passive resize with hot 
corners)
* Basic MPL compatibility interface (enough to make ggplot.py work)
* Expose image plot in Python interface

Issues or enhancement requests can be logged on the Bokeh Github page: 
https://github.com/continuumio/bokeh

Questions can be directed to the Bokeh mailing list: bo...@continuum.io

Regards, 

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

Re: [Numpy-discussion] RuntimeWarning raised in the wrong line

2013-11-20 Thread Benjamin Root 
On Wed, Nov 20, 2013 at 9:09 AM, Daπid  wrote:

> I have the following code, operating on some arrays.
>
> pen = 1 - (real_sum[int(i1 + t)]) / (absolute[int(i1 + t)])
> if np.isnan(pen):
> pen = 0.0
>
> I know that, sometimes, real_sum and absolute are 0 at the designated
> point, so I should get a RuntimeWarning. But, the warning is puzzling:
>
> RuntimeWarning: invalid value encountered in double_scalars
>   pen = 0.0
>
> Is the warning actually being raised at that point? Or can I not really
> trust the line reported by the warning? I have tried to replicate it in
> interactive terminal, but without luck, I always get it in the previous
> line.
>
>
> I am using Python 2.7 and Numpy 1.8.0.
>
>
> /David.
>
>
This can sometimes happen in very weird edge cases of development
workflows. Essentially, if one edits the source code while the module is
still loaded in the python session, the line numbers recorded in the *.pyc
files diverge from the source code. The warning that is emitted checks the
source code at that time to print out the relevant line. Maybe that might
explain what is happening here?

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

[Numpy-discussion] RuntimeWarning raised in the wrong line

2013-11-20 Thread Daπid 
I have the following code, operating on some arrays.

pen = 1 - (real_sum[int(i1 + t)]) / (absolute[int(i1 + t)])
if np.isnan(pen):
pen = 0.0

I know that, sometimes, real_sum and absolute are 0 at the designated
point, so I should get a RuntimeWarning. But, the warning is puzzling:

RuntimeWarning: invalid value encountered in double_scalars
  pen = 0.0

Is the warning actually being raised at that point? Or can I not really
trust the line reported by the warning? I have tried to replicate it in
interactive terminal, but without luck, I always get it in the previous
line.


I am using Python 2.7 and Numpy 1.8.0.


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

Re: [Numpy-discussion] strange runtimes of numpy fft

2013-11-20 Thread Henry Gomersall 
On 19/11/13 17:52, Nathaniel Smith wrote:
> On Tue, Nov 19, 2013 at 9:17 AM, Henry Gomersall  wrote:
>> >On 19/11/13 16:08, Stéfan van der Walt wrote:
>>> >>On Tue, Nov 19, 2013 at 6:03 PM, Henry Gomersall   wrote:
> >>> >However, FFTW is dual licensed GPL/commercial and so the wrappers are
> >>> >also GPL by necessity.
>>> >>I'm not sure if that is true, strictly speaking--you may license your
>>> >>wrapper code under any license you wish.  It's just that it becomes
>>> >>confusing when the combined work then has to be released under GPL.
>> >
>> >This is on shaky GPL ground. I'm inclined to agree with you, but given
>> >any usage necessarily has to link against the FFTW libs, any resultant
>> >redistribution is going to be GPL by necessity. I.e. pyFFTW is useless
>> >without FFTW so it's just simpler to make it GPL for the time being.
> The case where it makes a difference is when someone has purchased a
> commercial license to FFTW and then wants to use it from their
> proprietary Python application.

Yes, this didn't occur to me as an option, mostly because I'm keen for a 
commercial FFTW license myself and it would gall me somewhat if I 
couldn't gain the same benefit from my own code as others.

So, given that, if anyone has an FFTW license and is keen for decent 
Python wrappers, I'd be more than happy to discuss a sub-license to FFTW 
in exchange for a more liberal (say MIT) license for pyFFTW.

Cheers,

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