strictly weak ordering of i,j,k coordinates

Hi,

for my stdext::hash_map I have to implement a operator for strictly weak
ordering of my key_values which are are i,j,k coordinates which identify cells of a dynamic cell-grid.

How can I order them? Ive tried it very hard but all attempts failed so far and
gave bad results.

Here is the codebase for the problem:

struct Coordinate
{
int i,j,k;
}

class hash_compare : public stdext::hash_compare<Coordinate>
{
public:
// hash function
size_t operator() (const Coordinate& key) const
{
// hash function proposed in [Worley 1996]
return 541*key.i + 79*key.j + 31*key.k;
}

// strictly weak ordering as requested by msdn
bool operator() (const Coordinate& lhs, const Coordinate& rhs) const
{
// HERE IS THE PROBLEM: my current method is bad, since it does not conform to the strictly weak ordering rules
return (lhs.i + lhs.j + lhs.k)<(rhs.i + rhs.j + rhs.k);
}
};

// the hashtable itsself
stdext::hash_map<Coordinate, Cell, hash_compare> gridCells;

I ask because Im afraid that such ordering of i,j,k coordinates is not possible without some additional
helper variables (gridResolutionX, gridResolutionY, gridResolutionZ) which help in mapping the coordinates
onto a linear sequence. But the usage of such helper variables would destroy the purpose of a dynamic grid
and therefore the usage of a hash_map.

Thanks in advance for your help.
dave
[1602 byte] By [skydave] at [2007-11-20 11:42:37]
# 1 Re: strictly weak ordering of i,j,k coordinates
You seem to be trying to accomplish two mutually exclusive goals. If you want a strictly weak mapping (into a linear space), then you MUST know the bounds.

Consider a 3x3 where L=x*3+y, and a 4x4 where L=x*4+y. Obviously there is NO solution for (L1==L2) && (X1==X2) && (Y1==Y2). You can find a solution for any TWO parameters matching, but will (by definition) have a mis-matched third parameter.

I would suggest stepping back from the IMPLEMETATION, and start looking at the actual ARCHITECTURE. What EXACTLY are you trying to accomplish?
TheCPUWizard at 2007-11-10 22:24:24 >
# 2 Re: strictly weak ordering of i,j,k coordinates
Thanks for your reply, wizard of the cpu.

Basicly I need a grid of cells for an algorithm I want to implement.
But instead of a fixed-sized array I want that grid to be dynamic.

So instead of:

#define GRIDRESOLUTIONX 999999
#define GRIDRESOLUTIONY 999999
#define GRIDRESOLUTIONZ 999999

struct Cell
{
};

Cell gridCells[ GRIDRESOLUTIONX*GRIDRESOLUTIONY*GRIDRESOLUTIONZ ];

I want a hashtable which associates Coordinates (i,j,k) to Cells. That is because:
1. the algorithm only works on a rather small number of cells within that grid and
2. the algorithm should not be bound to a special region (which would be the case when using the fixed method)

As far as I see it is a weak point of the way the stdext::hash_map is designed. From my current point of view the
stdext::hash_map cant be used when the keys can not be ordered strictly weak.
But that condition(being able to order the keys) is not a k.o.-criteria for hash-maps in general.
Or do I miss something here?

Please keep on posting. Many thanks!
dave

P.S.: Its not clear to me why the stdext::hash_map uses ordering at all.
I see that a hash_map has to test 2 keys for equality, and that this is implicitly done with the
ordering operator (key1 == key2 <=> !(key1<key2)&&!(key2<key1) ).
The designer of the template wanted to safe the developer from having to
supply an additional operator to the template traits. But why order the keys?
skydave at 2007-11-10 22:25:29 >
# 3 Re: strictly weak ordering of i,j,k coordinates
Solved:

The solution is to do lexicographical ordering. We know this from ordering strings,
but the idea can be generalized. So in fact the coordinate i,j,k is a
string of size 3 where each literal is not of type char, but int.

However, I still dont like stdext::hash_map.

bye,
dave.
skydave at 2007-11-10 22:26:33 >
# 4 Re: strictly weak ordering of i,j,k coordinates
Dave,

that will only work IF the bounds of the array are such that
(sizeof(xDim) +sizeof(yDim) + sizeof(zDim)) < sizeof(hashKey).

For a 32 bit hash key, this effectively limits the bounds to 2^10 (1024) for a cube.

Therefore you are back to a bounded (a form of fixed) dimensions.
TheCPUWizard at 2007-11-10 22:27:32 >
# 5 Re: strictly weak ordering of i,j,k coordinates
Thanks for pointing this out! - Ill definitely have to keep that in mind. Maybe I will rethink my strategy...

I wish a nice week.
bye
skydave at 2007-11-10 22:28:31 >