This would be useful for special cases (+Inf, -Inf, NaN), but would require significant reworking to be useful in general.
We all know that equal comparisons on floating point values are very dangerous, so specific values should probably not be entered in the typical case. The idea would seem to have some usefulness for ranges, but the syntax would need to change, because we need to be able to define for each edge value of a range if it is included or excluded.
for example if we have two cases with ranges: [-0.5..0.5] and [0.5..1.5], we need to be able to define which of the two cases executes if the value is exactly 0.5.
So the exact value 0.5 would be included in the second case and excluded from the first. You could even exclude it from both cases and have a special case for 0.5.
This is deliberately not implemented. The Case Structure admits only ordinal data types. Supporting NaN can't really be done because the Case Structure is, by definition, testing for equality to its given value, and all values say FALSE when compared to NaN, including NaN. Using the Case Structure syntax for that special case would be a significant abuse of the structure, and would be really strange if we started allowing composite cases like "Inf, NaN".
The special case of Inf and -Inf could be handled, but would leave a rather weird hole in that people would be constantly asking why they can't check for zero or one or any other special value. And we would not do the other values. Exact matches on floating point values should nearly always be checked with an epsilon value if they come from any sort of computation. Floating point ranges need to be checked in an always ascending way, requiring an ordering to the case structure frames that we currently do not mandate for any data type. That would be a significant change in the usage patterns of the case structure, turning it from a switch function to more of an "if-then-else-if" structure.
As much as you might say, "Oh, it's obvious how the case structure would work in such and such a case..." the non-ordinal types have many caveat cases and are not amenable to the switch-like nature of the Case Structure. No other programming language that I can point to would admit the floating point types to a switch structure. I cannot see LabVIEW being the first to do that. It just isn't mathematically sound.
Now, having said all that, introducing a completely new structure node specifically for handling floating point numbers could be viable. The syntax we would use for its case frames would be somewhat different, and the UX would be different since the order of the case frames would matter. Brainstorms along those lines could be worthwhile.
Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-should-accept-the-DBL-values-as-a-case/...