Hashing numbers

AdamB

123.hash
123.hash

gives the same answer.

Geom::Point3d.new(1,2,3).hash
Geom::Point3d.new(1,2,3).hash

gives 2 different answers. I understand why, I just think its a bug in realworld usage.

What do you think?

fredo6

This is normal, because you hash the object reference, not its content.
This one gives always the same result


Geom;;Point3d.new(1,2,3).to_a.hash

Fredo

AdamB

OK..

But if it hashes the reference then XXXX.to_a will generate a different hash each time because the array is new each time and therefore has a different reference.

And your answer begs the question:

If method hash() hashes the object reference and not the object value, then what in the Hans Christian Andersen is the point? By definition an object reference is unique since it refers to a unique object. What value does generating another unique number bring?

Confused...

fredo6

Adam,

Although everything is in theory an object in Ruby, there seems to be some exceptions for basic types such as numbers and lists of numbers.
So even if it seems that a new array is created each time, Ruby interprets a list of numbers as basic types, and use its content, not its reference. This may not be logic, but this is convenient.

Your point about hashing object reference is correct. The object refence being unique, you can use it directly as a key of hash tables. This is usally what I do when going through list of entities and making sure I treat them one. For instance, I would use a hash table, with the key edge.to_s or face.to_s (in pratice, because of SU7, I prefer now to use edge.entityID)

Fredo

Jim

@unknownuser said:

(in pratice, because of SU7, I prefer now to use edge.entityID)

Fredo,

I'm not sure I understand. What has changed with entityID in version 7?

fredo6

Actually nothing as changed with SU7. I simply thought that, because SU7 offers the feature to automatically split edges when intersecting, it could cause a probleme when you transform a model interactively. What I found out, is that his feature is a property of the Line tool. In Ruby, if you create an edge that happens to intersect another one, it is not 'cut'. Same when you transform via the method entities.transform_entities, for instance by scaling or moving.

Otherwise just some clarifications on the differences between Object Reference and entityID for Sketchup entities.

Object Reference is unique at a given time, but can change whenever the model changes. Sketchup may need to reconstruct geometry and alter the objects even if they remain the same visually in the model. So Object Reference should be used for scanning a selection in one pass, but not across modifications of the model. The most obvious case where this would be a problem is when you perform an Undo.

EntityIDsurvives to changes of geometry in the model via transformation. If you scale an edge or a face, it will preserve its entityID. Same for Undo. However, it is good to keep in mind that for Components, entityID are attached to the Component DEFINITION, not to the instance. Which means that if you do a recursive test on a selection, you can come across the same entityID several times for different component instances. Indeed, you could keep track of the entityID of each of the Component Instances, which is unique by Instance. So, you may think that the hash key should then be a combination of the Instance ID and entityID. Wrong, because your instance may itself be embedded within a Component, which has itself several instances.

OK, this looks complex, but remember that the problem exists only if you explore the model recursively, that is going 'inside' components. If you keep at one level, then both Object Reference and entityID are somehow unique at a given level.

Fredo