Re: [Numpy-discussion] Interface numpy arrays to Matlab?

2017-08-28 Thread Gregory Lee 
I have not used Transplant, but it sounds fairly similar to
Python-matlab-bridge.  We currently optionally call Matlab via
Python-matlab-bridge in some of the the tests for the PyWavelets package.

https://arokem.github.io/python-matlab-bridge/
https://github.com/arokem/python-matlab-bridge

I would be interested in hearing about the benefits/drawbacks relative to
Transplant if there is anyone who has used both.


On Mon, Aug 28, 2017 at 4:29 PM, CJ Carey  wrote:

> Looks like Transplant can handle this use-case.
>
> Blog post: http://bastibe.de/2015-11-03-matlab-engine-performance.html
> GitHub link: https://github.com/bastibe/transplant
>
> I haven't given it a try myself, but it looks promising.
>
> On Mon, Aug 28, 2017 at 4:21 PM, Stephan Hoyer  wrote:
>
>> If you can use Octave instead of Matlab, I've had a very good experience
>> with Oct2Py:
>> https://github.com/blink1073/oct2py
>>
>> On Mon, Aug 28, 2017 at 12:20 PM, Neal Becker 
>> wrote:
>>
>>> I've searched but haven't found any decent answer.  I need to call
>>> Matlab from python.  Matlab has a python module for this purpose, but it
>>> doesn't understand numpy AFAICT.  What solutions are there for efficiently
>>> interfacing numpy arrays to Matlab?
>>>
>>> Thanks,
>>> Neal
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.17.2 release.

2019-09-05 Thread Gregory Lee 
Hi Chuck,

It is not critical, but it would be nice if the fft ZeroDivisionError fix
in https://github.com/numpy/numpy/pull/14279 could make it into 1.17.2. It
has an "approved" review and seems to be ready.
Thanks!

Greg

On Thu, Sep 5, 2019 at 6:56 PM Charles R Harris 
wrote:

> Hi All,
>
> I'm planning to make a 1.17.2 release Friday or Saturday in order to fix
> some newly reported regressions. If there is anything that you think
> absolutely needs to be in that release, please yell.
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Good use of __dunder__ methods in numpy

2020-03-05 Thread Gregory Lee 
On Thu, Mar 5, 2020 at 2:01 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Ah thank you for info, yes i'm talking about normal methods.
> If i can get a link to a file that shows how dunder methods help with
> having cool coding APIs that would be great!
>
> Thanks!
>
>
> Yours,
>
> Abdur-Rahmaan Janhangeer
> pythonmembers.club  | github
> 
> Mauritius
>
>
You may want to take a look at PEP 465 as an example, then. If I recall
correctly, the __matmul__ method described in it was added to the standard
library largely with NumPy in mind.
https://www.python.org/dev/peps/pep-0465/




>
> On Thu, Mar 5, 2020 at 10:32 PM Sebastian Berg 
> wrote:
>
>> Hi,
>>
>> On Thu, 2020-03-05 at 11:14 +0400, Abdur-Rahmaan Janhangeer wrote:
>> > Greetings list,
>> >
>> > I have a talk about dunder methods in Python
>> >
>> > (
>> > https://conference.mscc.mu/speaker/67604187-57c3-4be6-987c-ea4bef388ad3
>> > )
>> >
>> > and it would be nice to include Numpy in the mix. Can someone point
>> > me to one or two use cases / file link where dunder methods help
>> > numpy?
>> >
>>
>> I am not sure in what sense you are looking for. NumPy has its own set
>> of dunder methods (some of which should not be used super much
>> probably), like `__array__`, `__array_interface__`, `__array_ufunc__`,
>> `__array_function__`, `__array_finalize__`, ...
>> So we are using `__array_*__` for numpy related dunders.
>>
>> Of course we use most Python defined dunders, but I am not sure that
>> you are looking for that?
>>
>> Best,
>>
>> Sebastian
>>
>>
>> > Thanks
>> >
>> > fun info: i am a tiny numpy contributor with a one line merge.
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)

2020-06-24 Thread Gregory Lee 
norm='forward' is my preference out of the names suggested so far. The
option seems reasonable and should be pretty low maintenance to add.

For SciPy, we would probably be willing to make the corresponding changes
in the scipy.fft module (but probably not in the outdated scipy.fftpack
module).


On Wed, Jun 24, 2020 at 1:38 PM Ross Barnowski  wrote:

