The namespaces need to be different for each test, or else only the first
implementation of the function will be used for all tests that call that
function.
Also updated the test to verify that we can count starting from a non zero
number.
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
A couple of tests were failing with the Intel compiler due to
imprecision in comparing floating point values.
Also snuck in some minor documentation fixes in a comment for
FunctionInterface.
The unit test for StorageBasic tested the StealArray feature and then
used the delete[] operator on the stolen array to deallocate it. For
many standard libraries the default implementation for delete[] is
the same as (or at least compatible with) std::allocator, but for
the PGI compiler they were not compatible and this resulted in a
run-time error. This change fixes the problem with the test by using
the same allocator as the StorageBasic test.
It's easy to put accidently put something that is not a valid tag in a
ControlSignature or ExecutionSignature. Previously, when you did that
you got a weird error at the end of a very long template instantiation
chain that made it difficult to find the offending worklet.
This adds some type checks when the dispatcher is instantated to check
the signatures. It doesn't point directly to the signature or its
parameter, but it is much closer.
Instead of just checking that a dispatcher's Invoke input is an
ArrayHandle, also check that the ValueType of the ArrayHandle is
compatible with the types of the worklet operator. This is done by
adding a template argument to the ControlSignature tags that is a type
list tag that gets passed to the type check.
The Transport class is responsible for moving data from the control
environment to the execution environment. (Actually, it might be more
accurate to say it gets the execution environment associated with a
given control object.) The Transport class is templated with a tag that
controls the mechanism used for the transport.
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.
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.
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.
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.
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.
