Potentially Fixes #288 ESMF_ArrayCreateGetUTest

[danrosen25]

Potentially Fixes #288 ESMF_ArrayCreateGetUTest where data in arrayDup is not initialized and compared to data in array.

• fill array with random number 0 - 1000
• fail if every element in array matches

[theurich]

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.

[danrosen25]

@theurich
How about the new changes, where I fill the array with a number between 0 and 1000 (inclusive of 0 and exclusive of 1000)?

[theurich]

@theurich How about the new changes, where I fill the array with a number between 0 and 1000 (inclusive of 0 and exclusive of 1000)?

@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 random_number in filling the array that the other random data is compared against. Still, I am interested to see what Bill thinks about this situation.

[billsacks]

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.