[Numpy-discussion] Question about optimizing random_standard_normal

Sebastian Berg sebastian at sipsolutions.net
Mon Feb 8 12:04:23 EST 2021


On Mon, 2021-02-08 at 16:36 +0000, Kevin Sheppard wrote:
> That is good news indeed.  Seems like a good upgrade, especially
> given the breadth of application of normals and the multiple
> appearances within distributions.c (e.g., Cauchy). Is there a
> deprecation for a change like this? Or is it just a note and new
> random numbers in the next major?  I think this is the first time a
> substantially new algo has replaced an existing one.
>  

I don't think we can deprecate or even warn about it, that would just
result in noise that cannot be silenced.
If we really think warnings are necessary, it sounds like you would
need an opt-in `numpy.random.set_warn_if_streams_will_change()`.
That sounds like diminishing returns on first sight.

It may be good that this happens now, rather than in a few years when
adoption of the new API is probably still on the low side.


This type of change should be in the release notes undoubtedly and
likely a `.. versionchanged::` directive in the docstring.

Maybe the best thing would be to create a single, prominent but brief,
changelog listing all (or almost all) stream changes? (Possibly instead
of documenting it in the individual function as `.. versionchanged::`)

I am thinking just a table with:
  * version changed
  * short description
  * affected functions
  * how the stream changed (if that is ever relevant)


Cheers,

Sebastian


> Kevin
>  
>  
> From: Robert Kern
> Sent: Monday, February 8, 2021 4:06 PM
> To: Discussion of Numerical Python
> Subject: Re: [Numpy-discussion] Question about optimizing
> random_standard_normal
>  
> On Mon, Feb 8, 2021 at 10:53 AM Kevin Sheppard <
> kevin.k.sheppard at gmail.com> wrote:
> > My reading is that the first 4 are pure C, presumably using the
> > standard practice of inclining so as to make the tightest loop
> > possible, and to allow the compiler to make other optimizations. 
> > The final line is what happens when you replace the existing
> > ziggurat in NumPy with the new one. I read it this way since it has
> > both “new” and “old” with numpy. If it isn’t this, then I’m unsure
> > what “new” and “old” could mean in the context of this thread.
> 
>  
> No, these are our benchmarks of `Generator`. `numpy` is testing
> `RandomState`, which wasn't touched by their contribution.
>  
>   
> https://github.com/numpy/numpy/blob/master/benchmarks/benchmarks/bench_random.py#L93-L97
>   
> https://github.com/numpy/numpy/blob/master/benchmarks/benchmarks/bench_random.py#L123-L124
>  
> > I suppose camel-cdr can clarify what was actually done.
> 
>  
> > > > > But I did run the built-in benchmark: ./runtests.py --bench
> > > > > bench_random.RNG.time_normal_zig and the results are:
> 
>  
> -- 
> Robert Kern
>  
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210208/cf34023d/attachment.sig>


More information about the NumPy-Discussion mailing list