float as a key in std::map

[S__B]

Both have their advantages and disadvantages.

The advantage of using coordinates is that it results in a unique ordering. The disadvantage to it is that the order of your nodes can change drastically if one of them is moved even just a little bit.

The advantage of using vector length is that it uses an actual mathematical/physical value, which is the Euclidean Norm (although almost any 3D norm will do). An advantage to doing this is that for starters, it makes sense by looking at a graph which nodes are order before what other nodes, and the ordering is more robust to tiny changes in point positions.

I don't think this would work, as infinitely many points on "the sphere" will have the same key. So in the end the "find" will be indeterminate.

[Lindley]

Well, you could always make vector length the "primary" key and resolve equality using theta (polar coordinates).

[Paul McKenzie]

I strongly want support what Paul has said. Floating point numbers are not suitable for being used as keys. The 'same' mathematical value can be represented with different bits and cannot be found anymore in the map, e. g. value 12 can be represented as 12.000000000... or as 11.9999999999... (even in math) depending on statements like x = 12. or x = sqrt(144); .

For the 3D coordinates you probably have equidistant values (if not, how would you ever expect to find a point again?). Then, you easily can substitute the floats by integers by counting the steps, thus avoiding any of the issues discussed here.

The bottom line to all of this is by whatever means necessary, by hook or by crook, get out of using floating point values for lookups, counters, etc. and use something consistent that will work (if given the same data) all the time, on every compiler, no matter what compiler options are selected. I had a link to a PDF document, where a complex problem was described that was initially coded using floating point values, and it went through the steps of how they eventually solved the problem using integral values. The solution was not obvious, but it was possible. Wish I had it with me, but unfortunately, I don't have the URL right now.

I'm sure that many code reviewers would reject outright any usage of doubles as keys, unless that double can be normalized (and consistently normalized) to a proper integral key or value. How the normalization is done is what we're being paid for (if we are being paid to do it) -- it's our job to figure these things out. It may be easy or difficult, but it has to be done and honestly, should have been part of the design phase from the start.

I mention the debugging, because I can't imagine myself sitting there with an app that uses floating point this way, and then get a phone call or an email from customer support saying that they have someone who is getting strange and/or inconsistent results. Then what? It's either going to be some sort of patch fix (once you find out what the exact data the person is using, and that may take a while figuring that out), or you have to scrap the whole idea and go back to rethinking how to accomplish what you're trying to do.

Regards,

Paul McKenzie

[JohnW@Wessex]

I had a link to a PDF document, where a complex problem was described that was initially coded using floating point values, and it went through the steps of how they eventually solved the problem using integral values.

The Bresenham line algorithm is a good example of replacing floating point calculations with integers.

http://en.wikipedia.org/wiki/Bresenh...line_algorithm