-
Notifications
You must be signed in to change notification settings - Fork 75
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
Potentially Fixes #288 ESMF_ArrayCreateGetUTest #289
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.
This looks very close to what I was thinking. Thank you for starting this PR.
One concern I have is with hugh()
. My worry is that the largest representable number might not be so special, i.e. it might be not unlikely to hit it in uninitialized memory. I don't know that it is true, but that is just my feeling. Subtracting localpet might not change anything about it, since hugh
might be so large that subtracting something O(1) makes no difference.
With that in mind, I was more thinking of initializing maybe in the more reasonable range of say 1000*(localPet+1), and then in addition start change maybe by 0.1 for each local element increment. Hitting all of those matching seems super unlikely to me.
* fill array with random number 0 - 1000 * fail if every element in array matches
94f511d
to
e309515
Compare
@theurich |
@danrosen25 I like this version! However, I am going to tag @billsacks here, since he had valid concerns about use of "randomness" in testing before. I agree with him that it is generally a bad idea to have randomness in tests, because you loose reproducibility, which is a pain to deal with when things are failing. However, here I think the situation is random already, due to the uninitialized data.... so in my mind I do not see a problem with use of |
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.
Thanks for tagging me on this, and sorry for my delay in responding.
I agree with all points in @theurich 's last comment - that we should generally try to avoid randomness, but also that this situation is special in that the only purpose of these values is to compare with uninitialized data, which is already effectively random. So I support this change. I do feel like a slightly more ideal change would be to initialize farrayPtr2D with a hard-coded list of pseudo-random values, but I feel like this use of random_number is okay here. I'd just say that ideally there would be a comment before the random_number call along these lines:
! Generally we want to avoid using random_number in unit tests. But here the purpose of the initialization is to compare against uninitialized data, which is already effectively random. So we use random number initialization for convenience and because it doesn't lead to much additional randomness of this test against uninitialized data.
@billsacks |
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.
Looks good - thank you very much for this @danrosen25 !
Potentially Fixes #288 ESMF_ArrayCreateGetUTest where data in arrayDup is not initialized and compared to data in array.