Lots of tests have to move values in and out of arrays and check them
against expected values. It is also often the case that these tests are
run on lots of different types. There is some repeated code for
generating known values for particular indices. This change unifies some
of that. This can probably also encourage making more generic tests.
The previous commits had TypeListTagAll containing a subset of Vec
types. This commit adds all possible vectors with 2 to 4 components
containing one of the basic C types.
Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
Since we want our code to generally handle data of different precision
(for example either float or double) expand the types in our list types
to include multiple precision.
Previously we just hand coded base lists up to 4 entries, which was fine
for what we were using it for. However, now that we want to support base
types of different sizes, we are going to need much longer lists.
There are multiple reasons for this name change:
* The name Tuple conflicts with the boost::Tuple class, which as a
different interface and feature set. This gets confusing, especially
since VTK-m uses boost quite a bit.
* The use of this class is usually (although not always) as a
mathematical vector.
* The vtkm::Scalar and vtkm::Vector* classes are going to go away soon
to better support multiple base data type widths. Having this
abbriviated name will hopefully make the code a bit nicer when these
types have to be explicitly specified.
Also modified the implementation a bit to consolidate some of the code.
In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).
Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
The previous behavior of the pyexpander check (in
VTKmCheckPyexpander.cmake) was to generate the file in the binary
directory and then remove it from there iff the check failed. This
caused two problems. The first is that if the check failed then the file
was deleted and there was no file to copy to the source as the
instructions suggested. The second is that if the check succeeded the
build would then use the files in the build directory rather than the
source directory, and if the programmer accidently modified the binary
files (because, for example, if a build error occured there), the
configure system would not catch that.
This change in behavior was that if the check failed, the file is
renamed to have a .save extension so that the file remains and can be
easily copied back to the source directory if that is appropriate. If
the check succeeds, the generated file is removed and a file with the
extension .check is touched. That .check file is used as a make target
to signal that the test has been performed.
We have a test for FunctionInterface to make sure that calling a function
indirectly through that is about as fast as directly. On MSVC we sometimes
observe that this timing fails in debug mode. This is probably the compiler
adding some code to each function invocation. That won't happen in production
compiles, so we don't care about it too much. Make an exception in this case.
When compiling with 32-bit Ids for a 64 bit machine (which is not
uncommon), it is possible that the distance between two iterators
is larger than the maximum value that can be stored in vtkm::Id.
If two such iterators were passed to ArrayPortalFromIterators, that
would cause problems.
This change checks for that condition and throws an out of memory
exception if it occurs. That would be a pretty darn big array and
is more likely to be the cause of an error somewhere else in the
code, but either way the check and error is good. This change also
fixes a warning we have been getting with MSVC.
The SystemInformation test always passes. It prints out the contents of
various configuration parameters. The intention is to capture this
information in dashboard reports. That way if a change causes a
dashboard failure and a developer does not have access to the dashboard,
she can look at the output of this test to see the configuration of the
build and that machine.
For MSVC we use the non-portable wrapper stdext::checked_array_iterators
because the compiler insists on it for safety. When we check to make sure
our templates are giving us raw pointers, we have to check for this wrapper
instead of the raw pointer itself.
This moves the ability to get an iterator from an array portal out of
the portal itself. The next step is to move the GetIteratorBegin/End out
of ArrayPortal. This should make the implemenation a bit cleaner.
MSVC likes to warn about using raw pointers as iterators in generic
algorithms because they have been known to lead to problems. When
compiling with that compiler, wrap raw pointers in
stdext::checked_array_pointer to suppress the error and also add a bit
more checking.
The CMake template for the source file that contains the main function for
tests uses functions that MSVC considers unsafe. We want to check for these
conditions but have no control over the CMake-generated test code (which
looks right anyway). This disables the warning specifically for those
source files but nothing else.
I wanted to test ArrayHandleCounting with some non-standard data type.
I was using a class that looked like a number that counts by two, but
the operator behavior was not a proper group and that was causing issues.
Replaced that with a class that inefficiently represents an unsigned
integer as a string with that many characters. The inefficiency does not
matter because it is just a test.
It appears that when the Intel compiler is optimizing, constant floating
point values can be slightly different than the same value stored in memory
and never changed. This change uses the test_equal method to compare
these floating point values that might have a slight numeric error.
Although we cannot expect every developer to have pyexpander, for those
that do the build will automatically run it and check the expanded file
in the source code. If they match, a descriptive error is given.
We don't automatically update the file because subtle problems might
occur. It is better to alert a developer to fix the problem properly.
This commit removes the usage of the boost preprocessor library to
iteratively generate templates with a variable number of parameters. It
is replaced with a template that is expanded by running it through the
pyexpander macro processing tool (http://pyexpander.sourceforge.net).
One reason for this change is to make the code easier to read. In
particular, it is difficult to understand compiler errors when they
occur deep within an iterating macro. Another reason for this change is
that the Intel compiler currently has a bug that breaks with the boost
preprocessor library.
One issue with this approach is that the macro expansion is not part of
the build process. Although open, pyexpander is not a tool most
developers will have readily installed on their system. Thus, if you
want to make changes to any of the macro code, you have to make sure
pyexpander is installed, then make changes to the input files, then
manually run pyexpander from the command line.
After a talk with Robert Maynard, we decided to change the name
ArrayContainerControl to Storage. There are several reasons for this
change.
1. The name ArrayContainerControl is unwieldy. It is long, hard for
humans to parse, and makes for long lines and wraparound. It is also
hard to distinguish from other names like ArrayHandleFoo and
ArrayExecutionManager.
2. The word container is getting overloaded. For example, there is a
SimplePolymorphicContainer. Container is being used for an object that
literally acts like a container for data. This class really manages
data.
3. The data does not necessarily have to be on the control side.
Implicit containers store the data nowhere. Derivative containers might
have all the real data on the execution side. It is possible in the
future to have storage on the execution environment instead of the
control (think interfacing with a simulator on the GPU).
Storage is not a perfect word (what does implicit storage really mean?),
but its the best English word we came up with.
