Ticket #744 (closed defect: fixed)
Opened 20110906T12:50:5105:00
Last modified 20121121T11:48:0006:00
Verify Imglib OPS function definitions & inputs
Reported by:  bdezonia  Owned by:  bdezonia 

Priority:  major  Milestone: 

Component:  ImgLib2 OPS  Version:  
Severity:  serious  Keywords:  
Cc:  Blocked By:  
Blocking:  #1571 
Description
A goodly number of operations were added to OPS recently  both in the operation.complex and operation.real packages. There are a couple things that need to be done yet.
1) we need to verify (especially in the complex cases) that the function definitions are correct. This is easily done via the MathWorld website.
2) some functions can fail with divide by zero errors. we need to update their compute() methods to check their input values for validity. Mathworld can be of help here but also the definitions themselves show divide by zero potentialities.
Change History
comment:1 Changed 20110913T09:57:5605:00 by bdezonia
comment:2 Changed 20110921T15:02:3305:00 by bdezonia
 Milestone changed from imagej2.0beta1 to imagej2.0beta2
comment:3 Changed 20120206T12:32:2506:00 by bdezonia
Java can handle divide by 0.0 just fine. But we may want to reason about whether there are output values that make sense (i.e. some limit as input approaches 0 or approaches other values that result in divide by 0). Look at this as time allows.
comment:5 Changed 20120514T10:14:5705:00 by bdezonia
 Milestone changed from imagej2.0.0beta3 to imagej2.0.0beta4
comment:7 Changed 20120906T16:57:5205:00 by bdezonia
 Milestone changed from imagej2.0.0beta4 to imagej2.0.0beta5
comment:8 Changed 20121105T13:17:1906:00 by bdezonia
 Status changed from new to closed
 Resolution set to fixed
I don't think we need to do this anymore. The existing operations are documented and the output values follow convention. The rest is vague issues.
comment:10 Changed 20121121T11:48:0006:00 by bdezonia
 Milestone changed from imagej2.0.0beta7 to imagej2.0.0beta6
Recently I went through all the Real and Complex operations and tagged their source code with references to documentation confirming definitions. Where the code was wrong I fixed it.
For performance reasons I have decided against wholesale input checking. A divide by zero error message is not horrible (as opposed to a "archosh() : bad input" message). Also I compared to Matlab and it has little error checking for problem cases.
One place where input checking would be good are cases where operations that invert some other function's value could result in a divide by zero. For instance arccsc(x) == 1 / arcsin(x) (I think). However if the denominator = 0 then we can reason what the function value should be.