-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
document non-reproducibility of objectid #57477
Comments
Make a PR? Just adapt the phrasing from the
|
Do you have an example? We might just have a simple bug in some case or other |
|
|
If you make 2 different objects, of course those generally should have different objectid values, since they are different objects |
Sure, if you think about it it makes perfect sense. If you don't it's very confusing, though. In my case I was using objectid to sort arrays of objects in a simulation, so that I could make sure there were no duplicates. It took me half a day to realise that that was the reason my simulations seemed to behave non-deterministically. |
The objectid is not unique |
It's not, not even for objects of the same type? I thought it was essentially just the object pointer for mutable structs. |
The |
Does this imply that if I do use immutable objects not referencing other mutable objects the objectid should return the same value at least for the same Julia version? |
Yes, objectid is likely surprisingly stable (though not guaranteed), even across machines and versions, since we have very little incentive to change the algorithm very often
|
At least for some types
objectid
usually varies across program runs (I assume because it's simply a pointer value). As that can break numerical reproducibility of a program it would be good to mention this inobjectid
's doc string.The text was updated successfully, but these errors were encountered: