Implement approx_eq_eps, to_untyped and from_untyped in more places

[nical]

Fixes #362 and addresses a comment of https://phabricator.services.mozilla.com/D38455

---

This change is 

[nical]

r? anyone

[kvark]

would this be equivalent to multiplying by Scale<f32, T, UnknownUnit>? If so, there might be a simpler and more universal way to get to/from untyped

[nical]

I'm note sure I follow, rigid transforms don't have a scale. to/from_untyped is mostly there because you have your properly typed code and sometimes you delegate some work to a library that doesn't use units or doesn't use your units, so you cast the unit away for API compatibility.

I wonder if what you mean by scale is some sort of typed identity transform to reify the notion of casting between units in a more explicit way. Maybe it'd make sense in some context? I think that in the case of casting to the unknown unit all we want is to just give up some type info for API compat reason between some independent pieces of code and to/from_untyped are the simplest and most natural ways in that situation.

[kvark]

You are correct, rigid transforms don't have a scale, so Scale is inapplicable.

[kvark]

the matrix API receives epsilon by reference. Is there a strong reason to break consistency at this level?

[nical]

Sorry that was me hesitating and forgetting to clean it up. I'd rather we consistently pass it by value but I don't care enough to change it.

[kvark]

I do wonder if such epsilon comparison is useful at this level. Do you have a use case in mind?
A small change in one of the components may contributing to arbitrary differences in the transformed vectors, so it's not like we can reason about the locality of error here.

[nical]

Well, this one we already have a use case for in WebRender with on of Glenn's recent patches. I don't think the change is completely arbitrary. It's as arbitrary as any similar chain of additions and multiplications where a small increment somewhere could be magnified by a factor coming from another term, but very very tiny epsilon still lead to tiny changes in practice unless you apply a huge scale or translation.

To extend my thinking a bit, I believe that what doesn't make sense is to have approx_eq without explicitly passing the epsilon because the threshold that you need always depends on what arithmetic you do beforehand and a bit of knowledge about reasonable input ranges for your usecase.

[kvark]

It's not just about huge scaling. This is a 3D transform that is subject to perspective. Any changes to W component bring a huge deal of non-linearity to this.

[kvark]

Have a weak yes here. I don't like the approx comparison on perspective matrices... but if @gw3583 is already using those, then at least it's a practical concern.

[nical]

@bors-servo r=kvark

[bors-servo]

📌 Commit 0b9b518 has been approved by kvark

[bors-servo]

⌛ Testing commit 0b9b518 with merge 582df22...

[bors-servo]

☀️ Test successful - checks-travis
Approved by: kvark
Pushing 582df22 to master...