# itk::NeighborhoodRange: a new class for efficient modern C++ style iteration

**URL:** https://discourse.itk.org/t/itk-neighborhoodrange-a-new-class-for-efficient-modern-c-style-iteration/833
**Category:** Engineering
**Created:** [April 10, 2018, 7:37pm UTC](https://discourse.itk.org/t/itk-neighborhoodrange-a-new-class-for-efficient-modern-c-style-iteration/833 "2018-04-10T19:37:56Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)
#### Post date: [April 14, 2018, 3:13pm UTC](https://discourse.itk.org/t/itk-neighborhoodrange-a-new-class-for-efficient-modern-c-style-iteration/833/11 "2018-04-14T15:13:05Z")

</div>

`NeighborhoodOffsets.h` sounds good to me!.

The name `GenerateOffsetsForRectangularNeighborhood`, might be misleading, because the offsets could be Cubic if `Size` is 3D. Or lines if Size\<1\>.  
I would recommend the more formal `GenerateHyperRectangleOffsets`, or `GenerateNRectangleOffsets`?

GenerateNCrossOffsets(radius), for one pixel wide Greek cross (`+`), with the lengths of the cross taken from radius?

I would put there:

```auto
Generate3D26TopologyOffsets,
 equivalent to GenerateOffsetsForRectangularNeighborhood<Size<3>>({1,1,1}) 
with the index {0} removed.

Generate3D18TopologyOffsets
removing {0} and all indices with
 std::inner_product(indice.begin(), indice.end(), indice.begin(), 0) == 3, 
or putting other way, all indices in the corners of the cube removed.

Generate3D6TopologyOffsets,
 equivalent to GenerateNCrossOffsets<Size<3>>)({1,1,1}) with index {0} removed. 

Generate2D8Topology
 GenerateOffsetsForRectangularNeighborhood<Size<2>>({1,1}) with the index {0} removed.

Generate2D4Topology
equivalent to GenerateNCrossOffsets<Size<2>>)({1,1}) with index {0} removed. 

```

Or maybe easier to just hard-code the relative indices, but I am concerned about the order of the indices:

For example, in the case of the Gaussian that you use.

```auto
    for (const TOutput kernelValue : operatorNeighborhood.GetBufferReference())
    {
      result += kernelValue * (*neighborhoodRangeIterator);
      ++neighborhoodRangeIterator;
    }

```

There, the indices of `neighborhoodRangeIterator` has the same order than the `Buffer` of the `operatorNeighborhood`, because you coded `GenerateOffsetsForRectangularNeighborhood` generating the offsets in the same order than the buffer. What about when a user puts indices at random order? Shouldn’t we provide a helper function to order them in the same way than Buffer is ordered if that is the standard?

Good stuff!

---

_[View the full topic](https://discourse.itk.org/t/itk-neighborhoodrange-a-new-class-for-efficient-modern-c-style-iteration/833)._