[vspline] 38/72: removed interpolator.h from the repository
Kay F. Jahnke
kfj-guest at moszumanska.debian.org
Sun Jul 2 09:02:41 UTC 2017
This is an automated email from the git hooks/post-receive script.
kfj-guest pushed a commit to branch master
in repository vspline.
commit 5b1d08d6f57e7e2c1e5f6d9aac5b8ce5a3ea2be9
Author: Kay F. Jahnke <kfjahnke at gmail.com>
Date: Sat Mar 18 11:24:35 2017 +0100
removed interpolator.h from the repository
---
interpolator.h | 507 ---------------------------------------------------------
1 file changed, 507 deletions(-)
diff --git a/interpolator.h b/interpolator.h
deleted file mode 100644
index e95b584..0000000
--- a/interpolator.h
+++ /dev/null
@@ -1,507 +0,0 @@
-/************************************************************************/
-/* */
-/* vspline - a set of generic tools for creation and evaluation */
-/* of uniform b-splines */
-/* */
-/* Copyright 2015, 2016 by Kay F. Jahnke */
-/* */
-/* Permission is hereby granted, free of charge, to any person */
-/* obtaining a copy of this software and associated documentation */
-/* files (the "Software"), to deal in the Software without */
-/* restriction, including without limitation the rights to use, */
-/* copy, modify, merge, publish, distribute, sublicense, and/or */
-/* sell copies of the Software, and to permit persons to whom the */
-/* Software is furnished to do so, subject to the following */
-/* conditions: */
-/* */
-/* The above copyright notice and this permission notice shall be */
-/* included in all copies or substantial portions of the */
-/* Software. */
-/* */
-/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND */
-/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES */
-/* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND */
-/* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT */
-/* HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, */
-/* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING */
-/* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR */
-/* OTHER DEALINGS IN THE SOFTWARE. */
-/* */
-/************************************************************************/
-
-/*! \file interpolator.h
-
- \brief interface definition for interpolators
-
- The code in this file formalizes the services of an 'interpolator'.
- In vspline itself, the only use of this class is as a base class of
- class evaluator. Class evaluator is a typical example for a
- vspline::interpolator: it receives coordinates and yields values. But
- of course this sort of interface can be used in many other places -
- in fact naming it 'interpolator' isn't really apt, because it's more
- of a 'functor yielding values at real coordinates'.
-
- The code for class interpolator actually originated as part of
- class evaluator, but then I realized that what is now in class
- interpolator is a broader concept which is useful in itself, and
- best factored out.
-
- The remap routines in remap.h make use of class interpolator rather
- than class evaluator, making them much more versatile. I found that with
- class interpolator at hand I can implement processing pipelines which
- go all the way from a starting point like a bunch of coordinates or
- even only discrete coordinates into a target - to packed 8bit RGBA
- ready to feed to the GPU. This is easily achieved by following a
- functional programming scheme with different classes derived from
- class interpolator. Consider a scenario where you have two processing
- stages, where each can be expressed in terms of a class derived from
- class interpolator.
-
- The first, 'innermost' class provides eval().
-
-~~~~~~~~~~~~~~~~~~~~~
- class A
- : public vspline::interpolator < 2 , float , float , int >
- {
- typedef vspline::interpolator < 2 , float , float , int > base_type ;
- using_interpolator_types(base_type)
-
- ...
-
- void eval ( const nd_rc_type & c ,
- value_type & result ) const
- {
- // code to yield a value_type for a coordinate
- }
- } ;
-~~~~~~~~~~~~~~~~~~~~~
-
- A second, 'outer' class could look like this:
-
-~~~~~~~~~~~~~~~~~~~~~
- class B
- : public vspline::interpolator < 2 , int , float , int >
- {
- typedef vspline::interpolator < 2 , int , float , int > base_type ;
- using_interpolator_types(base_type)
-
- const A & inner ;
-
- B ( const class A & _inner )
- : inner ( _inner ) {} ;
-
- void eval ( const nd_rc_type & c ,
- value_type & result ) const
- {
- inner::value_type x ; // have a place for inner to deposit a value
- inner.eval ( c , x ) ; // let inner run
- result = some_function ( x ) ; // postprocess inner's result
- }
- } ;
-~~~~~~~~~~~~~~~~~~~~~
-
- This scheme also works for preprocessing incoming coordinates, like with
- a coordinate transformation. In fact the whole distinction between 'coordinates'
- and 'values' is arbitrary, the code simply produces n-dimensional output from
- m-dimensional input, where the only limitation is that the values which
- are handled are TinyVectors of some elementary type, and calling the dimension
- of the 'values' 'channels' is just as arbitrary.
-*/
-
-#ifndef VSPLINE_INTERPOLATOR_H
-#define VSPLINE_INTERPOLATOR_H
-
-#include <vspline/common.h>
-#include <vspline/coordinate.h>
-
-namespace vspline {
-
-#ifdef USE_VC
-
-// properly defining the simdized type of a given value_type is quite a mouthful,
-// so we use aliases here. first we define the simdized elementary type of value_type.
-// Inside a struct interpolator we have a type name handy for this type: ele_v
-// simdized_ele_type<T> is used as a template argument.
-
-template < class value_type >
-using simdized_ele_type = typename vspline::vector_traits<value_type>::ele_v ;
-
-// next we define an aggregate of simdized elementary types constituting
-// a simdized value_type. Inside a struct interpolator, we also have a type name
-// for this type: mc_ele_v
-
-template < class value_type >
-using simdized_type = typename vspline::vector_traits<value_type>::type ;
-
-#endif
-
-template < int _dimension , // dimension of the spline
- class _value_type , // type of interpolation result
- class _rc_type , // singular real coordinate, like float or double
- class _ic_type , // singular integral coordinate, like int
- int _vsize = 1 > // number of elements in a vector/SimdArray
-struct interpolator
-{
- // fix the types we're dealing with
-
- typedef _ic_type ic_type ;
- typedef _rc_type rc_type ;
-
- // number of dimensions of coordinates
-
- enum { dimension = _dimension } ;
-
- // number of elements in simdized data
-
- enum { vsize = _vsize } ;
-
- // unvectorized nD coordinates
-
- typedef vigra::TinyVector < rc_type , dimension > nd_rc_type ;
- typedef vigra::TinyVector < ic_type , dimension > nd_ic_type ;
-
- // data type of interpolator's result
-
- typedef _value_type value_type ;
-
- // elementary type of same
-
- typedef typename vigra::ExpandElementResult < value_type > :: type ele_type ;
-
- // number of channels of same
-
- enum { channels = vigra::ExpandElementResult < value_type > :: size } ;
-
- /// for single coordinates we require an eval() taking a const& to a
- /// single coordinate and a reference to the place where the result should
- /// be deposited.
-
- virtual void eval ( const nd_rc_type & c ,
- value_type & result ) const = 0 ;
-
- /// for convenience: operator() using eval()
-
- value_type operator() ( const nd_rc_type & c ) const
- {
- value_type v ;
- eval ( c , v ) ;
- return v ;
- }
-
-#ifdef USE_VC
-
- // for vectorized operation, we need a few extra typedefs
- // I use a _v suffix to indicate vectorized types and the prefixes
- // mc_ for multichannel and nd_ for multidimensional
-
- /// a simdized type of the elementary type of value_type,
- /// which is used for coefficients and results. this is fixed via
- /// the traits class vector_traits (in common.h). Note how we derive
- /// this type using vsize from the template argument, not what
- /// vspline::vector_traits deems appropriate for ele_type - though
- /// both numbers will be the same in most cases.
-
- typedef typename vector_traits < ele_type , vsize > :: ele_v ele_v ;
-
- /// compatible-sized simdized type of vsize ic_type
-
- typedef typename vector_traits < ic_type , vsize > :: ele_v ic_v ;
-
- /// compatible-sized simdized type of vsize rc_type
-
- typedef typename vector_traits < rc_type , vsize > :: ele_v rc_v ;
-
- /// multichannel value as SoA, for pixels etc.
-
- typedef vigra::TinyVector < ele_v , channels > mc_ele_v ;
-
- /// SoA for nD coordinates/components
-
- typedef vigra::TinyVector < rc_v , dimension > nd_rc_v ;
-
- /// SoA for nD shapes (or multidimensional indices)
-
- typedef vigra::TinyVector < ic_v , dimension > nd_ic_v ;
-
- /// SoA for multichannel indices (used for gather/scatter operations)
-
- typedef vigra::TinyVector < ic_v , channels > mc_ic_v ;
-
- /// chunk of vsize real coordinates
-
- typedef vigra::TinyVector < rc_type , vsize > rc_chunk_type ;
-
- /// chunk of vsize integral coordinates
-
- typedef vigra::TinyVector < ic_type , vsize > ic_chunk_type ;
-
- /// chunk of vsize value_type
-
- typedef vigra::TinyVector < value_type , vsize > value_chunk_type ;
-
- /// simdized evaluation routine. This routine takes the simdized coordinate
- /// per const reference and deposits the result via a reference. This
- /// method is pure virtual and must be implemented by derived classes.
- /// This is the only vectorized evaluation routine which a class derived
- /// from vspline::interpolator has to provide: the other eval variants
- /// (below) are taking either or both of their arguments as pointers to
- /// (interleaved) memory and (de)interleave to/from simdized types defined
- /// inside the method. This is provided as utility code by class
- /// vspline::interpolator and is pulled in with a using declaration
- /// in the macro using_interpolator_types, see below.
-
- virtual void eval ( const nd_rc_v & coordinate , // simdized nD coordinate
- mc_ele_v & result ) const = 0 ; // simdized value_type
-
- /// here I provide an (ineffecient) method to evaluate vectorized data by
- /// delegating to the unvectorized evaluation routine. This will work, but
- /// it's slow compared to proper vector code.
- /// But for 'quick shots' one can use this idiom in a derived class:
- ///
- /// virtual void eval ( const nd_rc_v & coordinate ,
- /// mc_ele_v & result ) const
- /// {
- /// broadcast_eval ( coordinate , result ) ;
- /// }
-
- void broadcast_eval ( const nd_rc_v & coordinate , // simdized nD coordinate
- mc_ele_v & result ) const // simdized value_type
- {
- nd_rc_type c ;
- value_type v ;
- rc_type * pc = (rc_type*)(&c) ;
- ele_type * pv = (ele_type*)(&v) ;
-
- for ( int e = 0 ; e < vsize ; e++ )
- {
- for ( int d = 0 ; d < dimension ; d++ )
- pc[d] = coordinate[d][e] ;
- eval ( c , v ) ;
- for ( int ch = 0 ; ch < channels ; ch++ )
- result[ch][e] = pv[ch] ;
- }
- }
-
- /// again, for convenience, operator() using eval()
-
- mc_ele_v operator() ( const nd_rc_v & c ) const
- {
- mc_ele_v v ;
- eval ( c , v ) ;
- return v ;
- }
-
- // next we have a few methods to interface with (interleaved) memory.
-
- /// method to load/gather interleaved memory into a simdized coordinate
-
- void load ( const nd_rc_type * const pmc , // -> vsize coordinates
- nd_rc_v & cv ) const // simdized coordinates
- {
- if ( dimension == 1 )
- {
- cv[0].load ( (rc_type*) pmc ) ;
- }
- else
- {
- for ( int d = 0 ; d < dimension ; d++ )
- {
- cv[d].gather ( (rc_type*) pmc ,
- ic_v::IndexesFromZero() * dimension + d ) ;
- }
- }
- }
-
- /// method to store/scatter a simdized value to interleaved memory
-
- void store ( const mc_ele_v & ev , // simdized value
- value_type * result ) const // -> vsize result values
- {
- if ( channels == 1 )
- {
- ev[0].store ( (ele_type*) result ) ;
- }
- else
- {
- for ( int ch = 0 ; ch < channels ; ch++ )
- {
- ev[ch].scatter ( (ele_type*) result ,
- ic_v::IndexesFromZero() * channels + ch ) ;
- }
- }
- } ;
-
- /// eval taking pointers to vsize coordinates and vsize values,
- /// expecting these data to be contiguous in memory. This variant
- /// provides (de)interleaving of the the data. This method is a helper
- /// routine and deliberately not a pure virtual method. If a derived
- /// class needs it, it can just use the base class' method, which in
- /// turn will delegate to the fully simdized eval above. Having the
- /// variants using pointers here has an advantage: derived classes
- /// do not need to concern themselves with (de)interleaving and the
- /// fastest method of loading/storing the data is picked automatically.
- /// Note how the conditionals on 'dimension' and 'channels' have no
- /// run-time cost, since both values are known at compile-time and
- /// the conditional plus the 'dead' branch are optimized away. So we
- /// get the fastest way of (de)interleaving automatically, as if we'd
- /// handcoded for the specific case.
-
- void eval ( const nd_rc_type * const pmc , // -> vsize coordinates
- value_type * result ) const // -> vsize result values
- {
- nd_rc_v cv ;
- mc_ele_v ev ;
-
- load ( pmc , cv ) ;
- eval ( cv , ev ) ;
- store ( ev , result ) ;
- } ;
-
- /// eval taking a reference to a simdized coordinate and a pointer
- /// to memory accommodating the result, expecting this memory to be
- /// contiguous.
-
- void eval ( const nd_rc_v & cv , // simdized coordinate
- value_type * result ) const // -> vsize result values
- {
- mc_ele_v ev ;
-
- eval ( cv , ev ) ;
- store ( ev , result ) ;
- } ;
-
- /// variant taking the coordinates via a pointer and
- /// evaluating into a simdized result passed in by reference
-
- void eval ( const nd_rc_type * const pmc , // -> vsize coordinates
- mc_ele_v & result ) const // simdized result
- {
- nd_rc_v cv ;
-
- load ( pmc , cv ) ;
- eval ( cv , result ) ;
- } ;
-
-// /// variants loading from and/or storing to iterators. Wile it would be nice
-// /// to call these variants 'eval' as well, we can't do so unless we are more
-// /// specific; passing in the iterator types as template arguments conflicts
-// /// with other signatures which can fit the template.
-//
-// template < class iter_type >
-// void load ( iter_type & source_iter , // iterator yielding coordinates
-// nd_rc_v & cv ) const // simdized coordinates
-// {
-// rc_chunk_type rc_chunk ;
-//
-// for ( int i = 0 ; i < vsize ; i++ )
-// {
-// rc_chunk[i] = *source_iter ;
-// source_iter++ ;
-// }
-//
-// load ( (nd_rc_type*) (&rc_chunk) , cv ) ;
-// }
-//
-// template < class iter_type >
-// void store ( const mc_ele_v & ev , // simdized value
-// iter_type & target_iter ) const // iterator to store values
-// {
-// value_chunk_type value_chunk ;
-//
-// store ( ev , (value_type*) (&value_chunk) ) ;
-//
-// for ( int i = 0 ; i < vsize ; i++ )
-// {
-// *target_iter = value_chunk[i] ;
-// target_iter++ ;
-// }
-// } ;
-//
-// template < class src_iter_type , class trg_iter_type >
-// void iter_eval ( src_iter_type & src_iter ,
-// trg_iter_type & trg_iter ) const
-// {
-// nd_rc_v cv ;
-// mc_ele_v ev ;
-//
-// load ( src_iter , cv ) ;
-// eval ( cv , ev ) ;
-// store ( ev , trg_iter ) ;
-// } ;
-//
-// template < class trg_iter_type >
-// void iter_eval ( const nd_rc_v & cv , // simdized coordinate
-// trg_iter_type & trg_iter ) const
-// {
-// mc_ele_v ev ;
-//
-// eval ( cv , ev ) ;
-// store ( ev , trg_iter ) ;
-// } ;
-//
-// template < class src_iter_type >
-// void iter_eval ( src_iter_type & src_iter ,
-// mc_ele_v & result ) const // simdized result
-// {
-// nd_rc_v cv ;
-//
-// load ( src_iter , cv ) ;
-// eval ( cv , result ) ;
-// } ;
-
-#endif
-
-} ;
-
-/// since we use the types in class interpolator frequently, there are
-/// macros to pull all the types of class interpolator into a class derived
-/// from it. classes which want to use these macros need to invoke them
-/// with the base class as their argument.
-/// for unverctorized operation we have:
-
-#define using_singular_interpolator_types(base_type) \
- using typename base_type::ic_type ; \
- using typename base_type::rc_type ; \
- using typename base_type::nd_ic_type ; \
- using typename base_type::nd_rc_type ; \
- using typename base_type::value_type ; \
- using typename base_type::ele_type ; \
- enum { dimension = base_type::dimension } ; \
- enum { level = dimension - 1 } ; \
- enum { channels = base_type::channels } ; \
- using base_type::operator() ;
-
-/// for vectorized operation there are a few more types to pull in, and we also
-/// pull in those eval variants which aren't pure virtual in the base class
-/// with a using declaration.
-
-#define using_simdized_interpolator_types(base_type) \
- using typename base_type::ele_v ; \
- using typename base_type::ic_v ; \
- using typename base_type::rc_v ; \
- using typename base_type::mc_ic_v ; \
- using typename base_type::nd_ic_v ; \
- using typename base_type::nd_rc_v ; \
- using typename base_type::mc_ele_v ; \
- using base_type::broadcast_eval ; \
- using base_type::eval ;
-
-/// finally a macro automatically pulling in the proper set of type names
-/// depending on USE_VC. This is the macro used throughout. Here, vsize is also
-/// fixed to tha base class' value - or to 1 if USE_VC isn't defined.
-
-#ifdef USE_VC
-#define using_interpolator_types(base_type) \
- enum { vsize = base_type::vsize } ; \
- using_singular_interpolator_types(base_type) \
- using_simdized_interpolator_types(base_type)
-#else
-#define using_interpolator_types(base_type) \
- enum { vsize = 1 } ; \
- using_singular_interpolator_types(base_type)
-#endif
-
-} ; // end of namespace vspline
-
-#endif // VSPLINE_INTERPOLATOR_H
-
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/vspline.git
More information about the debian-science-commits
mailing list