Skip to content
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

Fixes issue with rvs_normal where it lacks the elemental property #665

Merged
merged 3 commits into from Jul 7, 2022

Conversation

14NGiestas
Copy link
Member

As noted in PR#662 there's an error in the demo program given for rvs_normal where it lacks the shown elemental property.

example/demo_normal_rvs.f90:29:12:

   29 |     print *, norm(a, b)         ! a rank 3 random variates array
      |            1
Error: There is no specific function for the generic ‘rvs_normal’ at (1)
<ERROR> Compilation failed for object " example_demo_normal_rvs.f90.o "
<ERROR>stopping due to failed compilation

Copy link
Member

@jvdp1 jvdp1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading the code again, I wonder if this function could be elemental. For example, if an array v(2) is passed as argument, will the function provided the same result if result(2) is computed before result(1), instead of computing result(1) before result(2)? I don't think that the standard implies any order of the computations.

@14NGiestas
Copy link
Member Author

I think it's just a matter of batch calling the function over an array without having to deal with do loops, if you take a look at L185 you will see the pattern, 2 arguments -> impure elemental.

But I can see there is a problem with reproducible "randomness": if the order of the computations is changed (by doing it in parallel it's known that it happens), and since it depends on some stateful routines (there are some variables with the save attribute) I guess the result will be different, but I don't think the distribution will be changed.

@jvdp1
Copy link
Member

jvdp1 commented Jul 1, 2022

But I can see there is a problem with reproducible "randomness": if the order of the computations is changed (by doing it in parallel it's known that it happens), and since it depends on some stateful routines (there are some variables with the save attribute) I guess the result will be different, but I don't think the distribution will be changed.

Indeed, I refered to the problem of reproducible randomness. I agree with you that it won't affect the generated distribution.
Furthermore, the equivalent function in stdlib_stats_distribution_uniform is already impure elemental. Therefore, it would be logical that the equivalent fiunctions are impure elemental in both stdlib_stats_normal and in stdlib_stats_distribution_exponential.

The specs should be adapted to reflect these changes too.

Copy link
Member

@jvdp1 jvdp1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you.

@jvdp1 jvdp1 requested a review from a team July 4, 2022 15:20
@jvdp1
Copy link
Member

jvdp1 commented Jul 7, 2022

Thank you. I will merge it to move further wiuth other PRs.

@jvdp1 jvdp1 merged commit f98f3d3 into fortran-lang:master Jul 7, 2022
@14NGiestas 14NGiestas deleted the rvs_normal-issue branch July 20, 2022 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants