PR #2475: Expression syntax extension

[wmayer]

I have doubts: in Base/Placement.cpp

Nope, the implementation is correct.

meaning that a rotation's inverse() is effectively it's matrice's inverse, but a translation's inverse() is its opposite (negative). Which is of course the correct mathematical operation.

So, your suggestion is to invert the rotation and simply multiply the translation with -1. Here is an example that this is wrong:

Code: Select all

p=App.Placement(App.Vector(1,1,1), App.Rotation(1,0,0,0))
q=App.Placement(-p.Base, p.Rotation.inverted()) # is assumed to be the inverse
p.multiply(q) # should give the identity but it isn't, it's: Placement [Pos=(0,2,2), Yaw-Pitch-Roll=(0,0,0)]

# but
p.multiply(p.inverse()) # gives the expected result: Placement [Pos=(0,0,0), Yaw-Pitch-Roll=(0,0,0)]

The placement describes an affine transformation where a point x is transformed to y. With the given rotation matrix R and the translation t it can be written as:
y = R * x + t

If you want to get the inverse transformation it's a matter of solving the algebraic equation to x:
y = R * x + t
<=>
y - t = R * x, with Q := R**-1, R is always invertible (because its inverse is its transposed) so that Q exists
<=>
Q * (y - t) = Q * (R * x)
<=>
Q * y - Q * t = (Q * R) * x, because matrix multiplication is associative
<=>
Q * y - Q * t = I * x, because Q is the inverse of R, I is the identity matrix
<=>
x = Q * y - Q * t

So, this is an affine transformation with the rotation Q and the translation -Q * t

[Zolko]

I have doubts: in Base/Placement.cpp

Nope, the implementation is correct.

yes, I know

meaning that a rotation's inverse() is effectively it's matrice's inverse, but a translation's inverse() is its opposite (negative). Which is of course the correct mathematical operation.

So, your suggestion is to invert the rotation and simply multiply the translation with -1. Here is an example that this is wrong:

no, what I'm saying is that the inverse() of a rotation is the inverse of the rotation matrix, and the inverse() of a translation is the opposite (negative) of the translation vector. And that's correct. Because I was talking about pure rotations and translations. Now, these cannot be combined simply, yes, I know.

[wmayer]

Okay.

[Zolko]

you seem to have missed the second line in the function you quoted, which also acts on translation part of a placement.

no, I didn't miss it: let's see what multVect() does for a rotation:

Code: Select all

void Rotation::multVec(const Vector3d & src, Vector3d & dst) const
{
    double x = this->quat[0];
    double y = this->quat[1];
    double z = this->quat[2];
    double w = this->quat[3];
    double x2 = x * x;
    double y2 = y * y;
    double z2 = z * z;
    double w2 = w * w;

    double dx = (x2+w2-y2-z2)*src.x + 2.0*(x*y-z*w)*src.y + 2.0*(x*z+y*w)*src.z;
    double dy = 2.0*(x*y+z*w)*src.x + (w2-x2+y2-z2)*src.y + 2.0*(y*z-x*w)*src.z;
    double dz = 2.0*(x*z-y*w)*src.x + 2.0*(x*w+y*z)*src.y + (w2-x2-y2+z2)*src.z;
    dst.x = dx;
    dst.y = dy;
    dst.z = dz;
}

which means that if the rotation quaternion is zero, the destination point is unaffected (dx=dy=dz=0). Meaning that the Placement.inverse() of a pure translation is -Placement .... which is I think correct.

EDIT: no, it's not correct, I was too fast: the quaternion for a 0° rotation is not 0 but identity : (0,0,0,1). Therefore, we don't have dx=dy=dz=0 but dst.x=dx=src.x, dst.y=dy=src.y and dst.z=dz=src.z, in other words dst=src. . Wich still means that the destination point is unaffected.

[Zolko]

PR link here

I can see in that PR that "Base: add Python number protocol support to Placement/Rotation" has been merged, and indeed in the latest AppImage (FreeCAD_0.19-18227...) it is possible tu use Placements in the ExpressionEngine, like:

Code: Select all

Bielle#LCS_1.Placement

but unfortunately it's not possible to do operations on those Placements, like multiplication (*) or inverse (^1).

Well, I can add number protocol to Placement too, just like matrix, so you can do something like

Code: Select all

Group.<<Box.>>.Placement * Group.<<$Cube.>>.Placement ^ -1

This would be a very important addition to allow Asm4 to work with the merged App::Link of v0.19-pre

[realthunder]

I can see in that PR that "Base: add Python number protocol support to Placement/Rotation" has been merged

No, this PR is still open. I have add support to invert the placement (with ^-1).

[Zolko]

this PR is still open. I have add support to invert the placement (with ^-1).

I'm sorry if I seem too impatient, but this feature - the ability to multiply and invert Placements inside an ExpressionEngine - would be very important for App::Link. Is there anything I can do to help with this ? This is not strictly an App::Link thing, may-be someone else as realthunder knows how to extend the ExpressionEngine parser ? The underlying maths are already in place (::operator* and .inverse() methods for Base::Placement) so it's really "only" a parser thing (but I don't want to seem to minimize the complexity involved)

ping

any idea ?

[Kunda1]

FYI, yorik is on vacation...so @wmayer has a lot more workload then he's already used to.

[Zolko]

realthunder force-pushed the realthunder:ExprOp branch from ef65725 to 768a641 yesterday

not sure to understand what that means.

[realthunder]

realthunder force-pushed the realthunder:ExprOp branch from ef65725 to 768a641 yesterday

not sure to understand what that means.

I added a new commit to fix a problem. I also force pushed it to rebase it with the current upstream head.