Shoud we adhere to CUDA's confusing use of "index" and "id"? #50
Labels
question
Further information is requested
Comments
|
@codecircuit : Question for you as well. |
|
Sticking to #1 for now - which means a bunch of changes to our current code. |
eyalroz
pushed a commit
that referenced
this issue
Mar 16, 2020
* `grid_info` methods with the word `index` in them now return positions - where applicable, in a multi-dimensional grid; * `grid_info` methods with the word `id` in them now return single values - where applicable, linearizations of multi-dimension positions. * Added a specific inclusing of `grid_info.cuh` where it was being made implicitly, in a few places. * Added: comment explaining the index <-> distinction for grid_info functions. * Using unsigned in the `dimensions_t` class and the return values of some grid_info functions which were returning `size_t` * Added: Dimensionality-templatized functions for working with 3-D structures when they actually contain only effectively-lower-dimensionality information: `size()`, `equals()` and `less_than()`. * Added: `position_t`, an alias for uint3 used for positions within a grid or a block. Note: _not_ the same as `dimensions_t` * Split off some general-grid and linear-grid versions of functions,which need to differ.
Closed
|
Personally I stick to 2. I think it is not intuitive to call a multi dimensional object an "index". With indices I associate something linear. But sometimes I name index variables |
|
@codecircuit : Other people I asked have mostly told me the detriment of 2 would exceed the benefit - unless I expect people to only use my grid_info code, not read about indices and id's in the CUDA documentations and be generally isolated from the switched semantics. ... which is not what's going to happen. |
|
I agree with you. Point 1. makes more sense here. |
eyalroz
pushed a commit
that referenced
this issue
Mar 25, 2020
* `grid_info` methods with the word `index` in them now return positions - where applicable, in a multi-dimensional grid; * `grid_info` methods with the word `id` in them now return single values - where applicable, linearizations of multi-dimension positions. * Added a specific inclusing of `grid_info.cuh` where it was being made implicitly, in a few places. * Added: comment explaining the index <-> distinction for grid_info functions. * Using unsigned in the `dimensions_t` class and the return values of some grid_info functions which were returning `size_t` * Added: Dimensionality-templatized functions for working with 3-D structures when they actually contain only effectively-lower-dimensionality information: `size()`, `equals()` and `less_than()`. * Added: `position_t`, an alias for uint3 used for positions within a grid or a block. Note: _not_ the same as `dimensions_t` * Split off some general-grid and linear-grid versions of functions,which need to differ.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An index is either a "list of items" arranged in order, or "a number... used as an indicator or measure", or "a number ... associated with another to indicate... position in an arrangement".
An id is an identification, or " a document bearing identifying information".
So, if we have an item in a 3D block, the triplet of coordinates in each axes is - literally - that item's 'id' not its 'index'. If anything, it is its position in a linearization of that grid that could be considered its 'index'.
... Unfortunately, CUDA defines this exactly backwards: The 'index' in CUDA is the 3-dimensional entity, and the 'id' is the number.
Currently, in my code, I'm making a bit of a mess of these two conceptions. I'm going to sort that out, but the question is how?
_index()functions in grid_info to returnuint3's anddimensions_t's.What do you think?
The text was updated successfully, but these errors were encountered: