| • schwarzt | |
| Nov 9 2009, 9:51 PM |
| F368: NoNaNCheckGeometry3D.patch | |
| Nov 9 2009, 9:52 PM |
Is the check for NaN's in mitk::Geometry3D::BackTransform() still necessary?
(Method called by IndexToWorld()).
This method is actually one of the very few in the inner most loop of algorithmic calculations, especially registration, so every line of code here underlies quite critical speed considerations.
Ivo actually spend some time to optimize vector addition here in Assembler.
So, with the closing of T1995, can we remove the check for NaN's here?
Daniel, please have a look.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T2883 Check for NaN's in mitk::Geometry3D still necessary? Speed considerations. | ||
| Resolved | None | T2885 Strange function in mitk::Geometry3D() |
Could you please ask Daniel or Thomas to quickly evaluate about how much change in execution time we are talking? (just do a normal 3D registration with and without the patch)
My guess is that the change is insignificant.
Where did Ivo work on Assembler code??? Assembler is platform specific and probably not easily optimizable. I'm just curious.
Thomas or Daniel,
can you try to run a long lasting registration with and without these lines:
if (inverse[i][j] != inverse[i][j] ) // this is only true for NaN
{
++nans;
}at mitk::Geometry3D, line 374.
Thanks.
Tobias changed this method to use vnl has_nans(), which is supposedly fast, making this bug irrelevant.