When vectorization is enabled we start using 'fast' math, and therefore instead
of getting perfect 0.0 values we get values that are extremely close to zero.
There was an error in the test_equal comparison that would return true
when the second value was 0 (or close to 0) and the first value was not.
This was a bug I introduced with commit
b270438fea8a9fe4200322bfe6344ab2075c4d9a. I clearly misinterpreted how a
conditional worked.
This class implicitly stores the point coordinates for a rectilinear
cell (such as a voxel) with just the location of the lower left point
and the spacing in each dimension. In addition to saving space, this
class should allow cell-specific functions to specialize for faster
processing.
The PrintSummary for CoordinateSystem went in an infinite loop. It was
supposed to call PrintSummary of its superclass (Field), but instead it
called itself.
The PrintSummary for Field only worked for fields of type vtkm::Float32.
To make it work for all array types, I added a PrintSummary method to
DynamicArrayHandle, and Field calls that without trying to cast to a
static type.
Variable topology fields
Changes to fetching in topology maps that lets you properly deal with cases where you do not know how many values are being fetched at compile time. For example, explicit cell sets can have any number of cell shapes that have different numbers of nodes.
This change should resolve issue #26.
See merge request !128
The PGI compiler appearently saw the condition (var != var) and optimized
it to always be false. However, in this particular case var was holding
a NaN value that we were testing to make sure it does not equal itself.
Get around the problem by comparing the variable to the result of a
function call.
This class holds a Vec and exposes some number of components. The class
is used when you need a Vec of a size that is not known at compile time
but that a maximum length of reasonable size is known.
Some changes to the Vec class and VecTraits in anticipation of creating
Vec-like objects. The following changes are made:
* Add GetNumberOfComponents to Vec, which returns NUM_COMPONENTS.
* Likewise, all VecTraits have a GetNumberOfComponents method.
* The ToVec method in VecTraits is changed to CopyInto so that it can be
used when the length of the Vec-like is not known. CopyInto is also
added to Vec.
* VecTraits has a typedef named IsSizeStatic which is set to
VecTraitsTagSizeStatic when the number of components is known at compile
time and VecTraitsTagSizeVariable when the number of components is not
known until runtime.
C and C++ has a funny feature where operations on small integers (char
and short) actually promote the result to a 32 bit integer. Most often
in our code the result is pushed back to the same type, and picky compilers
can then give a warning about an implicit type conversion (that we
inevitably don't care about). Here are a lot of changes to suppress
the warnings.
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 test_equal method compares the ratio of the two values to decide if
they are close enough. Although there is a previous check to make sure
that neither value is too close to zero, the MSVC sometimes gives a
warning because it cannot trace the flow of the check. Add another
conditional (that will never actually be executed) to check a second time
that we never divide by 0.
Unlike most compilers, MSVC will give conversion warnings when
implicitly converting a 32-bit int to a 32-bit float because the
mantissa can potentially drop some of the lower order bits of large
ints. Use static casts to (hopefully) remove the warnings.
Some compilers, particularly icc, do strange things to literals during
optimization that makes them slightly different. This change was originally
to fix a testing issue with the icc build. It is not actually fixing the
problem, but I am leaving in the change because it is good practice.
Robert Maynard pointed out that the unary operator- I added to Vec could
lead to undesirable behavior for vectors of unsigned integer types. This
changed makes the definition of operator- conditional on the component
type being either a signed integer or a float type.
I also added some more actual testing of the new operator.
Previously, the templated Vec classes had overloaded multiply operators
to allow it to be multiplied by any basic type (float, double, int,
long, char, etc.). This was there to make it easier to multiply a vector
by a scalar without having to jump through introspection hoops for the
component types. However, using them almost always resulted in a
conversion warning on some type of compiler, so I think it is easier
just to remove them.
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.
Fancy Arrays as input to Device Algorithms
Currently working on the general approach to get ArrayHandleZip/Permutation to be handled by all device adapter algorithms.
See merge request !32
Fix compile warnings that come up with the flags
-Wconversion -Wno-sign-conversion
This catches several instances (mostly in the testing framework) where
types are implicitly converted. I expect these changes to fix some of
the warnings we are seeing in MSVC.
I was going to add these flags to the list of extra warning flags, but
unfortunately the Thrust library has several warnings of these types,
and I don't know a good way to turn on the warnings for our code but
turn them off for Thrust.
