7 ms·

Java has a specific hack for this which I discovered by accident a few years ago. Normally, given (primitive) double values d0 and d1, then boxing them does no

• bobbylarrybobby 4y ago
  Using floats as hash keys is insane, no?
  • metadat 4y ago
    Yes, why would you ever want a map with floating point keys? 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.
    • masklinn 4y ago
      > Yes, why would you ever want a map with floating point keys? Because it's a cache and you didn't specifically handle that edge case.
      • malcolmgreaves 4y ago
        I don't know what precisely the poster meant. However, from my perspective, I see it as a simpler design to explicitly hash float values into keys.
        • masklinn 4y ago
          That... still requires the foresight to see that edge case, and being in a situation where you're not colliding your float hashes with random integers?
        • kazinator 4y ago
          Externally hashing outside of the hash table requires you to take on ugly complications. What if two distinct floating point keys map to the same key? The values of your hash table then have to be lists or arrays so you can keep all colliding entries. You've then wastefully built chained hashing around a hash table!
          • metadat 4y ago
            The same approach I suggested elsewhere in this thread will work for this case, too. Convert floats to their string representations and key off that. Equality ambiguity problem solved.
    • kazinator 4y ago
      > Yes, why would you ever want a map with floating point keys? One possible answer: you're in Javascript or something similar. You wanted integer keys, but all you have is floating-point numbers.
      • metadat 4y ago
        Or.. convert the integers to string form and use that. Wacky nonsense situation averted.
    • kazinator 4y ago
      Say I'm in a dynamic language and have a dictionary in which an object of any type whatsoever can be a key. Why would I arbitrarily disallow floating-point objects, if a character, string, lexical closure, database connection, file handle, ..., or lists or arrays of these can all be hash keys. 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.
      • derefr 4y ago
        Because all those other things are either identity types (handles, closures, etc) or are value types where the only possible way to represent them is with a single "canonical form." 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.
        • wruza 4y ago
    • yakaccount4 4y ago
      I agree. There are several instances of "valid" keys nobody should use.
      • metadat 4y ago
        100% with you bud. 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.
    • TeMPOraL 4y ago
      Memoizing computations for which you know the input(s) come from a small range of numbers? 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.
    • wruza 4y ago
      Having a generic container that handles all types of values except one only for policy reasons is rarely a good idea. If floating point instabilities should be a concern (yes), then not at the Map level. That would be a naive crutch. 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.
  • vbezhenar 4y ago
    No. JavaScript does that all the time.
    • easrng 4y ago
      JavaScript actually converts all non-Symbol keys to strings.
    • ithkuil 4y ago
      (Because JS has no integers)
      • yawaramin 4y ago
        That used to be the case but JavaScript has BigIntegers now.
    • pclmulqdq 4y ago
      Yet another reason not to do it. Still, if your floats are always integers under a certain size, it works fine to use floats as hash table keys.
  • chrisseaton 4y ago
    It's done all the time in JavaScript. Why not in Java?
    • xg15 4y ago
      I'm surprised this is done in JS. If you're doing any kind of calculation with floats (and use actual non-integer numbers, not just ints stored as floats) then it's generally difficult to get the same exact result every time on every system, due to rounding errors. That's why to my knowledge, any strict equality check on floats is generally frowned upon. (exceptions: you know all the floats are actually non-huge ints; You're comparing with a value the variable was explicitly set to at some time before)
      • chrisseaton 4y ago
        JavaScript conceptually only has floats (ignoring big integers, which isn't what most people use for numbers), so any map of numbers to values is using a float key. You refer to that, but yeah they're all floats. > 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.
        • cookiengineer 4y ago
          This is so wrong ECMAScript does not have maps where keys can be integers and neither can keys be floats. Everything is a pointer to a value, and otherwise reflected with a symbol or string (which in return is a unique symbol). An object doesn't have object[1] because it is actually object[reference("1")] This way boxing and unboxing of arrays is much cheaper, due to the arrays not needing a resizing of their cells once datatypes change. (TypedArrays are optimized in a different manner, but we are speaking about the NaN use case, which implies either an Array or Object) There are dozens of talks about e.g. v8's hidden classes on youtube that show up this very mechanism. No idea where you got that float keys idea from.
          • 4y ago
  • bushbaba 4y ago
    Not if you’re hash table is designed to accommodate key conflicts, and the float is deterministic.
    • deleted 4y ago
      [deleted]
  • zbentley 4y ago
    Not at all. 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.
    • makapuf 4y ago
      I understand your point, but really floats are not reals and we should test for equality of a float+precision.
• xg15 4y ago
  Note that the contract for the equals() method requires that the method always returns true when called on itself. So the designers had to decide whether to break the contract on NaN or the contract on equals(). I could imagine that honoring equals() was the solution with the least expected breakage with downstream users.