> I think it's also important to get the thoughts of the SciPy community on
> this topic so that we avoid divergence between numpy.fft and scipy.fft. I
> would recommend sending this discussion to the scipy mailing list as well.
>
> ~Ross
>
> On Tue, Jun 23, 2020 at 4:11 PM Feng Yu  wrote:
>
>> Your approach sounds good to me.
>>
>> Thanks,
>>
>> Yu
>>
>> On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <
>> cv1...@wildcats.unh.edu> wrote:
>>
>>> Chris Vavaliaris wrote
>>> > Hello,
>>> >
>>> > - my first reaction would be that the less argument names we change at
>>> a
>>> > time the better, so that we don't confuse people or cause codes written
>>> > with
>>> > previous NumPy versions to break. Personally I always think of "ortho"
>>> as
>>> > "orthonormal", which immediately brings "unit norm" to mind, but I
>>> have no
>>> > problem whatsoever with changing its name to "unitary" or maybe "unit",
>>> > which I'd probably choose if we were writing the routines from
>>> scratch.
>>> >
>>> > - In terms of the "inverse" name option, I do believe that it'd be a
>>> > confusing choice since "inverse" is used to describe the inverse FFT;
>>> if
>>> > we
>>> > choose to stick with a name that's based on the fact that this scaling
>>> is
>>> > opposite to the "norm=None" option, then I'd suggest "norm=opposite"
>>> as a
>>> > better choice. However, following Ross' comment, I think we could
>>> choose a
>>> > name based on the fact that the forward transform is now scaled by `n`,
>>> > instead of the backward one as in the default "norm=None". In this
>>> case,
>>> > I'd
>>> > suggest "norm=forward", which we can also nicely abbreviate to the
>>> > 4-character form "norm=forw" if desirable.
>>> >
>>> > Chris
>>> >
>>> >
>>> > Feng Yu wrote
>>> >> Hi,
>>> >>
>>> >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as
>>> 'unitary'.
>>> >> Since we are in general working with complex numbers, I do suggest
>>> >> unitary
>>> >> over ortho.
>>> >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions)
>>> and (
>>> >>
>>> https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT
>>> )
>>> >>
>>> >> 2. I share Chris's concern about 'inverse', but I could not come up
>>> with
>>> >> a
>>> >> nice name.
>>> >>
>>> >> 3. Now that we are at this, should we also describe the corresponding
>>> >> continuum limit of FFT and iFFT in the documentation?
>>> >>
>>> >> A paragraph doing so could potentially also help people diagnose some
>>> of
>>> >> the normalization factor errors. I assumed it is common that one
>>> needs to
>>> >> translate a CFT into DFT when coding a paper up, and the correct
>>> >> compensation to the normalization factors will surface if one does the
>>> >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the
>>> >> variable
>>> >> is angular frequency, but it's been a while since I did that last
>>> time.
>>> >>
>>> >> - Yu
>>> >>
>>> >> NumPy-Discussion mailing list
>>> >
>>> >> NumPy-Discussion@
>>> >
>>> >> https://mail.python.org/mailman/listinfo/numpy-discussion
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from: http://numpy-discussion.10968.n7.nabble.com/
>>> > ___
>>> > NumPy-Discussion mailing list
>>>
>>> > NumPy-Discussion@
>>>
>>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>> Hello all,
>>> the discussion on this topic has been stagnant for the past couple of
>>> weeks,
>>> so I just wanted to ask if anyone has any alternative names for the new
>>> normalization option that would like to share.
>>>
>>> If not, I'd suggest that we move on with "norm=forward", which seems to
>>> be a
>>> more straightforward choice than the "norm=inverse" naming alternative. I
>>> can wait a couple of days for possible new recommendations to be
>>> submitted,
>>> and will then recommit to the open PR to account for the new kwarg name.
>>>
>>> In terms of the name for the "norm=ortho" option, I suggest that we keep
>>> it
>>> as is for now so that we don't introduce two API changes at once. If
>>> desired, we can discuss it separately and open a new PR introducing a
>>> name
>>> such as "norm=unitary" or "unit" as recommended in previous messages. I'm
>>> happy to handle that if you think it'd be a useful change.
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://numpy-discussion.10968.n7.nabble.com/
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>>

Re: [Numpy-discussion] Should we transfer MacPython/numpy-wheels to the NumPy org?

2020-10-29 Thread Gregory Lee 
On Thu, Oct 29, 2020 at 6:00 AM Matti Picus  wrote:

>
> On 10/29/20 5:42 AM, Charles R Harris wrote:
> > Hi All,
> >
> > Seems that is pretty easy to transfer a github repo to another owner.
> > Should we do this for the numpy-wheels repo? That would put all the
> > management in one place and now might be a good time to do it before
> > the 1.20.x branch.
> >
> > Chuck
> >
>
> What is the goal? So far it is convenient that all the repos that upload
> to https://anaconda.org/multibuild-wheels-staging are under one org to
> coordinate upload token use.
>
>
One case using *multibuild-wheels-staging* that is not currently under
MacPython is https://github.com/scikit-image/scikit-image-wheels. We have
not actually uploaded to *multibuild-wheels-staging* yet, but will be doing
so when we build wheels for the upcoming 0.18 release.



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