[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] comparing typed arrays
Right, thank you guys for the heads up.
I was totally aware about adding an epsilon would definitly help not rejecting good candidate for equivalence , but I overlooked the IEEE754 signed zero.
Still this might not prevent to wrap the float compare natively within typed arrays implementation but I agree that the final API / constraints might end up not exactly as I was expecting it at first.
On Wed, Jun 6, 2012 at 11:55 AM, Won Chun <firstname.lastname@example.org>
I'd like to point out that while I think a memcmp on typed arrays would be a really good idea, that may not accurately cover the case that you're describing Fabrice (comparing matrices). Given the quirks of floating point calculations if the matrices you were comparing had been calculated mathematically rather than copied directly from a static source you could easily introduce minor variations into the matrix elements that would cause a memcmp to fail. A more realistic (though unfortunately slower) usage would be to compare each value with a small epsilon to account for floating point jitter.
Of course, that entirely depends on your use case. I'm just saying that while I fully support fast TypeArray comparisons I don't think it should be advocated for comparing vectors/matrices in general.
In general, you want some kind of slop for floating point comparisons, but element-by-element epsilons for transformation matrices might be nonsensical. Better to do comparisons in a domain where transformations are easily manipulated. Things like offset vectors or quaternions would use absolute epsilons, scaling factors would use relative epsilons, etc.
On Wed, Jun 6, 2012 at 11:15 AM, Fabrice Robinet <email@example.com>
On Wed, Jun 6, 2012 at 1:25 AM, Florian Bösch <firstname.lastname@example.org>
Looking at the typed array spec I did not find a way to compare (efficiently) 2 arrays,
Is that something that was considered and discarded for some reason ? Or did it just not made it into the spec yet ?
I don't know the reason why it's not in the spec. I would think it'd be useful if the comparison operator between typed arrays/views would make a range check and if matching performed a memcmp.
Indeed, specifying a range for the compare and underneath relying on memcmp is *exactly* what I believe is missing.
I'll follow up by filing an issue about this.