[Numpy-discussion] Interpolation using `np.interp()` with periodic x-coordinates (Saullo Castro)

Saullo Castro saullogiovani at gmail.com
Thu Oct 2 13:07:41 EDT 2014


Jaime has helped me and PR#5117 is getting ready to be merged
<https://github.com/numpy/numpy/pull/5117>...


2014-10-02 19:00 GMT+02:00 <numpy-discussion-request at scipy.org>:

> Send NumPy-Discussion mailing list submissions to
>         numpy-discussion at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/numpy-discussion
> or, via email, send a message with subject or body 'help' to
>         numpy-discussion-request at scipy.org
>
> You can reach the person managing the list at
>         numpy-discussion-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NumPy-Discussion digest..."
>
>
> Today's Topics:
>
>    1. Re: Interpolation using `np.interp()` with periodic
>       x-coordinates (Charles R Harris)
>    2. Re: Proposal: add ndarray.keys() to return dtype.names
>       (Sebastian Wagner)
>    3. Re: Proposal: add ndarray.keys() to return        dtype.names
>       (John Zwinck)
>    4. skip samples in random number generator (Brad Buran)
>    5. Re: skip samples in random number generator (Robert Kern)
>    6. Re: skip samples in random number generator (Nathaniel Smith)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 1 Oct 2014 18:12:56 -0600
> From: Charles R Harris <charlesr.harris at gmail.com>
> Subject: Re: [Numpy-discussion] Interpolation using `np.interp()` with
>         periodic x-coordinates
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>         <CAB6mnxJwuw8k=NCkkUyKioCvLUy3XfUQkR=
> o-DgkxWQfvWOB6A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Sep 24, 2014 at 3:57 PM, Saullo Castro <saullogiovani at gmail.com>
> wrote:
>
> > From the closed pull request PR #5109:
> >
> > https://github.com/numpy/numpy/pull/5109
> >
> > it came out that the a good implementation would be adding a parameter
> > `period`. I would like to know about the community's interest for this
> > implementation.
> >
> > The modification are shown here:
> >
> >
> https://github.com/saullocastro/numpy/compare/interp_with_period?expand=1
> >
> > Please, let me know about your feedback.
> >
>
> I don't have any problem with allowing periodic interpolation.
>
> Chuck
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/numpy-discussion/attachments/20141001/519ac77f/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 02 Oct 2014 12:27:26 +0200
> From: Sebastian Wagner <sebix at sebix.at>
> Subject: Re: [Numpy-discussion] Proposal: add ndarray.keys() to return
>         dtype.names
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID: <0294ae9ec5a919857265bed55ebffda3 at fizeau.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> So, for non-structured arrays, the consens is an Exception. The question
> is, which one.
> AttributeError would be fully backwards compatible. Existing code checks
> for the method and if it exists, the object has fields.
> ValueError would make more sense, as the value - the array - is in wrong
> format/structure/type.
>
> regards,
>
> On 2014-10-01 16:47, Eelco Hoogendoorn wrote:
> > Ah yes; you can use..
> >
> > from types import MethodType
> >
> > ...to dynamically add methods to specific instances of a type. This
> > may be cleaner or more pythonic than performing a check within the
> > method, I dunno.
> >
> > On Wed, Oct 1, 2014 at 4:41 PM, Benjamin Root <ben.root at ou.edu> wrote:
> >
> >> Actually, if I remember correctly, special methods show up in the
> >> ndarray object when the dtype is datetime64, right?
> >>
> >> On Wed, Oct 1, 2014 at 10:13 AM, Eelco Hoogendoorn
> >> <hoogendoorn.eelco at gmail.com> wrote:
> >>
> >> Well, the method will have to be present on all ndarrays, since
> >> structured arrays do not have a different type from regular arrays,
> >> only a different dtype. Thus the attribute has to be present
> >> regardless, but some Exception will have to be raised depending on
> >> the dtype, to make it quack like the kind of duck it is, so to
> >> speak. Indeed it seems like an atypical design pattern; but I don't
> >> see a problem with it.
> >>
> >> On Wed, Oct 1, 2014 at 4:08 PM, John Zwinck <jzwinck at gmail.com>
> >> wrote:
> >>
> >> On 1 Oct 2014 04:30, "Stephan Hoyer" <shoyer at gmail.com> wrote:
> >>>
> >>> On Tue, Sep 30, 2014 at 1:22 PM, Eelco Hoogendoorn
> >> <hoogendoorn.eelco at gmail.com> wrote:
> >>>>
> >>>> On more careful reading of your words, I think we agree; indeed,
> >> if keys() is present is should return an iterable; but I don't think
> >> it should be present for non-structured arrays.
> >>>
> >>> Indeed, I think we do agree. The attribute can simply be missing
> >> (e.g., accessing it raises AttributeError) for non-structured
> >> arrays.
> >>
> >> I'm generally fine with this, though I would like to know if there
> >> is precedent for methods being present on structured arrays only.
> >> Even if there is no precedent I am still OK with the idea, I just
> >> think we should understand if how novel this will be.
> >> _______________________________________________
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion [1]
> >>
> >> _______________________________________________
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion [1]
> >
> > _______________________________________________
> >  NumPy-Discussion mailing list
> >  NumPy-Discussion at scipy.org
> >  http://mail.scipy.org/mailman/listinfo/numpy-discussion [1]
> >
> >
> >
> > Links:
> > ------
> > [1] http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Oct 2014 19:09:47 +0800
> From: John Zwinck <jzwinck at gmail.com>
> Subject: Re: [Numpy-discussion] Proposal: add ndarray.keys() to return
>         dtype.names
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>         <CAK_AF3A9aONKmu8RKgOZWgLKpmTgD=wyB6xkh0+v12nzRP=
> Sog at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Oct 2, 2014 at 6:27 PM, Sebastian Wagner <sebix at sebix.at> wrote:
> > So, for non-structured arrays, the consens is an Exception. The question
> > is, which one.
> > AttributeError would be fully backwards compatible. Existing code checks
> > for the method and if it exists, the object has fields.
> > ValueError would make more sense, as the value - the array - is in wrong
> > format/structure/type.
>
> If a non-structured array has its keys() raise AttributeError, I think
> that hasattr(arr, "keys") should return False, which implies that
> getattr(arr, "keys") should throw AttributeError.  This would require
> that ndarray.__getattribute__ raise AttributeError, meaning "the
> attribute isn't here," not merely "the attribute doesn't have a value
> now."  Otherwise people may rightly complain when they interrogate an
> array to see if it has keys(), find out that it does, but then get an
> error upon calling it which could have been known ahead of time.
>
> Now, to actually implement it this way would seem to require setting
> the "tp_getattro" function pointer
> (https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_getattro).
> Currently PyArray_Type has this field as null.  If I understand
> everything correctly, adding a non-null function pointer here would
> mean some small runtime overhead to resolve every attribute on
> ndarray.  I could easily be missing some detail which would allow us
> to do what I described above without a performance hit, but someone
> better versed would need to explain how/why.
>
> If I'm right about all that, and if the consensus is that keys()
> should raise an exception when dtype.names is None, then perhaps
> raising ValueError is the only viable option.
>
> I'd appreciate opinions from those experienced in the details of the C API.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 2 Oct 2014 08:42:46 -0700
> From: Brad Buran <bburan at alum.mit.edu>
> Subject: [Numpy-discussion] skip samples in random number generator
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>         <
> CAHb_y2LaLg3A4Jch9ErKMcDMHMzhKcVS0W20CeNKxBxBHL1o8A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Given the following:
>
> from numpy import random
> rs = random.RandomState(seed=1)
> # skip the first X billion samples
> x = rs.uniform(0, 10)
>
> How do I accomplish "skip the first X billion samples" (e.g. 7.2
> billion)?  I see that there's a numpy.random.RandomState.set_state
> which accepts (among other parameters) a value called "pos".  This
> sounds promising, but the other parameters I'm not sure how to compute
> (e.g. the 1D array of 624 unsigned integers, etc.).  I need to be able
> to skip ahead in the sequence to reproduce some signals that were
> generated for experiments.  I could certainly consume and discard the
> first X billion samples; however, that seems to be computationally
> inefficient.
>
> Brad
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 2 Oct 2014 16:52:11 +0100
> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [Numpy-discussion] skip samples in random number
>         generator
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>         <
> CAF6FJivcx3q+TWYoLXbdzBCgc2uk8isV83ZU-+28LDyndh5SSg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Oct 2, 2014 at 4:42 PM, Brad Buran <bburan at alum.mit.edu> wrote:
> > Given the following:
> >
> > from numpy import random
> > rs = random.RandomState(seed=1)
> > # skip the first X billion samples
> > x = rs.uniform(0, 10)
> >
> > How do I accomplish "skip the first X billion samples" (e.g. 7.2
> > billion)?  I see that there's a numpy.random.RandomState.set_state
> > which accepts (among other parameters) a value called "pos".  This
> > sounds promising, but the other parameters I'm not sure how to compute
> > (e.g. the 1D array of 624 unsigned integers, etc.).  I need to be able
> > to skip ahead in the sequence to reproduce some signals that were
> > generated for experiments.  I could certainly consume and discard the
> > first X billion samples; however, that seems to be computationally
> > inefficient.
>
> Unfortunately, it requires some significant number-theoretical
> precomputation for any given N number of steps that you want to skip.
>
> http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/JUMP/index.html
>
> It's also unreliable for your purpose. You don't know how many random
> integers were actually pulled from the core PRNG if you ever used any
> of the nonuniform distributions (they usually will consume a variable
> number of uniform pseudorandom numbers to give you a single nonuniform
> number).
>
> Instead, you should just pickle the RandomState object just before you
> start using it for anything that you want to reproduce. The unpickled
> RandomState will reproduce the same numbers the first one did.
>
> --
> Robert Kern
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 2 Oct 2014 17:28:47 +0100
> From: Nathaniel Smith <njs at pobox.com>
> Subject: Re: [Numpy-discussion] skip samples in random number
>         generator
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>         <
> CAPJVwBmZBQU-nYO1SE6SCvN+6eOTW9mrzruwDKkUF188bGfT_A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 2 Oct 2014 16:52, "Robert Kern" <robert.kern at gmail.com> wrote:
> >
> > On Thu, Oct 2, 2014 at 4:42 PM, Brad Buran <bburan at alum.mit.edu> wrote:
> > > Given the following:
> > >
> > > from numpy import random
> > > rs = random.RandomState(seed=1)
> > > # skip the first X billion samples
> > > x = rs.uniform(0, 10)
> > >
> > > How do I accomplish "skip the first X billion samples" (e.g. 7.2
> > > billion)?  I see that there's a numpy.random.RandomState.set_state
> > > which accepts (among other parameters) a value called "pos".  This
> > > sounds promising, but the other parameters I'm not sure how to compute
> > > (e.g. the 1D array of 624 unsigned integers, etc.).  I need to be able
> > > to skip ahead in the sequence to reproduce some signals that were
> > > generated for experiments.  I could certainly consume and discard the
> > > first X billion samples; however, that seems to be computationally
> > > inefficient.
> >
> > Unfortunately, it requires some significant number-theoretical
> > precomputation for any given N number of steps that you want to skip.
> >
> > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/JUMP/index.html
>
> If someone really wanted this functionality then I suppose it would be
> possible to precompute the special jump coefficients for lengths 2, 4, 8,
> 16, 32, ..., and then perform arbitrary jumps using a sequence of smaller
> jumps. (The coefficient table could be shipped with the source code.)
>
> -n
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/numpy-discussion/attachments/20141002/d58de1c1/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> End of NumPy-Discussion Digest, Vol 97, Issue 3
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141002/8f12f930/attachment.html>


More information about the NumPy-Discussion mailing list