<div dir="ltr">Devroye's book is excellent.  Thanks for reminding me of it!</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 4, 2018 at 11:59 PM, Christoph Baumgarten <span dir="ltr"><<a href="mailto:christoph.baumgarten@gmail.com" target="_blank">christoph.baumgarten@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">A good source on the ratio of uniforms method is the book by Devroye: "non-uniform random variate generation" or the original paper "Computer Computer Generation of Random Variables using the ratio of uniform deviates" by kinderman / monahan.</div></div><br><div class="gmail_quote"><div dir="ltr"> <<a href="mailto:scipy-dev-request@python.org" target="_blank">scipy-dev-request@python.org</a>> schrieb am Sa., 4. Aug. 2018, 18:03:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send SciPy-Dev mailing list submissions to<br>
        <a href="mailto:scipy-dev@python.org" rel="noreferrer" target="_blank">scipy-dev@python.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:scipy-dev-request@python.org" rel="noreferrer" target="_blank">scipy-dev-request@python.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:scipy-dev-owner@python.org" rel="noreferrer" target="_blank">scipy-dev-owner@python.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of SciPy-Dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Review of PR 8293 - sampling of random variates (Neal Becker)<br>
   2. Re: Backwards Compatibility for low level LAPACK routines<br>
      (Ralf Gommers)<br>
   3. Re: Backwards Compatibility for low level LAPACK routines<br>
      (Pauli Virtanen)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Sat, 4 Aug 2018 07:44:06 -0400<br>
From: Neal Becker <<a href="mailto:ndbecker2@gmail.com" rel="noreferrer" target="_blank">ndbecker2@gmail.com</a>><span class=""><br>
To: SciPy Developers List <<a href="mailto:scipy-dev@python.org" rel="noreferrer" target="_blank">scipy-dev@python.org</a>><br>
Subject: Re: [SciPy-Dev] Review of PR 8293 - sampling of random<br>
        variates<br></span>
Message-ID:<br>
        <<a href="mailto:CAG3t%2BpF_5GMXGDJUJF-Z8n2iRHvTSpwG6_b4y1dMWSqwKS_29w@mail.gmail.com" rel="noreferrer" target="_blank">CAG3t+pF_5GMXGDJUJF-<wbr>Z8n2iRHvTSpwG6_b4y1dMWSqwKS_<wbr>29w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<div><div class="h5"><br>
<br>
Don't know about this particular code, but unuran is pretty comprehensive,<br>
and there's a good book from the author.<br>
<br>
On Fri, Aug 3, 2018, 5:37 PM Phillip Feldman <<a href="mailto:phillip.m.feldman@gmail.com" rel="noreferrer" target="_blank">phillip.m.feldman@gmail.com</a>><br>
wrote:<br>
<br>
> The ability to sample random variates from a distribution where only the<br>
> density is available seems quite useful.  Is there a reference that<br>
> describes the method?<br>
><br>
> Phillip<br>
><br>
> On Thu, Aug 2, 2018 at 11:43 PM, Christoph Baumgarten <<br>
> <a href="mailto:christoph.baumgarten@gmail.com" rel="noreferrer" target="_blank">christoph.baumgarten@gmail.com</a><wbr>> wrote:<br>
><br>
>> PR 8293 introduces a method to sample random variates for more complex<br>
>> distributions to scipy.stats (such as hyperbolic distributions and the<br>
>> generalized inverse gaussian (see PR 8681)). I think the PR is in good<br>
>> shape, it would be great if it could be merged soon since i could then<br>
>> continue to work on adding new distributions. The PR has been open for 7<br>
>> months now. If someone could continue the review, that would bei great.<br>
>> Thanks!<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> SciPy-Dev mailing list<br>
>> <a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
>><br>
>><br>
> ______________________________<wbr>_________________<br>
> SciPy-Dev mailing list<br>
> <a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
><br></div></div>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.python.org/pipermail/scipy-dev/attachments/20180804/73dd5df9/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://mail.python.org/<wbr>pipermail/scipy-dev/<wbr>attachments/20180804/73dd5df9/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 4 Aug 2018 06:06:22 -0700<br>
From: Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" rel="noreferrer" target="_blank">ralf.gommers@gmail.com</a>><span class=""><br>
To: SciPy Developers List <<a href="mailto:scipy-dev@python.org" rel="noreferrer" target="_blank">scipy-dev@python.org</a>><br></span>
Subject: Re: [SciPy-Dev] Backwards Compatibility for low level LAPACK<br>
        routines<br>
