Consider deterministic ids for hypar elements about elements HOT 3 CLOSED

Ids are now incremented long types. I like where this suggestion is coming from, and it might be that we can add something along these lines in the future, as Navisworks had with their "path" property. That is, in addition to the id, you'd have a path like 0:1:5:27:... where each id is the sub-element id within an aggregating element. These would be unique and would allow for scenarios like the one mentioned above with mullion ids in a curtain wall.

For now I'm closing.

from elements.

I’m all ears. The challenge with a deterministic id, if I’m understanding your meaning, is that it’s not guaranteed to be unique. Of course, neither are Guids, but they have a very small probability of clash.

What mechanism would you propose to generate a deterministic id for an Element?

from elements.

Yeah, I agree that uniqueness is an important issue. The goal would be to create element ids that are unique within the scope of a particular function's execution, but remain consistent across reexecutions of the originating hypar function. This would allow other systems (eg, tesselation, or the viewer example above) to more easily understand "what changed" between hypar function executions.

I also agree that collisions between guids are reasonably unlikely. And if you take the rule of thumb that with a good method of distributing ids, you can have the square root of the total number of possible ids used before you start to see collisions, then with guids hypar functions could have 2^64 identified elements; if that's enough, just use a few more bytes and the ceiling goes up substantially.

Here are a few ideas for creating ids. I wonder if there are things to be learned from how the mechanical cad world handles the concept of persistent id's (which I'm not very familiar with). And maybe this is a fool's errand, and different systems that have different conceptions of what "identifies" an element should just inspect elements and make their own determinations.

Scheme 0, existing implementation: randomly assigned ids.

Pros:

• Very simple
• Low chances of collision, and collision doesn't depend on fiddly logic (and can be solved by re-executing the function!)

Cons:

• No consistent identification of elements between hypar function executions.

Scheme 1: incrementing ids.

Assign ids by giving subsequently created elements incremented ids.

Pros:

• Simple
• No collisions
• Identical executions of a hypar function (with some restrictions) will result in consistent id's

Cons:

• Element ids depends on the execution order of different blocks of code in the generating function.
• Especially in situations where hypar functions exploit parallelism, this will break down. Even things like the order in which elements inside hash maps are traversed will start to leak into id assignment, which seems non-obvious.

Scheme 2: Content hash of element's contents

Each element could have an id assigned based on a hash of all state associated with it.

Pros:

• Reasonably simple
• Consistent identification of identical elements
• Lends itself to memoization of downstream elements (eg, tessellation) based on id

Cons:

• Any changes to an element will generate a new id -- I cannot change the material of an element, I create a new set of results that replaces one element with another, almost identical one
• Arbitrary changes to various datastructures (in, say, new versions of hypar) will cycle generated element ids, in ways that may be difficult to manage.
• Any user-written data-structures attached to or incorporated into hypar elements would have to behave "nicely" -- correctly implementing some IHashable interface, or weird things might potentially happen.

Scheme 3: Content hash based on the "lineage" of an element, or some other subset of properties

E.g: a mullion's id could be a hash of the concatenation of the id of grid that it was placed on and the grid u/v indices that locate it. The grid's id would be based on the hash of the solid id and face index that it was placed on. So, changing the material of the mullion would not change it's id. Likewise, moving the solid in space and changing the grid spacing would not change the mullion's id. However, inserting a new face in the solid might.

Pros:

• Consistent identification across a range of possible changes in the element.

Cons:

• More complicated
• The logic for what triggers an id to cycle would permeate a lot of code, and could be difficult for users to reason about

from elements.