-
Notifications
You must be signed in to change notification settings - Fork 91
safegaurd Box-Muller normal random number generation against u=0.0 #158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR.
I'm not in favor of using assumed-size arrays. Alternatively, if we want to not duplicate the code, we could discuss replacing existing rank-specific functions with one impure elemental
subroutine. In general for performance non-critical code I prefer using functions, but here a subroutine would be a good compromise to reduce code duplication.
As for guarding against u == 0
, why not just do something like this:
u = max(tiny(u), u)
which is much simpler than the doubly-nested do
loop.
For guarding against call random_number(u)
u = 1 - u because |
That is indeed much simpler; performance should be tested. It may be significantly faster too! As far as not using assumed size arrays, that is a matter of preference and if this project does not want to use them, then I would agree |
I have went ahead and implemented The procedure is also now EDIT: Turns out this approach runs rather slower than the previous method on my machine when compiled with |
Great, thank you! You can remove the old functions from the code since the new subroutine will be used instead and we have git to keep history. |
Great @dacarnazzola let's just rename |
Alright, all fair points. I have updated the fix to only provide one value at a time, keeping no internal state. In response to a couple of questions/comments
If my comment about |
Do you want the |
Same here, but that may change as compilers and hardware improve. |
Since we now have just one specific procedure, I'd remove the interface altogether. |
This has been done. I don't have a lot of experience with submodules, but the compiler wasn't liking the main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
This fix also allows a single
randn_vec
subroutine to be used for any array rank, as well as improves performance ~3-10x. See example program below for that: