Case structure should accept the DBL values as a case

[Anagha.G]

I  am not very experienced in LabVIEW but i faced a problem while giving a DBL value (representation of numeric) to a case structure. I dont know why it did not accept the values like 1.1, 1.221 etc.and gave the error "selector values have wrong types" .

 So I think case structure should accept the DBL representation of numeric at least upto some digits after decimal point.

[X.]

It makes sense that it is not allowed when you realize that you are shooting yourself in the foot if you write codes that tests for a specific DBL (or SGL, EXT, complex, etc) value, due to the finite precision of floating point computation (and data representation). In other words, 1/3 is not equal to 0.333333333 (etc) but a machine specific value that you just could not type in into your case structure, as you are requesting. I am taking the example of one third, but any other value applies. If you are looking for a specific floating point result, you should be very careful to rather test for a difference less than a specified epsilon. You could use the machine epsilon, which is a constant you can find in the Numeric palette, but usually, a fraction -say 10E-9 times your value- of the final result is just as good for that purpose.

[AristosQueue (NI)]

X is correct. Floating point comparison is a bad idea in any programming language -- lots of articles online about why this is bad in C++, C#, etc. LabVIEW's case structure works only on ordinal types. The correct pattern of usage is for you to write your own test that takes into account precision and outputs an integer (or, more preferably, an enum) that corresponds to the region the double falls into, and then use the case structure to choose what to do based on the value of that integer (or enum).

[smercurio_fc]

Somebody owes me a another nickel in my retirement fund.

[Darin.K]

I think the floating point comparison argument is pretty weak in this particular case. The underlying issue is the default inclusiveness of the values of the selector. For integers it is easy to specify 1..3,4..6. For integers all value 1..6 are included, for floats there is a hole between 3 and 4. You would have to write 1..3,3.00000001..6. Of course there is still a gap. Strings pose the same problem, that is why the rules are different there. First I would like a choice to specify inclusiveness of a case using [) notation, then floats could be handled easily, for example [1..3],(3..6]. If you insist on handling floating point precision explicitly, by all means do it outside the case, for the 95+% of the times a simple comparison suffices then I think the compact notation of the Case structure is an improvement.

[GregSands]

I agree with Darin.K's comments that this could be useful for floating point ranges - in fact if implemented I would suggest it only works for ranges, and the [) notation is easy to follow.  It would be equivalent to using multiple "In Range and Coerce" functions, without the coerce, and with compile-time checking for non-overlapping ranges.

I guess you could though have a range like [1..1], which would check that the value was within eps of 1.  Perhaps instead of just saying the f.p. comparison is bad, LabVIEW should provide tools that make it easy to do it right.  So kudos from me, with these qualifications.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.