floating point invalid operation in transform
billv wrote on Jan 26, 2011
I get the message "ERROR: floating point invalid operation" while trying to run TRANSFORM on images. identify, reidentify, and fitcoords have all run without problems. I understand that this error arises from some operation fault, but the images do not have NaN's or unusually large or small values. Could the problem be related to bug # 559? (I'm not using log resampling though.)
I'm running v2.14 on a MacBook Pro under Snow Leopard.
I'm running v2.14 on a MacBook Pro under Snow Leopard.
Mike Fitzpatrick wrote on Jan 26, 2011
It is highly likely that Bug #559 is a resolved issue and your problem comes about because of either something in the data/header or your parameter values. There is no known issue with the task, if you could post your image and parameters (i.e. a 'dpar transform" output) to the anonftp at ftp://iraf.noao.edu/pub we'll see if we can reproduce and debug the problem.
billv wrote on Jan 26, 2011
The image has been posted to the anonftp site, along with the parameters and the database files.
Mike Fitzpatrick wrote on Jan 26, 2011
I'm gonna pass this to Frank for resolution. I can reproduce the problem which comes down to essentially a divide-by-zero problem when initializing the task.
Francisco Valdes wrote on Jan 26, 2011
Hi,
The problem is the surface you created with fitcoords is constant (i.e. maps all points to the same value) on one axis. The surface should have a minimum order of 2 (a linear function) for each axis. There are also potential problems with fitting the 2D dispersion/spatial function when the sampling is not very uniform (in your case there are only a few lines) and the fit could do funny things where it becomes poorly constrained.
I redid a fitcoords solution with orders of 2 and it worked. All the attempts you made used an order of 1 for the spatial part. I have modified fitcoords for a future release such that it is not possible to set the orders to 1 (or less) in fitcoords.
I am not 100% certain that this will avoid transform encountering a arithmetic exception because the surface inversion process is tricky and if functions become non-monotonic it is possible for zero derivatives to result in a zero denominator. I added some checks for this but it did not stop arithmetic exceptions with the case your provided.
So go back to fitcoords and use a minimum order of 2 for either axis.
Frank Valdes
The problem is the surface you created with fitcoords is constant (i.e. maps all points to the same value) on one axis. The surface should have a minimum order of 2 (a linear function) for each axis. There are also potential problems with fitting the 2D dispersion/spatial function when the sampling is not very uniform (in your case there are only a few lines) and the fit could do funny things where it becomes poorly constrained.
I redid a fitcoords solution with orders of 2 and it worked. All the attempts you made used an order of 1 for the spatial part. I have modified fitcoords for a future release such that it is not possible to set the orders to 1 (or less) in fitcoords.
I am not 100% certain that this will avoid transform encountering a arithmetic exception because the surface inversion process is tricky and if functions become non-monotonic it is possible for zero derivatives to result in a zero denominator. I added some checks for this but it did not stop arithmetic exceptions with the case your provided.
So go back to fitcoords and use a minimum order of 2 for either axis.
Frank Valdes
Last post on Jan 26, 2011