Unary operations on scalars and vectors will return vtkm::Float64 for
integral input types and vtkm::Float64 input types. Unary operations will
return vtkm::Float32 for vtkm::Float32 input vectors and scalars.
Changed return types for all scalar and vector unary math operations
to return vtkm::FloatDefault instead of input type. vtkm::Float64 will
be returned when the input is vtkm::Float64.
Modified the vector magnitude worklet to accept VecAll instead
of Vec3 and return Scalar. Modified the Magnitude() and Sqrt() functions
to return FloatDefault for all inputs except for Float64.
Perhaps we should modify other functions in Math.h and VectorAnalysis.h to
return float types for intergral arguments instead of integral types?
Literals that are used to represent the bits of certain floating point
numbers (e.g. VTKM_NAN_BITS_64) are placed into unsigned integers before
converted to floating points. We ran into an example where the compiler
complained that a literal (specifically VTKM_NEG_INF_BITS_64) was
declared signed and was negative but then placed in an unsigned (64-bit)
integer. This should fix the problem by making the literal itself
unsigned.
The math nonfinite check functions (like IsNan) were calling the std
equivalent function. This is fine for most architectures, but is not
available for devices under CUDA. Instead, call the CUDA version of
these functions when compiling with CUDA.
This fixes an issue that became apparent once we added CUDA error code
checking.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
We had a report that vtkm::Min/Max was significantly slower than other
products. This was traced back to the fact that these functions were not
completely inlining because they were calling fmin or fmax, and that
resulted in an actual C library call. It turns out using the templated
functions in the std namespace is faster.
This change has the VTK-m min/max functions use the std version in
almost all circumstances. The one exception (so far) is that fmin and
fmax are used for CUDA devices since the std functions are not declared
to run on the device and the nvcc compiler treats these functions
special.
On one of my compile platforms, GCC was giving conversion warnings from
any boost include that was not wrapped in pragmas to disable conversion
warnings. To make things easier and more robust, I created a pair of
macros, VTKM_BOOST_PRE_INCLUDE and VTKM_BOOST_POST_INCLUDE, that should
be wrapped around any #include of a boost header file.
The VTKM_MSVC is just defined if using MSVC. It is not set to any value.
There was a reference in Math.h that assumed it was set to true, which
it was not. This simple change should fix that.
Also fix some issues that caused the compile to fail when trying to
run some of the math functions on a CUDA device. In particular, CUDA
is picky about using a global const on a device when the const type is
not one of the basic C types.