Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Oh look at it stupid technomusings.
Context:
- You have a sequence of N-byte-wide values.
- Each value is unique.
- You XOR them all together into an N-byte-wide key.
- Just dump the key into a list somewhere.
Problem:
- A new value sequence is input.
- Same rules: all values are unique and fixed-size.
- You XOR them all together into a key.
- You walk the list of keys and check them for equality against the new one.
The same sequence of values, regardless of order, would ((supposedly)) always give you the same key. I used this years ago, for a renderer that used indexed colors, to see if I had to make a new palette or not when saving/loading textures: the image format had the key on the header.
It worked, but I was using a __very__ limited value range, cursed 8-bit YUV lossy fuckery; never bothered investigating the idea any further.
So, question:
- Is there any specific situation in which you get a false positive?
- Is there any specific situation in which you get a false negative?
My brain wants to say 'yes' to both because I'm privy to the mystical truth that my methods invariably fall on the idiot side of the spectrum. But my lazy testing keeps saying 'no, you dumbass'.
So who's wrong?
brb gon hit that crack~
question
if you aint freebasin you aint doing shit