Additional Issues for Vector and Image Arithmetic

[calvin.harman@…]

This bug was created for the purpose of generating additional discussion for
section 4.7 of the SDRS and addressing follow-up issues to:

1) Bug #28, "List of Binary and Unary Operations..."
2) Eugene's prototype vector/matrix macro code.
3) IfA header files.
4) MHPCC code implementation.

With clarifications of the required arithmetic operations in Bug 28 and the
sample code, there are still a number of operations to be considered:

1) Function combinations: psBinaryOp or psUnaryOP.

2) Structure combinations: psVector-psVector, psImage-psVector, psVector-

psScalar, psImage-psScalar, psImage-psImage, psImage-psVector(transpose), etc.

3) Data type combinations: S32, F32, F64, C32, etc.

4) Arithmetic combinations: +, -, *, /, ^{, ln, log, sin, asin, etc.}

There are several hundred possibilities, and not all arithmetic operations and
data types fall into categories that can be reused with generic function
macros. Issues encountered to date include:

1) Is mixing of data types (i.e. F32 with S32) allowed?
2) Checking for divide by zero for "/" when other operations don't need it.
3) Differences in complex function names over standard c function names.
4) Definition of min, max for complex functions.
5) Debugging/readability of function macro code.
6) Do image-vector operations act on all rows or just the first?
7) Should number of elements in image-image (and others) agree?
8) Definition of psScalar...

Should it be consistent with psImage and psVector definitions?
Should it be private?
Should there be a psScalarAlloc, psScalarFree?

[eugene]

we need to iterate on a few of these issues. for some, the answers are easy:

1) mixing of types is not allowed (SDRS updated to specify this)
6) image op vector operates on all rows / columns of the image
7) number of elements (image/vector sizes) must agree

[calvin.harman@…]

A few more questions...

1) Is there a definition of ten() for complex numbers?

2) In psLib standards, are casts allowed for complex and real numbers as in:

complex double c = 3 + 4i;
double x = (double)c; Works. Now x = 3

double y = 3;
complex double d = (complex double)y; Works. Now d = 3 + 0i

[eugene]

responses to the remaining points listed below:

2) divide by zero: it will be necessary to check, which means the macro
implementation will have to include some alternate forms for such functions

3) we have to be a bit careful here: for example, log of a negative float is
defined for complex math, but not for real math. same for sqrt. the functions
we specify for psImage and psVector probably should follow that same behavior:
ie, you must use the complex function name to have the behavior on a real data
type. we must be careful here.

4) casting of real to complex and vice versa will follow the C standard as
identified by Ross

[Eric.VanAlst@…]

The resolution specifies a list of operators but there is no list in SDR-06
section 4.7. The list of operator should be added to the SDR.

[Paul Price]

Added the list of operators to the SDRS. Got the list from the rel2_2 of
psMatrixVectorArithmetic.c

The list of required operators for \code{psBinaryOp} are:
\begin{itemize}
\item Addition (+)
\item Subtraction (-)
\item Multiplication (*)
\item Division (/)
\item Power (^{)
\item Minimum (min)
\item Maximum (max)
\end{itemize}}

The list of required operators for \code{psUnaryOp} are:
\begin{itemize}
\item Absolute value (abs)
\item Exponent (exp)
\item Natural Log (ln)
\item Power of 10 (ten)
\item Log (log)
\item Sine (sin and dsin)
\item Cosine (cos and dcos)
\item Tangent (tan and dtan)
\item Arcsine (asin and dasin)
\item Arccosine (acos and dacos)
\item Arctan (atan and datan)
\end{itemize}
The trigonometric operators prefixed with d refer to the standard
trigonometric operators acting on input that is in decimal degrees.

[Paul Price]

Should be fixed in SDRS-07 and ADD-06 (7 September 2004).