Missing "Const" attribute in xml

[dpoen]

@wmayer no clue if this is really related: https://forum.freecadweb.org/viewtopic. ... 10#p565791
but could it be that the function for obj.Shape.scaled is also missing this const attribute?

I might be dreaming, but still, I says it :
Just the post before, I read "I have absolutely no idea where the magic take place in the code when assigning a new value to '.Shape'. "
That make me think about an issue with the Matrix (and as well with Placement) : when calling the inverse() method, "sometimes" it actually change the Matrix (afaik and remember, the Matrix take the value of the inverse, "as if" the result of the computation have been applied to the object).
But it's kinda hard to find a reproducible example to showcase it... :/
This is why I've looked into the const attribute.
My current solution is everytime I have to inverse a matrix, I use FreeCAD.Matrix(m).inverse() instead of m.inverse()

[adrianinsaval]

to me this looks like the matrix is actually getting edited when calling inverse() rather than just returning the inverted matrix: https://github.com/FreeCAD/FreeCAD/blob ... x.cpp#L487
I have no idea when a function is considered const really

[wmayer]

Yes, it's missing there too: git commit a527daa4b3

[adrianinsaval]

Yes, it's missing there too: git commit a527daa4b3

thanks!

[wmayer]

I have no idea when a function is considered const really

Basically if the underlying C++ method is const then the attribute for the Python wrapper can be set.

[dpoen]

to me this looks like the matrix is actually getting edited when calling inverse() rather than just returning the inverted matrix: https://github.com/FreeCAD/FreeCAD/blob ... x.cpp#L487
I have no idea when a function is considered const really

In python, Matrix.inverse() return the inverse and invert() actually inverse the matrix "in place", overwriting it (note that the python api and the c++ api naming are different...)

[dpoen]

Forgot to link the PR....
https://github.com/FreeCAD/FreeCAD/pull/7073

[adrianinsaval]

In python, Matrix.inverse() return the inverse and invert() actually inverse the matrix "in place", overwriting it (note that the python api and the c++ api naming are different...)

got it, everything makes sense now!

[jnxd]

In python, Matrix.inverse() return the inverse and invert() actually inverse the matrix "in place", overwriting it (note that the python api and the c++ api naming are different...)

This is a point of contention though: matrices shouldn't explicitly be inverted. Ideally there should be a function that solves an equation Ax = b where A is our matrix, for example, by LU decomposition. Otherwise we're quickly looking at large round-off errors.

[dpoen]

This is a point of contention though: matrices shouldn't explicitly be inverted. Ideally there should be a function that solves an equation Ax = b where A is our matrix, for example, by LU decomposition. Otherwise we're quickly looking at large round-off errors.

I kinda agree, but the main point is that we are dealing here with very small matrix (and with size being known)...

- About the speed of the operation :
Yes, there is a 3 time ratio between both way, but I often need to solve one given system for many inputs : example : if I when to change the origin of multiples points (lets says a mesh), I need to take the inverse matrix of the transform of the target origin, then multiply by all the point in my mesh to get the work done. At this point I'm way better off computing the inverse matrix once and multiply by all my point (granted, it's faster only if I have more than 3 point in my mesh, which is often the case)
Moreover, given the figure 2 in "Numerical experiments", if I look at the curve for n=4, I get only negligible value, so I'm not sure if it's worth it... Yes, 3 times faster is 3 times faster, but I mean FreeCAD is not aimed at inverting matrix, and other stuff will take significantly much more time...

- About the loss of accuracy :
Given the figure 3 in "Numerical experiments", if I look at the curve for n=4, the error doesn't seems to be such a big deal, IMHO

- About our use case :
I do think (but I could be vastly wrong) that more often than not FreeCAD matrix are often transformation (rotation/translation...), and might be well invertible (ie well-conditioned) (but don't quote me on that). (and for my use case, I should replace the inversion of rotation matrix by transpose, but I'm too lazy now xD)

Having say that, it will not harm to add a matrix.solve(vector) method that will compute matrix.inverse()*vector, using the fast way

Whatever the conclusion is, invert() and inverse() should continue to exist, but should behave correctly, as described earlier !

That my 2cents !

PS: @jnxd I did start a work of cleaning up the https://github.com/FreeCAD/FreeCAD/blob ... Matrix.cpp file, which contains the code to inverse a matrix https://github.com/FreeCAD/FreeCAD/blob ... x.cpp#L492. But I'm not so confident to work on that part of the code... If you feel up the task, we might join forces
I've exposed my thought here : https://forum.freecadweb.org/viewtopic. ... 55#p568155 and the branch : https://github.com/ShuffleWire/FreeCAD/ ... ean_matrix