Remove duplication of calls to resampling functions

[wleoncio]

The resampling procedure should be its only funciton. Instead, it is performed on rtrunc() and then again on sampleFromUntruncated().

[wleoncio]

One promising solution involves determining a larger sample size than the user requested (if a and b are not the defaults) and dropping the truncated values from that. That should generate very little extra code footprint, basically just a formula for the new n, ideally something directly proportional to how extreme the requested configuration is. For example:

1. buffer_n = n * 100 / (b - a)
2. buffer_n = n * 100 / P(a < X < b)

[rho62]

Hi Waldir I believe I’ve found the solution for the discrete distributions (and I’m working on it for the continuous ones) The approach so far, has been to sample from the original distribution and subsequently truncate the sample. We sample elements that will be discarded and we don’t know the exact number we need to sample in order to achieve the requested truncated sample size. The solution is however quite obvious: We should sample directly from the truncated distribution, which is easily obtained. So we sample from the domain a:b using probabilities obtained from the truncated distribution. I enclose my code. You can perhaps tidy it up, so it can be in a “publishable” state and conform with the package. Please also have a look at the error-trapping etc We should do the same the other discrete distributions (Poisson, neg. binom) /René Fra: Waldir Leoncio ***@***.***> Svar til: ocbe-uio/TruncExpFam ***@***.***> Dato: fredag 18. februar 2022 kl. 12:07 Til: ocbe-uio/TruncExpFam ***@***.***> Kopi: Subscribed ***@***.***> Emne: Re: [ocbe-uio/TruncExpFam] DRY resampling (Issue #72) One promising solution involves determining a larger sample size than the user requested (if a and b are not the defaults) and dropping the truncated values from that. That should generate very little extra code footprint, basically just a formula for the new n, ideally something directly proportional to how extreme the requested configuration is. For example: 1. buffer_n = n * 100 / (b - a) 2. buffer_n = n * 100 / P(a < X < b) — Reply to this email directly, view it on GitHub<#72 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFPRUPSEZT35QAASJTEBKATU3YR6TANCNFSM5J5VCBQQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wleoncio]

Hi Rene, thanks for chiming in! I couldn't find your code, I suppose it was attached to your reply (which GitHub discards). Could you post your solution on https://gist.github.com/ and add the link to it here? You can also send it to me by e-mail and I'll do that, noproblem. :)

[wleoncio]

Renamed this issue to clarify the difference between what is handled here (i.e., the WET coding that calls sampleFromUntruncated() more often than it should) and what is handled on #77 and #78, which is the analytical solution to the sampling itself. Solving the latter two will probably also end up solving this issue, however.

[wleoncio]

Since #77 and #78 have been implemented, this older procedure might be superseded. It currently is still the default, but that can change at any time. The only advantage of the older procedure is sample-equivalence to their untruncated counterparts (given the same seed). Unless this equivalence is essential, working on this issue might not be worth it.

Closing for now, revisiting in the future if necessary.