You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Come up with a rename to clarify aid instance vs aid #141
In the code, it is often not clear if aid means aid instance (so a column or expression) or a value ("instance" 😉) of aid instance, being something derived from an AID value. (But it's not really the AID value anymore, because it may have been hashed!)
I think the term instance hinders more than it helps. We have AID columns and AID values.
We should differentiate between them if the defining scope allows for both to exist at the same time.
Otherwise, using aid generically and taking context into account is mostly fine IMO (we can't put all the relevant information into variable names anyway).
As Edon said, the hash part is not relevant after initialization anymore, so we can leave it out of the name.
There is no way to get an unsafe AID value because it's literally impossible without the type adapter. A postgres Datum is an opaque value unless we have type info, which is handled by the AidSpec.
wait, so what is the hashing for? isn't it there to make the seed pseudo-random? we're turning of hashing only in DEBUG, so I assumed that it is there for some sort of safety
wait, so what is the hashing for? isn't it there to make the seed pseudo-random? we're turning of hashing only in DEBUG, so I assumed that it is there for some sort of safety
We need to squash various types into an aid_t. For text we hash to get a number, for numbers we hash to mix distribution (IDs tend to be sequential, using only the lower end of bits). For debug we leave it off in case we want to investigate what entity is contributing to what.
Activity
cristianberneanu commentedon Jan 5, 2022
I think the term
instancehinders more than it helps. We have AID columns and AID values.We should differentiate between them if the defining scope allows for both to exist at the same time.
Otherwise, using
aidgenerically and taking context into account is mostly fine IMO (we can't put all the relevant information into variable names anyway).As Edon said, the hash part is not relevant after initialization anymore, so we can leave it out of the name.
pdobacz commentedon Jan 6, 2022
I have been thinking about this: If you're open to reconsider
aid_hash, it would be a option which could potentially help solve this. Arguments:reference, e.g.: (type AidCountState = { AidContributions: Dictionary<AidHash, float>; mutable UnaccountedFor: int64 })edongashi commentedon Jan 6, 2022
There is no way to get an unsafe AID value because it's literally impossible without the type adapter. A postgres Datum is an opaque value unless we have type info, which is handled by the AidSpec.
pdobacz commentedon Jan 6, 2022
wait, so what is the hashing for? isn't it there to make the seed pseudo-random? we're turning of hashing only in DEBUG, so I assumed that it is there for some sort of safety
pdobacz commentedon Jan 6, 2022
ah, ok I see what you mean now. nvm
edongashi commentedon Jan 6, 2022
We need to squash various types into an
aid_t. For text we hash to get a number, for numbers we hash to mix distribution (IDs tend to be sequential, using only the lower end of bits). For debug we leave it off in case we want to investigate what entity is contributing to what.