4 ms·

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 util

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.

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.