Doxygen was having trouble with `@copydoc` when copying documentation of
templated functions. The doxygen comments in `Math.h` is restructured to
not need `@copydoc`, and the documentation is generated correctly.
The maximum recursion that could happen was 1 call in, but compilers had
trouble determining that. Split this into 2 non-recursive functions so
the compiler can easily determine the stack depth.
There is a small section in the code generated from Math.h.in that is
subject to clang formatting. A recent change reformatted that bit of
Math.h, so we need to update Math.h.in accordingly.
This is only set while compiling device code, and is useful
for code that needs different implementations on devices (e.g.
they call CUDA device intrinsics, etc).
This commit adds several geometric constructs to vtk-m
in the `vtkm/Geometry.h` header. They may be used from
both the execution and control environments.
We also add methods to perform projection and Gram-Schmidt
orthonormalization to `vtkm/VectorAnalysis.h`.
See `docs/changelog/geometry.md` included in this commit
for more information.
a9e64c4b FloatPointReturnType is float if 'T' is < 32bytes instead of being double.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Acked-by: Thomas Otahal <tjotaha@sandia.gov>
Merge-request: !1048
There were some recent changes to supress some CUDA errors in (among
many other places) some Math.h functions. These changes were done to
Math.h, but they also need to be reflected in Math.h.in so we can
continue to mainting the automatically generated functions.
Previously FloatPointReturnType would always be double for types that
are not float, which caused Int8/Int16 types to promote to double instead
of float.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
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.
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.