axelpale / nudged Goto Github PK

Currently the methods are bound to this during construction. Due to frequent use of immutable transformations, it is probably better to bind to prototype.

How to do this? Possibilities:

• Maybe a section in docs for each transformation type.
• Extended API docs for each estimator.
• A collage of types and their visual representation.
• Animation?

Handy in debugging

Request to implement methods to estimate only the optimal rotation matrix i.e. rotator from a domain, range, and optional fixed point.

Request to implement ways to rotate existing Transform objects by an angle in radians and an optional fixed point.

The lib could be more friendly for TypeScript users.

@lsps9150414 Could you share a rough insight on how should it be done? Is it enough to have one index.d.ts file in the root of the project, or should lib/ and each directory under it, like lib/point/ and lib/transform/ also have their own index.d.ts files? Thanks for any guidance on this.

Self documenting method names are the best.

This API documentation is missing.

Currently IDENTITY is the only one. Prebuilt transformations come handy in tests and during development.

For example nudged.Transform.CW90, .CCW90, .X2

These are needed to find if two transformations are almost equal. Let t1 and t2 be transformations. They are almost equal if following is true:

t1.subtract(t2).norm() < EPSILON

Implement methods:

• transform.toArray()
• nudged.createFromArray(arr)

Working on gesture handling and this lib literally saved me tons of hours. Please accept my worship 🙇🏻‍♂️ 🙇🏻‍♂️ 🙇🏻‍♂️

Parse values from CSS transform property string. Can be used to modify the transform of the element.

Let the domain be [[-1,0],[1,0]] and the range [[0,-1],[0,1]]. The in other words the plane rotates 90 degrees.

Let us apply TS estimator. The estimate becomes { a: 0, b: 0, x: 1, y: 0 } which means that all points map to [1,0].

This is optimal behavior in a sense that it maps the domain as close to the range as possible. However, is this desired behavior? The singularity causes information loss. It maps the whole space to a point and therefore it is not anymore an affine transformation but an affine map. Should we promise that the estimates are always true affine transformations?

An approach that would satisfy the requirement is to fall back to translation if the linear transformation becomes singular. However, this causes a discontinuity at rotation angles near 90 degrees.

Another approach would always estimate a TSR and then extract the required part, TS.

Request to implement matrix multiplication.

Documentation says that nudged.Transform#get_matrix() returns affine matrix in the following form (which would be incorrect if it did):

|s  -r  tx|
|r   s  ty|
|0   0   1|

In fact, the function returns proper matrix (contrary to the doc) which is:

|s*cos -s*sin  tx|
|s*sin  s*cos  ty|
|0      0      1|

Allow identity transformation type. It would help users because the calling code can call nudged even when no estimation needs to be done.

nudged.Transform.IDENTITY

Is the identity transformation equal to nudged.Transform(1,0,0,0)

A single domain point and a range point should not cause rotation. However in v1.3.0 the following happens:

> var domain = [[0.21255673222390348, 0.20282314674735248]]
> var range = [[0.20801815431164927, 0.19818456883509827]]
> var tr = nudged.estimateTR(domain, range)
> tr.getScale()
1
> tr.getRotation()
3.141592653589793
> tr.getTranslation()
[ 0.42057488653555275, 0.40100771558245074 ]
> tr.getMatrix()
{ a: -1,
  b: 0,
  c: -0,
  d: -1,
  e: 0.42057488653555275,
  f: 0.40100771558245074 }

What causes this?