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

document non-reproducibility of objectid #57477

Open
mhinsch opened this issue Feb 20, 2025 · 11 comments
Open

document non-reproducibility of objectid #57477

mhinsch opened this issue Feb 20, 2025 · 11 comments
Labels
docs This change adds or pertains to documentation hashing

Comments

@mhinsch
Copy link

mhinsch commented Feb 20, 2025

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 in objectid's doc string.

@nsajko nsajko added the docs This change adds or pertains to documentation label Feb 20, 2025
@nsajko
Copy link
Contributor

nsajko commented Feb 20, 2025

Make a PR? Just adapt the phrasing from the hash doc string:

The hash value may change when a new Julia process is started.

@nsajko nsajko added the hashing label Feb 20, 2025
@vtjnash
Copy link
Member

vtjnash commented Feb 20, 2025

Do you have an example? We might just have a simple bug in some case or other

@oscardssmith
Copy link
Member

objectid([1]) is the simple example here.

@Seelengrab
Copy link
Contributor

[sukera@tower ~]$ julia -e 'println(objectid([1]))'
9761962143716435815
[sukera@tower ~]$ julia -e 'println(objectid([1]))'
4188474808741520571

@vtjnash
Copy link
Member

vtjnash commented Feb 20, 2025

If you make 2 different objects, of course those generally should have different objectid values, since they are different objects

@mhinsch
Copy link
Author

mhinsch commented Feb 20, 2025

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.

@vtjnash
Copy link
Member

vtjnash commented Feb 20, 2025

The objectid is not unique

@mhinsch
Copy link
Author

mhinsch commented Feb 20, 2025

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.

@nsajko
Copy link
Contributor

nsajko commented Feb 20, 2025

The objectid doc string clearly implies the return value is not necessarily unique. My guess is any uniqueness is implementation-defined.

@disberd
Copy link

disberd commented Feb 21, 2025

If you make 2 different objects, of course those generally should have different objectid values, since they are different objects

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?

@vtjnash
Copy link
Member

vtjnash commented Feb 21, 2025

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

$ ./julia1.13/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca
$ ./julia1.12/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca
$ ./julia111/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca
$ ./julia1.10/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca
$ ./julia1.9/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca
$ ./julia1.8/julia -E 'objectid(1)'
0x5bca7c69b0d0ebca

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation hashing
Projects
None yet
Development

No branches or pull requests

6 participants