Message-ID:<br>
        <<a href="mailto:CABL7CQgmuAF2V0Pyrtt5qEBPE9M1ostJL54fx8YVVTZbgRF7KQ@mail.gmail.com" rel="noreferrer" target="_blank">CABL7CQgmuAF2V0Pyrtt5qEBPE9M1<wbr>ostJL54fx8YVVTZbgRF7KQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Sat, Aug 4, 2018 at 12:49 AM, Ilhan Polat <<a href="mailto:ilhanpolat@gmail.com" rel="noreferrer" target="_blank">ilhanpolat@gmail.com</a>> wrote:<br>
<br>
> It will gain a dgeqrf_lwork function as usual to return the necessary<br>
> workspace size as<br>
><br>
> lwork, info = dgeqrf_lwork(m,n)<br>
><br>
> Then the "work" variable will be removed from dgeqrf signature and will<br>
> be made hidden.<br>
><br>
> For example for the previous example I gave before, the optimal size is<br>
> 12800 and work array is returning an 12800-long array for a 400-400 array<br>
> computation.<br>
><br>
<br>
Ah okay. Then the alternative is to just leave the work parameter, ignore<br>
it in the code if it's passed in (or give a warning/error) and document it<br>
as not being used. Right?<br>
<br>
If you're removing "work" from both the signature and the return value,<br>
that's a bigger change indeed, that can't be handled well that way. I'm not<br>
100% sure, but I think I agree that a backwards incompatible change here<br>
will be better than introducing a bunch of new functions with worse names.<br>
<br>
We could introduce a Python wrapper for these to give a proper<br>
FutureWarning first.<br>
<br>
Cheers,<br>
Ralf<br>
<br>
<br>
<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Sat, Aug 4, 2018 at 3:25 AM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" rel="noreferrer" target="_blank">ralf.gommers@gmail.com</a>><br>
> wrote:<br>
><br>
>><br>
>><br>
>> On Thu, Aug 2, 2018 at 11:37 AM, Ilhan Polat <<a href="mailto:ilhanpolat@gmail.com" rel="noreferrer" target="_blank">ilhanpolat@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> Due their historical evolution, there are certain LAPACK wrappers that<br>
>>> are not standardized. Some work with minimum lwork variables instead of<br>
>>> their optimal values. Also these routines often return quite big arrays<br>
>>> during the lwork queries, to demonstrate :<br>
>>><br>
>>> import scipy.linalg as la<br>
>>> la.lapack.dgeqrf(a=np.random.<wbr>rand(400,400), lwork=-1)<br>
>>><br>
>>> is a workspace size query (via lwork=-1). The current default size is<br>
>>> "3*a.shape[0] + 1" hence 1201. However the optimal workspace size is 12800<br>
>>> on my machine. Therefore the mismatch is sometimes quite dramatic<br>
>>> especially in some other routines. Notice also that to obtain this number<br>
>>> the routine actually returns a 400-long array tau and requires the input<br>
>>> matrix to be transferred back and forth. Moreover, they can't be handled<br>
>>> via scipy.linalg.lapack._compute_<wbr>lwork function.<br>
>>><br>
>>> There are a few routines like this and I feel like they should be fixed<br>
>>> and I'm willing to. However this means that their output signature is going<br>
>>> to change which imply backwards compatibility breaks.<br>
>>><br>
>><br>
>> What would the output change to? Currently it returns:<br>
>><br>
>>     qr : rank-2 array('d') with bounds (m,n) and a storage<br>
>>     tau : rank-1 array('d') with bounds (MIN(m,n))<br>
>>     work : rank-1 array('d') with bounds (MAX(lwork,1))<br>
>>     info : int<br>
>><br>
>> Ralf<br>
>><br>
>><br>
>>> I tried to see whether we could deprecate them with new wrappers with<br>
>>> modified names, but to be honest, that would create too many duplicates. On<br>
>>> the other hand I don't have a feeling of how much break this would mean out<br>
>>> there in the wild.<br>
>>><br>
>>> Is this break an acceptable one or not? (well, none is acceptable<br>
>>> preferably, but in despair...)<br>
>>><br>
>>> Any other alternatives, thoughts are most welcome.<br>
>>><br>
>>> best,<br>
>>> ilhan<span class=""><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> SciPy-Dev mailing list<br>
>>> <a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
>>> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
>>><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> SciPy-Dev mailing list<br>
>> <a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
>> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
>><br>
>><br>
><br>
> ______________________________<wbr>_________________<br>
> SciPy-Dev mailing list<br>
> <a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
><br>
><br></span>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.python.org/pipermail/scipy-dev/attachments/20180804/d1e8615c/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://mail.python.org/<wbr>pipermail/scipy-dev/<wbr>attachments/20180804/d1e8615c/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 04 Aug 2018 16:00:36 +0200<br>
From: Pauli Virtanen <<a href="mailto:pav@iki.fi" rel="noreferrer" target="_blank">pav@iki.fi</a>><br>
To: <a href="mailto:scipy-dev@python.org" rel="noreferrer" target="_blank">scipy-dev@python.org</a><br>
Subject: Re: [SciPy-Dev] Backwards Compatibility for low level LAPACK<br>
        routines<br>
Message-ID: <<a href="mailto:5b464122e6ce8e5a7959f325e534f8d2543801d5.camel@iki.fi" rel="noreferrer" target="_blank">5b464122e6ce8e5a7959f325e534f<wbr>8d2543801d5.camel@iki.fi</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
la, 2018-08-04 kello 06:06 -0700, Ralf Gommers kirjoitti:<br>
[clip]<br>
> Ah okay. Then the alternative is to just leave the work parameter,<br>
> ignore<br>
> it in the code if it's passed in (or give a warning/error) and<br>
> document it<br>
> as not being used. Right?<br>
> <br>
> If you're removing "work" from both the signature and the return<br>
> value,<br>
> that's a bigger change indeed, that can't be handled well that way.<br>
> I'm not<br>
> 100% sure, but I think I agree that a backwards incompatible change<br>
> here<br>
> will be better than introducing a bunch of new functions with worse<br>
> names.<br>
> <br>
> We could introduce a Python wrapper for these to give a proper<br>
> FutureWarning first.<br>
<br>
Or, perhaps you can leave the `work` return variable in, but make it an<br>
1-element array? Its value can be filled in from the `callstatement`,<br>
cf eg <br>
<a href="https://github.com/scipy/scipy/blob/master/scipy/linalg/flapack_gen.pyf.src#L89" rel="noreferrer noreferrer" target="_blank">https://github.com/scipy/<wbr>scipy/blob/master/scipy/<wbr>linalg/flapack_gen.pyf.src#L89</a><br>
The actual work array is then made an intent(hide,cache) variable.<br>
<br>
        Pauli<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<span class=""><br>
<br>
______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" rel="noreferrer" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
<br>
<br></span>
------------------------------<br>
<br>
End of SciPy-Dev Digest, Vol 178, Issue 6<br>
******************************<wbr>***********<br>
</blockquote></div>
<br>______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
<br></blockquote></div><br></div>