Fabrice, what are the use cases for a memcmp-like comparison between
On Wed, Jun 6, 2012 at 11:55 AM, Won Chun <email@example.com
> On Wed, Jun 6, 2012 at 2:42 PM, Brandon Jones <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
>> 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.
> I agree with Brandon that you shouldn't use memcmp to compare floats, even
> includes a signed zero, that compare equal but have different bit
> 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
>>> Hi Florian,
>>> On Wed, Jun 6, 2012 at 1:25 AM, Florian Bösch <firstname.lastname@example.org
>>>> On Wed, Jun 6, 2012 at 8:18 AM, Fabrice Robinet <email@example.com
>>>>> 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.