DrChainsaw (May 21 2023 at 10:30): DrChainsaw (May 21 2023 at 10:30):Assume one wants to have some kind of simple object identity lookup table, like Base.ImmutableDict or just a tuple with pairs, but the keys are of all kinds of crazy types (values are always the same type). Would it be safe/useful to use objectid(x) as keys instead of x just to get some type harmonization and e.g. reduce the risk of exploding compile times?
Finding the object from the keys will never be useful in this case since it will only be used when one has access to the original object.
ederag (May 21 2023 at 11:44):Something like IdDict ?
ederag (May 21 2023 at 11:48):Those are fast; you "just" have to keep in mind that equal objects with different IDs will be treated as different keys.
DrChainsaw (May 21 2023 at 14:12):The way to use an IdDict would be to have an IdDict{UInt64} instead of an IdDict{Any} and always access it with objectid(x) instead of just x. I don't think this has any direct advantages in most cases, especially since IdDicts tend to be slower than normal Dicts for simple objects like UInt64s.
In my case I also want to avoid mutation (and Dicts in general) since I'd like it to be as autodiff compatible as possible which is why I looked into Base.ImmutableDict or just a plain tuple or some own type with the same type of characteristics.
The IdDict is however one reason why I asked the above since it seems to be doing alot more than just checking object identities. I guess one reason could be that you want to be able to retrieve the actual keys, e.g. when iterating and this is not something I need to do.
ederag (May 21 2023 at 16:11):I thought you wanted to make your dict work like an IdDict, which would be used as id_dict[object] directly
(no need to know the actual id, just use the object).
DrChainsaw (May 21 2023 at 17:05):Yeah, I was perhaps not so clear. The main goal was to avoid/circumvent type heterogenity, and since all I need is an IdDict to look up things from I though one could just store the object ids as UInt64s. The docs are not fully clear on what the unusual cases "usually when x !== y, objectid(x) != objectid(y)." are. Perhaps it is the normal hash collisions (i,e there are more possible objects than there are unique object ids).
Sukera (May 21 2023 at 17:07):it's exactly the usual hash collision
DrChainsaw (May 21 2023 at 17:48):I sometimes wonder why it is not possible to just get some unique memory address for an object, but I guess if it was simple then there would be datastructures which make use of it already. Back to the drawing table on this one...
Sukera (May 21 2023 at 17:50):not all objects are guaranteed to have a memory address :)
Sukera (May 21 2023 at 17:51):the hardware/OS/memory space under the hood is an implementation detail - just think of values that only exist in registers (or ones that only exist during optimization in compilation)
Last updated: Oct 02 2023 at 04:34 UTC