If I get floats from $somewhere, I might want to index them into a hash data structure without creating a huge sparse array.

If you assume float numbers have "identity" such that, whatever the precision, "x == x" always holds (other than NaN), then this is a perfectly valid thing to want.

I'm struggling to think of a valid use case where there is no better alternative.

Any design utilizing this language "feature" seems masochistic and begging to get sliced by sheet metal edges.

A hash table of floating-point values can be used for, say, memoizing a function whose argument (or arguments) are floating-point.

A compiler could use a floating-point-keyed hash table for deduplicating identical floating-point constants. Say that constants are stored in some static area, and referenced by address: it's wasteful to repeat those constants. Some constant defining mechanisms (like #define in C) proliferate copies of a constant as a repeated subexpression.

But IEEE754 allows not only NaNs, but also "negative zero" and denormals. Floating-point numbers, in other words, allow for multiple different bit-encodings that represent mathematically equal, but not identical, number values. There are non-canonical forms of the "same" numbers. And programming-language runtimes don't do anything to prevent CPUs from returning these non-canonical numbers; nor do they massage them back into canonical forms upon receiving them. They just end up blindly holding these non-canonical numbers — numbers which, if they ask the CPU if they're equal, they are; but if they look at the bit-patterns and compare those for equality, they're not.

> A compiler could use a floating-point-keyed hash table for deduplicating identical floating-point constants.

Bad example. A compiler wouldn't want a hash table whose key type is a floating-point number, because that would imply that the hash table is operating using IEEE754 definition of equality via-a-vis key presence collision checking.

Rather, a compiler would use a bitstring key type, where the keys are the bit patterns representing either the target ISA's native FP-register encodings of the given floating-point numbers; or the abstract/formal bit-packed form of those floating-point numbers according to IEEE754.

The difference between the two is that the latter uses bitstring collation (ordering and equality), not floating-point collation.

Unicore strings also have normalization forms. Not to make an argument, just a reminder.

IEEE754 floats (and doubles) are kind of unique among scalar types, in that the answer to "are these equal" in pretty much every programming language is delegated directly to the CPU to answer; and, in obeying IEEE754 semantics, the CPU's definition of equality for FP numbers makes things equal that aren't bit-representation-equal.

Why would you ever want a number to be stored in a floating point format - that is a much better question.

Most of our numeric values don’t even correspond to the domain of floating point. For business and programming goals, -0 is a complete technical nonsense. NaN too, it should just raise an exception (there are quiet and signalling nans, everyone defaults to quiet). And so should non-low-level integer overflow, really, unless there is a software fallback. Intermediate calculations limited to a low fixed number of digits is nonsense. Accounting for constant rounding/formatting errors is also a nuisance.

Builtin, first class citizen, hardware enabled, base 10 fixed point could be the answer. But there’s almost always either bigint-only which is barely used even in a standard library, or a serious performance hit which nobody wants. There would still be issues, but much less in practice.

Floating point is a niche type suitable for “multimedia”, NNs and maybe few other special contexts. They are the default only because everyone on the hardware..runtime spectrum traditionally believes that ordinary numbers are not their responsibility.

IEEE floating points are 32 bit / 64 bit, so it's not in principle any more insane than using (u)int32 / (u)int64 as keys. It's not like the key space is unbounded or even hard to estimate - it's just not a common thing to see in the wild, and I guess most devs rarely have a reason to consider how many values fit between two floating point numbers.

One possible answer: you're in Javascript or something similar. You wanted integer keys, but all you have is floating-point numbers.

Another one which probably shouldn't exist is a map with boolean keys.

Edit: It might be nice if a language compiler detects such bastardizations and spits out a proposal for a better alternative structure or approach, perhaps even stubbornly refusing to proceed to compile such a shitty idea.

Golang already kind of does a spiritual form of this by disallowing unused variables.

This would undoubtedly be similarly controversial. Ego ruins all.

Because it's a cache and you didn't specifically handle that edge case.

> it's generally difficult to get the same exact result every time on every system, due to rounding errors

Floating point arithmetic is 100% entirely deterministic - you don't just get different values randomly.

  map = new Map();
  map[1] = 3;
  map[1]; // 3
  map[1.2] = 3.4;
  map[1.2]; // 3.4
  typeof(map.keys().next().value); // "number"

But in general, using float keys does work - but can fail in unexpected ways due to rounding errors. E.g.:

  m = new Map();
  m.set(0.3, "foo");  // --> Map { 0.3 → "foo" }
  m.get(0.3); // --> "foo"
  m.get(0.1 + 0.2);  // --> undefined 

So using float keys which are derived from calculations and may contain non-integer numbers is a bad idea, because unless you have very good knowledge about floating point math, you can not easily predict what exact value the result of a calculation will be.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://stackoverflow.com/questions/8503157/ieee-754-floatin...

But isn't this still a map that has float and integer keys? Why doesn't it count?

Every object in JS has basic map functionality. Since version 1 of the language, you could always write things like:

  var o = new Object();
  o["foo"] = "bar";
  o["foo"] // --> "bar"

The problem is, Maps are also objects, so they still inherit the "old" map functionality in addition to the new functionality. Those two systems are completely independent, even though they act on the same object. So writing

  mymap["foo"] = 1

  mymap.set("foo", 1)

You can see it when trying to retrieve the value again:

  mymap["foo"] = 1
  mymap["foo"]; // --> 1
  mymap.get("foo"); // --> undefined

  mymap.set("bar", 1);
  mymap.get("bar"); // --> 1
  mymap["bar"]; // --> undefined

  map = new Map();
  map.set(1.2, 3.4);
  log(typeof(map.keys().next().value));

I think the GP was wrong there. JS maps absolutely do support float keys, it's just generally a bad idea to use them if you don't restrict yourself to integers.

    const object = {}
    object[1] = 3

    console.log(object["1"]) // 3
    for (const key in object) {
      console.log(typeof key) // "string"
    }

But object property names cannot be floats (which is what your example was, despite them being properties of a Map object).

JavaScript maps absolutely can use numbers (or any type) as keys, but that's not how its API works. Square brackets access object properties, but map entries are not stored like that, and that last `typeof` is `"undefined"` in every runtime I tried (not `"number"`). Try `map['set']` to see another example.

Here's what I think you meant:

    const map = new Map();
    map.set(1, 3);
    map.get(1); // 3
    map.set(1.2, 3.4);
    map.get(1.2); // 3.4
    typeof map.keys().next().value; // "number"

How do you explain this?

    const map = new Map();
    map.set(1, 3);
    map.get(1); // 3
    map.set(1.2, 3.4);
    map.get(1.2); // 3.4
    typeof map.keys().next().value; // "number"

Read the spec - it supports primitives for keys and it doesn’t stringing them. As others have said in this thread - you’re just wrong.