Re: How should unordered_map be used correctly ... ?
On Dec 20, 10:14 pm, mast4as <mast...@yahoo.com> wrote:
struct hashfunc {
size_t operator() (const point &pt) const { printf("in here\n");
return 541 * pt.x + 79 * pt.y + 31 * pt.z; }
};
Not too sure that this is a good hash function. (In fact, I'm
fairly sure it isn't, in general.) But generating a good hash
function for floating point values is a bit tricky. What sort
of values do x, y and z take on?
Oh so last question then. I remap the float values to integer but they
are signed ones. So what happens in that case if the returned value is
an unsigned int. Will it work or do I need to get x, y z as unsigned
integers ? In the current version of the code I have it seems to work
with integer. So even when z y or z are negative they seem to be
properly inserted in the table. I don't know why (technically) but
practically it does ;-)))
Interesting question; I had to look it up: when converting
a floating point type to an integral type, the conversion
truncates (rounds to zero); the behavior is undefined if the
resulting value cannot be represented in the target type. So
formally, if the destination type is unsigned, the behavior is
undefined.
Practically, converting a signed integral type to an unsigned is
always defined (the results are modulo 2^n, where n is the
number of bits), and I suspect that most implementations actually
applie the same rules, or something similar, for converting
float to integral type. If you want to be sure, however,
convert first to int, then to size_t.
If your floating point expression results in absolute values
larger than the max of a size_t, you will likely have problems.
(IIRC, your x, y and z were in the range of -50...50, so this
shouldn't be a problem in your case. It would be if they could
take on any real values.)
--
James Kanze