Ticket #744 (closed defect: fixed)
Verify Imglib OPS function definitions & inputs
Reported by: | bdezonia | Owned by: | bdezonia |
---|---|---|---|
Priority: | major | Milestone: | imagej2-b6-legacy |
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:2 Changed 8 years ago by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:3 Changed 8 years ago 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 7 years ago by bdezonia
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:7 Changed 7 years ago by bdezonia
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:8 Changed 7 years ago 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 7 years ago by bdezonia
- Milestone changed from imagej-2.0.0-beta7 to imagej-2.0.0-beta6
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.